Eine Vision zur Beobachtbarkeit in der Praxis

Einer der wichtigsten Trends in der Software-Infrastruktur im Jahr 2019 ist die Beobachtbarkeit .

Es hat in letzter Zeit viel Aufmerksamkeit gewonnen.

Was ist Beobachtbarkeit?

Es gibt viele Diskussionen und Witze über diesen Begriff. Zum Beispiel:

• Warum es Überwachung nennen? Das ist nicht mehr sexy genug.
• Beobachtbarkeit, da das Umbenennen von Ops in DevOps nicht schlecht genug war, wird jetzt auch die Überwachung devopsifiziert.
• Der neue Chuck Norris von DevOps.
• Ich bin ein Ingenieur, der die anderen Ingenieure in der Organisation überwachen kann.
• > Großartig, hier sind 80.000 US-Dollar.
• Ich bin ein Architekt, der dazu beitragen kann, die Beobachtbarkeit für Cloud-native, container-basierte Anwendungen zu gewährleisten.
• > Super! Hier sind 300.000 US-Dollar!

Cindy sridharan

Was ist der Unterschied zwischen Überwachung und Beobachtbarkeit, wenn es eine gibt?

Rückblick ...

Vor Jahren haben wir unsere Software hauptsächlich auf physischen Servern ausgeführt. Unsere Anwendungen waren Monolithen, die auf LAMP oder anderen Stapeln aufgebaut waren. Das Überprüfen der Betriebszeit war so einfach wie das Senden regulärer Pings und das Überprüfen der CPU- / Festplattenauslastung für Ihre Anwendung.

Paradigmenwechsel

Der Hauptparadigmenwechsel kam aus den Bereichen Infrastruktur und Architektur. Cloud-Architekturen, Microservices, Kubernetes und unveränderliche Infrastrukturen veränderten die Art und Weise, wie Unternehmen Systeme erstellen und betreiben.



Infolge der Übernahme dieser neuen Ideen sind die von uns gebauten Systeme immer verteilter und kurzlebiger geworden.

Virtualisierungs-, Containerisierungs- und Orchestrierungsframeworks sind für die Bereitstellung von Rechenressourcen verantwortlich, und die Behandlung von Fehlern schafft eine Abstraktionsschicht für Hardware und Netzwerk.

Um von der zugrunde liegenden Hardware und dem Netzwerk zu abstrahieren, müssen wir uns darauf konzentrieren, dass unsere Anwendungen im Kontext unserer Geschäftsprozesse wie beabsichtigt funktionieren.

Was ist Überwachung?

Die Überwachung bezieht sich im Wesentlichen auf den Betrieb, das Testen auf die Softwareentwicklung. Tatsächlich überprüfen Tests das Verhalten von Systemkomponenten anhand einer Reihe von Eingaben in einer Sandbox-Umgebung, normalerweise mit einer großen Anzahl verspotteter Komponenten.



Das Hauptproblem ist, dass die Menge möglicher Probleme in der Produktion in keiner Weise durch Tests abgedeckt werden kann. Die meisten Probleme in einem ausgereiften, stabilen System sind Unbekannte, die sich nicht nur auf die Softwareentwicklung selbst, sondern auch auf die reale Welt beziehen.

Black Box vs. White-Box-Überwachung

Es gibt zwei Ansätze zur Überwachung.

Bei der Black-Box-Überwachung behandeln wir das System oder Teile davon als Black-Box und testen sie im Freien. Dies kann bedeuten, dass API-Aufrufe, Ladezeiten oder die Verfügbarkeit verschiedener Teile des Systems überprüft werden. In diesem Fall ist die Menge an Informationen über und die Kontrolle über das System begrenzt.



White-Box-Überwachung bezieht sich auf die Situation, in der wir Informationen aus den Interna des Systems ableiten. Dies ist keine revolutionäre Idee, hat aber in letzter Zeit viel Aufmerksamkeit auf sich gezogen.



Observability ist also nur ein anderer Name für die White-Box-Überwachung? Nicht ganz.

Warum wir eine neue Art der Überwachung brauchen

Oft wird zwischen Überwachung und dem Konzept der Beobachtbarkeit unterschieden, wobei letzteres als etwas definiert wird, das auf die eine oder andere Weise Daten über den Zustand der Infrastruktur / Apps und Leistungsspuren sammelt (https://thenewstack.io/monitoring-and) -Beobachtbarkeit-was-ist-der-Unterschied-und-warum-macht-es-wichtig /).

Oder laut Honeycomb.io :

• "Sie überprüfen den Status und das Verhalten Ihrer Systeme anhand einer bekannten Basislinie, um festzustellen, ob sich etwas nicht wie erwartet verhält."
• "Sie können Nagios-Schecks ausstellen, um sicherzustellen, dass einige Dinge innerhalb der bekannten guten Schwellenwerte liegen."
• "Sie können Dashboards mit Graphite oder Ganglia erstellen, um Sätze nützlicher Diagramme zu gruppieren."
• "All dies sind hervorragende Werkzeuge, um die bekannten Unbekannten über Ihr System zu verstehen."

Ein großes Ökosystem von Produkten wie New Relic, HP und AppDynamics hat sich entwickelt. Alle diese Tools eignen sich perfekt für die Überwachung auf niedriger und mittlerer Ebene oder zum Entwirren von Leistungsproblemen.

Sie können jedoch keine Abfragen zu Daten mit einer hohen Kardinalität verarbeiten und sind bei Problemen, die mit Integrationsproblemen von Drittanbietern oder dem Verhalten großer komplexer Systeme mit Schwärmen von Diensten in modernen virtuellen Umgebungen zusammenhängen, schlecht.

Warum Dashboards nutzlos sind

Eigentlich sind sie nicht. Aber nur, wenn Sie wissen, wann und wo Sie zuschauen müssen. Ansonsten ist es besser, YouTube anzuschauen.

Dashboards werden nicht skaliert.

Stellen Sie sich eine Situation vor, in der Sie eine Reihe von Metriken haben, die sich auf Ihre Infrastruktur beziehen (z. B. CPU-Auslastung / Festplattenkontingente) und Apps (z. B. JVM-Zuordnungsgeschwindigkeit / GC-Läufe) usw. Die Gesamtzahl dieser Metriken kann leicht auf Tausende oder Zehntausende anwachsen. Alle Ihre Dashboards sind grün, aber dann tritt ein Problem in einem Integrationsdienst eines Drittanbieters auf. Ihre Dashboards sind immer noch grün, aber die Endbenutzer sind bereits betroffen.

Sie beschließen, Ihrer Überwachung Integrationsdienstprüfungen von Drittanbietern hinzuzufügen und eine zusätzliche Reihe von Metriken und Dashboards auf Ihrem Fernsehgerät abzurufen. Bis der nächste Fall entsteht.

Auf die Frage, warum Kunden eine Website nicht öffnen können, sieht die Antwort häufig folgendermaßen aus:



Die Spaghettifizierung von Dashboards

Während die Telemetrie verschiedener Teile des Systems üblich ist, endet sie normalerweise mit einem Bündel Spaghetti, die auf einem Armaturenbrett gezeichnet sind.

Dies sind die Betriebsmetriken von GitLab, die für die Öffentlichkeit zugänglich sind.

Und dies ist nur ein kleiner Teil einer ganzen Armee von Dashboards



Es sieht aus wie ein Wandteppich, bei dem es leicht ist, den Faden zu verlieren.

Protokollaggregation

Protokollaggregationstools wie ELK Stack oder Splunk werden von der überwiegenden Mehrheit der modernen IT-Unternehmen verwendet. Diese Instrumente sind erstaunlich hilfreich für die Ursachenanalyse oder für Obduktionen. Sie können auch verwendet werden, um einige Bedingungen zu überwachen, die aus Ihrem Protokollfluss abgeleitet werden können.

Es ist jedoch mit Kosten verbunden. Moderne Systeme erzeugen große Mengen an Protokollen, und eine Erhöhung Ihres Datenverkehrs kann Ihre ELK-Ressourcen erschöpfen oder die Abrechnungsrate von Splunk bis zum Mond erhöhen.

Es gibt einige Stichprobenverfahren, mit denen die Anzahl der sogenannten Bohrprotokolle um mehrere Größenordnungen reduziert und alle abnormalen Protokolle gespeichert werden können. Es kann einen allgemeinen Überblick über das normale Systemverhalten und eine detaillierte Ansicht aller problematischen Ereignisse geben.

Von Protokollen zu einem Ereignismodell

Normalerweise spiegeln Protokollzeilen Ereignisse wider, die im System auftreten. Zum Beispiel Herstellen einer Verbindung, Authentifizieren, Abfragen der Datenbank usw. Wenn Sie alle Phasen ausführen, ist eine Arbeit abgeschlossen. Das Definitionsereignis als logische Arbeit kann als Teil der Service Level-Ziele angesehen werden, die sich auf einen bestimmten Service beziehen. Mit "Service" meine ich nicht nur Softwaredienste, sondern auch bestimmte physische Geräte wie Sensoren oder andere Maschinen aus der IoT-Welt.

Es ist auch sehr komplementär zu domänengesteuerten Designprinzipien. Durch die Isolierung und die Aufteilung der Verantwortlichkeiten zwischen Diensten oder Domänen werden Ereignisse für jede Arbeit in jedem Teil des Systems spezifisch.

Beispielsweise können Anmeldedienstereignisse durch erfolgreiche Anmeldungen und fehlgeschlagene Anmeldungen mit einem eigenen dynamischen Kontext getrennt werden.

Metriken und Ereignisse sollten eine Geschichte über die Prozesse im System erstellen.

Ereignisse können so abgetastet werden, dass bei normalem Systemverhalten nur ein Bruchteil davon gespeichert wird und alle problematischen Ereignisse unverändert gespeichert werden. Ereignisse werden aggregiert und als wichtige Leistungsindikatoren gespeichert, die auf den Zielen bestimmter Dienste basieren.

Es kann Service-Ziel-Metriken und die zugehörigen Metadaten zusammenführen, die die Verbindungen zwischen Problemen von Moment zu Moment nutzen.

Diese Daten wurden mit Blick auf eine hohe Kardinalität geschrieben und enthüllen die Unbekannten im System.

Ist dies eine Form der Software-Instrumentierung? Ja Wenn Sie jedoch die Datenmengen vergleichen, die aus der Protokollierung auf Debug-Ebene und der vollständigen Instrumentierung stammen, können Sie durch Aufteilen von Protokollen in Ereignisse aus einem Feuerwehrschlauch in der Produktionsumgebung trinken, ohne in Daten und Kosten zu versinken.

„Die Definition eines Ereignisses als Arbeit kann als mit den Zielen eines bestimmten Dienstes verbunden angesehen werden.“

Warum wir nicht bereit sind für vollständige KI-Lösungen

KI ist ein gutes Schlagwort, um Start-up-Investitionen anzuziehen. Der Teufel steckt jedoch immer im Detail.

1. Reproduzierbarkeit

Das Problem eines vollständig auf maschinellem Lernen basierenden Systems (der sogenannte vollständige KI-Ansatz) besteht darin, dass es keine Reproduzierbarkeit gibt, da es ständig neue Verhaltensweisen lernt. Wenn Sie verstehen möchten, warum beispielsweise eine Bedingung zu einer Warnung geführt hat, können Sie diese nicht untersuchen, da sich die Modelle bereits geändert haben. Jede Lösung, die auf dem ständigen Erlernen von Verhalten beruht, ist mit diesem Problem konfrontiert.

Es ist wichtig, das System selbst zu optimieren, wenn Sie mit hochgradig detaillierten Daten oder Metriken arbeiten. Ohne Reproduzierbarkeit ist dies jedoch sehr schwierig.

2. Ressourcenverbrauch

Für jede Art von ständigem maschinellem Lernen benötigen Sie eine erhebliche Menge an Rechenressourcen. In der Regel erfolgt dies in Form von Stapelverarbeitungsdatensätzen. Bei einigen Produkten sind die Mindestanforderungen für die Verarbeitung von 200.000 Metriken v32CPU und 64 GB RAM. Wenn Sie die Anzahl der Metriken verdoppeln möchten, benötigen Sie einen anderen Computer, der dieselben Anforderungen erfüllt.

3. Sie können Deep Learning noch nicht vollständig automatisieren

Laut einer Masterarbeit von Samreen Hassan Massak (noch nicht vollständig abgeschlossen) dauert der Schulungsprozess für Tausende von Metriken CPU-Zeit in Tagen oder GPU-Zeit in Stunden. Sie können es nicht skalieren, ohne Ihr Budget zu sprengen.

4. Geschwindigkeit

Lösungen wie Amazon Forecast, die als Stapelverarbeitungsdienste fungieren, die Daten aufnehmen und auf das Ende der Berechnung warten, sind dafür nicht geeignet.

5. Klarheit

Basierend auf den Erfahrungen von Google:

"Die Regeln, nach denen reale Vorfälle am häufigsten erfasst werden, sollten so einfach, vorhersehbar und zuverlässig wie möglich sein."

landing.google.com/sre/sre-book/chapters/monitoring-distributed-systems

Wenn sich Modelle oder Regeln ständig ändern, verlieren Sie das Verständnis für das System und es funktioniert wie eine Black Box.

Anomalien = Warnungen?

Angenommen, Sie haben Tausende von Metriken, und wenn Sie eine gute Beobachtbarkeit wünschen, müssen Sie Daten mit hohem Kardinalwert sammeln. Jeder Herzschlag des Systems erzeugt statistische Schwankungen in Ihrem Metrikschwarm.

https://berlinbuzzwords.de/15/session/signatures-patterns-and-trends-timeseries-data-mining-etsy

Die wichtigsten Lehren, die aus Etsys Kale-Projekt gezogen werden können:



Das Warnen vor Metrikanomalien führt schließlich zu einer enormen Menge von Warnungen und manueller Arbeit, die mit Schwellenwerten und handgefertigten Filtern spielt.

Warum wir einen Streaming-Ansatz brauchen

Um die Beobachtbarkeit zu erreichen und Unbekanntes ins Rampenlicht zu rücken, sind hochgradig detaillierte Daten erforderlich, die nach Rechenzentren, Build-Versionen, Diensten, Plattformen und Sensortypen kategorisiert werden können. Das Aggregieren in einer beliebigen Kombination ist von Natur aus kombinatorisch.

Selbst wenn Sie Ihre Metriken und Ereignisse sorgfältig entwerfen, werden Sie letztendlich eine ziemlich große Menge davon erhalten. Wenn Sie in Echtzeit in dieser Größenordnung arbeiten, haben regelmäßige Abfragen oder Stapeljobs eine erhebliche Latenz und einen erheblichen Overhead.

Dinge zu beachten

Jede Operation, die an einem unendlichen Datenstrom ausgeführt wird, ist ein ziemliches technisches Unterfangen. Sie müssen sich mit den Auswirkungen verteilter Systeme befassen.



Während Sie Ereignisse, Service Level-Ziele oder KPI auf hoher Ebene überwachen, müssen Sie reaktiv sein und Ihre Daten nicht ständig abfragen, sondern stattdessen mit einem Stream arbeiten, der horizontal skaliert werden kann und einen hohen Durchsatz und eine hohe Geschwindigkeit erzielt, ohne eine überwältigende Menge an Daten zu verbrauchen Ressourcen.

Einige Streaming-Frameworks wie Apache Storm, Apache Flink und Apache Spark sind auf die Tupelverarbeitung und nicht auf die sofort einsatzbereite Zeitreihenverarbeitung ausgerichtet.

Es gibt auch Probleme mit der Semantik verteilter Systeme.

Angenommen, Sie haben viele Bereitstellungen in verschiedenen Rechenzentren. Möglicherweise liegt ein Netzwerkproblem vor, und der Agent, der Ihre KPI-Metriken speichert, kann diese nicht weiterleiten. Nach einer Weile - sagen wir 3 Minuten - sendet der Agent diese Daten an das System. Und diese neuen Informationen sollten eine Aktion auslösen, die auf dieser Bedingung basiert. Sollten wir dieses Datenfenster im Speicher speichern und nicht nur vorwärts, sondern auch zeitlich nach Bedingungen suchen? Wie groß sollte dieses Desynchronisationsfenster sein? Die Bearbeitung von Tausenden von Metriken in Echtzeit macht diese Fragen sehr wichtig. Bei Stream-Processing-Systemen können Sie nicht alles in der Datenbank speichern, ohne an Geschwindigkeit zu verlieren.

Die Echtzeit-Stream-Analyse von Zeitreihendaten in verteilten Systemen ist schwierig, da die Ereignisse bezüglich des Systemverhaltens nicht in Ordnung sein können und die Bedingungen, die aufgrund dieser Daten auftreten können, von der Reihenfolge der Ereignisse abhängen. Dies bedeutet, dass eine mindestens einmalige Semantik leicht erreicht werden kann, aber wenn nur einmal viel, viel schwieriger sein kann.

Wünschenswerte Funktionen einer Überwachungsstrategie gemäß der Google SRE-Arbeitsmappe

• „Modernes Design umfasst normalerweise die Trennung von Erfassung und Regelauswertung (mit einer Lösung wie Prometheus Server), Langzeitzeitreihenspeicherung (InfluxDB), Alarmaggregation (Alertmanager) und Dashboarding (Grafana).“
• „Die protokollbasierten Systeme von Google verarbeiten große Mengen hochgradig detaillierter Daten. Es gibt eine gewisse Verzögerung zwischen dem Eintreten eines Ereignisses und dem Anzeigen in Ereignissen. Für nicht zeitkritische Analysen können diese Protokolle mit einem Stapelsystem verarbeitet, mit Ad-hoc-Abfragen abgefragt und mit Dashboards visualisiert werden. Ein Beispiel für diesen Workflow wäre die Verwendung von Cloud Dataflow zur Verarbeitung von Protokollen, BigQuery für Ad-hoc-Abfragen und Data Studio für die Dashboards. “
• „Im Gegensatz dazu liefert unser auf Metriken basierendes Überwachungssystem, das eine große Anzahl von Metriken von jedem Dienst bei Google sammelt, viel weniger detaillierte Informationen, jedoch nahezu in Echtzeit. Diese Eigenschaften sind ziemlich typisch für andere log- und metrikbasierte Überwachungssysteme, obwohl es Ausnahmen gibt, wie z. B. Echtzeit-Protokollsysteme oder Metriken mit hoher Kardinalität. “
• „In einer idealen Welt sollten Überwachungs- und Alarmierungscodes denselben Teststandards unterliegen wie die Codeentwicklung. Während Prometheus-Entwickler über die Entwicklung von Komponententests für die Überwachung diskutieren, gibt es derzeit kein weit verbreitetes System, mit dem Sie dies tun können. “
• „Bei Google testen wir unsere Überwachung und Alarmierung in einer domänenspezifischen Sprache, mit der wir synthetische Zeitreihen erstellen können. Wir schreiben dann Aussagen basierend auf den Werten in einer abgeleiteten Zeitreihe oder dem Zündstatus und dem Vorhandensein bestimmter Warnungen auf dem Etikett. “

Vielen Dank an Charity Majors und Cindy Sridharan
Vielen Dank an Sigrid Maasen für ihre Hilfe