Zum Inhalt springen

Monitoring

Icinga2, Prometheus, Grafana, CheckMK — Monitoring erklärt.

Icinga2

Infrastruktur-Monitoring

Prometheus

Time-Series & Metrics

Grafana

Dashboards & Visualisierung

CheckMK

All-in-One Monitoring

Monitoring ist kein Dashboard — es ist eine Disziplin

Ein Monitoring-Stack entsteht nicht durch die Installation von Tools. Es ist ein Architekturbestandteil, der von Anfang an mitgedacht werden muss. Welche Metriken sind relevant? Wo entstehen sie? Wer reagiert auf Abweichungen — und wie schnell? Monitoring ohne Konzept erzeugt Daten, aber keine Erkenntnisse. Erst wenn Metriken, Schwellwerte und Eskalationspfade aufeinander abgestimmt sind, wird aus Technik ein belastbares Frühwarnsystem.

Die richtige Lösung für den richtigen Kontext

Jedes Monitoring-Tool hat seinen idealen Einsatzzweck. Icinga2 glänzt in klassischen Infrastrukturen mit Host- und Service-Checks. Prometheus ist das Mittel der Wahl für Kubernetes und Microservices. Grafana visualisiert — sammelt aber keine Daten. CheckMK bietet einen schnellen Einstieg ohne tiefes Konfigurations-Know-how. Die Wahl des richtigen Stacks hängt von der Infrastruktur, dem Team und den Anforderungen ab — nicht vom Hype.

Icinga2

Check-basiertes Monitoring mit maximaler Flexibilität.

Icinga2 ist ein Fork von Nagios und setzt auf ein Plugin-basiertes Modell mit Cluster-Fähigkeit. Der Kern: aktive Prüfungen (Checks) in definierten Intervallen gegen Hosts und Services. Das Ökosystem umfasst über 5.000 Plugins — von SNMP über HTTP bis zu Custom-Checks in jeder Sprache.

  • Ideal für: Klassisches Infrastruktur-Monitoring (Host/Service Checks), Behörden, ITIL-Umgebungen
  • Architektur: Check-basiert — aktive Prüfung in definierten Intervallen, Push- und Pull-Checks möglich
  • UI: Icingaweb2 als modulares Web-Interface, REST-API für Automatisierung und Integration
  • Alerting: Bewährtes Notification-System mit Eskalationen, Zeitfenstern und flexiblen Kommandos
  • Stärke: Extrem anpassbar durch Plugin-Architektur, Cluster- und Zone-Support für verteilte Setups

Prometheus

Pull-basierte Metriken mit Time-Series-Power.

Prometheus setzt auf ein Pull-Modell: Targets exportieren Metriken über HTTP-Endpoints, Prometheus scraped sie in konfigurierbaren Intervallen. Jede Metrik ist ein Stream von Timestamps und Values — gespeichert in der eigenen Time-Series-Datenbank (TSDB). PromQL erlaubt Aggregation, Rate-Berechnung und Joins über Labels.

  • Ideal für: Kubernetes, Microservices, dynamische und containerisierte Infrastruktur
  • Architektur: Pull-basiert mit Service Discovery (Kubernetes-nativ), Multi-Dimensional Labels statt hierarchischer Namensräume
  • Query-Sprache: PromQL — mächtig für Aggregationen, Histogramme, Rate-Berechnungen über beliebige Zeitfenster
  • Alerting: Alertmanager als eigenständige Komponente mit Grouping, Silencing, Inhibition und Routing
  • Skalierung: Federation, Remote Write/Read, Thanos oder VictoriaMetrics für Long-Term-Storage

Grafana

Visualisierung — nicht Datensammlung.

Grafana ist kein Monitoring-Tool im klassischen Sinne. Es sammelt keine Metriken, speichert keine Daten und führt keine Checks durch. Grafana visualisiert — und das hervorragend. Als Datasource dienen Prometheus, InfluxDB, Elasticsearch, MySQL, PostgreSQL und dutzende weitere Backends.

  • Ideal für: Dashboards, SLA-Reporting, Team-übergreifende Sichtbarkeit auf Infrastruktur und Applikationen
  • Datasources: Prometheus, InfluxDB, Elasticsearch, MySQL, PostgreSQL, Loki, Tempo und viele mehr
  • Features: Annotations für Events, Template Variables für dynamische Dashboards, Playlist-Mode für NOC-Screens
  • Alerting: Alerts direkt aus Dashboard-Panels konfigurierbar, Multi-Channel-Benachrichtigung (Mail, Slack, PagerDuty)
  • Wichtig: Grafana ersetzt kein Monitoring — es macht Monitoring sichtbar. Ohne valide Datenquelle zeigt ein Dashboard nichts

CheckMK

All-in-One: Discovery, Monitoring, Alerting, Reporting.

CheckMK kombiniert Monitoring-Engine, Auto-Discovery, Alerting und Reporting in einem Paket. Der Agent-basierte Ansatz erkennt Services automatisch — von Festplatten über Netzwerk-Interfaces bis zu Applikations-Metriken. Der Konfigurationsaufwand ist deutlich geringer als bei einem manuell zusammengestellten Stack.

  • Ideal für: Schneller Einstieg, heterogene Umgebungen, Organisationen ohne dediziertes Monitoring-Team
  • Architektur: Agent-basiert mit Auto-Discovery — Services werden erkannt, nicht manuell konfiguriert
  • Stärke: Geringer Konfigurationsaufwand, integriertes WATO für regelbasierte Konfiguration, Business Intelligence Module
  • Editionen: Raw (Open Source, Nagios-Kern), Enterprise (CMC-Kern, Performance), Cloud und MSP-Editionen
  • Trade-off: Weniger flexibel als ein Prometheus+Grafana-Stack, dafür schneller produktiv und einfacher zu betreiben

Time-Series-Datenbanken — warum Metriken anders ticken

Eine relationale Datenbank speichert Daten in Zeilen und Spalten. Änderungen erfolgen per UPDATE — ein Wert wird überschrieben. Für Metriken ist das grundlegend falsch. Metriken sind append-only: Jeder Messpunkt wird angehängt, nie überschrieben. Die CPU-Auslastung von vor 5 Minuten bleibt relevant — sie wird nicht durch den aktuellen Wert ersetzt.

Time-Series-Datenbanken wie Prometheus TSDB, InfluxDB oder VictoriaMetrics sind genau dafür optimiert: hoher Write-Throughput bei minimaler Latenz, effiziente Kompression von Zeitreihen (Delta-of-Delta, Gorilla-Encoding) und automatische Retention-Policies, die alte Daten nach definierten Zeiträumen löschen.

Warum rate() funktioniert: Prometheus-Counter sind monoton steigende Werte (z.B. http_requests_total). Die Funktion rate() berechnet die Änderungsrate pro Sekunde über ein Zeitfenster — sie erkennt dabei Counter-Resets (z.B. nach einem Restart) und korrigiert automatisch. Ohne Time-Series-Modell wäre diese Berechnung nicht möglich.

Histogramme in Prometheus: Ein Histogram besteht aus mehreren Time Series — Buckets (le-Labels), ein _sum und ein _count. Damit lassen sich Latenzen nicht nur als Durchschnitt, sondern als Quantile (p50, p95, p99) berechnen. Die Funktion histogram_quantile() interpoliert zwischen den Bucket-Grenzen. Das ermöglicht SLA-Messungen wie „99% der Requests antworten in unter 200ms“.

Alert-Spam

500 Mails am Tag, alles Warning, niemand schaut mehr hin. Jeder Host, jeder Service, jeder Schwellwert generiert eine eigene Nachricht. Das Ergebnis: Alert Fatigue. Das Team stumpft ab, echte Incidents gehen im Rauschen unter. Monitoring existiert auf dem Papier — aber nicht in der Praxis.

Gezieltes Alerting

Page nur bei echten Incidents. Warnings werden aggregiert und in Dashboards sichtbar gemacht — nicht als Mail verschickt. Jeder Alert hat ein verlinktes Runbook mit Diagnose-Schritten und Eskalationspfaden. Der Alertmanager nutzt Grouping (zusammengehörige Alerts bündeln), Silencing (geplante Wartung) und Inhibition (übergeordnete Alerts unterdrücken abhängige).

Tipp

Das beste Monitoring ist nutzlos, wenn niemand auf die Alerts reagiert. Alerting-Konzepte, Eskalationspfade und Runbooks gehören genauso zur Monitoring-Architektur wie die Technik selbst. Wer Monitoring einführt, ohne Prozesse zu definieren, betreibt Datensammlung — kein Monitoring.

Monitoring-Stack evaluieren? Lassen Sie uns über Ihre Anforderungen sprechen.