| 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".
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.
...
- services
- hosts
- downtimes
- comments
- performance data
See the full list of supported events.
Event Delivery
...
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)
| 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 |
|---|---|
| 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.
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".
...
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). |