Get best of the week

SRE-Beobachtbarkeit: Namespaces und metrische Struktur


Spyglass von Shorai-san

Strukturierte metrische Namespaces sind wichtig für den schnellen Zugriff auf Informationen bei Vorfällen. Planen Sie Namen und metrische Dimensionen sorgfältig, um eine Vielzahl von Abfragen und Erweiterungen zu unterstützen. Eine Möglichkeit, ein flexibles Metrikmodell effektiv zu erstellen, besteht darin, sie als Baum zu betrachten.

Dies bietet mehrere Vorteile: Anzeigen bestimmter Teilmengen von Daten, Definieren einer Metrik in Bezug auf ihre untergeordneten Daten und Herstellen von Beziehungen zwischen Metriken. Mail.ru Cloud Solutions

Team Übersetzter Artikel Hier werden die Eigenschaften von Metrik-Namespaces erläutert, sodass Sie die Details von Abfragen schrittweise erweitern und zu Teilmengen von Daten wechseln sowie die Metrik unter dem Gesichtspunkt der Metriken anzeigen können, aus denen sie besteht. Viele dieser Konzepte sind Ihnen vertraut, da sie in nativen Cloud-Überwachungslösungen wie Prometheus und DogStatsD implementiert sind.

Metrische Namespaces und ihre Struktur


Metrik-Namespaces sind die konzeptionellen Räume, in denen Metriken leben. Sie sind häufig auf eine Datenbank oder ein Konto beschränkt:


Der Metrik-Namespace ist auch die Struktur der Metriken innerhalb des Namespace. Der richtige Name und die richtige Struktur eröffnen eine Reihe großer Vorteile.

Der Namespace im obigen Diagramm hat keine explizite Struktur. Jede Metrik ist separat und unabhängig. Metriken haben nichts gemeinsam, außer der Tatsache, dass sie im selben Namespace vorhanden sind. In dieser nicht verwandten Struktur wird jede Metrik einzeln verwendet. Um die Häufigkeit von http-Anforderungen für einen Dienst anzuzeigen, muss direkt auf die Dienstmetrik zugegriffen werden - service_N_http_requests_total.

Angenommen, wir möchten die Gesamtzahl der Anforderungen an alle Dienste anzeigen. Was passiert im obigen Beispiel, wenn wir einen neuen Service erstellen?


Wenn die Gesamtzahl der Anforderungen durch Summieren der Anforderungen zu service_1 und service_2 berechnet wird, ändert das Hinzufügen von service_3 nicht die Gesamtzahl der Anforderungen. Um die korrekte Gesamtzahl der Anforderungen zu berechnen, müssen Sie die Zählregel ändern, indem Sie service_3_http_requests_total hinzufügen. Sehen Sie sich die Grafik mit der Anzahl der Anfragen unten an:


Metrikbaum


Eine Alternative zu einem strukturlosen Namespace besteht darin, eine explizite Struktur unter Verwendung des Metriknamens als Namespace zu akzeptieren. In der folgenden Abbildung sehen Sie diese Struktur als Baum:


In Prometheus und Datadog wird mithilfe von Tags und Tags eine Metrikstruktur erstellt . Mithilfe von Tags können Sie einen Baum dynamisch erstellen: Wenn ein neuer Dienst hinzugefügt wird, bezieht er sich auf die Stammmetrik.

In Prometheus kann die Anzahl der Anforderungen pro Sekunde für alle Dienste angezeigt werden, indem eine Anforderung erstellt wird, wie in der folgenden Abbildung dargestellt:


Mit einem strukturierten Namespace können Sie die Summe der Abfragen über den gesamten Knoten dynamisch berechnen. In diesem Fall berechnet Prometheus die Anzahl der Anforderungen pro Sekunde für jeden Dienst als separate Metrik.

Vererbungsmetriken definieren


Bei Verwendung des Metrikbaums enthält jede Metrikdimension (mit „Service“ bezeichnet) eine individuelle Häufigkeit von Anforderungen für einen bestimmten Service. Mithilfe des Metrik-Namespace können Sie nicht nur die gesamte Anforderungshäufigkeit, sondern auch die Anforderungshäufigkeit für jeden Dienst abrufen:


Mithilfe des Namespace können Sie nicht nur die allgemeinen Metrikdaten auswählen und visualisieren, sondern auch die Daten des Teils der allgemeinen Metrik, gruppiert nach Attributen. Im obigen Bild ist also die Häufigkeit von Anforderungen an einzelne Dienste sichtbar. Ihre Summe gibt die Häufigkeit von Anforderungen an den Knoten an.

Eingrenzen der Stichprobe - Teilmengen von Daten


Namespaces unterstützen auch das Eingrenzen von Abfragen, um bestimmte Teilmengen von Daten abzurufen. Stellen wir zum Beispiel die Frage: "Was ist die p99-Verzögerung (99% der Anforderungen sind schneller als die angegebene Verzögerung) bei allen erfolgreichen HTTP-Anforderungen für Server mit kanarischer Bereitstellung?".


Der obige Baum modelliert das Konzept eines Namespace und modelliert optional, wie Metriken auf der Festplatte gespeichert werden. Durch die Verwendung eines genau definierten Metrik-Namespace können Sie Metriken auf jeden Parameter erweitern.

Das Bild unten zeigt eine Grafik von p99 und p50 aus dem obigen Metrikbaum:


Wenn Sie eine spezifischere Anfrage stellen, können Sie beispielsweise die folgende Frage beantworten: "Wie hoch ist die Verzögerung p99 bei allen erfolgreichen HTTP-Anfragen für Server mit kanarischer Bereitstellung im Kontext jedes Servers?"


Unten finden Sie eine Visualisierung einer Metrik mit einer Auswahl von machine_id:


Da die Metrik eine genau definierte Struktur hat, können wir die erforderlichen Daten aus der Metrik der obersten Ebene auswählen, indem wir die erforderlichen Auswahlkriterien angeben - in unserem Fall machine_id.

Gewinnchancenregel


Koeffizienten sind eine weitere Möglichkeit, Daten (Korrelationen) zu strukturieren. Dies ist ein sehr leistungsfähiger Mechanismus und die Grundlage für die Berechnung der Verfügbarkeit und Fehlerrate von SLOs (diese Indikatoren wurden von Google SRE-Experten populär gemacht).

Mit Koeffizienten kann der Endbenutzer Metriken explizit zuordnen und eine Metrikstruktur erstellen. Diese Beziehungen werden am häufigsten als Prozentsatz ausgedrückt, dh die Zugänglichkeit kann als Verhältnis von "erfolgreichen Anforderungen / Gesamtzahl der Anforderungen" und der Fehlerrate als "Anzahl der Fehler / Gesamtzahl der Anforderungen" berechnet werden. Ein weiteres Beispiel für einen Koeffizienten ist, wie oft ein Zustand aus mehreren Zuständen entsteht.

Lassen Sie uns dies veranschaulichen und annehmen, dass es eine Anwendung gibt, die die Anforderung ausgeführt hat, und die Anforderung könnte zu einem von zwei Zuständen führen: Daten aus dem Cache (cache_hit: true) oder Daten aus der Hauptquelle (cache_hit: false). Um die Cache-Trefferquote anzuzeigen, sollten die Daten wie folgt strukturiert sein:


Die folgende Grafik zeigt die Häufigkeit des Treffer- und Fehlercaches. Jede Anforderung wird entweder in den Cache verschoben oder nicht. Insgesamt treten ca. 160 Anfragen pro Sekunde auf:


Das folgende Diagramm zeigt die Cache-Trefferquote im Verhältnis zur Gesamtzahl der Anforderungen. Der Treffer-Koeffizient beträgt 0,5 (50%):


Sie können also zwei beliebige Metriken in Beziehung setzen. In Datadog und Prometheus wird diese Beziehung durch eine einfache arithmetische Operation ausgedrückt.

Fragen beantwortet durch Daten


Es ist wichtig, über die Fragen nachzudenken, die Daten beantworten sollten. Im allerersten Beispiel kann die Datenabtastung die Frage nicht genau beantworten: "Wie viele Anforderungen pro Sekunde verarbeiten alle Instanzen?". Der Namespace-Baum würde jedoch helfen, die Antwort zu erhalten.

Ein weiterer häufiger Fall ist der Namespace von Client-Metriken mit dem Namen des Dienstes und nicht mit dem Namen der Client-Bibliothek. Durch Hinzufügen des Namens der Clientbibliothek zum Namespace wird die Frage beantwortet: "Die Gesamtzahl der Anforderungen aller Clients?".

Allgemeine nützliche Fragen beantworten die vier goldenen Signale von Google . Jede Frage wird allgemein gestellt und dann spezifiziert:

  1. Wie viele Anfragen stellen insgesamt alle Kunden?
  2. Wie viele Anfragen stellt jeder Kunde?
  3. Wie viele Anfragen stellt jeder Client an jeden Knoten?
  4. Wie hoch ist der Prozentsatz erfolgreicher Serveranforderungen für jeden RPC?

Die gleiche Strategie gilt für Verzögerungen, Fehlerraten und Ressourcensättigung.

Generische getaggte Metriken


Folgendes habe ich in Best Practices für die Abfrageoptimierung und Datenspeicherung für Datadog und Prometheus gelesen.

Um eine globale Ansicht zu erhalten, die die Detaillierung bestimmter Segmente unterstützt, beginnen Sie mit einem gemeinsamen oberen Namespace und fügen Sie Tags und Beschriftungen hinzu (beginnen Sie mit gemeinsamen und fügen Sie dann spezifischere hinzu). Beachten Sie dabei die folgende Empfehlung.

Vorsicht vor Kardinalität


Sowohl Datadog als auch Prometheus empfehlen, die Anzahl der Tags zu begrenzen. Um das Prometheus-Handbuch zu zitieren :



, , , . , .

, 10. , , . .

, 100 , , .

, node_exporter. . , , node_filesystem_avail. 10 000 , 100 000 node_filesystem_avail, Prometheus.

Wenn Sie FS-Kontingente pro Benutzer hinzufügen, erreichen Sie schnell mehrere zehn Millionen Zeitreihen von 10.000 Benutzern pro 10.000 Knoten. Dies ist zu viel für die aktuelle Implementierung von Prometheus. Selbst bei niedrigeren Zahlen haben Sie keine anderen, möglicherweise nützlicheren Indikatoren mehr für diese Überwachung.

Beginnen Sie ohne Tags und fügen Sie im Laufe der Zeit nach Bedarf weitere Tags hinzu.

Eine bequeme Überwachung auf Benutzerebene wird häufig besser durch verteilte Ablaufverfolgung erreicht . Die verteilte Ablaufverfolgung verfügt über einen eigenen Metrikbereich und bewährte Methoden.

Fazit


Es ist wichtig zu verstehen, welche Fragen durch Strukturierung der Metriken beantwortet werden können. Eine falsche Struktur führt zu Schwierigkeiten beim Erhalten von Antworten. Die Strukturierung des Metrikraums ist zwar nicht kompliziert, erfordert jedoch eine vorherige Planung, um die Daten optimal nutzen zu können.

Wenn Probleme auftreten, ist die Möglichkeit, die Metrik manuell zu erweitern, um alle Status anzuzeigen, von entscheidender Bedeutung, und es ist wichtig, dass der Namespace dies nicht beeinträchtigt.

Viel Glück!

Was noch zu lesen :

  1. Einfache Caching-Methoden in GitLab CI: Ein Bildhandbuch .
  2. Top 10 Kubernetes Tricks und Tipps .
  3. Unser Telegrammkanal zur digitalen Transformation .

More articles:


All Articles