Strukturierte Protokollierung, die alle glücklich macht

Wenn wir unsere Software ausführen, möchten wir natürlich sehen und verstehen, was passiert und wie gut unsere Software funktioniert. Um dies zu erreichen, benötigen wir Beobachtbarkeit als Schlüsseleigenschaft für unsere Software. Beobachtbarkeit ist ein Maß dafür, wie gut die internen Zustände eines Systems aus der Kenntnis seiner externen Ausgaben abgeleitet werden können. Aus dieser Definition, die der Kontrolltheorie entlehnt ist, ergibt sich, dass Metriken, Tracing und Protokollierung wichtige Themen sind, die in Ihrem Softwaresystem implementiert werden müssen.

Zwei dieser Säulen, Metriken und Rückverfolgung, sind ebenfalls von großer Bedeutung, damit Sie sich ein vollständiges Bild machen können. In diesem Blogbeitrag werde ich mich darauf konzentrieren, wie Sie den größten Nutzen aus Ihrer Protokollierung ziehen können.

Strukturiert, zentralisiert und normalisiert

Glücklicherweise war ich noch nie in einer Umgebung, in der überhaupt keine Protokollierung implementiert war. Normalerweise gibt es zumindest eine dateibasierte Klartextprotokollierung, die einen gewissen Einblick in Ihre Anwendung gewährt. Ein hervorragender Anfang zur Verbesserung dieser Art von Protokollierung ist der Übergang von der Klartextprotokollierung zur strukturierten Protokollierung. Dies kann wie folgt geschehen:

1. Schreiben der Log-Statements als json-Blobs.
2. Erfassen Sie sie auf einer zentralen Plattform, die in der Lage ist, sie zu analysieren.

Jetzt, da wir über eine strukturierte und zentralisierte Protokollierung verfügen, können wir die Protokollangaben mühelos durchsuchen, filtern und abfragen. Vielleicht sogar von mehreren Anwendungen gleichzeitig.

enn wir Daten aus verschiedenen Quellen betrachten, haben wir einen weiteren Wunsch: normalisierte Protokolle. Um dies zu erreichen, sollten alle Anwendungen ihre Protokollanweisungen auf die gleiche Weise strukturieren. Ziehen Sie beim Einrichten einer neuen Anwendung die Verwendung einer wiederverwendbaren Protokollierungskomponente oder einer Standardkonfiguration für die Protokollierung in Betracht.

Einblicke?

Jetzt, da wir unsere grundlegende Instrumentierung mit einer strukturierten, zentralisierten und normalisierten Protokollierung eingerichtet haben, sind wir mit der Beobachtbarkeit auf einem guten Weg. Wir können gleichzeitig alle unsere Anwendungen abfragen, nach bestimmten Ausnahmen suchen und Fehlerprotokolle herausfiltern.

Wenn Ihre Umgebung so ist wie die, in der ich gearbeitet habe, sind Sie wahrscheinlich mit Daten von unklarer Bedeutung überladen. Nur weil Sie eine strukturierte Protokollierung haben, heißt das noch lange nicht, dass sich die Protokollierung auch lohnt. Anders ausgedrückt: Nur weil Sie Tools zur Beobachtung installiert haben, bedeutet das nicht, dass Sie mehr sehen.

Wie einfach ist es also, daraus echte Erkenntnisse zu gewinnen?

Reinigung

Wir brauchen eine Strategie, um von der strukturierten Protokollierung zu Informationen zu gelangen. Es kann helfen, sich ein konkretes Ziel zu setzen. Z.B.: "Jede Protokollanweisung mit dem Schweregrad Fehler sollte ein tatsächlicher Fehler sein." Mit anderen Worten: Eine Protokollanweisung mit dem Schweregrad Fehler sollte darauf hinweisen, dass etwas schief gelaufen ist, d.h. dass eine Operation nicht erfolgreich ausgeführt werden konnte. Ein solches Ziel kann sich in vielen Situationen als nützlich erweisen.

Also habe ich mir dieses Ziel in einem meiner letzten Projekte gesetzt. Bei der Durchsicht der Protokolle habe ich festgestellt, dass es zwei weitere Typen gibt:

1. Der Schweregrad ist eigentlich vom Typ Warnung. Es ist etwas Unerwartetes passiert, aber die Anwendung kann sich davon erholen.
2. Es handelt sich um einen Fehler oder einen fehlenden Geschäftsablauf. Alles funktioniert korrekt für eine erfolgreiche Ausführung; es gibt nur einen Fehler im Code.

Nun, da ich mir dieses Ziel gesetzt hatte, brauchte ich einen Weg, um es zu erreichen. Ich führte eine Routine ein:

• Jeden Morgen, in den ~30 Minuten zwischen meinem Morgenkaffee und dem Stand-up-Meeting, habe ich das häufigste Fehlermuster aufgespürt.
• Weil wir in 30 Minuten nur so viel tun können, können wir entweder:
  • das Fehlermuster innerhalb der 30 Minuten lösen, oder
  • weitere Untersuchungen vorzubereiten und zu planen. Dazu gehören eine detailliertere Protokollanalyse und die Verwendung von Metriken und Tracing, um ein vollständiges Bild zu erhalten. Im letzteren Fall würde ich in der Regel ein Ticket für das Product Backlog erstellen

Die Ergebnisse der Routine? Nach nur wenigen Wochen war die Anzahl der Fehlerprotokolle deutlich reduziert. Und nach ein paar Monaten hatte ich mein Ziel erreicht.

Zusammenfassend lässt sich sagen, dass wir jetzt das Fehlerprotokoll nutzen können, um wertvolle Einblicke in den Zustand unserer Anwendungslandschaft zu erhalten - ein entscheidender Schritt und ein Werkzeug im größeren Werkzeugkasten der progressiven Bereitstellung.

Nächste Schritte, auch ein Wort der Warnung

Bei der Beobachtbarkeit geht es nicht nur um die Werkzeuge, sondern auch darum, sie mit nützlichen Daten zu versorgen.

Wir können nicht davon ausgehen, dass das, was wir einmal bereinigt haben, auch so bleibt. Bei jeder Änderung, die wir vornehmen, müssen wir unsere Anforderungen an die Beobachtbarkeit berücksichtigen. Beantworten Sie die folgenden Fragen: Welche Protokollierung brauchen wir? Welche Daten oder Tags sollten darin enthalten sein? Welche Metriken sollten wir hinzufügen, um Einblicke in unsere Service Level Ziele zu erhalten?

Wenn es zu viele Fehler gibt, die es zu untersuchen gilt, und wenn alles, was Sie sehen, ein Haufen bedeutungsloser Daten ist, wird sich einfach niemand damit befassen.