Netzwerkmonitoring mit Prometheus

Alte Ketten sprengen

,
Monitoringtools wie Nagios oder Icinga stoßen mit der zunehmenden Verbreitung von Microservices und containerbasierten Anwendungen an ihre Grenzen: Sie sind schlicht nicht dafür ausgelegt, mit derart kurzlebigen Objekten umzugehen. Prometheus als freies Werkzeug für das Sammeln und Auswerten von Logdaten sprengt die Fesseln des Legacy-Monitorings. Wir zeigen, wie sich mit dem Werkzeug Metriken aus der Infrastruktur einsammeln lassen.
Eine stillstehende IT kostet Firmen bares Geld, dabei können die Gründe für einen Ausfall vielfältig sein. Im Juni dreht sich der Schwerpunkt im ... (mehr)

Prometheus ist quasi ein Cousin des Container-Orchestrators Kubernetes: Während Letzteres von Googles Borg abstammt, ist Prometheus vom zugehörigen Monitoringtool Borgmon inspiriert. Ehemalige Google-Site-Reliability-Engineers starteten das Projekt 2012 bei Soundcloud. Heute wird Prometheus unter dem Dach der "Cloud Native Computing Foundation" (CNCF) weiterentwickelt.

Was Prometheus anders macht

Prometheus kennt keine Hosts oder Server mit bestimmten Zuständen, es konzentriert sich stattdessen darauf, Metriken aus verschiedenen Quellen zu sammeln und in seiner eigenen Zeitreihendatenbank zu speichern. Es speichert dabei neben dem Namen der Metrik und den zugehörigen Werten auch Labels, die den Kontext mit der überwachten Komponente herstellen. Der Monitoringansatz von Prometheus nennt sich "Whitebox-Monitoring" und geht davon aus, dass das überwachte System von sich aus Metriken an einer HTTP-Schnittstelle bereitstellt und diese von Prometheus nur noch eingesammelt und gespeichert werden müssen. Prometheus kennt als Metriken beispielsweise Zähler ("counter") und Messwerte ("gauge") [1]. Eine Zähler-Metrik kann so aussehen:

http_requests_total{job="webserver", status="200", method="GET"}@1434 317560938 = 94355

Die Labels (in unserem Beispiel "job", "status" und "method") machen eine Metrik sehr einfach multidimensional. Prometheus speichert für jedes Label-Wert-Paar eine eigene Zeitreihe, das heißt Metriken mit hoher Kardinalität oder Volatilität erhöhen den Speicherplatzbedarf signifikant. Dies gilt es im Blick zu behalten, ansonsten ist die Zeitreihendatenbank extrem effizient hinsichtlich des benötigten Speicherplatzes.

Eine große Stärke von Prometheus ist seine eingebaute "Service Discovery". Vor allem in größeren oder dynamischen Umgebungen möchten Administratoren die Liste der überwachten Systeme nur ungern manuell pflegen. Hier kann Prometheus punkten, indem es beispielsweise AWS-Instanzen oder Kubernetes-Pods automatisch findet. Darüber hinaus unterstützt es auch Azure und Google Cloud Storage sowie generische Ansätze wie DNS-basiertes Discovery.

Prometheus ist für Linux, macOS und Windows sowie als offizielles Docker-Image [2] verfügbar. Durch seine minimalistische Architektur lässt sich Prometheus sehr einfach ausprobieren. Es ist in Go geschrieben und so genügt es, das aktuelle Release von der Projektseite [3] herunterzuladen, ein Binary auszupacken und zu starten. Um sich mit den grundlegenden Funktionen vertraut zu machen, steht auch eine Demo-Umgebung bereit [4].

Überwacht Anwendungen, ob instrumentiert oder nicht

Klassische Monitoringtools wie Icinga und Nagios gehen davon aus, Komponenten oder Anwendungen mithilfe kleiner Programme ("Check-Plug-ins") zu überwachen. Dieser Ansatz wird auch "Blackbox-Monitoring" genannt, im Gegensatz zum oben beschriebenen Whitebox-Monitoring. Eine ständig wachsende Zahl von Applikationen stellt bereits Metriken im Prometheus-Format bereit, wie Docker, Kubernetes oder auch GitLab – sogenannte "instrumentierte" Anwendungen.

Mit Hilfe sogenannter "Exporter" kann Prometheus aber auch nicht-instrumentierte Systeme und Anwendungen überwachen. Der bekannteste ist der "node_ exporter" [5], der Betriebssystemmetriken wie Speicherverbrauch oder Netzwerkauslastung bereitstellt. Es gibt inzwischen eine ganze Reihe von Exportern für die unterschiedlichsten Anwendungsfälle wie Apache, MySQL, SNMP, vSphere und viele mehr [6]. Exporter sind selbständige Programme, die Metriken aus dem zu überwachenden System extrahieren und als Key-Value-Paare über eine HTTP-Schnittstelle bereitstellen (jeder Exporter nutzt hierzu seinen eigenen TCP-Port). Prometheus sammelt diese in einem vorher festgelegten Intervall ein. Dieser Vorgang wird als "scraping" bezeichnet. Sie können die Exporter analog zu Gateways sehen, die Daten einer Black-Box-Applikation ermitteln und Prometheus dann eine White-Box-Applikation vorspiegeln.

Die genannten Exporter lassen sich einfach im Betriebssystem oder in Form einer Prometheus-Client-Library in Applikationen integrieren. Wenn es sich jedoch beim zu überwachenden Device um Hardware wie beispielsweise ein Netzwerkgerät handelt, kommt der "SNMP-Exporter" [7] zum Einsatz. Das Abrufen von Informationen in SNMP ist dem Ansatz von Prometheus sehr ähnlich. Auch hier werden Metriknamen in Form von Object Identifiern (OID) und Metrikwerte zum Abruf bereitgestellt. Allerdings nicht als eine einzige Liste, sondern als Baumstruktur, und ein Bereitstellen über HTTP findet ebenfalls nicht statt. Dieses Manko kann der SNMP-Exporter ausgleichen: vergleichbar einem Proxy löst eine Scrape-Anfrage von Prometheus an den Exporter eine SNMP-Anfrage an das definierte Netzwerkgerät aus. Dessen Antwort wiederum reicht der Exporter in Form eines aufbereiteten HTTP-Response an Prometheus zurück.

Jede einzelne OID, die abgefragt werden soll, müssen Sie in die Konfiguration des Exporters eintragen. Selbst bei durchschnittlichen Netzwerkgeräten kommen hier schnell 50 und mehr unterschiedliche OIDs zusammen. Um nicht alle Zahlen auswendig kennen zu müssen, gibt es die MIBs (Management Information Base). Die MIBs beinhalten neben einer detaillierten Beschreibung der OID-Struktur auch einen symbolischen Namen sowie eine Beschreibung jeder Metrik. Da eine Zuordnung von Metrikname zu OID manuell sehr aufwändig ist, greifen Sie hier besser zum mitgelieferten "Generator-Tool".

Listing 1: SNMP-Exporter konfigurieren



##### snmp.yml-Beispieldatei
    Module_name:
       version: 2
       auth:
          community: TopSecret
       walk:
          - 1.3.6.1.2.1.2
       metrics:
          - name: ifInOctets
            oid: 1.3.6.1.2.1.2.2.1.10
            type: counter
            help: The total number of octets received on the interface
            indexes:
            - labelname: ifDescr
              type: gauge
            lookups:
            - labels:
              - ifDescr
              labelname: ifDescr
              oid: 1.3.6.1.2.1.2.2.1.2
              type: DisplayString
comments powered by Disqus

Artikel der Woche

Eigene Registry für Docker-Images

Wer selber Docker-Images herstellt, braucht auch eine eigene Registry. Diese gibt es ebenfalls als Docker-Image, aber nur mit eingeschränkter Funktionalität. Mit einem Auth-Server wird daraus ein brauchbares Repository für Images. (mehr)
Einmal pro Woche aktuelle News, kostenlose Artikel und nützliche ADMIN-Tipps.
Ich habe die Datenschutzerklärung gelesen und bin einverstanden.

Konfigurationsmanagement

Ich konfiguriere meine Server

  • von Hand
  • mit eigenen Skripts
  • mit Puppet
  • mit Ansible
  • mit Saltstack
  • mit Chef
  • mit CFengine
  • mit dem Nix-System
  • mit Containern
  • mit anderer Konfigurationsmanagement-Software

Google+

Ausgabe /2019