Überwachung für verteilte und Microservices-Bereitstellungen

Einige der grundlegendsten Änderungen im Verhalten vieler Systeme sind auf eine Explosion neuer Abstraktionsebenen zurückzuführen, um die herum Software entwickelt werden kann. Die Containertechnologie hat die Beziehung zwischen bereitgestellter Software und dem zugrunde liegenden Betriebssystem geändert. In Containern bereitgestellte Anwendungen haben eine andere Beziehung zur Außenwelt, zu anderen Programmen und zum Host-Betriebssystem als auf herkömmliche Weise bereitgestellte Anwendungen. Kernel- und Netzwerkabstraktionen können zu einem unterschiedlichen Verständnis der Betriebsumgebung führen, je nachdem, welche Ebene Sie überprüfen.

Diese Abstraktionsebene ist in vielerlei Hinsicht äußerst hilfreich, da sie konsistente Bereitstellungsstrategien erstellt, die Migration der Arbeit zwischen Hosts vereinfacht und Entwicklern eine genaue Kontrolle über die Laufzeitumgebungen ihrer Anwendungen ermöglicht. Diese neuen Funktionen gehen jedoch zu Lasten einer erhöhten Komplexität und einer weiter entfernten Beziehung zu den Ressourcen, die die einzelnen Prozesse antreiben.

Eine Gemeinsamkeit unter neueren Paradigmen ist die zunehmende Abhängigkeit von der internen Netzwerkkommunikation, um Aufgaben zu koordinieren und auszuführen. Was früher die Domäne einer einzelnen Anwendung war, kann jetzt auf viele Komponenten verteilt werden, die Informationen koordinieren und gemeinsam nutzen müssen. Dies hat einige Auswirkungen auf die Kommunikationsinfrastruktur und die Überwachung.

Erstens wird der Netzwerkzustand wichtiger als je zuvor, da diese Modelle auf der Kommunikation zwischen kleinen, diskreten Diensten basieren. In herkömmlichen, eher monolithischen Architekturen wurde das Koordinieren von Aufgaben, das Teilen von Informationen und das Organisieren von Ergebnissen größtenteils in Anwendungen mit regulärer Programmierlogik oder durch eine vergleichsweise geringe externe Kommunikation erreicht. Im Gegensatz dazu verwendet der logische Fluss stark verteilter Anwendungen das Netzwerk, um Informationen zu synchronisieren, den Zustand von Peers zu überprüfen und weiterzugeben. Der Zustand und die Leistung des Netzwerks wirken sich direkt auf mehr Funktionen als zuvor aus. Daher ist eine intensivere Überwachung erforderlich, um einen ordnungsgemäßen Betrieb zu gewährleisten.

Obwohl das Netzwerk kritischer denn je geworden ist, wird die Fähigkeit, es effektiv zu überwachen, aufgrund der erhöhten Anzahl von Teilnehmern und einzelnen Kommunikationslinien immer schwieriger. Anstatt die Interaktionen zwischen einigen Anwendungen zu verfolgen, ist eine korrekte Kommunikation zwischen Dutzenden, Hunderten oder Tausenden von verschiedenen Punkten erforderlich, um die gleiche Funktionalität sicherzustellen. Zusätzlich zu den Komplexitätsaspekten belastet das erhöhte Verkehrsaufkommen die verfügbaren Netzwerkressourcen zusätzlich, was die Notwendigkeit einer zuverlässigen Überwachung noch verschärft.

Oben haben wir die Tendenz moderner Architekturen erwähnt, Arbeit und Funktionalität auf viele kleinere, diskrete Komponenten aufzuteilen. Diese Entwürfe können sich direkt auf die Überwachungslandschaft auswirken, da sie Klarheit und Verständlichkeit besonders wertvoll, aber zunehmend schwer fassbar machen.

Es sind robustere Werkzeuge und Instrumente erforderlich, um einen guten Betriebszustand zu gewährleisten. Da die Verantwortung für die Ausführung einer bestimmten Aufgabe jedoch fragmentiert und auf verschiedene Mitarbeiter aufgeteilt ist (möglicherweise auf vielen verschiedenen physischen Hosts), kann es schwierig sein, zu verstehen, wo die Verantwortung für Leistungsprobleme oder Fehler liegt. Anforderungen und Arbeitseinheiten, die Dutzende von Komponenten berühren, von denen viele aus Pools möglicher Kandidaten ausgewählt wurden, können die Visualisierung des Anforderungspfads oder die Ursachenanalyse mithilfe traditioneller Mechanismen unpraktisch machen.

Ein weiterer Kampf bei der Anpassung der konventionellen Überwachung besteht darin, kurzlebige oder kurzlebige Einheiten sinnvoll zu verfolgen. Unabhängig davon, ob es sich bei den betroffenen Einheiten um Cloud-Computing-Instanzen, Container-Instanzen oder andere Abstraktionen handelt, verletzen diese Komponenten häufig einige der Annahmen, die von herkömmlicher Überwachungssoftware getroffen werden.

Um beispielsweise zwischen einem problematischen heruntergefahrenen Knoten und einer Instanz zu unterscheiden, die absichtlich zerstört wurde, um eine Verkleinerung vorzunehmen, muss das Überwachungssystem Ihre Bereitstellungs- und Verwaltungsebene besser verstehen als zuvor erforderlich. Bei vielen modernen Systemen treten diese Ereignisse sehr viel häufiger auf. Daher ist es nicht sinnvoll, die Überwachungsdomäne jedes Mal manuell anzupassen. Die Bereitstellungsumgebung ändert sich bei diesen Entwürfen schneller, sodass die Überwachungsebene neue Strategien anwenden muss, um wertvoll zu bleiben.

Eine Frage, der sich viele Systeme stellen müssen, ist, was mit den Daten aus zerstörten Instanzen zu tun ist. Während Arbeitseinheiten schnell bereitgestellt und aus der Bereitstellung entfernt werden können, um sich ändernden Anforderungen gerecht zu werden, muss entschieden werden, was mit den Daten in Bezug auf die alten Instanzen geschehen soll. Daten verlieren nicht unbedingt sofort an Wert, nur weil der zugrunde liegende Mitarbeiter nicht mehr verfügbar ist. Wenn täglich Hunderte oder Tausende von Knoten ein- und ausgehen, kann es schwierig sein, anhand der fragmentierten Daten kurzlebiger Instanzen eine Beschreibung des allgemeinen Betriebszustands Ihres Systems zu erstellen.

Der Anstieg des Gesamtverkehrsaufkommens aufgrund der gestiegenen Anzahl von Diensten ist eines der am einfachsten zu bedenkenden Probleme. Über den Anstieg der Übertragungszahlen hinaus, der durch neue Architekturen verursacht wird, kann die Überwachungsaktivität selbst das Netzwerk blockieren und Hostressourcen stehlen. Sie können entweder Ihre Überwachungsinfrastruktur skalieren oder die Auflösung der Daten, mit denen Sie arbeiten, verringern, um das Volumen optimal zu bewältigen. Beide Ansätze sind einen Blick wert, aber wir werden uns auf den zweiten konzentrieren, da er eine erweiterbare und allgemein nützliche Lösung darstellt.

Durch Ändern Ihrer Datenerfassungsraten kann die Datenmenge minimiert werden, die Ihr System von Hosts erfassen muss. Stichprobenerfassung ist ein normaler Teil der Metrik-Sammlung, der angibt, wie oft Sie nach neuen Werten für eine Metrik fragen. Durch Erhöhen des Abtastintervalls wird die zu verarbeitende Datenmenge verringert, aber auch die Auflösung (Detailgenauigkeit) Ihrer Daten. Während Sie vorsichtig sein und Ihre minimale nützliche Auflösung verstehen müssen, kann das Optimieren der Datenerfassungsraten einen erheblichen Einfluss darauf haben, wie viele Überwachungsclients Ihr System angemessen bedienen kann.

Um den Informationsverlust aufgrund niedrigerer Auflösungen zu verringern, können Sie weiterhin Daten auf Hosts mit derselben Häufigkeit erfassen, diese jedoch für die Übertragung über das Netzwerk in besser verdauliche Zahlen zusammenfassen. Einzelne Computer können Metrikwerte aggregieren und mitteln und Zusammenfassungen an das Überwachungssystem senden. Dies kann zur Reduzierung des Netzwerkverkehrs bei gleichzeitiger Wahrung der Genauigkeit beitragen, da eine große Anzahl von Datenpunkten weiterhin berücksichtigt wird. Beachten Sie, dass dies zur Reduzierung des Einflusses der Datenerfassung auf das Netzwerk beiträgt, jedoch nicht zur Reduzierung der Belastung, die mit dem Sammeln dieser Nummern innerhalb des Hosts verbunden ist.

Wie oben erwähnt, ist eines der Hauptunterscheidungsmerkmale zwischen traditionellen Systemen und modernen Architekturen die Aufschlüsselung der Komponenten, die an der Bearbeitung von Anforderungen beteiligt sind. In verteilten Systemen und Mikrodiensten wird eine Arbeitseinheit viel wahrscheinlicher über eine Art Scheduling- oder Arbitrating-Schicht einem Pool von Arbeitnehmern zugewiesen. Dies hat Auswirkungen auf viele der automatisierten Prozesse, die Sie möglicherweise im Zusammenhang mit der Überwachung erstellen.

In Umgebungen, in denen mehrere austauschbare Mitarbeiter beschäftigt sind, können die Richtlinien für Gesundheitsprüfungen und Warnungen zu komplexen Beziehungen mit der von ihnen überwachten Infrastruktur führen. Gesundheitskontrollen bei einzelnen Arbeitnehmern können hilfreich sein, um defekte Geräte automatisch außer Betrieb zu setzen und zu recyceln. Wenn Sie jedoch über eine skalierte Automatisierung verfügen, spielt es keine Rolle, ob ein einzelner Webserver aus einem großen Pool ausfällt. Das System korrigiert sich automatisch, um sicherzustellen, dass sich nur fehlerfreie Einheiten im aktiven Pool befinden, die Anforderungen empfangen.

Obwohl Host-Integritätsprüfungen fehlerhafte Einheiten auffangen können, ist eine Integritätsprüfung des Pools selbst besser für Warnmeldungen geeignet. Die Fähigkeit des Pools, die aktuelle Arbeitsbelastung zu befriedigen, hat einen größeren Einfluss auf die Benutzererfahrung als die Fähigkeiten eines einzelnen Arbeitnehmers. Warnungen, die auf der Anzahl fehlerfreier Mitglieder, der Wartezeit für das Pool-Aggregat oder der Pool-Fehlerrate basieren, können die Bediener über Probleme informieren, die schwieriger automatisch zu mindern sind und die Benutzer mit höherer Wahrscheinlichkeit beeinträchtigen.

Im Allgemeinen muss die Überwachungsschicht in verteilten Systemen die Bereitstellungsumgebung und die Bereitstellungsmechanismen besser kennen. Das automatisierte Lebenszyklusmanagement wird aufgrund der Anzahl der an diesen Architekturen beteiligten einzelnen Einheiten unglaublich wertvoll. Unabhängig davon, ob es sich bei den Einheiten um unformatierte Container, Container in einem Orchestrierungsframework oder Rechenknoten in einer Cloud-Umgebung handelt, gibt es eine Verwaltungsebene, die Integritätsinformationen verfügbar macht und Befehle zum Skalieren und Reagieren auf Ereignisse akzeptiert.

Die Anzahl der im Spiel befindlichen Teile erhöht die statistische Ausfallwahrscheinlichkeit. Wenn alle anderen Faktoren gleich sind, würde dies mehr menschliches Eingreifen erfordern, um auf diese Probleme zu reagieren und sie zu mildern. Da das Überwachungssystem für das Erkennen von Fehlern und die Beeinträchtigung des Dienstes verantwortlich ist und sich in die Steuerungsschnittstellen der Plattform einhaken kann, kann es eine große Klasse dieser Probleme lindern. Eine sofortige und automatische Reaktion, die von der Überwachungssoftware ausgelöst wird, kann zur Aufrechterhaltung des Betriebszustands Ihres Systems beitragen.

Diese enge Beziehung zwischen dem Überwachungssystem und der Bereitstellungsplattform ist in anderen Architekturen nicht unbedingt erforderlich oder üblich. Automatisierte verteilte Systeme sollen sich jedoch selbst regulieren und anhand vorkonfigurierter Regeln und des beobachteten Status skaliert und angepasst werden können. Das Überwachungssystem übernimmt in diesem Fall eine zentrale Rolle bei der Kontrolle der Umgebung und der Entscheidung, wann Maßnahmen ergriffen werden sollen.

Ein weiterer Grund, warum das Überwachungssystem Kenntnisse über die Bereitstellungsebene haben muss, besteht darin, mit den Nebenwirkungen von kurzlebigen Fällen umzugehen. In Umgebungen mit häufigen Fluktuationen in den Arbeitsinstanzen ist das Überwachungssystem auf Informationen von einem Seitenkanal angewiesen, um zu verstehen, wann Aktionen beabsichtigt waren oder nicht. Beispielsweise können Systeme, die API-Ereignisse von einem Bereitsteller lesen können, anders reagieren, wenn ein Server absichtlich von einem Bediener zerstört wird, als wenn ein Server plötzlich ohne zugeordnetes Ereignis nicht mehr reagiert. Die Unterscheidung zwischen diesen Ereignissen kann dazu beitragen, dass Ihre Überwachung nützlich, genau und vertrauenswürdig bleibt, auch wenn sich die zugrunde liegende Infrastruktur häufig ändert.

Einer der herausforderndsten Aspekte bei stark verteilten Workloads ist das Verständnis des Zusammenspiels zwischen verschiedenen Komponenten und die Isolation der Verantwortung bei der Ursachenanalyse. Da eine einzelne Anforderung möglicherweise Dutzende kleiner Programme berührt, um eine Antwort zu generieren, kann es schwierig sein, zu interpretieren, wo Engpässe oder Leistungsänderungen entstehen. Um bessere Informationen darüber zu erhalten, wie jede Komponente zur Latenz und zum Verarbeitungsaufwand beiträgt, wurde eine Technik namens verteiltes Tracing entwickelt.

Bei der verteilten Ablaufverfolgung handelt es sich um einen Ansatz für Instrumentierungssysteme, bei dem jeder Komponente Code hinzugefügt wird, um die Anforderungsverarbeitung beim Durchlaufen Ihrer Dienste zu veranschaulichen. Jede Anforderung erhält eine eindeutige Kennung am Rand Ihrer Infrastruktur, die weitergeleitet wird, wenn die Aufgabe Ihre Infrastruktur durchläuft. Jeder Dienst verwendet diese ID dann, um Fehler und die Zeitstempel für den Zeitpunkt zu melden, zu dem er die Anforderung zum ersten Mal sah und an die nächste Stufe weiterleitete. Durch Aggregieren der Berichte von Komponenten mithilfe der Anforderungs-ID kann ein detaillierter Pfad mit genauen Zeitdaten durch Ihre Infrastruktur verfolgt werden.

Diese Methode kann verwendet werden, um zu verstehen, wie viel Zeit für jeden Teil eines Prozesses aufgewendet wird, und um schwerwiegende Latenzerhöhungen eindeutig zu identifizieren. Diese zusätzliche Instrumentierung ist eine Möglichkeit, die Erfassung von Metriken an eine große Anzahl von Verarbeitungskomponenten anzupassen. Bei einer visuellen Zuordnung mit der Zeit auf der x-Achse zeigt die resultierende Anzeige die Beziehung zwischen den verschiedenen Phasen, die Ausführungsdauer der einzelnen Prozesse und die Abhängigkeitsbeziehung zwischen Ereignissen, die parallel ausgeführt werden müssen. Dies kann unglaublich hilfreich sein, um zu verstehen, wie Sie Ihre Systeme verbessern und wie viel Zeit Sie damit verbringen.

Der erste Schritt, um sicherzustellen, dass Sie auf Probleme in Ihren Systemen reagieren können, besteht darin, zu wissen, wann sie auftreten. In unserem Leitfaden unter https://www.digitalocean.com/community/tutorials/gathering-metrics-from-your-infrastructure-and-applications, in dem Metriken aus Ihrer Infrastruktur und Ihren Anwendungen erfasst werden, haben wir die vier goldenen Indikatoren für die Signalüberwachung eingeführt wird vom Google SRE-Team als wichtigstes Tracking-Tool identifiziert. Die vier Signale sind:

Dies sind nach wie vor die besten Ausgangspunkte für die Instrumentierung Ihrer Systeme. Bei stark verteilten Systemen nimmt jedoch die Anzahl der zu überwachenden Ebenen in der Regel zu. Die zugrunde liegende Infrastruktur, die Orchestrierungsebene und die Arbeitsschicht erfordern jeweils eine zuverlässige Überwachung mit durchdachten Warnungen, die wichtige Änderungen identifizieren. Die Alarmierungsbedingungen können komplexer werden, um die in der Plattform enthaltenen kurzlebigen Elemente zu berücksichtigen.

Sobald Ihre Systeme eine Anomalie erkannt und Ihre Mitarbeiter benachrichtigt haben, muss Ihr Team mit der Datenerfassung beginnen. Bevor Sie mit diesem Schritt fortfahren, sollten Sie wissen, welche Komponenten betroffen sind, wann der Vorfall begann und welche spezifischen Alarmbedingungen ausgelöst wurden.

Der nützlichste Weg, um den Umfang eines Vorfalls zu verstehen, ist es, auf hoher Ebene zu beginnen. Beginnen Sie mit der Untersuchung, indem Sie Dashboards und Visualisierungen überprüfen, in denen Informationen aus allen Systemen gesammelt und verallgemeinert werden. Auf diese Weise können Sie schnell korrelierte Faktoren identifizieren und die unmittelbaren Auswirkungen auf die Benutzer erkennen. Während dieses Vorgangs sollten Sie in der Lage sein, Informationen von verschiedenen Komponenten und Hosts zu überlagern.

Ziel dieser Phase ist es, ein mentales oder physisches Inventar der Gegenstände zu erstellen, um diese genauer zu prüfen und Prioritäten für Ihre Untersuchung zu setzen. Wenn Sie eine Kette verwandter Probleme identifizieren können, die verschiedene Ebenen durchlaufen, sollte die unterste Ebene Vorrang haben: Fixes für grundlegende Ebenen lösen häufig Symptome auf höheren Ebenen. Die Liste der betroffenen Systeme kann als informelle Checkliste für Bereiche dienen, anhand derer Fixes später überprüft werden können, wenn eine Schadensbegrenzung implementiert wird.

Wenn Sie der Ansicht sind, dass Sie eine vernünftige Übersicht über den Vorfall haben, durchsuchen Sie die Komponenten und Systeme auf Ihrer Liste nach Priorität. Detaillierte Messdaten zu den einzelnen Einheiten helfen Ihnen dabei, den Fehlerpfad zur Ressource mit der niedrigsten Zuständigkeit zu verfolgen. Sehen Sie sich detailliertere Dashboards und Protokolleinträge an und lesen Sie die Liste der betroffenen Komponenten, um zu verstehen, wie sich die Nebenwirkungen im System ausbreiten. Bei Mikrodiensten führt die Anzahl der voneinander abhängigen Komponenten dazu, dass Probleme häufiger auf andere Dienste übergreifen.

Diese Phase konzentriert sich darauf, den Dienst, die Komponente oder das System zu isolieren, der bzw. das für den anfänglichen Vorfall verantwortlich ist, und zu identifizieren, welches spezifische Problem auftritt. Dies kann neu implementierter Code, eine fehlerhafte physische Infrastruktur, ein Fehler oder ein Fehler in der Orchestrierungsschicht oder eine Änderung der Arbeitslast sein, die das System nicht ordnungsgemäß verarbeiten konnte. Durch die Diagnose, was passiert und warum, können Sie herausfinden, wie Sie das Problem beheben und den Betriebszustand wiederherstellen können. Wenn Sie wissen, inwieweit durch die Behebung dieses Problems Probleme behoben werden können, die auf anderen Systemen gemeldet wurden, können Sie die Priorisierung der Schadensbegrenzungsaufgaben fortsetzen.

Sobald die Einzelheiten identifiziert sind, können Sie daran arbeiten, das Problem zu lösen oder zu mindern. In vielen Fällen gibt es möglicherweise eine offensichtliche und schnelle Möglichkeit, den Dienst wiederherzustellen, indem entweder mehr Ressourcen bereitgestellt, ein Rollback ausgeführt oder der Datenverkehr auf eine alternative Implementierung umgeleitet wird. In diesen Szenarien wird die Lösung in drei Phasen unterteilt:

In vielen verteilten Systemen stellen Redundanz und hochverfügbare Komponenten sicher, dass der Dienst schnell wiederhergestellt wird, obwohl möglicherweise mehr Arbeit im Hintergrund erforderlich ist, um die Redundanz wiederherzustellen oder das System aus einem herabgesetzten Zustand zu bringen. Sie sollten die zuvor erstellte Liste der betroffenen Komponenten als Maßstab verwenden, um zu bestimmen, ob Ihre anfängliche Schadensbegrenzung kaskadierende Serviceprobleme behebt. Mit der Weiterentwicklung der Überwachungssysteme können möglicherweise auch einige dieser umfassenderen Wiederherstellungsprozesse automatisiert werden, indem Befehle an die Bereitstellungsebene gesendet werden, um neue Instanzen fehlerhafter Einheiten aufzurufen oder fehlerhafte Einheiten auszutauschen.

Angesichts der in den ersten beiden Phasen möglichen Automatisierung besteht die wichtigste Arbeit für das Betriebsteam häufig darin, die Hauptursachen eines Ereignisses zu verstehen. Das aus diesem Prozess gewonnene Wissen kann zur Entwicklung neuer Trigger und Richtlinien verwendet werden, um zukünftige Ereignisse vorherzusagen und die Reaktionen des Systems weiter zu automatisieren. Die Überwachungssoftware erhält häufig neue Funktionen als Reaktion auf jeden Vorfall, um sich vor den neu entdeckten Fehlerszenarien zu schützen. Bei verteilten Systemen können verteilte Ablaufverfolgungen, Protokolleinträge, Zeitreihenvisualisierungen und Ereignisse wie kürzlich bereitgestellte Bereitstellungen dazu beitragen, die Reihenfolge der Ereignisse zu rekonstruieren und festzustellen, wo Software und menschliche Prozesse verbessert werden könnten.

Aufgrund der besonderen Komplexität großer verteilter Systeme ist es wichtig, den Lösungsprozess eines wichtigen Ereignisses als Gelegenheit zu betrachten, Ihre Systeme zu erlernen und zu optimieren. Die Anzahl der beteiligten separaten Komponenten und Kommunikationspfade erfordert eine starke Abhängigkeit von Automatisierung und Tools, um die Komplexität zu bewältigen. Die Codierung neuer Erkenntnisse in die Reaktionsmechanismen und Regelsätze dieser Komponenten (sowie in die Betriebsrichtlinien, an die sich Ihr Team hält) ist die beste Methode für Ihr Überwachungssystem, um den Management-Footprint für Ihr Team in Schach zu halten.