- Logo

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.path definiert den Pfad für das Dateisystem, das überwacht werden soll
  • percent.used.space.warning.threshold legt den Grenzwert des Dateisystems in Prozent fest, bei dem ein Ambari-WARNING generiert wird.
  • percent.free.space.critical.threshold definiert den Grenzwert in Prozent, ab dem ein CRITICAL-Alert generiert wird
  • minimum.free.space ist 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
Bildquelle: pixelio.de / Bildnr. 185690

Tags:
Woodmark - Rick Moritz

Rick Moritz

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.

Interesse am Arbeiten bei Woodmark?

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.