22. 03. 2022
Icinga Web 2, Machine Learning, NetEye
Recently I was asked why alerting in a NetEye 4 environment isn’t run via the central master, but instead via the satellites. The background to this is that the NetEye Master is located in Italy, which controls various satellites in other European and African countries.
It’s therefore a strategic decision that alarms are sent from the local satellites for reasons such as SMS costs, interruptions in WAN connections, etc.
To achieve this, I made the following settings.
- The Icinga notification feature must be activated on the NetEye satellites:
icinga2 feature enable notification - Copy (or create) the notification scripts used on the satellite to the same location as on the master. For example with the mail-host-notification command, the script must be at
/neteye/shared/icinga2/conf/icinga2/scripts/mail-host-notification.sh - Then create a “notification template” for hosts and services for each satellite (zone) in Icinga Director. It should be noted that the zone in which the alarm is to be carried out can be selected under “Zone settings”.
See this example:
If you inherit settings from other “notification templates”, these must also be in exactly the same zone. Otherwise the configuration will not work on the satellite because the satellite does not recognize this notification template.
Next I create a “user template” for this zone, which under “Zone settings” again refers to the desired zone. This is necessary because the user on which the notifications are based is created precisely in this zone by assigning this template. Otherwise the zone does not recognize the user, the Icinga configuration is not adopted, and thus the Icinga service on the satellite stops.
For example:
Then I create a user with email alerting who should be the one notified for this zone. It’s important that I use the “notify-all-events-rome” template that I just created above so that this user is created on the desired satellite.
Here’s an example again:
Finally, of course, you have to create the “notification apply rules” that apply to this user and zone. It’s important to note that it uses the notification template and the user we just created. Of course, the assignment rule must be selected for the desired objects.
The final example:
Finally, for this configuration I’d like to underline a few essential topics that are very important for correct functionality:
- You must always ensure that every created object that is to be executed on the satellite is assigned the correct zone.
- As soon as several satellites with several different users have to be managed, it’s extremely important to ensure that the configurations for the satellites are correctly rolled out and that they receive all the objects necessary that are to be used in the alarm. This must absolutely be verified, because otherwise it can quite easily happen that the icinga2 service on the satellite won’t run after it’s been rolled out.
I’ve configured this setup even on a seven satellite environment, where I’ve received email and SMS alerts, some of which are attached to the satellite servers via various gateways.
TobiasGoller
NetEye Solution Architect at Würth Phoenix
I started my professional career as a system administrator.
Over the years, my area of responsibility changed from administrative work to the architectural planning of systems.
During my activities at Würth Phoenix, the focus of my area of responsibility changed to the installation and consulting of the IT system management solution WÜRTHPHOENIX NetEye.
In the meantime, I take care of the implementation and planning of customer projects in the area of our unified monitoring solution.
Author
Latest posts by TobiasGoller
12. 04. 2022
Unified Monitoring
News from nBox and ntopng
22. 03. 2022
Icinga Web 2, Machine Learning, NetEye
Performance Metrics Collection from NetEye to Elastic
14. 03. 2022
Unified Monitoring
SOS Berlin JobScheduler – JS7
15. 11. 2021
NetEye
The NetEye 4 SMS Tools Module
17. 05. 2021
Service Management
SOS Berlin JobScheduler – NEWS