OSM Fault Management: Difference between revisions

From OSM Public Wiki
Jump to: navigation, search
mNo edit summary
mNo edit summary
Line 52: Line 52:
2. Create an alarm following the example above and you will see an event appear at the histogram.  This event came from the 'alarm_response' topic.
2. Create an alarm following the example above and you will see an event appear at the histogram.  This event came from the 'alarm_response' topic.


[[File:OSM Kibanapng|800px|Screenshot of OSM Kibana add-on]]
[[File:OSM Kibana.png|800px|Screenshot of OSM Kibana add-on]]


3. Trigger a VDU alarm (with CPU spikes or any other mechanism), and you will see a notification arrive at Kibana.  This event came from the 'alarm_response' topic as well.
3. Trigger a VDU alarm (with CPU spikes or any other mechanism), and you will see a notification arrive at Kibana.  This event came from the 'alarm_response' topic as well.

Revision as of 14:47, 17 May 2018

This is new set of features are available since the Release FOUR Lightweight build, by gradually adding capabilities on log visibility, events and failures of both the system and network services.

Basic functionality

Logs & Events

As of Release 4.0.0, logs can be monitored on a per-container basis via command line, like this:

docker logs <container id or name>

Furthermore, there are some important events flowing between components through the Kafka bus, which can be monitored on a per-topic basis by external tools.

VDU-level alarms and thresholds

By default, alarms can be configured through the MON component at the VIM level, in order to send a notification whenever a metric threshold is crossed.

Starting with OSM R4, it is possible to configure an alarm via the OSM CLI, by running the followeing command (in the example: NS name: "vnf01", VNF index: 1, VDU name: "ubuntuvnf_vnfd-VM", metric type: "cpu_utilization", severity: "critical", threshold value: 50, operator: "greater than", statistic measuring type: "average", name: "scale_out_alarm")

osm ns-alarm-create --ns vnf01 --vnf 1 --vdu ubuntuvnf_vnfd-VM --metric cpu_utilization --severity critical --threshold_value 50 --threshold_operator GT --statistic AVERAGE scale_out_alarm

Possible metric names are: cpu_utilization, average_memory_utilization, ... Other parameter options can be explored through running "osm ns-alarm-create --help".

Whenever an alarm is triggered, the notification is received by MON and put in the bus so other components can consume them. For example, there is a new Policy Manager component that soon will be able to take actions like further logging or scaling based on this notifications.

Please note that this is supported in OpenStack only at this point in time, however, other VIMs and VNF-based alarms and thresholds will be available soon.

Experimental functionality

Some extensions have been added to the OSM installer to include an optional 'OSM ELK' stack to allow for events visualization, consisting of an ELK stack, with minor configurations that make it able to monitor some kakfa topics and logs.

Basic architecture is as follows:

Diagram of OSM ELK Experimental add-ons

Enabling the OSM ELK Stack

If you want to install OSM along with the ELK stack, run the installer as follows:

./install_osm_release.sh --elk_stack

If you just want to add the ELK stack to an existing OSM R4 Lightweight build, run the installer as follows:

 ./install_osm_release.sh -o elk_stack

If you need to remove it at some point in time, just run the following command:

docker stack rm osm_elk

Testing the OSM ELK Stack

By default, the available ELK Stack monitors the 'alarm_response' Kafka topic, and any log sent to TCP port 5000.

1. Visit Kibana frontend at http://1.2.3.4:5601, replacing 1.2.3.4 with the IP address of your host.

2. Create an alarm following the example above and you will see an event appear at the histogram. This event came from the 'alarm_response' topic.

Screenshot of OSM Kibana add-on

3. Trigger a VDU alarm (with CPU spikes or any other mechanism), and you will see a notification arrive at Kibana. This event came from the 'alarm_response' topic as well.

4. Configure the Policy Manager component to log events to Logstash and repeat (3), you will see further details whenever an alarm is triggered.

docker service update --env-add LOGSTASH_URI=logstash:5000 osm_pm

In the near future, more components will have visibility through Kibana. Please send your feedback and suggestions to OSM_TECH@list.etsi.org