Alarmierung mit Alerta
Gefahr im Verzug
Veröffentlicht in Ausgabe 03/2025 - SCHWERPUNKT
In gewachsenen Strukturen gibt es oft mehr als ein Monitoringsystem. Beispielsweise nutzt die Produktion Zabbix, die Forschung mit ihren Rechen-clustern setzt Ganglia ein und die IT schwört auf Observium. Oder an jedem Firmenstandort läuft ein lokales Monitoring – natürlich von unterschiedlichen Herstellern, weil verschiedene Standorte zugekauft wurden.
Der Alarmmanager Alerta [1] sammelt die Meldungen von allen Systemen ein, fasst sie zusammen, entfernt Duplikate und stellt das Resultat als übersichtliche Webseite dar. Die Webansicht von Alerta liefert damit die Meldungen aller beteiligten Überwachungsanwendungen und sortiert diese nach Kritikalität. Möchten Sie nicht gleich in die Vollen gehen, liefert die Demoseite [2] einen Vorgeschmack der Features.
Alerta installieren
Alerta setzt auf die Programmiersprache Python mit Flask als Webframework. Der Datenbestand wandert wahlweise in MongoDB oder PostgreSQL. Für Aktionen auf der Kommandozeile gibt es den gleichnamigen Befehl, der Alarme generieren kann. Weniger Aufwand haben Sie mit Docker und dem im GitHub-Repository bereitgestellten "docker-alerta" [3].
In gewachsenen Strukturen gibt es oft mehr als ein Monitoringsystem. Beispielsweise nutzt die Produktion Zabbix, die Forschung mit ihren Rechen-clustern setzt Ganglia ein und die IT schwört auf Observium. Oder an jedem Firmenstandort läuft ein lokales Monitoring – natürlich von unterschiedlichen Herstellern, weil verschiedene Standorte zugekauft wurden.
Der Alarmmanager Alerta [1] sammelt die Meldungen von allen Systemen ein, fasst sie zusammen, entfernt Duplikate und stellt das Resultat als übersichtliche Webseite dar. Die Webansicht von Alerta liefert damit die Meldungen aller beteiligten Überwachungsanwendungen und sortiert diese nach Kritikalität. Möchten Sie nicht gleich in die Vollen gehen, liefert die Demoseite [2] einen Vorgeschmack der Features.
Alerta installieren
Alerta setzt auf die Programmiersprache Python mit Flask als Webframework. Der Datenbestand wandert wahlweise in MongoDB oder PostgreSQL. Für Aktionen auf der Kommandozeile gibt es den gleichnamigen Befehl, der Alarme generieren kann. Weniger Aufwand haben Sie mit Docker und dem im GitHub-Repository bereitgestellten "docker-alerta" [3].
Im ersten Schritt öffnen Sie die docker-compose.yml-Datei und ändern den Wert für "ADMIN_PASSWORD".
Anschließend fahren Sie die Container mit
docker-compose up -d hoch und erreichen die Weboberfläche anschließend unter "http://<Ihr_Server>:8080/". Hier der komplette Vorgang:wget https://raw.githubusercontent.com/alerta/docker-alerta/refs/heads/master/docker-compose.yml
sed -i -e 's/ADMIN_PASSWORD=.*/ADMIN_PASSWORD=abc123/' docker-compose.yml
docker-compose up -d
alias alerta="docker exec -it root_web_1 /venv/bin/alerta"
alerta version
Der letzte Befehl liefert Ihnen die Versionsnummer und prüft damit automatisch, ob die Container laufen und ob die interne Kommunikation in Alerta funktioniert.
Melden Sie sich auf der Webseite mit den Zugangsdaten aus der compose-Datei an. Die nun sichtbare Alarmliste ist zunächst leer. Was jetzt noch fehlt, sind einige Probealarme, um die Webseite mit Leben zu füllen. Prinzipiell darf sich jedes Monitoringsystem über das API einbringen, aber den Anfang macht das alerta-Kommando aus dem nächsten Abschnitt.
Alarme auf der Kommandozeile
Alerta kommt mit dem gleichnamigen Befehl, der nicht nur Alarmierungen sendet, sondern ein vollwertiger Ersatz für die Webkonsole ist – allerdings in der Konsolenansicht. Das Kommando ist Teil der Docker-Installation, aber auch losgelöst nutzbar über den Python-Installer Pip [4]. Der Alerta-Server und das Alerta-Kommando verwenden standardmäßig denselben API-Schlüssel, sodass Sie den ersten Alarm an den Start bringen können:
alerta send --resource <Ihr_Server> --service Disk --event DiskFull --environment Production --severity major
Laufen beide Komponenten auf unterschiedlichen Hosts oder nutzen unterschiedliche API-Keys, ist eine Anpassung in der lokalen Konfiguration erforderlich. Der alerta-Befehl bezieht seine Parameter aus der alerta.conf-Datei im Home-Verzeichnis oder aus Umgebungsvariablen. Im GitHub-Repo sind beide Möglichkeiten beschrieben und mit Beispielen versehen. Einen schnellen Überblick über die kritischen Alarme gibt
alerta top. Leider lässt sich die Ansicht nicht so schön filtern wie mit der Webkonsole, die wir im folgenden Abschnitt vorstellen.Farbvielfalt im GUI
Die grafische Oberfläche von Alerta zeigt sich unverschlüsselt im Webbrowser unter "http://<Ihr_Server>:8080/". Nach dem Login sollte der Testalarm des alerta-Kommandos sichtbar sein. Der voreingestellte Filter zeigt nur offene Meldungen an, also solche, für die der Client noch keine Entwarnung gegeben hat. Rechts in der jeweiligen Alarmzeile lässt sich die Meldung bequem per Maus bestätigen oder löschen.
Bei der Farbwahl geht Alerta aufs Ganze: Alarme der Gewichtung "Critical" sind rot, "Warnungen" bekommen blau, "Major" wird orange, "Minor" zeigt sich in Gelb und normale "Meldungen" werden grün dargestellt. Ein Alarm bleibt so lange in der Liste, bis der Client eine weitere Meldung mit dem Schweregrad "normal" sendet. Das Einstellungssymbol oben links öffnet die Menüstruktur, hinter der sich Benutzer, Gruppen und API-Schlüssel anlegen lassen. Hier generieren Sie beispielsweise einen API-Key für die Integration des eigenen Monitoringsystems.
Integration mit dem Monitoring
Nagios ist zwar nicht der jüngste Besucher der Monitoring-Party, aber dafür der Bekannteste. Mit dem "Nagios-to-Alerta-Gateway" [5] existiert auf GitHub ein Event-Broker, der Nagios-Alarme ohne großen Aufwand an Alerta sendet. Eine bestehende Nagios-Umgebung benötigt die vorkompilierte Datei "alerta-neb.o.nagios4" im lokalen Dateisystem. Binden Sie diese als "broker_module" in Ihre "nagios.conf" ein und fügen Sie den API-Schlüssel und die URL des Alerta-Servers in derselben Zeile hinzu. Nach einem Neustart von Nagios geht jede Meldung in Kopie an Alerta. Der Event-Broker kümmert sich um die Authentifizierung und das richtige Format.
Existiert kein fertiges Integrationsprojekt für Ihre Monitoringsoftware, müssen eigene Programmierkenntnisse herhalten. Das klingt komplizierter als es ist, solange das Monitoringsystem einen beliebigen Befehl als Alarm auslösen kann. Dieser Befehl ruft dann das alerta-Kommando auf und sendet den Alarm zum Alerta-Server. Beispielsweise prüft das Überwachungstool M/Monit auf dem lokalen Rocky-Linux den HTTPD-Prozess und kontaktiert Alerta, sobald der Webdienst nicht erreichbar ist. Die Konfiguration im M/Monit-Stil lautet:
check process httpd with pidfile /run/httpd/httpd.pid
if 2 restart within 3 cycle then exec "/usr/local/bin/alerta --config-file /etc/alerta.conf --profile production send --resource Rocky9 --service Web --event ServiceDown --environment Production --severity major"
Leider gibt M/Monit keine Entwarnung, aber immerhin probiert es mehrmals einen Neustart, bevor Alerta von der Niederlage erfährt.
Nagios und M/Monit sind nur zwei Beispiele für das Zusammenspiel mit Alerta. Die Dokumentation [6] führt unter "Integrations & Plugins" und im GitHub-Repository eine lange Liste kompatibler Anbieter und Softwareprojekte, darunter Grafana, Telegram, Slack, Zabbix und Fail2ban. Mit Erweiterungen wie pinger und urlmon prüft Alerta selbstständig die Gegenstelle auf Verfügbarkeit und generiert aus den Ergebnissen seine Alarme. Beim Stöbern in der Liste ist stets die Richtung wichtig, denn beispielsweise kann Alerta SNMP-Traps und Syslog-Nachrichten nur empfangen, aber nicht senden – bei E-Mail und Microsoft Teams ist es genau umgekehrt.
Benutzer verwalten
Der angemeldete Admin darf und sieht alles. Ein neuer Benutzer entsteht im Web-GUI im Bereich "Users" und erhält seine Berechtigungen über die gewählte Rolle "user" oder "guest". Was hier nach einem grobkörnigen Berechtigungskonzept klingt, lässt sich im Bereich "Permissions" feingliedrig unterteilen. Dort erhalten die Rollen gezielte Rechte auf einzelne Funktionen innerhalb der Website wie beispielsweise Lesezugriff auf die Alarme oder Änderungsrechte für API-Keys.
In der Voreinstellung dürfen sich die Nutzer über die Webseite selbstständig einen Account anlegen und anschließend mit dem GUI arbeiten. Diese Selbstregistrierung lässt sich zwar abschalten, aber nur in der Compose-Datei, wo Sie die Variable "SIGNUP_ENABLED" auf "False" setzen und die Container neu starten müssen. Anschließend verschwindet die Registrierungsoption von der Anmeldeseite.
Da lokale Benutzerkonten in größeren Umgebungen lästig sind, erlaubt Alerta das Anmelden an einen Authentifizierungsserver. Die Möglichkeiten reichen von OpenID Connect über SAML und OAuth2 bis hin zum klassischen LDAP. Darüber lassen sich die gängigsten Authentifizierungsdienste sowie ein lokales Active Directory nutzen. Die entsprechende Konfiguration erfolgt auf der Kommandozeile in der Konfigurationsdatei "alertad.conf". Bei der Fehlersuche unterstützt die DEBUG-Variable, die die Ausgabe von
docker-compose logs -f mit detaillierten Logmeldungen anreichert.Mandantenfähig einrichten
Alerta kann eingehende Alarme Mandanten zuordnen. Das entsprechende Benutzerkonto sieht in der Webansicht nur die Meldungen seines Monitoringsystems, eignet sich also zur Administration mehrerer Kunden. Die Zuordnung erfolgt über den API-Key. Erhält Alerta einen Alarm, der sich mit dem API-Schlüssel von Kunde A authentifiziert hat, gehört diese Meldung offensichtlich zu diesem Mandanten. Diese Unterscheidung ist auch nützlich, wenn mehrere Monitoringsysteme im selben Unternehmen an Alerta berichten. In diesem Fall ist jedes einzelne System ein Kunde, sodass die Web- ansicht stets zeigt, aus welcher Umgebung der Alarm stammt.
Alerta erlernt die Mandantenfähigkeit erst, wenn in der Compose-Datei die Variable "CUSTOMER_VIEWS" auf "True" steht. Zum Aktivieren ist ein Neustart der Container erforderlich. Anschließend führt die Weboberfläche die neue Rubrik "Customers". Legen Sie für jeden Kunden oder für jedes Monitoringsystem einen "Customer" an. Anschließend erstellen Sie für jeden Eintrag einen neuen API-Schlüssel. In Bild 2 sammelt Alerta die Meldungen von mehreren Systemen ein und zeigt in der Customer-Spalte die Quelle.
Alerta in der Cloud nutzen
Um die Monitoringsysteme verschiedener Kunden zentral zu erfassen, können Sie den Alerta-Server bei einem Cloudanbieter hosten und die Alarme über das Internet empfangen. Dazu braucht die bisherige Umgebung aber etwas Ertüchtigung, da der Server bisher nur unverschlüsselt erreichbar ist. Dies übernimmt ein vorgeschalteter Webserver wie beispielsweise Caddy. Die Caddy-Software holt sich selbstständig TLS-Zertifikate von Let's Encrypt und verhindert so die Warnungen im Webbrowser. Außerdem ist die Konfiguration mit wenigen Zeilen erledigt.
Aber zuerst bringen Sie caddy entweder per Paketmanager, Executable oder Container auf die lokale Linux-Maschine. Der Webserver erwartet seine Konfiguration in der "Caddyfile"-Datei. Für seine Rolle als Reverse-Proxy benötigt Caddy nur wenige Zeilen:
https://<alerta.example.net> {
reverse_proxy localhost:8080
# tls internal
}
Ersetzen Sie die erste Zeile durch den DNS-Namen Ihres Servers. Beim ersten Aufruf von
caddy run kontaktiert Caddy den Zertifikatsserver von Let's Encrypt und beschafft sich gültige TLS-Zertifikate für den in der ersten Zeile gewählten Namen. Haben Sie keine öffentliche Domain haben oder probieren das Setup im lokalen Netz aus, entfernen Sie das Kommentarzeichen in Zeile 3. Caddy benutzt dann selbst signierte Zertifikate. Anschließend ist Alerta unter "https://<alerta.example. net>" erreichbar – sowohl die Webseite als auch das API. Wenn der Hosting-Anbieter eine Firewall vorschaltet, benötigt diese eine Erlaubnis für die Ports 80 (Let's Encrypt) und 443 (HTTPS).Caddy lässt sich auch als Docker-Container starten und damit in die vorhandene Compose-Datei integrieren. Das erweiterte "docker-compose.yml"-File steht unter [7] zum Download bereit.
Gezielter API-Einsatz
Bei Alerta läuft alles über das Application Programming Interface (API), auch wenn dies auf den ersten Blick nicht sichtbar ist. Das Web-Frontend kommuniziert über localhost mit dem Backend und übergibt alle Befehle im JSON-Format an das API. Das ist zwar keine bahnbrechende Neuerung, zeigt aber die strukturierte Arbeitsweise der Entwickler. Der API-Zugriff ist offen, erfordert aber eine Authentifizierung in Form eines API-Keys. Das ist derselbe Schlüsseltyp, den auch ein Monitoringsystem nutzt, um Alarme an Alerta zu übergeben. Im einfachsten Fall greift curl auf das API zu und holt sich eine Übersicht über die aktuelle Lage:
curl --header 'Authorization: Key 1aSTt...' \
https://<alerta.example.net>/api/alerts/count | jq
{
"autoRefresh": true,
"severityCounts": {
"critical": 2,
"major": 1,
"minor": 4,
"normal": 101,
"unknown": 1,
"warning": 2
},
"status": "ok",
"statusCounts": {
"closed": 101,
"open": 10
},
"total": 111
}
Die Kommandoverkettung mit "jq" verschönert die Ausgabe etwas, da sonst alles in einer langen Zeile stehen würde. Interessant ist auch der Endpunkt "alert", über das API einen Alarm entgegennimmt, ohne dass der alerta-Befehl auf der lokalen Maschine installiert sein muss. Damit lässt sich Alerta vollständig mit curl bedienen oder in die eigene Software integrieren.
Die offizielle Dokumentation erklärt im Abschnitt "API Reference" alle Funktionen und liefert ausführliche Beispiele. Wer gefahrlos in einer Demoumgebung üben will, sollte sich den API-Baukasten unter "explorer.alerta.io" anschauen. Bei Startschwierigkeiten prüft eine Anfrage auf den Endpunkt "/management/healthcheck", ob der Alerta-Dienst läuft und die Datenbank in Ordnung ist. Idealerweise kommt ein "200-OK" zurück.
Prüfen, ob ein Dienst noch lebt
Alerta hat dann doch noch ein Feature aus der Welt des passiven Monitorings dabei: Heartbeats. Dies ist ein API-Endpunkt, den ein Skript oder Cronjob regelmäßig aufrufen muss. Bleibt dieser Aufruf aus, kann Alerta daraus einen Alarm generieren. Diese Funktion eignet sich etwa für Backupjobs, bei denen es nicht sofort auffällt, wenn sie fehlerhaft arbeiten. Ein bestehendes Backupskript lässt sich mit einer curl-Anweisung um einen Heartbeat erweitern:
curl --request POST --header 'Authorization: Key H0i_bj...' \
--header 'Content-type: application/json' \
--data '{ "origin": "gitea", "timeout": 360 }' \
https://<alerta.example.net>/api/heartbeat
Die Aktualisierungsmeldungen zeigt Alerta im Web-GUI bei "Heartbeats" (Bild 3). Server oder Dienste, die sich längere Zeit nicht melden, sind als "expired" gekennzeichnet. Leider entsteht nicht automatisch ein Alarm, sondern erst nach dem Kommando
alerta heartbeats --alerts. Die Dokumentation empfiehlt diesen Befehl als Cron-Job, der alle fünf Minuten läuft.
Alerta berichtet
Alerta kann nicht nur Meldungen empfangen, sondern auch an andere Alerta-Server weiterleiten. Das Feature richtet sich an Umgebungen mit hierarchisch aufgebauten Strukturen. Beispielsweise erhält der lokale Alerta-Server an einem Firmenstandort alle Alarme und berichtet diese weiter an die Unternehmenszentrale. Der empfangende Server darf auch einen anderen Alarmmanager nutzen, solange die Software die JSON-Meldungen korrekt interpretieren kann.
Ein weiterer Anwendungsfall ist ein hochverfügbarer Alerta-Cluster. Eingehende Alarme an den Cluster-Knoten A sendet Alerta weiter an Knoten B und umgekehrt – so bleiben beide Server synchron. Um mögliche Endlosschleifen kümmert sich Alerta selbstständig.
Die nächste Berichtsfunktion bezieht sich auf die Top-10-Reports. Welche Dienste waren am häufigsten betroffen? Im Web-GUI bei "Reports" listet Alerta seine Sorgenkinder sortiert nach der Anzahl der Meldungen auf. Hier kann sich der Admin gezielt mit besonders störenden Fehlern beschäftigen. Wenn beispielsweise derselbe Server jeden Tag gegen vier Uhr morgens über eine hohe CPU-Last stöhnt, dann könnte der tägliche Cron-Job eine mögliche Ursache dafür sein.
Abschließend sei noch erwähnt, dass die Alarmsoftware offen ist für Änderungen und viel Raum für Integrationen und kleine Spielereien bietet. Für die Programmiersprache Python stellen die Entwickler eine Bibliothek zur Verfügung, sodass sich Alerta besonders einfach in Python-Skripte integrieren lässt. Interessant sind auch die Webhooks, über die sich Drittanbieter wie AWS CloudWatch und Grafana in Alerta einklinken, um dort Alarme zu generieren.
Fazit
Alerta ist kein Monitoringsystem, das Zustände im Netz abfragt, sondern ein Sammelbecken für die Alarmmeldungen aus anderen Systemen. Daraus gewinnt Alerta einen Überblick, auf welchen Monitoringinseln der Normalzustand herrscht und wo die Welt gerade untergeht. Für die Interaktion mit Ihrer Monitoringumgebung bietet Alerta ein Kommandozeilentool und ist darüber hinaus vollständig per API bedienbar. Damit steht die Integration in einer beliebigen Programmiersprache nichts im Weg. Zudem findet Alerta auch in der Cloud ein Zuhause und eigent sich dergestalt für Dienstleister.
(jp)
Link-Codes
[1] Alerta: https://alerta.io/
[2] Demoumgebung: https://try.alerta.io/
[3] Docker-Alerta: https://github.com/alerta/docker-alerta
[4] Python-Alerta-Client: https://github.com/alerta/python-alerta-client
[5] Nagios-to-Alerta Gateway: https://github.com/alerta/nagios-alerta
[6] Alerta-Dokumentation: https://docs.alerta.io/
[7] Docker-Compose-Datei mit Alerta, PostgreSQL und Caddy: https://www.it-administrator.de/sites/default/files/2025-02/docker-compose.txt