Praxisratgeber für modernes Cloud-Monitoring Icinga 2 mit OpenTelemetry: So gelangen Prüfwerte direkt ins Cloud-Monitoring

Seit Version 2.16 exportiert Icinga 2 Prüfwerte direkt im OpenTelemetry-Format. Der Ratgeber zeigt, wie Unternehmen Monitoring-Metriken ohne zusätzlichen Exporter an Prometheus, Grafana Mimir oder gehostete Backends übertragen, Alarmgrenzen zentral halten und den Umstieg sicher planen.

Icinga 2 ist eine quelloffene Monitoring-Lösung für Hosts, Services und Netzwerkkomponenten. In festen Intervallen ruft sie Check-Plugins auf, wertet deren Exit-Code als Status aus, also „OK“, „Warning“, „Critical“ oder „Unknown“, und benachrichtigt bei einem Zustandswechsel die im Notification-Objekt hinterlegten Kontakte. Hinter einem senkrechten Strich hängt jedes Plugin an seine Ausgabe die gemessenen Zahlen an, die Performance Data, kurz Perfdata. Bei „check_load“ stehen dort die drei Lastmittelwerte über eine, fünf und fünfzehn Minuten als „load1“, „load5“ und „load15“, jeweils mit der gemessenen Zahl und den Grenzen für „Warning“ und „Critical“, zum Beispiel „load1=0.42;5;10“.

Zusätzlicher Aufwand durch getrennte Monitoring-Datenbanken

Für den Weg dieser Zahlen in eine Zeitreihendatenbank gibt es bislang den GraphiteWriter und den InfluxdbWriter. Beide setzen eine eigene Zeitreihendatenbank voraus, die allein die Zahlen aus dem Monitoring aufnimmt. Anwendungen, die ein Entwicklerteam mit einem OpenTelemetry-SDK instrumentiert hat, schicken ihre Zahlen dagegen über OTLP an ein zweites Backend, entweder direkt oder über einen Collector dazwischen. Steht dort Prometheus, fragt PromQL die Serien ab, die Benachrichtigung übernimmt eine Rule im Alertmanager. Andere Backends bringen eigene Abfragesprachen und eigene Alarmwege mit.