Die drei Säulen der Observability: Logs, Metriken und Traces

Was sind Logs?

Logs – oder Protokolle – sind Dateien, die Ereignisse, Warnungen und Fehler aufzeichnen, die in einer Softwareumgebung auftreten. Die meisten Protokolle enthalten Kontextinformationen, zum Beispiel den Zeitpunkt eines Ereignisses und den Benutzer oder Endpunkt, der damit verbunden ist.

Eine Protokolldatei für einen Webserver enthält beispielsweise Informationen wie den Startzeitpunkt des Servers und die Anfragen von Clients sowie die zugehörige Reaktion der Server. Es werden sowohl Informationen über jede erfolgreiche Transaktion als auch über Fehler wie fehlgeschlagene Verbindungen zu Clients aufgezeichnet.

Fehler und Warnungen werden manchmal in separaten Protokolldateien aufgezeichnet, oft gibt es aber auch nur eine Datei für alle Ereignisse. Für Observability-Programme ist das jedoch unerheblich, da sie ohnehin die Logs zusammenfassen und gemeinsam analysieren.

Vorteile und Grenzen von Logs

Protokolle sind ein Grundpfeiler der Observability, da sie eine umfassende Aufzeichnung aller Ereignisse und Fehler bieten, die während des Lebenszyklus von Software-Ressourcen auftreten. Wenn Sie wissen wollen, wann ein Problem aufgetreten ist oder welche Ereignisse oder Trends damit korrelieren, sind Protokolle eine hervorragende Quelle.

Allerdings taugen sie nicht als alleinige Quelle für Informationen. Ein großes Manko ist, dass der Umfang der aufgezeichneten Ereignisse erheblich von der Vorkonfiguration abhängt. Wenn Ihre Protokollierungs-Tools und -einstellungen nicht so konfiguriert sind, dass bestimmte Informationen aufgezeichnet werden, erscheinen sie nicht in Ihren Protokolldateien.

Ein weiteres Problem bei der Observability von Protokollen ist, dass die Protokolldaten nicht immer lang genug gespeichert werden. In den meisten Fällen verschwinden beispielsweise die von containerisierten Anwendungen erstellten Protokolle endgültig, wenn der Container heruntergefahren wird. Sie können dieses Problem lösen, indem sie die Protokolldaten an einen anderen Ort verschieben, während der Container noch läuft, aber es besteht immer noch das Risiko, dass einige Protokolldateien verloren gehen.

Was sind Metriken?

Metriken sind quantifizierbare Messwerte, die den Zustand und die Leistung von Anwendungen oder der Infrastruktur widerspiegeln. Anwendungsmetriken erfassen beispielsweise, wie viele Transaktionen die Anwendung pro Sekunde verarbeitet, während Infrastrukturmetriken messen, wie viele CPU- oder Speicherressourcen auf einem Server belegt sind.

Es gibt viele Arten von Metriken, die Sie erheben lassen können. Zwei beliebte Methoden, um Metriken zu bestimmen, sind die RED-Methode von Weaveworks, die sich auf Raten, Fehler und Anfragedauer konzentriert, und die Golden Signals-Methode von Google, die Latenz, Verkehr, Fehler und Sättigung misst.

Vorteile und Grenzen von Metriken

Der Hauptvorteil von Metriken ist, dass sie einen Echtzeiteinblick in den Zustand der Ressourcen bieten. Wenn Sie wissen wollen, wie reaktionsschnell Ihre Anwendung ist, oder Anomalien erkennen wollen, die frühe Anzeichen für ein Leistungsproblem sein könnten, sind Metriken eine wichtige Quelle der Transparenz.

Durch das Korrelieren von Metriken mit Daten aus Protokollen und Traces erhalten Sie den größtmöglichen Kontext zur Systemleistung oder zu potenziellen Verfügbarkeitsproblemen. Aus diesem Grund sind Metriken für die Observability besonders wichtig.

Wie Protokolle erfassen Metriken jedoch nur die Anwendungs- und Infrastrukturdaten, die Sie vorab festgelegt haben. Darüber hinaus sind Metriken in der Regel nicht dazu geeignet, die Ursache eines Problems zu ermitteln, insbesondere nicht in einem komplexen verteilten System. So können Metrikdaten beispielsweise darauf hinweisen, dass Ihre Anwendung eine hohe Fehlerquote aufweist, doch Sie können anhand der vorhandenen Informationen nicht genau ermitteln, welcher Dienst innerhalb einer Microservices-Architektur die Fehler auslöst.

Was sind verteilte Traces?

Eine verteilte Trace ist ein Datensatz, der eine Anfrage verfolgt, während sie die verschiedenen Teile einer Anwendung durchläuft. Traces zeichnen auf, wie lange jede Anwendungskomponente braucht, um die Anfrage zu verarbeiten und das Ergebnis an die nächste Komponente weiterzuleiten. Traces können auch aufzeigen, welche Teile der Anwendung einen Fehler auslösen.

Vorteile und Grenzen von verteilten Traces

Wenn Sie die Ursache eines Problems erforschen müssen, sind verteilte Traces der effektivste Weg, dies zu erreichen. Obwohl Sie anhand der Protokolle und Metriken feststellen können, dass es ein Problem gibt, ist es in Microservices-Umgebungen ohne Traces schwierig, seine Ursache zu finden.

Die größte Einschränkung bei verteilten Traces ist, dass Sie in den meisten Fällen nur einen Bruchteil aller Anwendungsanfragen verfolgen können. Das Ausführen von Traces benötigt zu viel Zeit und verbraucht zu viele Ressourcen, um jede davon zu überwachen. Das bedeutet, dass Sie nicht immer Tracing-Daten zur Verfügung haben, wenn ein Fehler auftritt.

Oft ist es nicht möglich, aus den Traces der einen Anfrage zu extrapolieren, woher die Fehler bei einer anderen Anfrage kommen. Die Informationen zu Anfragen, Endpunkten und clientseitigen Konfigurationen variieren oft zu sehr zwischen den einzelnen Vorgängen.

Wie arbeiten Protokolle, Metriken und Traces zusammen?

Wie bereits erwähnt, bieten Protokolle, Metriken und Traces jeweils einen wertvollen, aber begrenzten Einblick in die Softwareumgebung. Wenn Sie die drei kombinieren, erhalten Sie jedoch ein relativ vollständiges Bild der Vorgänge in Ihrem System.

So können Sie beispielsweise bei der kontinuierlichen Verfolgung von Metriken feststellen, dass sich die Antwortrate der Anwendung verlangsamt, was auf ein Leistungsproblem hindeutet. Bevor Sie jedoch von einem Problem ausgehen, sollten Sie in den Anwendungsprotokollen nachsehen, ob Sie die langsameren Antworten durch eine harmlose Änderung erklären können, zum Beispiel wenn die Anwendung komplexere Transaktionen verarbeitet als normalerweise. Wenn Sie feststellen, dass die Leistungsverschlechterung der Anwendung auf einen Fehler zurückzuführen ist, können Sie anhand der verteilten Trace-Daten feststellen, welcher spezifische Microservice davon betroffen ist.

Kritische Anmerkungen zu den drei Säulen

Die drei Säulen der Observability bilden eine solide Grundlage für die Überwachung Ihrer Systeme. Sie sollten sich jedoch nicht auf diese beschränken. Je mehr Daten Sie haben, um die Beobachtungs-Workflows zu informieren, desto besser.

So kann es beispielsweise sinnvoll sein, Protokolle, Metriken und Traces mit Daten aus einer CI/CD-Pipeline zu kontextualisieren, um festzustellen, welche Anwendungsaktualisierung oder -umverteilung mit einer Leistungsverschlechterung korreliert. Ebenso können Geschäftsmetriken, wie zum Beispiel Kundenbindungsraten, mit technischen Beobachtungsmetriken korreliert werden, um die Auswirkungen von technischen Problemen auf die Geschäftsleistung zu messen.

Wenn Sie Cloud-native Umgebungen beobachten möchten, sollten Sie damit beginnen, Protokolle, Metriken und Traces zu sammeln und zu analysieren. Dies sind nicht die einzigen potenziellen Quellen der Observability, aber sie sind die wichtigsten, was sie zu den drei Säulen der Observability macht.