Managing alerts with Alerta.io
Hello, Khabrovites. Course starts soon “Monitoring and Logging: Zabbix, Prometheus, ELK”, and on the eve of it, we invite you to sign up for an open webinar “Prometheus as a new round of monitoring systems”…
For now, let’s share a traditional, useful translation.
Alerta Is a very simple monitoring system, at least it looks like that to the user. With its help, you can manage alerts from several sources in one place. It includes an API server for receiving, processing and rendering alerts, a web interface and console utilities. It groups alerts by various attributes such as environment, service, event, and resource and leaves host-based monitoring tools in the 90s.
I’ve tried using it for System Alerts on Palo Alto Network (PAN) firewalls, see repository… PAN setup is very simple. I ended up getting on portal only a dozen alerts, not hundreds and thousands as in Monitor-> Systems. This is due to their deduplication and correlation (by tags, custom attributes, environments, services, etc.).
Although I prefer to watch alerts only in one place, for alerta.io I configured plugins for Slack and MS Teams, creating channels there to receive messages. Another channel in the messenger isn’t as bad as tracking another URL. I was not even afraid to send informational messages there, which I usually avoid.
The console utility (which can also be run from a GUI in a terminal or as a Python SDK) is very useful for quickly viewing status, requests, heartbeat, and service.
$ alerta status
METRIC TYPE NAME VALUE AVERAGE
--------------------------- ------ ------------------------- ------- ---------
Total alerts gauge alerts.total 21
Received alerts timer alerts.received 898 30.853
Count alerts timer alerts.counts 1310 4.59695
Alert queries timer alerts.queries 2627 36.0689
Alerta console auto-refresh text switch.auto-refresh-allow ON
API alert submission text switch.sender-api-allow ON
It is important to remember that this is by no means “another monitoring tool”, but only a way to reduce a large number of alerts and aggregate them from multiple monitoring systems such as Zabbix, Nagios or Sensu.
According to the documentation, on receipt alerts can be additionally processed using pre-receive hooks, adding information to them or rejecting them. And you can also initiate the launch of actions in other systems using post-receive – hooks or operator actions or when the alert status changes for bi-directional integration. For example, alerts can be normalized to ensure that all of them have the required attributes and tags, or that they are in a valid range. This can be seen in the reject plugin, which handles the alert policy.
Plugins can also be used to enrich alerts with additional information. For example, the Geo location plugin adds location data to the alert based on the client’s IP address. A generic enhance plugin adds a custom attribute based on the information contained in the alert.
Sign up to an open lesson.