Sehen Sie sich unser Webinar zur automatisierten Diagnose an auf Anfrage um mehr über allgemeine Diagnosen für allgemeine Komponenten zu erfahren und wie wir Ihnen sofort einsatzbereite Jobvorlagen zur Verfügung stellen, damit Sie sofort loslegen können.

Dies ist der zweite Teil einer Reihe über automatisierte Diagnose, ein häufiger Anwendungsfall für die PagerDuty Prozessautomatisierung Portfolio.

Im letztes Stück haben wir über die Grundlagen der automatisierten Diagnose gesprochen und darüber, wie Teams die Lösung nutzen können, um Eskalationen an Spezialisten zu reduzieren und Einsatzkräften zu ermöglichen, schneller zu handeln. In diesem Blog sprechen wir über einige grundlegende Diagnosebeispiele für Komponenten, die für unsere Benutzer am relevantesten sind.

Aber bevor wir loslegen, wollen wir klären, was automatisierte Diagnose ist nicht , basierend auf dem Feedback des Publikums auf Twitter von letzter Artikel :

1. Automatisierte Diagnose unterscheidet sich von Alarmkorrelation . Die Korrelation der Alarme hängt von einer bestimmten Signaltiefe sowie einer Engine ab die die korrelierten Signale richtig identifizieren können. Die automatische Diagnose soll dem Ersthelfer helfen, die Ursache des Problems zu ermitteln, um das Problem entweder schneller selbst zu beheben oder genauer zu eskalieren.
2. Automatisierte Diagnose ist nicht dasselbe wie Monitoring . Das Monitoring ist darauf ausgerichtet, unerwünschte Zustände in Leistung oder Aktivität zu identifizieren. Das bedeutet, dass am meisten Die Überwachung ist nicht darauf ausgelegt, die Aktivitäten eines Ersthelfers zu simulieren, um ein echtes Positiv zu bestätigen oder die ersten zu ergreifenden Maßnahmen zu ermitteln. Die Überwachung konzentriert sich auf das Auslösen des Alarms. Die automatisierte Diagnose konzentriert sich darauf, zu bestimmen, wie ein Problem behoben werden kann, nachdem der Alarm bereits erstellt wurde.

Automatisierte Diagnosen können jedoch durchaus Daten nutzen, die von Überwachungstools erfasst werden – die meisten Leute wenden nicht auf jeden erfassten Datenpunkt Schwellenwerte an. Tatsächlich besteht eine unserer am häufigsten verwendeten Diagnoseintegrationen darin, CloudWatch-Protokolle abzufragen. Während wir einen Protokollaggregator als Überwachungstool betrachten, bestehen die ersten Untersuchungsschritte manchmal darin, die Daten im Überwachungstool zu betrachten, das nur zur Diagnose von Problemen dient.

Wenn den Einsatzkräften On-Demand- oder Pre-Run-Diagnosefunktionen für ihre eigenen Umgebungen zur Verfügung gestellt werden, kann dies ihnen dabei helfen, die wahrscheinliche Ursache schnell zu ermitteln und so weniger Personen, die bei dem Vorfall helfen. Indem Ersthelfern „diagnostische“ Daten zur Verfügung gestellt werden, die normalerweise nur von Fachexperten abgerufen werden können, wird die Notwendigkeit, mehr Personen zur Fehlerbehebung bei Vorfällen hinzuzuziehen, erheblich reduziert . Dies wiederum senkt die Kosten von Vorfällen und verkürzt die durchschnittliche Reaktionszeit (MTTR) durch die Automatisierung der Ermittlungsschritte, die normalerweise manueller Natur sind.

Der Status Quo: Automatisierung bei der Reaktion auf Vorfälle

Betriebsleiter sind oft begeistert von der Idee, Selbstheilung oder automatische Behebung zu ermöglichen. Es ist ganz natürlich anzunehmen, dass eine schnellere Lösung durch Automatisierung gleichbedeutend mit „einer Heilung“ ist. Doch meistens greift die Branchentheorie, dass „keine zwei Vorfälle wirklich identisch sind“. Bei einem hohen Grad an Variabilität verringert dies den Wert einer solchen potenziellen Automatisierung, da sie weniger wahrscheinlich ausgeführt wird. Beispielsweise kann der Neustart eines Kerndienstes die richtige Methode sein, um das heutige Problem zu beheben, aber morgen könnte dies zu einem kaskadierenden Ausfall – und einem noch größeren Vorfall – führen.

*Der Leser schaltet nun kognitiv in den ersten Schritt einer Antwort.*

Aber wissen Sie, was sich häufig wiederholt? Es sind dieselben Ermittlungsschritte, die ein Mitarbeiter unternimmt, um zu diagnostizieren, was schiefgelaufen ist, und um herauszufinden, was passiert ist. Je mehr Aktionen sich wiederholen, desto wertvoller ist die Automatisierung. Nehmen wir beispielsweise an, ein Vorfall tritt in Ihrer Kubernetes-Verteilung auf. Unabhängig von der Art des Vorfalls, sei es etwas in Ihrem Image-Repository oder Ihrem Load Balancer, werden Sie wahrscheinlich immer noch denselben Diagnoseschritt ausführen, nämlich Ihre Kubernetes-Protokolle abzurufen.

Diese Diagnoseschritte bleiben oft statisch – größtenteils – je nach der Komponente, mit der Sie arbeiten, unabhängig von der Priorität des auftretenden Vorfalls. Automatisierte Diagnosen können auf heterogene Vorfälle angewendet werden; sie müssen nicht speziell für denselben, wiederkehrenden Vorfall entwickelt werden, sondern können für fast jede gängige Komponente auf alle Arten von häufigen Vorfalltypen und -schweregraden angewendet und angepasst werden – spezifisch für Ihre Umgebung. Stellen Sie es sich wie einen Arztbesuch vor. Egal, ob Sie wegen einer bestimmten Beschwerde oder nur zu einer jährlichen Kontrolluntersuchung in die Notaufnahme gehen, Sie werden trotzdem bei jedem Besuch Temperatur, Blutdruck und Gewicht gemessen.

Häufige Beispiele

Jede Entwicklerumgebung ist anders; aber viele Umgebungen sind sich auch ziemlich ähnlich, wenn man genauer hinsieht. In den Anfangsphasen einer Reaktion stammen die meisten Diagnosen aus drei Hauptdatenquellen:

• Anwendungsdaten
• Systemdaten
• Umweltdaten

Es gibt mehrere Beispiele für gängige Diagnosen und Komponenten, die zu Beginn einer Reaktion automatisch abgerufen werden können. Dies würde dem Responder nicht nur helfen, die Schwere des Vorfalls besser zu verstehen, sondern auch sicherstellen, dass der Responder nicht zu viele Spezialisten hinzuzieht und sie bei ihrer normalen Arbeit unterbricht. Sehen wir uns zum Beispiel Folgendes an: Kubernetes (k8s) als Komponente für einen Responder während eines Vorfalls. Wenn ein Vorfall in einer k8s-Umgebung auftritt, führt der Infrastrukturingenieur, der die Technologie wartet, normalerweise folgende Aktionen aus:

• Endstücke vom K8s-Pod
• Rufen Sie Protokolle von K8s nach Selektorbezeichnung ab
• Image-Repository prüfen
• Beschreiben der Bereitstellung
• Befehl im Pod ausführen

Eines haben all diese Aktionen gemeinsam? Ein typischer L1-Responder, der einen Vorfall bestätigt, weiß nicht, wie er diese Aktionen orchestrieren soll – das ist einfach nicht sein Fachgebiet. Aber mit den sofort einsatzbereiten Jobs der automatischen Diagnose von PagerDury kann der L1-Responder diese Diagnosen automatisch ausführen und diese Jobs ausführen, was die Reaktion beschleunigt und die Eskalation an den für die K8s-Umgebung verantwortlichen Infrastrukturingenieur reduziert.

Einige gängige Diagnose- und Warnbeispiele sind:

• CPU-/Speicherintensive Dienste
  • Allgemeine Warnung: Hohe CPU/Speicher
  • Häufige Frage: Welcher/welche Dienst(e) verbrauchen CPU/Speicher?
• Dateigröße / Datenträgerverbrauch
  • Allgemeine Warnung: Hohe CPU/Speicher
  • Häufige Frage: Welche Dateien/Verzeichnisse verbrauchen den meisten Speicherplatz?
• Systemprotokolle: Linux/Windows-Befehle
  • Allgemeine Warnung : Server-/Dienstprobleme
  • Häufige Frage: Handelt es sich um ein Betriebssystem- oder App-Problem?
• SQL-Datenbankbefehle
  • Allgemeine Warnung: Datenbankblöcke/Deadlocks
  • Häufige Frage: Gibt es eine Abfrage mit langer Ausführungsdauer, die andere Datenbankanforderungen blockiert?
• Host-Verfügbarkeit
  • Allgemeine Warnung: Host ausgefallen
  • Häufige Frage: Ist es tatsächlich ausgefallen oder handelt es sich um ein Problem mit der Erreichbarkeit aufgrund einer Fehlalarmmeldung?
• Anwendungsfehler: Anwendungsprotokolle oder Traces
  • Allgemeine Warnung: 400/500 Fehlercodes
  • Häufig gestellte Frage: Was ist der Stacktrace?

Einige Beispiele gängiger Diagnosen für bekannte Komponenten:

• Wolkenuhr Protokolle: Oberflächenspezifische Anwendungs- und VPC-Protokolle.
• ECS: Zeigen Sie Fehler gestoppter ECS-Aufgaben an.
• ELB: Debuggen Sie nicht verfügbare Zielgruppeninstanzen.
• Kubernetes . Rufen Sie Protokolle von Pods nach Auswahlbezeichnung ab.
• Linux. Servicestatus abrufen.
• Nginx . Fehlerprotokolle abrufen.
• Redis . Langsame Protokolleinträge.

Und dies sind nur einige der über 30 sofort einsatzbereiten Jobvorlagen, die wir für unsere Benutzer erstellt haben und die Sie in der Lösungshandbuch zur automatisierten Diagnose. Um die Automated Diagnostics Solution nutzen zu können, benötigen Sie entweder eine PagerDuty Runbook Automation-Lizenz oder eine Process Automation-Lizenz (früher Rundeck Enterprise). Weitere Informationen finden Sie in der FAQ für Einzelheiten zur Verwendung. Wenn Sie keine Lizenz für eines dieser Produkte besitzen, kontaktiere uns um mehr zu lernen.

Automatisierung der Diagnose in PagerDuty

Vorfälle, die den Responder benachrichtigen, sind mit Informationen gefüllt, die von Überwachungstools bereitgestellt werden, die eine „kurzsichtige“ Sicht auf die Warnung(en) haben. Ein häufiges Beispiel ist, dass eine hohe CPU-Auslastung eine Warnung auslöst und dies einen Responder benachrichtigt. Die in der Warnung enthaltenen Informationen sind jedoch oberflächlich, da sie nicht angeben, was die Ursache für die CPU-Spitzen sein könnte.

Diagnosedaten sind die tieferen Informationen, die helfen, die Fragen „Warum“ und „Wo“ von Vorfällen zu beantworten. Obwohl einige Überwachungs- und Korrelationstools manche Hilfe bei der Bereitstellung einer Ursachenanalyse für Benutzer, die meisten sind jedoch nicht in der Lage, die Untersuchungs-/Fehlerbehebungsschritte eines Ersthelfers nachzubilden, bei denen unterschiedliche Datenquellen in einer einheitlichen Ansicht zusammengefasst werden. Indem den Ersthelfern On-Demand- oder Pre-Run-Diagnosefunktionen bereitgestellt werden, erhöhen sich die Chancen, dass der Ersthelfer das Problem selbst löst, sowie die Wahrscheinlichkeit, dass weniger Personen, die bei dem Vorfall helfen. Rufen Sie die automatische Diagnose auf.

Möchten Sie mehr über gängige Diagnosen für die von Ihnen verwendeten Komponenten erfahren? Registrieren für unser Webinar am 14. September mit gleichem Namen, moderiert von Justyn Roberts, Senior Solutions Consultant, PagerDuty. Neu in der Prozessautomatisierung? Fordern Sie ein Demo . Nutzen Sie bereits PageDuty Process Automation? Schauen Sie sich die automatisierte Diagnose Lösungsleitfaden um den End-to-End-Prozess zur Erreichung der vollständigen Lösung zu sehen. Fragen? Kontaktieren Sie mich direkt auf Twitter @sordnam A und lass uns chatten!