Managed Monitoring · Prometheus, Grafana, Loki
Managed Monitoring und Observability für Cloud-Plattformen
SKAFFON baut und betreibt Metriken, Logs, Traces und die Alarmkette für Ihre Cloud- und Kubernetes-Plattformen, damit ein Alarm einen Zuständigen und eine Handlungsanweisung hat.
- Open-Source-Standards statt proprietärer Formate
- Betrieb und Support rund um die Uhr (24/7)
- Jeder Alarm mit Klasse und Steckbrief
01Ausgangslage
Monitoring scheitert selten am Werkzeug, sondern am Alarm
Zu viele Alarme, kein Zuständiger, keine Handlungsanweisung: So wird aus Überwachung Rauschen. Das Prometheus-Projekt fasst die Empfehlung knapp zusammen: Alarme einfach halten, auf Symptome alarmieren und keine Seiten auslösen, bei denen nichts zu tun ist (Prometheus, Alerting-Praxis). Genau darauf bauen wir den Betrieb.
Wer als IT-Leitung oder Plattformverantwortlicher wissen will, wer nachts auf einen Alarm reagiert und ob dieser Alarm überhaupt etwas bedeutet, findet hier unser Modell. Beratung und Methodik zur Zuverlässigkeit finden Sie unter SRE und Observability; diese Seite beschreibt den laufenden Betrieb.
02Signale
Was wir messen, sammeln und alarmieren
Wir arbeiten mit Open-Source-Standards, sodass Sie nicht an proprietäre Formate gebunden sind.
-
Metriken mit Prometheus
Für Infrastruktur, Kubernetes und Anwendungen; Exporter für Datenbanken, Server und weitere Komponenten.
-
Logs mit Loki
Loki indexiert nur die Labels der Log-Streams, nicht den Inhalt (Grafana Loki). Das hält den Betrieb schlank, macht aber die Wahl der Labels zur Entwurfsentscheidung.
-
Traces mit OpenTelemetry
Herstellerneutraler Rahmen für Traces, Metriken und Logs mit Collector und dem Protokoll OTLP (OpenTelemetry). Es ist selbst kein Backend, sondern liefert an die Ziele Ihrer Wahl. Wo Sie STACKIT nutzen, kann auch STACKIT Observability das Ziel sein, siehe Managed Kubernetes auf STACKIT.
-
Dashboards in Grafana
Je Plattform und je Dienst, mit Verweisen zu den zugehörigen Runbooks.
-
Alarmierung mit Alertmanager
Routing, Gruppierung, Unterdrückung und Stummschaltung; Aufschaltung auf Bereitschaft und Ticketsystem.
-
SLOs und Fehleranalyse
Auf Wunsch Service-Level-Ziele für Ihre Dienste und strukturierte Analyse nach Störungen.
03Alarmweg
Der Weg vom Signal zur Reaktion
Aus Rohsignalen wird erst durch die Alarmklasse eine Entscheidung: wecken, Ticket oder nur sichtbar.
04Alarmklassen
Welche Alarme nachts wecken und welche warten können
Die Matrix ist der Kern unseres Entwurfs. Jeder Alarm gehört in genau eine Klasse; ein Alarm ohne Klasse wird nicht aufgeschaltet.
| Klasse | Kriterium | Beispiel | Weg | Reaktion |
|---|---|---|---|---|
| Seite (sofort) | Nutzersichtbarer Fehler oder unmittelbar drohender Ausfall; ein Mensch kann jetzt etwas tun | Anwendung liefert Fehler an Nutzer; Zertifikat läuft in kurzer Frist ab; Backup-Kette gerissen | Bereitschaft | Nach Vertrag (24/7) |
| Ticket | Verlangt Handlung, aber nicht jetzt | Speicher füllt sich in absehbarer Zeit; wiederholt fehlgeschlagener unkritischer Job | Ticketsystem | Nächster Arbeitstag oder vereinbart |
| Dashboard | Information, kein Eingriff nötig | Einzelner Pod-Neustart, Auslastungstrend | Grafana | Im Bericht |
| Meta | Die Überwachung selbst ist gestört | Prometheus, Alertmanager nicht erreichbar | Seite, über unabhängigen Weg | Sofort |
Die Prometheus-Empfehlungen decken sich damit: Auf Latenz und Fehlerraten möglichst weit oben im Stack alarmieren, nur an einer Stelle im Stack auf Latenz alarmieren, Kapazitätsengpässe als Handlungsbedarf vor dem Ausfall behandeln und die Überwachung selbst überwachen, idealerweise ergänzt um externe Blackbox-Prüfungen. Konkrete Schwellwerte entstehen mit Ihren Diensten.
05Alertmanager
Ein Ausfall, eine Nachricht: Routing und Lärmschutz
Der Alertmanager fasst laut Dokumentation ähnliche Alarme zu einer Benachrichtigung zusammen (Gruppierung), unterdrückt Folgealarme, solange ein übergeordneter Alarm aktiv ist (Inhibition), und schaltet auf Zeit stumm (Silences). Das Routing ist ein Baum in der Konfiguration. Für Hochverfügbarkeit läuft er als Cluster; Prometheus soll laut Dokumentation auf die Liste aller Alertmanager zeigen und nicht über einen Load Balancer sprechen.
- Gruppierung nach Dienst und Umgebung, damit ein Ausfall eine Nachricht erzeugt, nicht fünfzig.
- Inhibition für Folgefehler: Ist der Cluster nicht erreichbar, schweigen die Alarme seiner Anwendungen.
- Routing nach Klasse und Zuständigkeit: Plattform an uns, Anwendung an Ihr Team (laut RACI).
- Silences nur mit Begründung und Ablauf, nachvollziehbar dokumentiert.
06Runbook-Kopf
Was im Steckbrief jedes Alarms steht
Jeder aufgeschaltete Alarm erhält einen Steckbrief, der im Alarmtext verlinkt ist. Alarme, die ohne Aktion verhallen, werden gelöscht oder herabgestuft; das ist Teil des regelmäßigen Reviews.
- Name und Klasse; Dienst und Umgebung
- Was bedeutet der Alarm für Nutzer?
- Auslösebedingung in Worten (die Regel steht im Code)
- Erste Diagnoseschritte mit Dashboard-Link
- Behebung oder Eskalation; Zuständiger laut RACI
- Letzte Überprüfung: wann wurde die Regel zuletzt auf Nutzen geprüft?
07Zuständigkeiten
Wer Plattform, Anwendung und Alarmregeln verantwortet
R = führt aus, A = trägt die Ergebnisverantwortung, C = wird konsultiert, I = wird informiert. Standardaufteilung; der Vertrag legt die endgültige Fassung fest.
| Tätigkeit | SKAFFON | Kunde |
|---|---|---|
| Monitoring-Plattform betreiben (Updates, Speicher, Hochverfügbarkeit) | R/A | I |
| Exporter und Instrumentierung auf Plattformebene | R/A | C |
| Instrumentierung im Anwendungscode (Metriken, Traces) | C | R/A |
| Alarmregeln für Plattform definieren | R/A | C |
| Alarmregeln für Anwendungen definieren | R | A |
| Alarm bewerten, Plattformstörung beheben | R/A | I |
| Störung in der Anwendung beheben | C | R/A |
| Dashboards pflegen | R | C |
| Aufbewahrungsdauer und Datenschutz der Logs festlegen | C | R/A |
| SLO festlegen (fachliche Ziele) | C | R/A |
| Regelmäßiger Alarm-Review | R | A |
Logs enthalten schnell personenbezogene Daten. Was geloggt wird und wie lange es aufbewahrt wird, entscheiden Sie; wir beraten zu Maskierung und Aufbewahrung, die rechtliche Bewertung liegt bei Ihnen.
08Laufender Betrieb
Wenn ein Alarm kommt: Incident, Change und Patch
Incident: Alarm, Einstufung nach Klasse, Eingrenzung anhand Dashboard und Logs, Behebung oder Workaround, Statusinformation, Abschluss mit Bestätigung, bei schweren Störungen Ursachenanalyse (Fehleranalyse) mit Maßnahmen, die auch Alarm und Dashboard verbessern.
Change: Alarmregeln, Dashboards und Routing liegen als Code im Repository; Änderungen laufen über Pull Requests mit Review und Freigabe.
Patch: Updates der Komponenten nach Beobachtung von Sicherheitsmeldungen und Release Notes, Test, Rollout im Fenster.
Betrieb und Support laufen 24/7. Prioritätsstufen P1 bis P4 und die Bedeutung der Reaktionszeit stehen im Servicelevel-Rahmen; Reaktionszeiten und Eskalationskette legt der Vertrag fest.
Kontinuität
Auch die Überwachung wird überwacht
Konfiguration, Regeln und Dashboards sind im Repository gesichert. Metrik- und Logdaten haben eine je Umgebung festgelegte Aufbewahrungsdauer; welche Daten zusätzlich gesichert werden müssen, hängt davon ab, ob sie Nachweisfunktion haben. Die Alarmkette wird redundant ausgelegt und zusätzlich über eine unabhängige Prüfung überwacht.
09Einstieg
Vom Signalinventar zum Parallelbetrieb
Alarmwege testen wir im Onboarding mit einem Probealarm.
- 01
Bestandsaufnahme
Ergebnis: ÜberblickDienste und bestehende Überwachung erfassen.
- 02
Signalinventar
Ergebnis: LückenWelche Metriken, Logs und Traces gibt es, welche fehlen?
- 03
Klassen und Zuständigkeiten
Ergebnis: AlarmmodellAlarmklassen festlegen, Verantwortung nach RACI zuordnen.
- 04
Plattform aufbauen oder übernehmen
Ergebnis: BetriebNeuaufbau oder Übernahme Ihrer bestehenden Komponenten.
- 05
Probealarm
Ergebnis: Alarmweg geprüftDie Alarmkette wird einmal komplett durchlaufen.
- 06
Parallelbetrieb
Ergebnis: UmstellungDie bisherige Lösung läuft weiter, bis die neue trägt; erst dann wird sie abgeschaltet.
10Passung
Welche Monitoring-Aufgaben wir übernehmen und welche nicht
Aufwand bestimmen die Zahl der überwachten Systeme und Umgebungen, Datenmengen für Metriken, Logs und Traces, Aufbewahrungsdauer, der Reifegrad der vorhandenen Instrumentierung, die Zahl der Alarmwege sowie das Servicefenster. Wir beginnen mit dem Signalinventar und legen daraus Umfang, RACI und Berichtsform fest; das Angebot ergänzt das Preismodell.
Das übernehmen wir
- Monitoring für Cloud- und Kubernetes-Plattformen betreiben, auch für Umgebungen, die Sie selbst oder Dritte betreiben.
- Bestehendes Monitoring nach Bestandsaufnahme übernehmen und Alarme bereinigen.
- SLOs für Ihre Dienste gemeinsam aus Ihren fachlichen Anforderungen ableiten; sie sind Ihre Ziele, nicht unsere Zusage.
Das liegt außerhalb
- Ein reines Werkzeug- oder Lizenzprodukt als Software as a Service ohne Betrieb durch Menschen.
- Überwachung von Endgeräten, Arbeitsplätzen oder Office-Netzen.
- Alarme für Anwendungen bewerten, die wir nicht kennen.
- Jedes Signal alarmieren: Das widerspricht dem Klassenmodell.
11
Häufige Fragen
Können Sie bestehendes Monitoring übernehmen?
Ja, nach einer Bestandsaufnahme. Oft beginnen wir mit einem Parallelbetrieb und bereinigen die Alarme.
Brauchen wir dafür OpenTelemetry?
Nein, nicht zwingend. Für Infrastruktur und Kubernetes genügt Prometheus. OpenTelemetry lohnt sich, wo Sie Traces und herstellerneutrale Instrumentierung in Anwendungen brauchen.
Veröffentlichen Sie Verfügbarkeitszahlen?
Verfügbarkeitsziele, Kennzahlen, Messmethode und Folgen bei Abweichung vereinbaren wir je Plattform vertraglich; die Systematik beschreibt der Servicelevel-Rahmen.
Wie laut ist Ihr Monitoring heute, und wer hört es?
Beschreiben Sie Ihre Plattform und Ihre heutige Alarmsituation. Fragen vorab beantworten wir über den Kontakt.