Der beste Ambari-Alert aller Zeiten
Ambari-Alert: Monitoring für alle
Der Ambari-Alert ist insbesondere in Entwicklungsumgebungen häufig das einzige Monitoring in Hadoop, über das ein DevOps-Team verfügt, um schnell Urteile über die Gesundheit eines Clusters treffen zu können. Das führt dazu, dass die häufigste Ursache für Ausfälle von Diensten erst mit dem Ausfall erkannt wird: Vollgelaufene Dateisysteme für Logs, Datenbanken oder Transaktionslogs werden von Ambari standardmäßig nicht überwacht! Lediglich einzelne Dateisysteme (das vom Ambari-Agent) stehen unter Bewachung, wobei allerdings Plattformen häufig mit mehreren Dateisystemen ausgeliefert werden, damit das root-Dateisystem nicht vollläuft. Sinn oder Unsinn dieser Maßnahme soll hier nicht diskutiert werden. Stattdessen möchte ich kurz zeigen, wie man einen flexiblen Ambari-Alert für beliebige Dateisysteme definiert.
Dieser stützt sich dabei auf die bereits bestehende Logik, bietet allerdings einen zusätzlichen Parameter an, der erlaubt, nur über die REST-API von Ambari weitere Verzeichnisse zu überwachen.
Zuerst müssen wir ein zusätzliches Python-Skript auf den Ambari-Server unter /var/lib/ambari-server/resources/host_scripts hochladen. Dieses hat vier Parameter, die man im alert.json setzen kann:
monitor.pathdefiniert den Pfad für das Dateisystem, das überwacht werden sollpercent.used.space.warning.thresholdlegt den Grenzwert des Dateisystems in Prozent fest, bei dem ein Ambari-WARNING generiert wird.percent.free.space.critical.thresholddefiniert den Grenzwert in Prozent, ab dem ein CRITICAL-Alert generiert wirdminimum.free.spaceist ein zusätzlicher Parameter, um CRITICAL-Alerts zu generieren, der ab einer minimalen Anzahl von frei verbleibenden Gigabyte getriggert wird
[dropshadowbox align=“right“ effect=“lifted-both“ width=“40%“ height=““ background_color=“#ffffff“ border_width=“1″ border_color=“#dddddd“ ]Achtung zu Name und ID:
Die ID ändert sich, falls man in Ambari den Namen oder Parameter des Alerts anpasst. Skripte, die eine konstante ID annehmen, sind nicht zu empfehlen. Hingegen kann kein zweiter Ambari-Alert mit dem gleichen Namen (siehe Parameter in alert.json) angelegt werden.[/dropshadowbox]
Um den Ambari-Alert zu aktivieren, ist zunächst ein Neustart des Ambari-Servers notwendig, welcher das Skript auf alle Agents verteilt. Danach muss man alert.json anpassen. Mit service_name und component_name kann man steuern, welche Server den Wert beobachten.
Von einem Server (und mit Credentials/SPNEGO), die einen Aufruf der Ambari-REST-API erlauben, setzt man dann alert.json in folgendem curl mit entsprechendem cluster_name ab:
curl -u admin:admin -i -H 'X-Requested-By: ambari' \
-X POST -d @alert.json \
http://localhost:8080/api/v1/clusters/cluster_name/alert_definitions
In der Rückgabe steckt die Alert-ID, mit der man in Ambari unter http://ambari-server.example.org/#/main/alerts/<ID> den Alert einsehen kann.
Falls der Ambari-Alert noch nicht angestartet wurde, kann er mit entsprechender ID und folgendem curl zur sofortigen Ausführung gebracht werden:
curl -u admin:admin -i -H 'X-Requested-By: ambari' -X PUT \
http://localhost:8080/api/v1/clusters/cluster_name/alert_definitions/ID?run_now=true
Löschen kann man den Ambari-Alert mit der jeweiligen ID:
curl -u admin:admin -i -H 'X-Requested-By: ambari' -X DELETE \
http://localhost:8080/api/v1/clusters/cluster_name/alert_definitions/ID
Rick hat sich mit Big Data Technologien und Konzepten beschäftigt und unsere Kunden bis Anfang 2018 als Solution Architect Big Data u.a. in der Entwicklung und mit Big-Data-Schulungen unterstützt. Seine Lieblingstechnologien sind aktuell Spark und Scala, mit einer Prise DevOps.
