Kubernetes-Betriebsteams benötigen mehr als Dashboards, die CPU- und Speicherauslastung sowie Fehlerraten anzeigen. Die Komplexität cloudnativer Umgebungen führt dazu, dass eine einzelne Anfrage ein Ingress-Gateway, Dienste, Warteschlangen, Speicher und Hintergrundprozesse durchläuft, während Workloads kontinuierlich verschoben und Versionen ständig geändert werden. Daher kann ein Deployment auf dieser Ebene fehlerfrei erscheinen, während eine nachgelagerte Abhängigkeit, eine Wiederholungsschleife oder eine Überlastung eines Pfads in der Control Plane zu einer erhöhten Latenz führt.
In einem auf dem CNCF-Blog veröffentlichten Beitrag erläutert Neel Shah von Stackgen, dass die herkömmliche Überwachung vordefinierte Fragen beantwortet, etwa: Hat die CPU-Auslastung einen bestimmten Grenzwert überschritten? Und steigen die Fehler? Observability zielt dem Beitrag zufolge hingegen darauf ab, das Team bei der Untersuchung eines unerwarteten Problems zu unterstützen und vom Erkennen des Symptoms zum Verständnis von Ursache und Umfang zu gelangen.
Metriken eröffnen die Untersuchung, beenden sie aber nicht
Metriken bleiben der natürliche Ausgangspunkt, weil sie numerisch sind, sich effizient speichern und abfragen lassen und sich für Alarme sowie Trendanalysen eignen. In Kubernetes können sie eine Belastung der Nodes, Neustarts von Containern, steigende Anfragelatenzen, eine Verlangsamung des API-Servers oder einen Rückstau in Warteschlangen sichtbar machen.
Der Beitrag empfiehlt, für Dienste das RED-Muster zu nutzen, also Rate, Errors und Duration, sowie für die Infrastruktur das USE-Muster, also Utilization, Saturation und Errors. Diese Indikatoren helfen dabei, ein erstes Bild des Vorfalls zu zeichnen: Eine steigende Anfragerate bei stabiler Latenz unterscheidet sich von einer steigenden Dauer und Sättigung bei gleichbleibendem Datenverkehr.
Wenn jedoch jedes Detail in ein Label innerhalb einer Metrik umgewandelt wird, entsteht ein Cardinality-Problem, da die große Zahl einzigartiger Kombinationen die Kosten erhöht und Abfragen verlangsamt. Der Beitrag warnt ausdrücklich davor, Anfrage- oder Benutzer-IDs sowie nahezu eindeutige Werte in Metriken abzulegen; solche Details eignen sich besser für Logs oder Traces.
Jedes Signal beantwortet eine andere Frage
Logs ergänzen den lokalen Kontext, den Diagramme normalerweise nicht speichern. Wenn sie strukturiert sind und konsistente Felder wie Zeit, Schweregrad, Dienstname, Namespace, Containeridentität, Anfragepfad und Trace-Kontext verwenden, wird es einfacher, ein bestimmtes Ereignis mit dem Dienst oder Prozess zu verknüpfen, der es erzeugt hat. Eine Metrik kann darauf hindeuten, dass der Zahlungsdienst betroffen ist, während das Log eine abgelaufene Frist, eine Ausnahme oder einen Fehler in einer Abhängigkeit offenlegt.
Verteilte Traces beantworten dagegen eine andere Frage: Wie hat sich eine einzelne Anfrage durch das System bewegt, und wo wurde Zeit verbraucht? Ihre Bedeutung ist in Kubernetes besonders groß, weil ein Fehler über mehrere Dienste, Wiederholungsversuche, Grenzen von Warteschlangen oder Datenbankaufrufe verteilt sein kann. Durch die Weitergabe des Trace-Kontexts lassen sich verschiedene Segmente im Kontext einer einzelnen Anfrage verknüpfen, während gemeinsame semantische Konventionen dabei helfen, die Namen von Feldern und Attributen in Metriken, Logs und Traces zu vereinheitlichen.
Der Beitrag bezieht auch Profiling in das Gesamtbild ein. Nachdem die Metriken den langsamen Dienst identifiziert haben, der Trace den betroffenen Anfragepfad bestimmt und die Logs das lokale Ereignis erläutert haben, können Profiling-Daten dabei helfen, die Funktion oder den Codepfad zu bestimmen, der CPU oder Speicher verbraucht.
Was ändert sich während des Vorfalls in der Praxis?
Der Beitrag beschreibt das Beispiel eines Checkout-Dienstes, der nach einer neuen Bereitstellung beginnt, das Ziel für die Latenz zu überschreiten, während die CPU- und Speichermetriken normal bleiben. Die Metriken machen das Problem sichtbar. Anschließend zeigt ein Trace einer langsamen Anfrage, dass der größte Teil der Verzögerung im Schritt zur Zahlungsautorisierung entsteht. Danach erscheinen in den Logs wiederholte Timeout-Meldungen, die mit demselben Anfragekontext verbunden sind.
Diese Abfolge führt das Team von der allgemeinen Frage, warum der Zahlungsdienst langsamer geworden ist, zu konkreteren betrieblichen Optionen, etwa dem Zurücknehmen einer Änderung an einer Abhängigkeit, dem Verringern der Verstärkung durch Wiederholungsversuche oder der vorübergehenden Umleitung des Datenverkehrs während der Untersuchung. Der Beitrag betont außerdem, dass der bessere Alarm ein Risiko für die Dienstqualität oder das Zuverlässigkeitsziel abbildet und nicht lediglich eine rohe Belastung der Infrastruktur; als Beispiel nennt er einen Alarm, der mit einem Anstieg des p99-Werts der Antwortlatenz auf über eine Sekunde über einen Zeitraum von zehn Minuten verbunden ist.
Anwendbare Designregeln
- Mit den verfügbaren Metriken und Logs beginnen und die Abdeckung schrittweise erweitern, statt ziellos alles zu sammeln.
- Dimensionen bevorzugen, die mit dem Dienst und dem Workload verbunden sind, statt Metriken mit extrem hoher Eindeutigkeit zu versehen.
- Eine konsistente Metadatenstruktur in Metriken, Logs und Traces verwenden.
- Anfrage- oder Trace-IDs in Logs aufnehmen, um den Wechsel zwischen den Signalen zu erleichtern.
- Alarme auf Zuverlässigkeitsrisiken und Dienstqualität ausrichten und nicht ausschließlich auf Ressourcenbelastung.
- Observability als Teil des Anwendungs- und Plattformentwurfs betrachten und nicht als nachträgliche Ergänzung nach der Bereitstellung.
Redaktionelle Einordnung von certi.news: Der wesentliche Wert liegt hier nicht in der Aufforderung, ein bestimmtes Tool zu kaufen oder eine einzelne Implementierung zu übernehmen, sondern in der Neudefinition des Ziels von Observability. Was sich tatsächlich ändert, ist die Art der Datennutzung: Die Metrik erfasst die Abweichung, der Trace bestimmt den Pfad, das Log erklärt das Ereignis und das Profiling kann die Ursache auf Codeebene bestimmen. Es bestehen weiterhin klare praktische Einschränkungen: Das Sammeln von mehr Signalen garantiert kein besseres Verständnis, und das Fehlen einheitlicher Namen und Felder kann die Verknüpfung brüchig machen, während einzigartige Details die Kosten von Metriken erhöhen und die Abfrageleistung beeinträchtigen können. Der Nutzen hängt daher von der Qualität des Designs und der Verknüpfung zwischen den Signalen ab und nicht von der Anzahl der Dashboards.