DayX & NBI Metrics

## Understanding Day-1 and Day-2 Operations

TODO: Page in elaboration. Meanwhile, you can find a good explanation and examples [in this presentation](http://osm-download.etsi.org/ftp/osm-6.0-six/8th-hackfest/presentations/8th%20OSM%20Hackfest%20-%20Session%207.1%20-%20Introduction%20to%20Proxy%20Charms.pdf)

VNF configuration is done in three "days":

- Day-0: The machine gets ready to be managed (e.g. import ssh-keys, create users/pass, network configuration, etc.)

- Day-1: The machine gets configured for providing services (e.g.: Install packages, edit config files, execute commands, etc.)

- Day-2: The machine configuration and management is updated (e.g.: Do on-demand actions, like dump logs, backup databases, update users etc.)

In OSM, Day-0 is usually covered by cloud-init, as it just implies basic configurations.

Day-1 and Day-2 are both managed by the VCA (VNF Configuration & Abstraction) module, which consists of a Juju Controller that interacts with VNFs through "charms", a generic set of scripts for deploying and operating software which can be adapted to any use case.

There are two types of charms:

- Native charms: the set of scripts run inside the VNF components. This kind of charms are new in Release 7.

- Proxy charms: the set of scripts run in LXC containers in an OSM-managed machine (which could be where OSM resides), which use ssh or other methods to get into the VNF instances and configure them.

![OSM Proxy Charms](assets/800px-Osm_proxycharms.png)

These charms can run with three scopes:

- VDU: running a per-vdu charm, with individual actions for each.

- VNF: running globally for the VNF, for the management VDU that represents it.

- NS: running for the whole NS, after VNFs have been configured, to handle interactions between them.

For detailed instructions on how to add cloud-init or charms to your VNF, visit the following references:

- [VNF Onboarding Guidelines, Day-0](http://osm-download.etsi.org/ftp/Documentation/vnf-onboarding-guidelines/#!02-day0.md)

- [VNF Onboarding Guidelines, Day-1](http://osm-download.etsi.org/ftp/Documentation/vnf-onboarding-guidelines/#!03-day1.md)

- [VNF Onboarding Guidelines, Day-2](http://osm-download.etsi.org/ftp/Documentation/vnf-onboarding-guidelines/#!04-day2.md)

Furthermore, you can find a good explanation and examples [in this presentation](http://osm-download.etsi.org/ftp/osm-6.0-six/8th-hackfest/presentations/8th%20OSM%20Hackfest%20-%20Session%207.1%20-%20Introduction%20to%20Proxy%20Charms.pdf)

## Monitoring and autoscaling

|OSM Projects|Project-scoped|

|OSM Network Services|NS-scoped sample dashboard|

##### 3) Interacting with Prometheus directly through its API

##### 3) Querying metrics through OSM SOL005-based NBI

For collecting metrics through the NBI, the following URL should be used:

```bash

https://<host-ip>:<nbi-port>/osm/nspm/v1/pm_jobs/<project-id>/reports/<network-service-id>

Where:

   <host-ip>: Is the machine where OSM is installed.

   <nbi-port>: The NBI port, i.e. 9999

   <project-id> : Currently it can be any string.

   <network-service-id>: It is the NS ID got after instantiation of network service.

```

Please note that a token should be obtained first in order to query a metric. More information on this can be found in the [OSM NBI Documentation](12-osm-nbi.md)

In response, you would get a list of the available VNF metrics, for example:

```yaml

   performanceMetric: osm_cpu_utilization

   performanceValue:

       performanceValue:

           performanceValue: '0.9563615332000001'

           vduName: test_fet7912-2-ubuntuvnf2vdu1-1

           vnfMemberIndex: '2'

       timestamp: 1568977549.065

```

##### 4) Interacting with Prometheus directly through its API

The [Prometheus HTTP API](https://prometheus.io/docs/prometheus/latest/querying/api/) is always directly available to gather any metrics. A couple of examples are shown below:

Further examples and API calls can be found at the [Prometheus HTTP API documentation](https://prometheus.io/docs/prometheus/latest/querying/api/).

##### 4) Interacting directly with MON Collector

##### 5) Interacting directly with MON Collector

The way Prometheus TSDB stores metrics is by querying Prometheus 'exporters' periodically, which are set as 'targets'. Exporters expose current metrics in a specific format that Prometheus can understand, more information can be found [here](https://prometheus.io/docs/instrumenting/exporters/)

Please note that as long as the Prometheus container is up, it will continue retrieving and storing metrics in addition to any other tool/DB you connect to `mon-exporter`.

##### 5) Using your own TSDB

##### 6) Using your own TSDB

OSM MON integrates Prometheus through a plugin/backend model, so if desired, other backends can be developed. If interested in contributing with such option, you can ask for details at our Slack #service-assurance channel or through the OSM Tech mailing list.

TODO: Include SOL005-based metric collection.

### Fault Management

Reference diagram: