Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

Table of Contents

Introduction

The azeti Distributed Monitoring (DM) Technology is a key feature of the azeti SONARPLEX. Its application area is the monitoring of multiple remote sites (following called “Sattelite”) where the overall status is collected in one central SONARPLEX (following called “NOC”).

...

The distributed monitoring uses two concepts for delivering information to the NOC. Both include different data and are scheduled differently.

Example Architecture

Below is an example scenario for monitoring a distributed monitoring setup using the azeti Agent as delivery technolgy. This is a worldwide setup where every location can also have a sub location. All status information and alerts are collected in "Central Office".

Distributed MonitoringImage Added

Each SONARPLEX communicates with the remote devices through the azeti Agent, which is installed on the devices by default. To save bandwidth and system performance, static information ( is sent regularly and updates are done incremental.

Status File Delivery

Delivery Technology

azeti Agent

Schedulingregularly every n minutes 
Data Contentoverall status and monitoring configuration
Example Setup

SONARPLEX to SONARPLEX

SONARPLEX to azeti Agent

Log Files

Distributed Monitoring (NOC Processor) [process_satellite.log]

Distributed Monitoring (Satellite Processor) [send_status.log]

Distributed Monitoring Event Log (NOC) [event.log]

The status file delivery is a regularly scheduled job where the overall status of the satellite is delivered to the configured destination, the NOC. The delivery interval can be configured as well as the destnation.

...

  • services
  • hosts
  • downtimes
  • comments
  • performance data

Status File Processing

The status file is automatically parsed and processed on the receiving system if it is a SONARPLEX.

Following actions are performed based on the received status file after it was compared with the last one:

  • information update of existing hosts and services
  • creation of new objects
  • performance data update
  • delete obsolete objects

Following are key features of the processing:See the full list of supported events

  • object updates are executed through external commands (e.g. ADD_SVC_COMMENT, ACKNOWLEDGE_SVC_PROBLEM) during runtime
  • check results are submitted as passive check results, which is an external command as well
  • the monitoring configuration is updated if required
  • the monitor process restarts if the configuration changed
  • all configuration hosts and services from the satellite are prefixed with the corresponding LOCATION_ID (see Configuration :: My Properties :: Resources)

Info

See the Reports :: Event Log in the user web interface for better understanding of the processing, all the external commands are logged there after the receipt of a recent status file.

Event Delivery

Delivery Technologies

azeti Agent, SNMP Traps

Schedulingon every occurrence of an event
Data ContentEvent information. See List of Events for detailed information
Example Architectures

SONARPLEX to SONARPLEX

SONARPLEX to azeti Agent

SONARPLEX to SNMP Trap Receiver (Northbound Integration)

...

The second concept is the Event Delivery. Every new event is immediately delivered, after it was processed internally, to the configured destinations. It depends on the delivery technology how the event is processed on the NOC side.

 

Supported Architectures

Below are some distributed monitoring use cases explained which show how the delivery technologies can be used

 

 

Example Architecture

Below is an example scenario for monitoring of worldwide distributed locations where every location can also have a sub location. All status information and alerts and collected in "Central Office".

Distributed MonitoringImage Removed

...

Understanding the difference between Alerts and Notifications

It is important to understand the difference between the event types. Alerts and notifications are the most important ones. Especially for the distributed monitoring environment it is crucial to deliver the appropriate event types to avoid unnecessary events and of course to make sure every important event is delivered to the NOC.

Characteristics of Alerts

  • alerts are created for SOFT and HARD states internally
  • alerts happen upon every state change
  • unaffected by downtimes
  • unaffected by acknowledgements

Characteristics of Notifications

  • result out of HARD states
  • happen after an HARD state alert
  • suppressed when object is acknowledged
  • suppressed when object is currently in downtime
  • can be deactivated

  • can be suppressed through Notification Intervals

Note

Only the Host and Service Notification Events can be suppressed by Acknowledgements and Downtimes. Select these both event types for the event delivery in your distributed monitoring set up if you want to suppress unnecessary alerts to the NOC during on-site maintenance (downtimes) or if the problems are already under investigation (acknowledgements).