PowerVC

 View Only

IBM PowerVC Event Management

By Abhishek Sharma M posted Fri July 13, 2018 03:41 AM

  

Events - An Overview


PowerVC services, such as compute, network, and image, generate notifications / events for different operations that they perform. For example, virtual machine deployment and storage volume creation.  All events except for audit events are generated by default; however, they are not stored by default. These notifications are beneficial for ecosystems that leverage PowerVC and listen to these events so they can act on them. There are many cases where PowerVC is upward integrated with other products or solutions and when they are stored, these events provide a mechanism to get periodic updates on operations performed on the PowerVC-based infrastructure.


Starting in version 1.4.0.1, PowerVC provides support to store events using the OpenStack Panko service. This blog explains how PowerVC can be enabled to manage these reported events by using CLI commands. There’s currently no support for viewing or managing events from the PowerVC UI.


Audit events


PowerVC generates and stores audit events (which are of event_type audit.http.request and audit.http.response) only when auditing is explicitly enabled. For more details on audit events, you can read configuring-powervc-auditing.  The difference between audit events and non-audit notifications are:



  • Audit events always follow CADF (Cloud Auditing Data Federation) standards, as described here: https://www.dmtf.org/standards/cadf.

  • Audit events are generated only when a specific create, delete, update, or delete (CRUD) operation is invoked from the PowerVC UI, REST API, or CLI. Audit events are not generated for state changes.


CLI for event configuration


To manage events, use the following powervc-config event subcommands.  The purge subcommand is new in PowerVC 1.4.1, but the rest are available in 1.4.0 FP1. Let’s go through each of them to understand how events can be managed.


List-types - list the types of events that are being stored


Add-type - store a new type of event


Remove-type - stop storing a type of event


Purge - delete all stored events (including audit events)


View stored and supported event types (powervc-config event list-types)


As mentioned earlier, the services in PowerVC generate different events. Run “powervc-config event list-types” without any arguments to view the list of event types that are currently configured to be stored in PowerVC:



Run “powervc-config event list-types –a” to view the list of services that generate events/notifications:



Run “powervc-config event list-types –a <service_name>” to list the events and notifications supported or generated by a specific service (referred to as <event_type> in later sections). As explained in the following section, the add-type subcommand has to be run to configure PowerVC to store one or more event or notification type. These events are not stored by default.



Add event types to be stored in PowerVC (powervc-config add-type)


Run “powervc-config event add-type <event_type> --restart” to store a particular event type (The “list-types sub-command” section describes how to determine the supported event types). The –restart argument restarts the event service and enables the new changes to take effect. With these changes, the specified event type will now get stored in the PowerVC events store when an event is generated from the specific PowerVC service. For example:



More than one event type can be given as input to the add-type command using space separated values as shown here:



The list-types command can be run to view the newly added event types.


Remove event types at PowerVC (powervc-config event remove-type)


Run “powervc-config event remove-type <event_type> --restart” to stop storing an event type. As with the add-types subcommand, the –restart argument must be specified for the configuration to take effect.



Purging stored events


When storing events in a large scale environment, the panko database tables could end up exhausting disk space over a period of time. The “purge” CLI can be used to manually clear all the events from the Panko event/traits tables.



It is important to note that the audit events are also purged with this command. The “powervc-audit-export” CLI can be used to export all the audit events from PowerVC into a file if audit events are required for future use or reference. PowerVC does not run these commands periodically. You can run a cron job that calls the purge CLI if you want the events purged periodically.


Accessing events of a particular event type


The captured events are stored in the panko database and can be accessed from REST API calls. Refer to this topic to learn about the OpenStack event APIs supported by PowerVC:  Supported OpenStack Event (Panko) APIs . As mentioned earlier in this document, these events are automatically generated from different PowerVC services and asynchronously reach PowerVC Panko service via the message queue (namely RabbitMQ).


To retrieve details of a particular event (for example, volume.create.end), we use the below API.


GET https://os4p-vm192:8778/v2/events?q.field=event_type&q.value=volume.create.end


Example:



Event Structure


event_type     A dotted string defining what event occurred, volume.create.end in the above example.


message_id     A UUID for the event.


Generated     A time stamp of when the event occurred in the system.


Traits    A  flat mapping of key-value pairs that describe the event. The event’s traits contain most of the details of the event. Traits are typed, and can be strings, integers, floats, or datetimes.


Raw     Mainly for auditing purpose, the full event message can be stored (unindexed) for future evaluation.


As you saw, PowerVC can now be enabled to manage events using the Panko service with the different commands listed above. If you have questions on this or any other PowerVC subject, comment on this post and don't forget to follow us on LinkedIn, Twitter, and Facebook.


Authors:


Abhishek Sharma M (abmsharm@in.ibm.com)


Divya K Konoor (dikonoor@in.ibm.com)


 


#troubleshooting
#Miscellaneous
0 comments
1 view

Permalink