diff --git a/05-osm-usage.md b/05-osm-usage.md index 8fa1986b1ba33c233dc95a4a90115342814778f6..510fc132a9631535e53b914be8ed89fc8685ff3a 100644 --- a/05-osm-usage.md +++ b/05-osm-usage.md @@ -282,7 +282,36 @@ And they can be provided with: ## 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 @@ -522,7 +551,36 @@ Starting in Release 7, Grafana Dashboards are created by default in OSM. This is |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://:/osm/nspm/v1/pm_jobs//reports/ + +Where: + + : Is the machine where OSM is installed. + : The NBI port, i.e. 9999 + : Currently it can be any string. + : 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: @@ -540,7 +598,7 @@ curl 'http://localhost:9091/api/v1/query?query=osm_cpu_utilization&time=2018-12- 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/) @@ -568,12 +626,10 @@ curl localhost:8000 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: diff --git a/assets/800px-OSM_proxycharms.png b/assets/800px-OSM_proxycharms.png new file mode 100644 index 0000000000000000000000000000000000000000..84409b07d0bbacfc0737c09dfdb44ddb5c22c8eb Binary files /dev/null and b/assets/800px-OSM_proxycharms.png differ