Erfassen von Metriken aus Ihrer Infrastruktur und Ihren Anwendungen

Um die Zuverlässigkeit und Stabilität Ihrer Anwendungen und Dienste zu gewährleisten, ist es wichtig, den Zustand Ihrer Systeme zu kennen. Informationen zum Zustand und zur Leistung Ihrer Bereitstellungen helfen Ihrem Team nicht nur, auf Probleme zu reagieren, sondern geben ihm auch die Sicherheit, Änderungen mit Zuversicht vorzunehmen. Eine der besten Möglichkeiten, diese Erkenntnisse zu gewinnen, ist ein robustes Überwachungssystem, das Messdaten sammelt, Daten visualisiert und Bediener benachrichtigt, wenn Probleme auftreten.

In unserem https://www.digitalocean.com/community/tutorials/an-einführung-in-metrik-überwachung-und-alarmierungsanleitung] haben wir einige der Kernkonzepte besprochen, die bei der Überwachung von Metriken und Alarmen eine Rolle spielen Überwachungssoftware und -infrastruktur. Metriken sind das Hauptmaterial, das von Überwachungssystemen verarbeitet wird, um eine zusammenhängende Ansicht der Systeme zu erhalten, die verfolgt werden. Zu wissen, welche Komponenten überwacht werden sollten und welche spezifischen Merkmale Sie berücksichtigen sollten, ist der erste Schritt bei der Entwicklung eines Systems, das zuverlässige und nachvollziehbare Erkenntnisse über den Zustand Ihrer Software und Hardware liefert.

In diesem Handbuch werden wir zunächst ein beliebtes Framework erläutern, mit dem die wichtigsten zu verfolgenden Metriken ermittelt werden. Anschließend werden wir erläutern, wie diese Indikatoren auf Komponenten in Ihrer gesamten Implementierung angewendet werden können. Dieser Prozess konzentriert sich zunächst auf die grundlegenden Ressourcen der einzelnen Server und passt dann den Umfang an, um immer größere Problembereiche abzudecken.

In dem einflussreichen Google SRE (Site Reliability Engineering) Book wird im Kapitel zur Überwachung verteilter Systeme ein nützliches Framework vorgestellt, das als die * vier goldenen Signale der Überwachung * bezeichnet wird stellt die wichtigsten Faktoren dar, die in einem benutzerbezogenen System gemessen werden müssen. Wir werden jede dieser vier Eigenschaften weiter unten diskutieren.

Anhand der vier goldenen Signale als Leitfaden können Sie untersuchen, wie diese Metriken in der gesamten Hierarchie Ihrer Systeme ausgedrückt werden. Da Services häufig durch Hinzufügen von Abstraktionsebenen zu grundlegenderen Komponenten erstellt werden, sollten Metriken so konzipiert werden, dass sie Einblicke auf jeder Ebene der Bereitstellung ermöglichen.

Wir werden verschiedene Komplexitätsebenen betrachten, die in gängigen verteilten Anwendungsumgebungen vorhanden sind:

Die obige Reihenfolge erweitert den Abstraktionsbereich und die Abstraktionsebene mit jeder nachfolgenden Ebene.

Die zu erfassenden Basismetriken sind diejenigen, die für die zugrunde liegenden Computer relevant sind, auf die sich Ihre Systeme verlassen. Obwohl bei der modernen Softwareentwicklung erhebliche Anstrengungen unternommen werden, um die physischen Komponenten und Betriebssystemdetails auf niedriger Ebene zu abstrahieren, ist jeder Dienst für seine Arbeit auf die zugrunde liegende Hardware und die zugrunde liegenden Betriebssysteme angewiesen. Aus diesem Grund ist es der erste Schritt, die grundlegenden Ressourcen Ihrer Maschinen im Auge zu behalten, um die Funktionsfähigkeit Ihrer Systeme zu verstehen.

Wenn Sie überlegen, welche Metriken auf der Maschinenebene erfasst werden sollen, berücksichtigen Sie die einzelnen verfügbaren Ressourcen. Dazu gehören Darstellungen der Hardware Ihres Servers sowie die vom Betriebssystem bereitgestellten Kernabstraktionen wie Prozesse und Dateideskriptoren. Betrachtet man jede Komponente in Bezug auf die vier goldenen Signale, so kann es sein, dass bestimmte Signale offensichtlich sind, während andere möglicherweise schwieriger zu beurteilen sind.

http://www.brendangregg.com [Brendan Gregg], ein einflussreicher Performance-Ingenieur, beschreibt viele Möglichkeiten, um Kernmetriken von Linux-Systemen zu erhalten, um die Anforderungen eines Frameworks zu erfüllen, das er http://www.brendangregg.com/usemethod nennt .html [USE-Methode für die Leistungsanalyse] ( u Tilization, s Aturation und e Spiegel). Da sich die USE-Methode und die vier goldenen Signale erheblich überschneiden, können wir einige seiner Empfehlungen als Ausgangspunkt verwenden, um herauszufinden, welche Daten von Serverkomponenten gesammelt werden sollen.

Zum Messen von * CPU * können die folgenden Messungen geeignet sein:

Für * memory * könnten die Signale so aussehen:

Für * Speichergeräte *:

Die * Netzwerk * ​​-Signale können folgendermaßen aussehen:

Neben der Darstellung physischer Ressourcen empfiehlt es sich auch, Messdaten zu Betriebssystemabstraktionen zu erfassen, für die Einschränkungen gelten. Einige Beispiele, die in diese Kategorie fallen, sind Dateizugriffsnummern und Threadanzahl. Hierbei handelt es sich nicht um physische Ressourcen, sondern um Konstruktionen mit vom Betriebssystem festgelegten Obergrenzen, um zu verhindern, dass sich Prozesse überdehnen. Die meisten können mit Befehlen wie "+ ulimit +" angepasst und konfiguriert werden. Wenn Sie jedoch Änderungen in der Nutzung dieser Ressourcen verfolgen, können Sie potenziell schädliche Änderungen in der Nutzung Ihrer Software erkennen.

Auf einer höheren Ebene beschäftigen wir uns mit den Anwendungen und Diensten, die auf den Servern ausgeführt werden. Diese Programme verwenden die einzelnen Serverkomponenten, mit denen wir uns zuvor befasst haben, als Arbeitsressourcen. Kennzahlen auf dieser Ebene helfen uns, den Zustand unserer Einzelhost-Anwendungen und -Dienste zu verstehen. Wir haben verteilte Multi-Host-Services in einen separaten Abschnitt unterteilt, um die wichtigsten Faktoren in diesen Konfigurationen zu erläutern.

Während die Metriken im letzten Abschnitt die Funktionen und die Leistung der einzelnen Komponenten und des Betriebssystems detailliert beschreiben, geben die Metriken hier Aufschluss darüber, wie gut Anwendungen die von uns geforderte Arbeit leisten können. Wir möchten auch wissen, von welchen Ressourcen unsere Anwendungen abhängen und wie gut sie diese Einschränkungen verwalten.

Es ist wichtig zu beachten, dass die Metriken in diesem Abschnitt eine Abweichung von dem verallgemeinerten Ansatz darstellen, den wir beim letzten Mal verwenden konnten. Die Metriken, die ab diesem Zeitpunkt am wichtigsten sind, hängen stark von den Eigenschaften Ihrer Anwendungen, Ihrer Konfiguration und den Workloads ab, die Sie auf Ihren Computern ausführen. Wir können Möglichkeiten zur Identifizierung Ihrer wichtigsten Metriken erörtern, aber Ihre Ergebnisse hängen davon ab, was der Server speziell tun soll.

Für Anwendungen, die Kunden bedienen, ist es oft recht einfach, die vier goldenen Signale auszuwählen:

Einige der wichtigsten Metriken, die Sie im Auge behalten möchten, beziehen sich auf Abhängigkeiten. Diese werden häufig am besten durch Sättigungsmetriken ausgedrückt, die sich auf einzelne Komponenten beziehen. Die Auslastung des Anwendungsspeichers, die verfügbaren Verbindungen, die Anzahl der geöffneten Datei-Handles oder die Anzahl der aktiven Worker können Ihnen beispielsweise dabei helfen, die Auswirkungen Ihrer im Kontext des physischen Servers angewendeten Konfiguration zu verstehen.

Die vier goldenen Signale wurden in erster Linie für verteilte Mikrodienste entwickelt und setzen daher eine Client-Server-Architektur voraus. Für Anwendungen, die keine Client-Server-Architektur verwenden, sind dieselben Signale immer noch wichtig, aber das Verkehrssignal muss möglicherweise leicht überarbeitet werden. Dies ist im Grunde genommen ein Maß für die Auslastung. Wenn Sie also eine Metrik finden, die die für Ihre Anwendung geeignete Metrik darstellt, wird dies dem gleichen Zweck dienen. Die Einzelheiten hängen davon ab, was Ihr Programm tut, aber einige allgemeine Alternativen können die Anzahl der Operationen oder Daten sein, die pro Sekunde verarbeitet werden.

Die meisten Dienste, insbesondere wenn sie in einer Produktionsumgebung betrieben werden, erstrecken sich über mehrere Serverinstanzen, um die Leistung und Verfügbarkeit zu erhöhen. Diese erhöhte Komplexität fügt eine zusätzliche Oberfläche hinzu, die zu überwachen ist. Distributed Computing und redundante Systeme können Ihre Systeme flexibler machen, die netzwerkbasierte Koordination ist jedoch anfälliger als die Kommunikation innerhalb eines einzelnen Hosts. Eine robuste Überwachung kann dazu beitragen, einige der Schwierigkeiten beim Umgang mit einem weniger zuverlässigen Kommunikationskanal zu lindern.

Über das Netzwerk hinaus sind für verteilte Dienste der Zustand und die Leistung der Servergruppe wichtiger als die gleichen Maßnahmen, die für jeden einzelnen Host gelten. Während Dienste eng an den Computer gebunden sind, auf dem sie ausgeführt werden, wenn sie auf einen einzelnen Host beschränkt sind, sind redundante Multi-Host-Dienste auf die Ressourcen mehrerer Hosts angewiesen und gleichzeitig von der direkten Abhängigkeit von einem einzelnen Computer entkoppelt.

Die goldenen Signale auf dieser Ebene ähneln denen, die den Zustand des Dienstes im letzten Abschnitt messen. Sie werden jedoch die zusätzliche Koordination berücksichtigen, die zwischen den Gruppenmitgliedern erforderlich ist:

Diese ähneln zwar eindeutig den wichtigen Metriken für Single-Host-Dienste, doch bei der Verteilung wird jedes der Signale immer komplexer. Die Latenz wird zu einem komplizierteren Problem, da für die Verarbeitung die Kommunikation zwischen mehreren Hosts erforderlich sein kann. Der Datenverkehr hängt nicht mehr von den Fähigkeiten eines einzelnen Servers ab, sondern ist eine Zusammenfassung der Gruppenfähigkeiten und der Effizienz des Routing-Algorithmus, der zur Arbeitsverteilung verwendet wird. Zusätzliche Fehlermodi werden im Zusammenhang mit Netzwerkverbindungen oder Hostfehlern eingeführt. Schließlich umfasst die Sättigung die kombinierten Ressourcen, die den Hosts zur Verfügung stehen, die Netzwerkverbindung, die jeden Host verbindet, und die Fähigkeit, den Zugriff auf die Abhängigkeiten, die jeder Computer benötigt, ordnungsgemäß zu koordinieren.

Einige der wertvollsten zu sammelnden Metriken befinden sich außerhalb Ihrer direkten Kontrolle an der Grenze Ihrer Anwendung oder Ihres Dienstes. Externe Abhängigkeiten, einschließlich der Ihres Hosting-Providers und aller Dienste, auf die sich Ihre Anwendungen stützen. Dies sind Ressourcen, die Sie nicht direkt verwalten können, die jedoch Ihre Fähigkeit beeinträchtigen können, Ihren eigenen Service zu gewährleisten.

Da externe Abhängigkeiten kritische Ressourcen darstellen, besteht eine der einzigen verfügbaren Strategien zur Reduzierung von Ausfällen darin, den Betrieb auf einen anderen Anbieter zu verlagern. Dies ist nur eine praktikable Strategie für Warendienste, und auch dann nur mit vorheriger Planung und loser Kopplung mit dem Anbieter. Selbst wenn die Schadensbegrenzung schwierig ist, ist die Kenntnis externer Ereignisse, die sich auf Ihre Anwendung auswirken, unglaublich wertvoll.

Die goldenen Signale für externe Abhängigkeiten könnten ungefähr so ​​aussehen:

Mithilfe dieser Metriken können Sie Probleme mit Ihren Abhängigkeiten identifizieren, Sie auf eine bevorstehende Ressourcenerschöpfung hinweisen und die Ausgaben unter Kontrolle halten. Wenn der Dienst über Drop-In-Alternativen verfügt, können diese Daten verwendet werden, um zu entscheiden, ob die Arbeit zu einem anderen Anbieter verlagert werden soll, wenn Metriken darauf hinweisen, dass ein Problem auftritt. In Situationen mit geringerer Flexibilität können die Metriken zumindest verwendet werden, um einen Bediener zu warnen, auf die Situation zu reagieren und verfügbare manuelle Minderungsoptionen zu implementieren.

Die Metriken der höchsten Ebene verfolgen Anforderungen durch das System im Kontext der äußersten Komponente, mit der Benutzer interagieren. Dies kann ein Load Balancer oder ein anderer Routing-Mechanismus sein, der für den Empfang und die Koordination von Anforderungen an Ihren Service verantwortlich ist. Da dies der erste Berührungspunkt mit Ihrem System ist, gibt das Sammeln von Metriken auf dieser Ebene eine Annäherung an die allgemeine Benutzererfahrung.

Während die zuvor beschriebenen Metriken unglaublich nützlich sind, sind die Metriken in diesem Abschnitt häufig die wichtigsten, für die eine Warnung eingerichtet werden muss. Um die Reaktionszeit zu verkürzen, sollten Warnungen - insbesondere Seiten - für Szenarien reserviert werden, die sich erkennbar negativ auf die Benutzerfreundlichkeit auswirken. Probleme, die mit diesen Metriken auftreten, können untersucht werden, indem die auf anderen Ebenen gesammelten Metriken verwendet werden.

Die Signale, nach denen wir hier suchen, ähneln denen der einzelnen Dienste, die wir zuvor beschrieben haben. Der Hauptunterschied ist der Umfang und die Wichtigkeit der Daten, die wir hier sammeln:

Da diese Metriken Benutzeranforderungen parallel ausführen, deuten Werte, die außerhalb des zulässigen Bereichs für diese Metriken liegen, wahrscheinlich auf eine direkte Auswirkung auf den Benutzer hin. Latenzzeiten, die nicht den kundenseitigen oder internen SLAs (Service Level Agreements) entsprechen, Datenverkehr, der auf einen starken Anstieg oder Abfall hindeutet, erhöhte Fehlerraten und die Unfähigkeit, Anforderungen aufgrund von Ressourcenbeschränkungen zu bearbeiten, lassen sich leicht abschätzen auf diesem Level. Vorausgesetzt, die Metriken sind korrekt, können die Werte hier direkt Ihren Verfügbarkeits-, Leistungs- und Zuverlässigkeitszielen zugeordnet werden.

In diesem Handbuch haben wir zunächst die vier goldenen Signale besprochen, die am hilfreichsten sind, um wichtige Änderungen in Ihren Systemen zu erkennen und zu verstehen. Anschließend haben wir die Signale als Linse verwendet, um die wichtigsten Faktoren für die Verfolgung auf verschiedenen Ebenen einer Bereitstellung zu bewerten.

Wenn Sie Ihre Systeme von oben nach unten bewerten, können Sie die kritischen Komponenten und Interaktionen identifizieren, die für die Ausführung zuverlässiger und leistungsfähiger Dienste erforderlich sind. Die vier goldenen Signale können ein guter Ausgangspunkt für die Strukturierung von Metriken sein, um den Zustand Ihrer Systeme am besten anzuzeigen. Bedenken Sie jedoch, dass die goldenen Signale zwar ein guter Rahmen sind, Sie jedoch andere für Ihre Situation spezifische Messgrößen berücksichtigen müssen. Sammeln Sie alle Daten, von denen Sie glauben, dass sie am wahrscheinlichsten vor Problemen warnen oder Ihnen bei der Fehlerbehebung helfen, wenn Probleme auftreten.