This plugin makes possible to collect generated metrics, alerts and monitored landscape structure from a third party software by using a REST API. When the Generic event server plugin is created and active, all generated alarms and metrics, will be stored in separate queues.

These queues will be polled via a REST API to collect alarms and metrics by chunks. Once the plugin is active, it is necessary to poll queues very regularly.

Warning: Queues are not persistent and are stored in memory. They will be lost if the Pro.Monitor server is restarted.

• From the plugin menu of Pro.Monitor, select Generic event server in the plugin drop down and press Add
• The plugin has the following parameters:

Note: To preserve server memory, alarms and metrics queue have a maximum size. If a queue is full, any new element will replace the oldest one.

Estimated memory consumption of alarms and metrics queues: 200 KB for chunk of 1000 alarms/metrics

The API can be used only with an authenticated user. He must have the monitoring authorization.

The API call must always include an Authorization header with Basic authentication key.

When this plugin is active, 3 services will be available for collecting monitoring data:

• /monitoring/landscapes : Collect monitored infrastructure metadata
• /monitoring/metrics : Collect metrics
• /monitoring/alarms : Collect alarms

This service returns a representation of the monitored landscape in JSON format. It will represent the monitored groups, systems and instances with their relationships and properties.

URL:

• GET /monitoring/landscapes
• Parameters: None

• Monitored landscape architecture is not supposed to change very often.
• Therefore it is probably not necessary to poll it more than once every hour.

• The service returns a JSON table of monitored groups, systems and instances
• Groups will contain systems, which will contain instances

Group structure format:

System structure format:

Instance structure format:

This service can either return a chunk of generated alarms, or the number of alarms waiting to be collected. To collect alarms will remove them from the queue.

URL:

• POST /monitoring/alarms?action=poll : Removes a chunk of the oldest alarms from the queue and return it.
• GET /monitoring/alarms?action=size : Returns the current size of the queue.

• (1) :
  • poll will remove a chunk from the queue and return it, works only with POST method, as it actually modifies the server state.
  • size will return the current size of the queue. Works only with GET method.

• It is advised to poll the queue often with small chunks
• We recommend a poll period of 60 sec.
• If the amount of returned alarms is equal to the max size of the chunk, it means that more alarms can be fetched and another call can be triggered.

• The service returns a JSON table of alarms

Alarm structure format:

• (1): Same problem on same resource gets same id.
• (2): If set to true, the severity will represent the last generated one before the alarm was cleared.
• (3): Some problems are events that cannot be “undone”, so the alert will always stay.

Note: Undocumented parameters are not to be used.

This service can either return a chunk of generated metrics, or the number of metrics waiting to be collected. To collect metrics will remove them from the queue.

URL:

• POST /monitoring/metrics?action=poll : Removes a chunk of the oldest metrics from the queue and return it.
• GET /monitoring/metrics?action=size : Returns the current size of the queue.

• (1) :
  • poll will remove a chunk from the queue and return it, works only with POST method.
  • size will return the current size of the queue. Works only with GET method.

• It is advised to poll the queue often with small chunks
• We recommend a poll period of 60 sec.
• If the amount of returned metrics is equal to the max size of the chunk, it means that more metrics can be fetched and another call can be triggered.

• The service returns a JSON table of metrics

Metric structure format:

• (1): Represents the resource being 'measured', by example Disk C:, User X
• (2): For percent, sampleMax is 100. To use only if hasMax is set.

Note: Undocumented parameters are not to be used.

Once the plugin is configured and active, alerts, metrics and monitored infrastructure will be available through the API.

1. Start by discovering the monitored landscapes 
2. Poll regularly alarms and metrics queues. We recommend to poll the queues every minute.
3. Refresh landscape metadata once per hour

• Generated alarms and metrics will correlate with discovered groups, systems and instances.
• For each alarm and metric, three parameters can be used to correlate it to a component of the landscape:
  • The groupUUID parameter will match the UUID of a discovered group.
  • The sid parameter will match the sid of a system
  • The instance parameter will match the name of an instance.