Beobachtbarkeitsmuster

Ebenso wie Muster entwickelt wurden, um das Layout von Code in Anwendungen zu unterstützen, gibt es Muster für die Bedienung von Anwendungen auf zuverlässige Weise. Drei nützliche Muster bei der Verwaltung von Anwendungen sind entstanden: Protokollierung, Überwachung und Warnungen.

Empfohlene Verwendung der Protokollierung

Unabhängig davon, wie vorsichtig wir sind, verhalten sich Anwendungen fast immer auf unerwartete Weise in der Produktion. Wenn Benutzer Probleme mit einer Anwendung melden, ist es hilfreich, zu sehen, was mit der App passiert ist, wenn das Problem aufgetreten ist. Eine der bewährten und wahrsten Methoden zum Erfassen von Informationen darüber, was eine Anwendung während der Ausführung ausführt, besteht darin, dass die Anwendung ihre Aufgaben notiert. Dieser Prozess wird als Protokollierung bezeichnet. Wann immer Fehler oder Probleme in der Produktion auftreten, sollte das Ziel sein, die Bedingungen zu reproduzieren, unter denen die Fehler aufgetreten sind, in einer Nichtproduktionsumgebung. Eine gute Protokollierung bietet Entwicklern eine Orientierungshilfe, die sie befolgen können, um Probleme in einer Umgebung zu duplizieren, die getestet und in der experimentiert werden kann.

Herausforderungen bei der Protokollierung mit cloudeigenen Anwendungen

In herkömmlichen Anwendungen werden Protokolldateien in der Regel auf dem lokalen Computer gespeichert. Tatsächlich gibt es auf Unix-ähnlichen Betriebssystemen eine Ordnerstruktur, die für alle Protokolle definiert ist, in der Regel unter /var/log.

Abbildung 7–1. Protokollierung in eine Datei in einer monolithischen App.

Die Nützlichkeit der Protokollierung in einer Flatfile auf einem einzelnen Computer wird in einer Cloudumgebung erheblich eingeschränkt. Anwendungen, die Protokolle produzieren, haben möglicherweise keinen Zugriff auf den lokalen Datenträger, oder der lokale Datenträger ist sehr vorübergehend, da Container um physische Computer herum angeordnet werden. Selbst einfache Skalierung von monolithischen Anwendungen über mehrere Knoten hinweg kann es schwierig machen, die entsprechende dateibasierte Protokolldatei zu finden.

Abbildung 7–2. Protokollierung in Dateien in einer skalierten monolithischen App.

Cloud-native Anwendungen, die mit einer Microservices-Architektur entwickelt wurden, stellen auch einige Herausforderungen für dateibasierte Logger dar. Benutzeranforderungen umfassen möglicherweise mehrere Dienste, die auf verschiedenen Computern ausgeführt werden, und umfassen serverlose Funktionen ohne Zugriff auf ein lokales Dateisystem überhaupt. Es wäre sehr schwierig, die Protokolle von einem Benutzer oder einer Sitzung über diese vielen Dienste und Computer hinweg zu korrelieren.

Abbildung 7–3. Protokollierung in lokalen Dateien in einer Microservices-App.

Schließlich ist die Anzahl der Benutzer in einigen cloudeigenen Anwendungen hoch. Stellen Sie sich vor, dass jeder Benutzer hunderte Protokollnachrichten generiert, wenn er sich bei einer Anwendung anmeldet. In Isolation ist das überschaubar, aber wenn man das auf 100.000 Benutzer hochrechnet, wird das Volumen der Protokolle so groß, dass spezielle Tools erforderlich sind, um die effektive Nutzung der Protokolle zu unterstützen.

Anmelden in cloudeigenen Anwendungen

Jede Programmiersprache verfügt über Tools, die das Schreiben von Protokollen zulassen, und in der Regel ist der Aufwand zum Schreiben dieser Protokolle gering. Viele der Log-Bibliotheken bieten das Protokollieren verschiedener Arten von Kritikalitäten an, die zur Laufzeit angepasst werden können. Beispielsweise ist die Serilog-Bibliothek eine beliebte strukturierte Protokollierungsbibliothek für .NET, die die folgenden Protokollierungsebenen bereitstellt:

• Ausführlich
• Fehlersuche
• Informationen
• Warnung
• Fehler
• Tödlich

Diese verschiedenen Protokollebenen bieten Granularität bei der Protokollierung. Wenn die Anwendung in der Produktion ordnungsgemäß funktioniert, kann sie so konfiguriert werden, dass nur wichtige Nachrichten protokolliert werden. Wenn die Anwendung falsch funktioniert, kann die Protokollebene erhöht werden, sodass ausführlichere Protokolle gesammelt werden. Dies schafft ein Gleichgewicht zwischen Leistung und einfachem Debuggen.

Die hohe Leistung der Logging-Tools und die Anpassbarkeit der Ausführlichkeit sollten Entwickler dazu ermutigen, häufig zu protokollieren. Viele bevorzugen ein Muster zum Protokollieren des Eintrags und Beendens jeder Methode. Dieser Ansatz klingt möglicherweise wie übertrieben, aber es ist nicht üblich, dass Entwickler weniger Logging wünschen. In der Tat ist es nicht ungewöhnlich, dass eine Bereitstellung nur zu dem Zweck erfolgt, die Protokollierung zu einer problematischen Methode hinzuzufügen. Achten Sie darauf, dass Sie lieber zu viel und nicht zu wenig protokollieren. Einige Tools können verwendet werden, um diese Art von Protokollierung automatisch bereitzustellen.

Aufgrund der Herausforderungen, die mit der Verwendung dateibasierter Protokolle in cloudeigenen Apps verbunden sind, werden zentralisierte Protokolle bevorzugt. Protokolle werden von den Anwendungen erfasst und an eine zentrale Protokollierungsanwendung ausgeliefert, die die Protokolle indiziert und speichert. Diese Systemklasse kann täglich zehn Gigabyte Von Protokollen aufnehmen.

Es ist auch hilfreich, einige Standardpraktiken beim Erstellen von Protokollierungen zu befolgen, die viele Dienste umfassen. Wenn Sie beispielsweise zu Beginn einer langen Interaktion eine Korrelations-ID generieren und diese dann in jeder Nachricht protokollieren, die sich auf diese Interaktion bezieht, können Sie einfacher nach allen zugehörigen Nachrichten suchen. Man muss nur eine einzelne Nachricht finden und die Korrelations-ID extrahieren, um alle zugehörigen Nachrichten zu finden. Ein weiteres Beispiel stellt sicher, dass das Protokollformat für jeden Dienst, unabhängig von der verwendeten Sprache oder Protokollierungsbibliothek, identisch ist. Diese Standardisierung erleichtert das Lesen von Protokollen erheblich. Abbildung 7-4 zeigt, wie eine Microservices-Architektur die zentralisierte Protokollierung als Teil des Workflows nutzen kann.

Abbildung 7-4. Protokolle aus verschiedenen Quellen werden in einen zentralen Protokollspeicher aufgenommen.

Herausforderungen bei der Erkennung und Reaktion auf potenzielle App-Gesundheitsprobleme

Einige Anwendungen sind nicht unternehmenskritisch. Vielleicht werden sie nur intern verwendet, und wenn ein Problem auftritt, kann der Benutzer das zuständige Team kontaktieren und die Anwendung kann neu gestartet werden. Kunden haben jedoch häufig höhere Erwartungen an die von ihnen verbrauchten Anwendungen. Sie sollten wissen, wann Probleme mit Ihrer Anwendung auftreten, bevor Benutzer dies tun, oder bevor Benutzer Sie benachrichtigen. Andernfalls wissen Sie möglicherweise das erste Mal von einem Problem, wenn Sie eine wütende Flut von Social Media-Beiträgen bemerken, die Ihre Anwendung oder sogar Ihre Organisation verhöhnen.

Einige Szenarien, die Sie möglicherweise berücksichtigen müssen, umfassen:

• Ein Dienst in Ihrer Anwendung schlägt ständig fehl und startet neu, was zu sporadisch langsamen Antworten führt.
• Zu einigen Tageszeiten ist die Reaktionszeit Ihrer Anwendung langsam.
• Nach einer letzten Bereitstellung hat sich die Auslastung der Datenbank verdreifacht.

Die ordnungsgemäße Implementierung kann Sie über Bedingungen informieren, die zu Problemen führen, sodass Sie zugrunde liegende Bedingungen beheben können, bevor sie zu erheblichen Auswirkungen des Benutzers führen.

Überwachen von cloudeigenen Apps

Einige zentralisierte Protokollierungssysteme übernehmen eine zusätzliche Rolle beim Sammeln von Telemetrie außerhalb von reinen Protokollen. Sie können Metriken sammeln, z. B. Zeit zum Ausführen einer Datenbankabfrage, durchschnittliche Reaktionszeit von einem Webserver und sogar CPU-Auslastungsdurchschnitte und Arbeitsspeicherdruck, wie vom Betriebssystem gemeldet. In Verbindung mit den Protokollen können diese Systeme einen ganzheitlichen Überblick über die Integrität von Knoten im System und die Anwendung insgesamt bieten.

Die Metrikerfassungsfunktionen der Überwachungstools können auch manuell aus der Anwendung gespeist werden. Geschäftsflüsse, die von besonderem Interesse sind, wie etwa neue Nutzerregistrierungen oder Auftragserteilungen, können so konfiguriert werden, dass sie einen Zähler im zentralen Überwachungssystem erhöhen. Dieser Aspekt entsperrt die Überwachungstools, um nicht nur die Integrität der Anwendung zu überwachen, sondern auch die Integrität des Unternehmens.

Abfragen können in den Protokollaggregationstools erstellt werden, um nach bestimmten Statistiken oder Mustern zu suchen, die dann in grafischer Form auf benutzerdefinierten Dashboards angezeigt werden können. Häufig investieren Teams in große, wandmontierte Displays, die sich durch die Statistiken im Zusammenhang mit einer Anwendung drehen. Auf diese Weise ist es einfach, die Probleme zu sehen, während sie auftreten.

Cloud-native Monitoring-Tools bieten Echtzeit-Telemetrie und Einblicke in Apps, unabhängig davon, ob sie single-process monolithische Anwendungen oder verteilte Microservice-Architekturen sind. Sie umfassen Tools, mit denen Daten aus der App gesammelt werden können, sowie Tools zum Abfragen und Anzeigen von Informationen zum Zustand der App.

Herausforderungen beim Reagieren auf kritische Probleme in cloudeigenen Apps

Wenn Sie auf Probleme mit Ihrer Anwendung reagieren müssen, müssen Sie das richtige Personal benachrichtigen. Dies ist das dritte cloudeigene Anwendungsbeobachtbarkeitsmuster und hängt von der Protokollierung und Überwachung ab. Ihre Anwendung muss sich anmelden, damit Probleme diagnostiziert werden können und in einigen Fällen in Überwachungstools eingespeist werden können. Es muss überwacht werden, um Anwendungsmetriken und Zustandsdaten an einem zentralen Ort zu aggregieren. Sobald dies eingerichtet wurde, können Regeln erstellt werden, die Warnungen auslösen, wenn bestimmte Metriken außerhalb akzeptabler Ebenen fallen.

In der Regel werden Warnungen auf einer Ebene über die Überwachung gelegt, sodass bestimmte Bedingungen entsprechende Warnungen auslösen, um Teammitglieder über dringende Probleme zu informieren. Einige Szenarien, die Benachrichtigungen erfordern können, umfassen:

• Einer der Dienste Ihrer Anwendung reagiert nach 1 Minute Ausfallzeit nicht.
• Ihre Anwendung gibt erfolglose HTTP-Antworten auf mehr als 1 % der Anforderungen zurück.
• Die durchschnittliche Antwortzeit Ihrer Anwendung für wichtige Endpunkte überschreitet 2000 ms.

Warnungen in cloudeigenen Apps

Sie können Abfragen für die Überwachungstools erstellen, um nach bekannten Fehlerbedingungen zu suchen. Beispielsweise könnten Abfragen die eingehenden Protokolle nach Hinweisen auf HTTP-Statuscode 500 durchsuchen, was auf einem Webserver ein Problem hinweist. Sobald eine dieser Erkannt wird, kann eine E-Mail oder eine SMS an den Besitzer des Ursprungsdiensts gesendet werden, der mit der Untersuchung beginnen kann.

Normalerweise reicht jedoch ein einzelner 500-Fehler nicht aus, um festzustellen, dass ein Problem aufgetreten ist. Dies könnte bedeuten, dass ein Benutzer sein Kennwort falsch eingegeben oder einige falsch formatierte Daten eingegeben hat. Die Warnungsabfragen können so gestaltet werden, dass sie nur ausgelöst werden, wenn eine größere als durchschnittliche Anzahl von 500 Fehlern erkannt wird.

Eines der schädlichsten Muster bei der Alarmierung besteht darin, so viele Alarme auszulösen, dass Menschen sie nicht mehr untersuchen können. Servicebesitzer werden schnell desensibilisiert gegenüber Fehlern, die sie zuvor untersucht und festgestellt haben, dass sie ungefährlich sind. Wenn dann echte Fehler auftreten, gehen sie im Rauschen von Hunderten falsch positiver Ergebnisse verloren. Das Gleichnis vom Jungen, der Wolf rief, wird häufig Kindern erzählt, um sie vor dieser Gefahr zu warnen. Es ist wichtig, sicherzustellen, dass die ausgelösten Warnungen auf ein echtes Problem hinweisen.