Eine Observability-Lösung sollte jedem Incident Responder helfen zu verstehen, was sich geändert hat und warum. Es wurde viel über die Unterschied zwischen Überwachung und Beobachtbarkeit , aber man kann leicht verstehen, wie wichtig beide für die Reaktion auf Vorfälle sind, wenn man sich vor Augen führt, wie Kunden PagerDuty– mit Überwachungs- und Beobachtungstools – verwenden, um die richtige Antwort zu finden. Der geschäftliche Vorteil, der durch die Reduzierung des Zeit- und Arbeitsaufwands zur Identifizierung und Behebung eines Problems entsteht, wird durch eine verbesserte Kundenerfahrung realisiert.

Verloren in einem Meer aus Tabs

Angesichts der Art des Workflows sind Hooks zwischen PagerDuty und Überwachungs- und Beobachtungslösungen nichts Neues. Die meisten Änderungen und Ereignisse, die mit einem laufenden Dienst zusammenhängen, sind jedoch nicht mit technischen Kennzahlen wie Latenz und Fehlern verknüpft. Wenn Sie Glück haben, erhalten Sie möglicherweise Markierungen in einem Kennzahlendiagramm, um eine Messung visuell mit einer kürzlich erfolgten Bereitstellung zu korrelieren. Diagrammmarkierungen oder Overlays sind bei herkömmlichen Architekturen (z. B. einem Webserver, der mit einer Datenbank kommuniziert) nützlich, lassen sich jedoch bei verteilten Systemen nur sehr schlecht skalieren, wenn zu jedem Zeitpunkt Dutzende von Änderungen bei Hunderten von Diensten stattfinden.

Verwenden Sie OpenTelemetry, um eine ereignisgesteuerte Observability-Pipeline zu erstellen

OpenTelemetry ist ein einheitlicher Standard, der Unternehmen dabei hilft, verschiedene Arten von Telemetrie herstellerneutral über Anwendungen und Dienste hinweg zu kombinieren. Seine Vorteile erstrecken sich auch auf alle DevOps- oder Cloud-Tools. OpenTelemetry definiert im Kern ein Datenmodell, das beschreiben kann, was während des gesamten Entwicklungslebenszyklus geschieht, einschließlich Metriken im Zusammenhang mit der Leistung von Code oder Infrastruktur, Beziehungen zwischen Diensten und detaillierten technischen Metadaten.

Mit über 100 verschiedene Integrationen (und es werden immer mehr) OpenTelemetry erhöht auch die Anzahl potenzieller Workflows zwischen Lösungen erheblich, ohne dass neue Entwicklungen, benutzerdefinierte Instrumente oder API-Verbindungen erforderlich sind. Und da es sich um einen Open-Source-Standard handelt, lässt es sich leicht erweitern. In diesem Fall ermöglicht es uns, aktive PagerDuty Vorfälle mit zugehörigen Überwachungsdaten zu verknüpfen.

Mithilfe des OpenTelemetry-Collectors haben wir eine Integration geschrieben, die alle Metriken und Traces mit zugehörigen Vorfallkennungen kennzeichnet. Immer wenn ein PagerDuty Vorfall ausgelöst und gelöst wird, aktualisieren wir die Tags unserer Metriken und Traces mit einem Link zurück zum aktiven Vorfall.

Als Observability-Plattform kann Lightstep dadurch nun effiziente Lösungspfade erzeugen.

Der goldene Pfad: PagerDuty und Lightstep ändern die Intelligenz

In diesem Beispiel steigt die Latenz für eine Online-E-Commerce-Site sprunghaft an und es wird ein PagerDuty Vorfall für den Dienst „nginx“ erstellt.

Schritt 1) Metrik-Dashboard

Als Nächstes springen wir in ein Lightstep-Dashboard, das einige für den nginx-Dienst mit einem aktiven PagerDuty Vorfall erfasste Metriken anzeigt. Sofort sieht etwas nicht ganz richtig aus – es gibt einen verdächtigen Anstieg. Es ist eine vernünftige Annahme, dass dieser Anstieg auf ein Problem hinweist, das untersucht werden sollte.

Schritt 2) Veränderungen untersuchen

Mit nur zwei Klicks auf das verdächtige Diagramm können Sie auf die Änderungsinformationen von Lightstep zugreifen, um alle Kennzahlen und Spuren zu analysieren und so die bestmögliche Vermutung über die Ursache eines verdächtigen Anstiegs im Diagramm anzustellen.

Schritt 3) Grundursache ermitteln

Im Rahmen der Änderungsintelligenz analysiert Lightstep Metriken und Spuren, um mögliche Ursachen eines laufenden Vorfalls zu ermitteln. Lightstep kann auch Leistungsänderungen in nachgelagerten Diensten berücksichtigen. Mit unserem benutzerdefinierten OpenTelemetry-Sammler können wir den laufenden PagerDuty Vorfall im Zusammenhang mit dem Dienst sehen. Dies hilft dem Responder zu erkennen, dass die von ihm betrachteten Metriken und Spuren mit einem laufenden Vorfall verbunden sind:

Telemetrie mit Menschen verbinden

Unser modifizierter OpenTelemetry-Collector schließt die Lücke zwischen technischen Leistungsdaten, Servicebesitzern und aktiven Vorfällen. Etwas Abstraktes wie die CPU-Auslastung oder die Speichernutzung wird jetzt einem aktiven PagerDuty Vorfall zugeordnet, was eine schnellere und effizientere Lösung ermöglicht. Über einen in Lightstep automatisch hinzugefügten Link können Sie mit einem Klick zum zugehörigen PagerDuty Vorfall zurückspringen:

Da PagerDuty Vorfälle über OpenTelemetry-Metriken und -Traces verfügbar sind, wird auch die Post-Mortem-Analyse einfacher. Lightstep kann so konfiguriert werden, dass historische Metriken und Traces gespeichert werden, die nur bei aktiven Vorfällen erfasst werden. So können Teams besser verstehen, wie sich ihr Service bei Vorfällen verhält, die in der vergangenen Woche oder im vergangenen Monat aufgetreten sind.

Wenn im obigen Screenshot keine Daten angezeigt werden, bedeutet dies, dass kein aktiver Vorfall aufgetreten ist. Dies ist ein seltenes Beispiel dafür, dass ein leeres Dashboard eine gute Sache ist.

OpenTelemetry vereinheitlicht die DevOps-Toolchain

Der OpenTelemetry-Standard schafft eine Grundlage für die Verbindung von Lösungen mit der besten Technologie. Sogar eine einfache Informationsbrockenkette – sei es ein PagerDuty Vorfall, der aktuelle Status eines Feature-Flags oder eine Bereitstellungsversion – verbindet den Produktwert eines Anbieters mit der gesamten Entwicklungspipeline. Mit OpenTelemetry geschieht dies mithilfe offener Standards für die automatische Instrumentierung des Codes eines Kunden. Jetzt können andere Produkte oder sogar benutzerdefinierte Tools diese Daten als Teil eines produktiven Entwickler-Workflows verwenden.

Möchten Sie mehr erfahren?

• Was ist OpenTelemetry?
• Feature Flags mit OpenTelemetry und Split.io
• Beobachtbarkeit in GitHub-Aktionen mit Lightstep und OpenTelemetry
• Lightstep Partner Toolkit