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 Serie über automatisierte Diagnose, ein häufiger Anwendungsfall für die PagerDuty -Prozessautomatisierung Portfolio.

Im letztes Stück Wir haben die Grundlagen der automatisierten Diagnose besprochen und wie Teams die Lösung nutzen können, um Eskalationen an Spezialisten zu reduzieren und den Einsatzkräften schnellere Maßnahmen zu ermöglichen. In diesem Blogbeitrag stellen wir einige grundlegende Diagnosebeispiele für die für unsere Benutzer relevantesten Komponenten vor.

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 der Alarmkorrelation . Die Alarmkorrelation hängt von einer bestimmten Signaltiefe sowie einer Engine ab die die korrelierten Signale richtig identifizieren können. Die automatisierte Diagnose soll dem Ersthelfer helfen, die Ursache des Problems zu triangulieren, um das Problem entweder schneller selbst zu beheben oder es präziser zu eskalieren.
2. Automatisierte Diagnose ist etwas anderes als Überwachung . Das Monitoring ist darauf ausgerichtet, unerwünschte Zustände in der 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 einen echten Positivbefund zu bestätigen oder die ersten zu ergreifenden Maßnahmen zu identifizieren. Die Überwachung konzentriert sich auf die Auslösung einer Warnung. Die automatisierte Diagnose konzentriert sich darauf, zu ermitteln, wie ein Problem behoben werden kann, sobald die Warnung bereits ausgelöst wurde.

Automatisierte Diagnosen können durchaus die von Überwachungstools erfassten Daten nutzen – die meisten Anwender wenden nicht auf jeden erfassten Datenpunkt Schwellenwerte an. Eine unserer am häufigsten genutzten Diagnoseintegrationen ist die Abfrage von CloudWatch-Protokollen. Obwohl wir einen Protokollaggregator als Überwachungstool betrachten, bestehen die ersten Untersuchungsschritte manchmal darin, die Daten im Überwachungstool zu betrachten, das ausschließlich zur Problemdiagnose dient.

Die Bereitstellung von On-Demand- oder Pre-Run-Diagnosefunktionen für die eigene Umgebung kann den Ersthelfern 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 der Bedarf an zusätzlichen Mitarbeitern zur Fehlerbehebung bei Vorfällen erheblich reduziert . Dies wiederum senkt die Kosten von Vorfällen und verkürzt die mittlere Reaktionszeit (MTTR) durch die Automatisierung der Untersuchungsschritte, die normalerweise manueller Natur sind.

Der Status Quo: Automatisierung bei der Incident Response

Betriebsleiter sind oft begeistert von der Idee, Selbstheilung oder automatische Fehlerbehebung zu ermöglichen. Es liegt nahe, anzunehmen, dass eine schnellere Problemlösung durch Automatisierung gleichbedeutend mit einer „Heilung“ ist. Doch häufig greift die Branchentheorie, dass „keine zwei Vorfälle wirklich identisch sind“. Hohe Variabilität mindert den Wert einer solchen potenziellen Automatisierung, da sie seltener umgesetzt wird. Beispielsweise kann der Neustart eines Kerndienstes zwar heute die richtige Lösung für ein Problem sein, morgen aber zu einem kaskadierenden Ausfall – und einem noch größeren Vorfall – führen.

*Der Leser schaltet nun kognitiv auf die Anfangsphasen einer Antwort um.*

Aber wissen Sie, was häufig repetitiv ist? Es sind dieselben Untersuchungsschritte, die ein Mitarbeiter unternimmt, um zu diagnostizieren, was schiefgelaufen ist und was passiert ist. Je repetitiver die Aktionen, desto wertvoller ist die Automatisierung. Nehmen wir beispielsweise an, ein Vorfall tritt in Ihrer Kubernetes-Distribution auf. Unabhängig von der Art des Vorfalls – sei es in Ihrem Image-Repository oder Ihrem Load Balancer – werden Sie wahrscheinlich immer denselben Diagnoseschritt durchführen und Ihre Kubernetes-Protokolle abrufen.

Diese Diagnoseschritte bleiben oft – größtenteils – statisch und hängen von der jeweiligen Komponente ab, 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 nahezu jede gängige Komponente auf alle gängigen Vorfalltypen und -schweregrade angewendet und angepasst werden – spezifisch für Ihre Umgebung. Stellen Sie es sich wie einen Arztbesuch vor. Ob Sie wegen einer bestimmten Beschwerde in die Notaufnahme gehen oder nur zur jährlichen Kontrolluntersuchung, beim Betreten werden Ihre Temperatur, Ihr Blutdruck und Ihr Gewicht gemessen.

Häufige Beispiele

Jede Entwicklerumgebung ist anders; viele Umgebungen ähneln sich jedoch auch, wenn man genauer hinsieht. In der Anfangsphase einer Reaktion stammen die meisten Diagnosedaten aus drei Hauptdatenquellen:

• Bewerbungsdaten
• Systemdaten
• Umweltdaten

Es gibt mehrere Beispiele für gängige Diagnosen und Komponenten, die zu Beginn einer Reaktion automatisch abgerufen werden können. Dies hilft dem Einsatzleiter nicht nur, die Schwere des Vorfalls besser zu verstehen, sondern stellt auch sicher, dass er nicht zu viele Spezialisten hinzuzieht und diese in ihrer normalen Arbeit unterbricht. Betrachten wir zum Beispiel: 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, typischerweise folgende Aktionen aus:

• Tail-Logs vom K8s-Pod
• Rufen Sie Protokolle von K8s nach Selektorbezeichnung ab
• Überprüfen Sie das Image-Repository
• 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. Mit den sofort einsatzbereiten Jobs der automatisierten Diagnose von PagerDury kann der L1-Responder diese Diagnosen jedoch automatisch ausführen. Dies beschleunigt die Reaktion und reduziert die Eskalation an den für die K8S-Umgebung zuständigen Infrastrukturingenieur.

Einige gängige Diagnose- und Warnbeispiele sind:

• CPU-/Speicherintensive Dienste
  • Allgemeine Warnung: Hohe CPU/Speicher
  • Häufige Frage: Welcher/welche Dienst(e) verbraucht/verbrauchen CPU/Speicher?
• Dateigröße / Festplattenverbrauch
  • 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ührungszeit, 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 durch einen falsch-positiven Befund?
• Anwendungsfehler: Anwendungsprotokolle oder -spuren
  • Allgemeine Warnung: 400/500 Fehlercodes
  • Häufige Frage: Was ist der Stacktrace?

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

• Cloudwatch Protokolle: Oberflächenspezifische Anwendungs- und VPC-Protokolle.
• ECS: Zeigen Sie Fehler bei gestoppten ECS-Aufgaben an.
• ELB: Debuggen Sie nicht verfügbare Zielgruppeninstanzen.
• Kubernetes . Rufen Sie Protokolle von Pods nach Selektorbezeichnung ab.
• Linux. Dienststatus 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). Siehe die Häufig gestellte Fragen für Details zur Verwendung. Wenn Sie keine Lizenz für eines dieser Produkte haben, Kontakt um mehr zu erfahren.

Automatisierung der Diagnose in PagerDuty

Vorfälle, die den Responder benachrichtigen, enthalten Informationen von Überwachungstools, die die Alarme kurzsichtig betrachten. Ein häufiges Beispiel ist eine hohe CPU-Auslastung, die einen Alarm auslöst und den Responder benachrichtigt. Die in der Warnung enthaltenen Informationen sind jedoch oberflächlich und geben keine Auskunft über die mögliche Ursache der CPU-Spitze.

Diagnosedaten sind die tieferen Informationen, die helfen, die Fragen nach dem „Warum“ und „Wo“ von Vorfällen zu beantworten. Obwohl einige Überwachungs- und Korrelationstools manche Obwohl sie den Benutzern zwar bei der Ursachenanalyse helfen, sind die meisten nicht in der Lage, die Untersuchungs- und Fehlerbehebungsschritte eines Einsatzkräftes nachzubilden, bei denen unterschiedliche Datenquellen in einer einheitlichen Ansicht zusammengefasst werden. Indem den Einsatzkräften On-Demand- oder Pre-Run-Diagnosefunktionen zur Verfügung gestellt 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. Starten Sie die automatische Diagnose.

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