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".
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 |
| Scheduling | regularly every n minutes |
| Data Content | overall 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.
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
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:
- 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)
See the 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 |
| Scheduling | on every occurrence of an event |
| Data Content | Event 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. 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).