Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 5 Next »

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 so called NOC receives status information from its satellites and sub-satellites on regular base where alerts from one remote location are sent immediately to the NOC SONARPLEX. This allows you to monitor locations worldwide but having one central view, e.g. for your Network Operation Center. Each satellite schedules and executes checks locally and sends the results to one central destination.

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 Monitoring

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

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.

A status file includes all necessary monitoring configuration informations as well as a snapshot of the overall status for all configured services and hosts. besides this acknowledgements, downtimes, contacts and all other necessary monitoring information is included. This overall status is generated right before the delivery to the NOC and is of course only a snapshot for this very moment.

New status information is interpreted by the NOC and required for the following tasks (all happen on NOC side):

  • initial creation of objects
  • update changed objects
  • add new objects
  • delete missing objects

The file includes information for the following objects:

  • services
  • hosts
  • downtimes
  • comments
  • performance data

See the full list of supported events.

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.

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

Only the Host and Service Notification Events can be suppressed by acknowledgements and downtimes. Use these evnt types in a distributed monitoring set up if you want to suppress unnecessary alert delivery to the NOC during on site maintenance (downtimes) or if the problems are already under investigation (acknowledgements).

  • No labels