Eine Observability-Lösung sollte jedem Incident-Responder helfen zu verstehen, was sich geändert hat und warum. Es wurde bereits viel darüber geschrieben. Unterschied zwischen Überwachung und Beobachtbarkeit Ein einfacher Weg, um zu verstehen, wie beides für die Reaktion auf Sicherheitsvorfälle unerlässlich ist, besteht darin, zu betrachten, wie Kunden PagerDuty– sowohl mit Monitoring- als auch mit Observability-Tools – nutzen, um die richtige Antwort zu finden. Der geschäftliche Vorteil, dass weniger Zeit und Aufwand für die Identifizierung und Behebung eines Problems benötigt werden, zeigt sich in einem verbesserten Kundenerlebnis.

Verloren im Meer der Tabs

Aufgrund der Art des Workflows sind Schnittstellen zwischen PagerDuty und Monitoring- sowie Observability-Lösungen nichts Neues. Die meisten Änderungen und Ereignisse im Zusammenhang mit einem laufenden Dienst lassen sich jedoch nicht mit technischen Metriken wie Latenz und Fehlern verknüpfen. Im besten Fall werden in einem Metrikdiagramm Markierungen angezeigt, die eine Messung visuell mit einem kürzlich erfolgten Deployment in Verbindung bringen. Solche Markierungen oder Overlays sind bei traditionellen Architekturen (z. B. einem Webserver, der mit einer Datenbank kommuniziert) hilfreich, skalieren aber bei verteilten Systemen, in denen gleichzeitig Dutzende von Änderungen an Hunderten von Diensten stattfinden, sehr schlecht.

Nutzen Sie OpenTelemetry zum Aufbau einer ereignisgesteuerten Observability-Pipeline.

OpenTelemetry ist ein einheitlicher Standard, der Unternehmen dabei unterstützt, verschiedene Telemetriedaten anwendungs- und serviceübergreifend herstellerneutral zu kombinieren. Er bietet zudem Vorteile für alle DevOps- und Cloud-Tools. Im Kern definiert OpenTelemetry ein Datenmodell, das den gesamten Entwicklungszyklus beschreibt, einschließlich Metriken zur Code- und Infrastrukturleistung, Beziehungen zwischen Diensten und detaillierten technischen Metadaten.

Mit über 100 verschiedene Integrationen OpenTelemetry erweitert die Anzahl potenzieller Workflows zwischen Lösungen erheblich (und die Zahl steigt stetig), ohne dass dafür Neuentwicklungen, benutzerdefinierte Instrumentierung oder API-Verbindungen erforderlich sind. Da es sich um einen Open-Source-Standard handelt, ist es zudem leicht erweiterbar. 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 entwickelt, die alle Metriken und Traces mit zugehörigen Vorfall-IDs versieht. Sobald ein PagerDuty Vorfall ausgelöst und behoben wird, aktualisieren wir die Tags unserer Metriken und Traces mit einem Link zum aktiven Vorfall.

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

Der goldene Pfad: PagerDuty und Lightstep Change Intelligence

In diesem Beispiel kommt es zu einem Latenzanstieg bei einer Online-E-Commerce-Website und es wird ein PagerDuty Vorfall für den „nginx“-Dienst erstellt.

Schritt 1) Kennzahlen-Dashboard

Als Nächstes sehen wir uns ein Lightstep-Dashboard an, das einige Metriken des Nginx-Dienstes mit einem aktiven PagerDuty Vorfall anzeigt. Sofort fällt etwas auf: Es gibt einen verdächtigen Ausschlag. Man kann mit Fug und Recht annehmen, dass dieser Ausschlag auf ein Problem hinweist, das untersucht werden sollte.

Schritt 2) Veränderung untersuchen

Mit nur zwei Klicks auf das verdächtige Diagramm können Sie auf die Lightstep Change Intelligence zugreifen, um alle Metriken und Traces zu analysieren und so eine bestmögliche Vermutung darüber zu ermitteln, was einen verdächtigen Ausschlag im Diagramm verursacht hat.

Schritt 3) Ermitteln Sie die Hauptursache

Im Rahmen der Änderungsanalyse untersucht Lightstep Metriken und Traces, um mögliche Ursachen eines laufenden Vorfalls zu ermitteln. Lightstep kann auch Leistungsänderungen in nachgelagerten Diensten berücksichtigen. Mit unserem benutzerdefinierten OpenTelemetry-Collector können wir den laufenden PagerDuty Vorfall im Zusammenhang mit dem Dienst einsehen. Dies hilft dem Reaktionsteam zu erkennen, dass die analysierten Metriken und Traces mit einem laufenden Vorfall zusammenhängen.

Telemetrie mit Menschen verbinden

Unser modifizierter OpenTelemetry-Collector schließt die Lücke zwischen technischen Leistungsdaten, Serviceverantwortlichen und aktiven Incidents. Abstrakte Werte wie CPU-Auslastung oder Speichernutzung werden nun einem aktiven PagerDuty Incident zugeordnet, was eine schnellere und effizientere Behebung ermöglicht. Über einen automatisch in Lightstep hinzugefügten Link gelangt man mit einem Klick zurück zum zugehörigen PagerDuty Incident.

Da PagerDuty Vorfälle über OpenTelemetry-Metriken und -Traces verfügbar sind, wird auch die Nachanalyse vereinfacht. Lightstep lässt sich so konfigurieren, dass historische Metriken und Traces nur bei aktiven Vorfällen erfasst werden. Dies hilft Teams, das Verhalten ihres Dienstes bei Vorfällen der vergangenen Woche oder des Vormonats besser zu verstehen.

Im obigen Screenshot bedeutet das Fehlen von Daten, dass kein aktiver Vorfall vorlag. Dies ist ein seltenes Beispiel dafür, dass ein leeres Dashboard ein gutes Zeichen sein kann.

OpenTelemetry vereinheitlicht die DevOps-Toolchain

Der OpenTelemetry-Standard schafft die Grundlage für erstklassige Technologien zur Vernetzung von Lösungen. Selbst kleinste Informationen – sei es zu einem PagerDuty Vorfall, dem aktuellen Status eines Feature-Flags oder einer Bereitstellungsversion – verbinden den Produktwert eines Anbieters mit der gesamten Entwicklungspipeline. Mit OpenTelemetry geschieht dies durch offene Standards zur automatischen Instrumentierung des Kundencodes. Andere Produkte oder auch benutzerdefinierte Tools können diese Daten nun in einen produktiven Entwickler-Workflow integrieren.

Möchten Sie mehr erfahren?

• Was ist OpenTelemetry?
• Funktionsflags mit OpenTelemetry und Split.io
• Observability in GitHub Actions mit Lightstep und OpenTelemetry
• Lightstep Partner Toolkit