[Vortrag] Actionable Monitoring

In diesem Vortrag soll sinnvolles Monitoring von Workflows auf Servern eingeführt werden. Dabei geht es vor allem darum, statt Fehlermeldungen Handlungsanweisungen zu liefern oder Fehler direkt automatisch zu beheben.

Als Beispiel dient ein Monitoring-Script in node.js, dass durch das Tool nexe abgerundet wird.

Slides

Script

Der aktuelle Stand bei den meisten Monitoring-Systemen entspricht dem Stand einer Motorkontrollleuchte: Wir sehen, dass es einen Fehler gibt, aber wir müssen tiefer reinschauen, um den Fehler zu finden und zu beheben.

Eine Motorkontrollleuchte. Hier kann viel Schiefgehen…

Was für Fehler können zum Beispiel auftauchen, wenn die Lampe angeht?

  • Lambdasonde
  • Katalysator
  • Zündspule(n)
  • Zündkerze(n)
  • Zündkabel
  • Einspritzventil(e)
  • Glühkerzen
  • Einspritzdüse(n)
  • Luftmassensensor (LMM)
  • Thermostat
  • AGR-Ventil
  • Abgasrückführung
  • Drosselklappe

Und das schlimme: Es muss nicht mal das Bauteil selber defekt sein, es kann auch zum Beispiel ein Sensor nur falsche Werte bekommen, weil ein anderes Teil defekt ist.

Eine Werkstatt kann nun per OBD2-Schnittstelle den Fehler auslesen und herausfinden, was genau defekt ist.

Ein OBD2-Adapter zum Fehlerauslesen

Anschließend kann der Fehler behoben werden und die Leuchte geht aus.

Genauso ist auch das meiste Monitoring in aktuellen Landschaften:

Es werden Server überwacht und angezeigt, wenn hier eine Standard-Metrik nicht stimmt.

Nagios mit Fehlern. Symbolbild (hoffentlich)

Wir sehen gewisse „Kontrollleuchten“:

  • HTTP erreichbar
  • SSH erreichbar
  • Speicherverbrauch
  • CPU-Auslastung
  • Anzahl Prozesse
  • Und so weiter….

Nun kann zum Beispiel die „HTTP“-Leucht auf „Rot“ gehen. Was wissen wir nun? Port 80 ist nicht mehr erreichbar, was aber viele Ursachen haben kann:

  • Webserver läuft nicht
  • Webserver läuft nicht mehr auf Port 80 (Konfiguration geändert?)
  • Firewall blockt den Port?
  • Netzwerk defekt?
  • Nagios ist auf dem Server gesperrt?

Wir müssen also tief einsteigen, um den Fehler finden und beheben zu können. Wenn wir Glück haben, gibt es noch ein Log, das die Fehler mit schreibt und durchsuchbar ist…

Nun geht es heute nicht mehr um Server, sondern vor allem darum, Services anzubieten. Also einen Mehrwert für den Kunden.

Dazu brauchen wir Prozesse und Workflows, die dem Kunden bestimmte Dinge zur Verfügung stellen, sei es eine Webseite, die Möglichkeit Mails zu verschicken oder auch die Bestellung von Hardware.

Ein Beispiel-Prozess ist zum Beispiel die Darstellung von Verkehrsmeldungen auf einer Webseite.

Dazu gibt es zunächst ein System in der Cloud, in dem die Meldungen verwaltet und bearbeitet werden.

Diese System schreibt per FTP die Meldungen regelmäßig als XML-Datei auf einen Transportserver in einer DMZ.

Von diesem wiederum holt sich per HTTP aus dem internen Netz ein Bearbeitungssystem die Datei und bereitet sie auf.

Das Ergebnis wir dann auf der Webseite dargestellt.

Der Beispiel-Prozess

Hier können viele Dinge schiefgehen, so das keine oder nur alte Informationen auf der Webseite angezeigt werden.

Fehler können zum Beispiel sein

  • XML-Datei zu Klein
  • XML-Datei zu Alt
  • XML-Datei nicht well-formed
  • FTP-Server Down
  • HTTP-Server Down

Was wollen wir also?

Wir wollen ein System, dass jeden einzelnen Bestandteil der Prozesskette überwacht (Monitoring) und uns Hinweise liefert, wie wir das Problem lösen können.

Wenn der HTTP-Server Down ist, können zum Beispiel folgende Hinweise angezeigt werden:

  • „Starte den nginx-Prozess neu: service nginx start“
  • „Schau mal ins Log: tail -n 20 /var/log/nginx.log“
  • „Check mal, ob das Netzwerk passt: nmap -p 80 Transportserver“

Diese Empfehlungen sind individuell für den Bestandteil und den Server.

Dadurch können Administratoren schon viel einfacher ihren Service wiederherstellen.

Meme: Alles soll von selber gehen!

Noch besser wäre es natürlich, wenn sich die Fehler von alleine beheben und wir davon höchstens Notiz nehmen dürfen.

Im aktuellen Fall könnte der Server selber versuchen, den HTTP-Server neu zu starten und uns informieren, dass er das gemacht hat. Nach 5 Versuchen würde er dann erst den Alarm anstoßen.

Sieg!

Im Idealfall wissen wir also genau, welcher Teil in so einer Prozesskette ausgefallen ist, der Ausfall wurde aber schon direkt behoben oder die Lösung zumindest angestoßen.

Ein Tool, das für genau diese Art von Monitoring gedacht ist ist srv-status.

Es ist in node.js geschrieben, wird über plugins gesteuert und bieten eine sehr genaue Konfuration mit Vorschlägen und Actions an.

Die Konfig eines Bestandteiles könnte so aussehen:

"name":"Is the nginx Running?",
"type":"process",
"target":"nginx",
"recommendations": [
"Restart nginx",
"Check service nginx status",
"Check nginx LogFile"
],
"actions": [
"service nginx start"
]

Zum Namen kommt noch der Typ, der entscheidet, welches Plugin genutzt wird. Das Target ist ein Paramter des Plugins. Hier prüft das Plugin „process“, ob ein Prozess mit Namen „nginx“ läuft.

Weiterhin gibt es Recommendations, also Vorschläge, die dem Admin angezeigt werden.

Die Actions schließlich werden nacheinander ausgeführt.

node.js hat schon viele Abhängigkeiten…

Nun steht unser Server in der DMZ und ist verwundbar, wir wollen also möglichst wenige Angriffsvektoren zulassen. Dazu gehört, node.js zu installieren und auch den Zugang zu npm freizugeben und Pakete zu installieren.

Eine Lösung dafür ist nexe.

Diese Tool nimmt ein Projekt und wandelt es in eine Binär-Datei um, die dann einfach kopiert werden kann.

Eine kleine Demo:

Zunächst klonen wir das Projekt srv-status und installieren die Abhängigkeiten

git clone  https://github.com/WebDaD/srv_status
cd srv_status
npm install

Nun erstellen wir eine einfach config, die prüft, ob ein Service nginx Läuft

{
  "statusFile":"/tmp/status.json",
  "log":{
    "name": "CHECK",
    "logLevel": "WARN"
  },
  "checkSuites": [
    {
      "name":"Basic Server Check",
      "checks": [
       {
          "name":"nginx Running",
          "type":"process",
          "target":"nginx",
          "critical": {
            "recommendations": [
              "Restart nginx",
              "Check service nginx status",
              "Check nginx LogFile"
            ],
            "actions": [
              "service nginx start"
            ]
          }
        }
      ]
    }
  ]
}

Als nächstes installieren und aktivieren wir nginx:

apt-get install nginx
service nginx start

Wir starten den Check!

node check.js ./config.json

Als Ergebnis können wir uns das Ergebnis anschauen (zb less /tmp/status.json)

{
  "checkSuites": [
    {
      "name": "Basic Server Check",
      "checks": [
        {
          "name": "nginx Running",
          "type": "process",
          "target": "nginx",
          "critical": {
            "recommendations": [
              "Restart nginx",
              "Check service nginx status",
              "Check nginx LogFile"
            ],
            "actions": [
              "service nginx start"
            ]
          },
          "status": "OK",
          "result": true
        }
      ],
      "status": "OK"
    }
  ],
  "status": "OK"
}

Wir sehen, dass auf jeder Ebene der Status mitgeführt wird:

  • Auf Ebene des Betandteils
  • Auf Ebene der Gruppe
  • Auf der Gesamtebene

Das erlaubt uns sehr einfach, den Fehler zu lokalisieren.

Als nächstes wollen wir einen Fehler provizieren und schalten den nginx aus

service nginx stop

Nun sehen wir, dass der Service auf Critical wechselt.

Lösen wollen wir das ganze automatisch, dazu nutzen wir die actions:

node action.js /tmp/status.json

Nach einem erneuten Check sehen wir, dass der Service wieder läuft!

Zum Abschluss der Demo versuchen wir das ganze noch mit den Binaries. Dazu erzeugen wir diese erstmal:

nexe -i check.js -t linux-x64 -o bin/check --build
nexe -i server.js -t linux-x64 -o bin/server --build
nexe -i action.js -t linux-x64 -o bin/action --build

Nun können wir das gleich auch mit den Binaries machen, so auch auf einem entfernten Linux-System

Gute Arbeit!

Als abschließendes Fazit wird empfohlen, Actionable Monitoring zu nutzen, um eben weg von allgemeinen Warnleuchten, hin zu selbstheilenden, automatischen und detailierten Fehlermeldungen zu kommen, die uns ermöglichen Fehler in Services effektiv und schnell zu lösen.

Schreibe einen Kommentar

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