Gewinne:
- Fähigkeit, die drei Säulen der Beobachtbarkeit (Metrik, Protokoll, Trace) und die vier goldenen Signale zu verstehen und künstliche Intelligenz PromQL-Abfragen, Alarmregeln und Dashboards generieren zu lassen
- Möglichkeit, Alarmmüdigkeit zu verhindern, indem Alarme aktionsorientiert und auf der richtigen Dringlichkeit gehalten werden und Schwellenwerte anhand der historischen Daten Ihres eigenen Systems getestet werden
- Möglichkeit, Privatsphäre und Geheimhaltung zu verhindern, indem sensible Bereiche maskiert werden, bevor die Protokolle an die künstliche Intelligenz übergeben werden
Auch wenn es den Anschein hat, als würde ein System funktionieren, kann es doch sein, dass es im Inneren zugrunde geht: Der Speicher füllt sich langsam, die Antwortzeiten nehmen zu, die Fehlerquote steigt. Dies lässt sich nur durch eine ständige Überwachung des Systems feststellen. Ein fortgeschritteneres Konzept ist die Beobachtbarkeit: die Fähigkeit, anhand der äußeren Zeichen zu verstehen, was im Inneren des Systems vor sich geht. Es gibt drei Säulen der Beobachtbarkeit, und der DevOps-Experte nutzt alle drei:
- Metrik: Über die Zeit gemessene numerische Werte – CPU-Auslastung, Anzahl der Anfragen, Antwortzeit, Fehlerrate. "Wie viel?" beantwortet die Frage.
- Protokoll: Vom System erstellte Textereignisaufzeichnungen – „Benutzer angemeldet“, „Datenbankverbindung verloren“. „Was genau ist passiert?“ beantwortet die Frage.
- Trace: Der Pfad, dem eine Anfrage folgt, während sie innerhalb des Systems von einem Dienst zum anderen weitergeleitet wird, sowie die Dauer jedes Schritts. „Wo ist die Langsamkeit?“ beantwortet die Frage.
Am häufigsten verwendete Tools: Prometheus für Metriken, Grafana für Visualisierung, Loki/ELK für Protokoll, Jaeger/OpenTelemetry für Trace. AI ist sehr geschickt darin, die Abfragesprachen (insbesondere Prometheus‘ PromQL), Alarmregeln und Dashboard-Konfigurationen für diese Tools zu schreiben. Hier ist die KI auch am stärksten: Sie fasst große Mengen an Protokollen und Metriken zusammen und markiert Anomalien.
Lassen Sie uns den Unterschied zwischen Überwachung und Beobachtbarkeit in einem Satz verdeutlichen: Bei der Überwachung werden Fragen gestellt, die Sie bereits kennen („Ist die CPU über 90 %?“); Beobachtbarkeit bedeutet, Fragen stellen zu können, die Sie noch nicht kannten („Warum tritt diese seltsame Langsamkeit nur bei einem bestimmten Kunden zu einer bestimmten Zeit auf?“). Moderne Systeme sind so komplex, dass man nicht alle Fehlerarten vorhersagen kann; Daher ist die Fähigkeit, umfangreiche Metriken, Protokolle und Traces zu sammeln und diese dann eingehend abzufragen – d. h. die Beobachtbarkeit – von entscheidender Bedeutung. Hier kommt die KI ins Spiel, wenn es um die Beantwortung der „bisher unbekannten Frage“ geht: Sie scannt schnell Ihre Rohdaten, schlägt Muster und Anomalien vor und Sie gelangen durch die Überprüfung dieser Hinweise zur Ursache.
Schritt für Schritt: Was und wie überwachen?
- Wählen Sie die richtigen Kennzahlen. In der Branche werden „vier goldene Signale“ zugrunde gelegt: Latenz, Verkehr, Fehler, Sättigung – wie voll die Ressource ist. Diese fassen den Zustand der meisten Dienste zusammen.
- Sammeln Sie Kennzahlen. Lassen Sie die Anwendung einen Endpunkt präsentieren, den Prometheus lesen kann.
- Richten Sie Dashboards ein. Visualisieren Sie diese Metriken in Grafana.
- Schreiben Sie Alarmregeln. Wer wird bei Überschreitung eines Schwellenwerts gewarnt und wie?
- Protokolle zentralisieren. Machen Sie alle Serviceprotokolle an einem Ort durchsuchbar.
- Lärm reduzieren. Zu viel Alarm führt zu „Alarmmüdigkeit“; Der wichtige Alarm verschwindet.
Tipp: Ein guter Alarm erfüllt zwei Dinge: Er ist umsetzbar und hat die richtige Dringlichkeit. Ein Alarm, der jemanden um 3 Uhr morgens weckt, muss tatsächlich ein nächtliches Eingreifen erfordern. Wecken Sie niemanden wegen etwas auf, das keine eigene Aktion erfordert, wie zum Beispiel „CPU 70 %“; Zeigen Sie es an der Tafel an.
Wie schreibe ich eine Alarmregel?
Eine Warnung besteht aus drei Komponenten: Bedingung (welche Metrik welchen Schwellenwert überschreitet und für wie lange), Dauer („für 5 Minuten“, um vorübergehende Schwankungen auszulösen) und Wichtigkeit/Aktion (für wen, über welchen Kanal). KI stellt diese drei meisterhaft in den richtigen Kontext. Beispielsweise ist die Übersetzung einer Regel wie „Kritischer Alarm, wenn die Fehlerrate 5 Minuten lang 5 % überschreitet“ in PromQL eine Sekundenbruchteilaufgabe für die KI – aber Sie entscheiden, ob der Schwellenwert für Ihr System richtig ist.
Achtung: Die von der KI vorgeschlagenen Alarmschwellen sind allgemeine Annahmen. Die normale Belastung, Toleranz und Arbeitsauswirkungen Ihres Systems sind unterschiedlich. Bevor Sie einen Schwellenwert direkt in Prod eingeben, sehen Sie sich Ihre historischen Daten an und fragen: „Wie oft wurde dieser Schwellenwert in der Vergangenheit ausgelöst, wie viele davon waren echte Probleme?“ Beantworten Sie die Frage.
Protokolldatenschutz: kritische Warnung
Protokolle sind die am häufigsten übersehene Quelle für Lecks. Eine Protokollzeile kann versehentlich ein Passwort, eine Kreditkartennummer oder persönliche Daten (gemäß KVKK/DSGVO) enthalten. Beim Einfügen von Protokollen in eine KI zur Analyse:
- Empfindliche Bereiche abdecken. Ersetzen Sie Werte wie Token, Passwort, E-Mail, ID-Nummer durch <ZENSIERT>.
- Nennen Sie Beispiele, nicht alle. Statt einer Million Zeilen genügen oft ein paar hundert repräsentative Zeilen.
- Wählen Sie ein von der Institution zugelassenes Fahrzeug. Verwenden Sie insbesondere für Produktionsprotokolle ein Tool, dessen Daten nicht in das Training einfließen.
Vier goldene Signale und Alarmtabellen
Signal
gemessen an
Beispiel einer Alarmschwelle
Dringlichkeit
Latenz
Reaktionszeit
p95 > 800 ms, 5 Min
hoch
Verkehr
Anfrage/Sek
Plötzlicher Anstieg/Abfall um 300 %
mittel
Fehler
Rate fehlgeschlagener Anfragen
> 5 %, 5 Min
kritisch
Sättigung
Ressourcenbelegung
Festplatte > 85 %
hoch
drei Mini-Koffer
Fall 1 – 400 Protokollzeilen zusammengefasst in 30 Sekunden. Ein Dienst war langsamer geworden. Der Ingenieur übergab die maskierten 400 Protokollzeilen an die KI und sagte: „Fassen Sie die wiederkehrenden Fehlermuster und die Zeitintensität zusammen.“ KI hat gezeigt, dass bei einem bestimmten externen API-Aufruf alle 30 Sekunden eine Zeitüberschreitung auftritt. Grundursache in 30 Sekunden gefunden; Das manuelle Scannen von Protokollen würde eine halbe Stunde dauern.
Fall 2 – Alarmmüdigkeit behoben. Ein Team erhielt täglich 200 Alarme und ignorierte sie alle – bis auch ein echter Ausfallalarm übersehen wurde. Geben Sie der KI alle Alarmregeln und fragen Sie: „Welche sind nicht umsetzbar und welche können kombiniert werden?“ sie fragten. Die Anzahl der Alarme sank auf 12 pro Tag; Jeder Alarm wurde nun ernst genommen.
Fall 3 – falscher Schwellenwert frühzeitig erkannt. YZ schlug für die Festplatte „Warnen, wenn 95 % voll“ vor. Der Ingenieur schaute sich historische Daten an: Sobald die Festplatte 95 % erreicht hatte, blieb nur wenig Zeit für Eingriffe. Es senkte den Schwellenwert auf 80 % und fügte einen zweiten Alarm basierend auf der „Wachstumsrate“ hinzu. Durch die Überprüfung konnte ein tatsächlicher Ausfall um Mitternacht verhindert werden.
Vier kopierbare Vorlagen
1) Protokollzusammenfassung (maskiert):
Analysieren Sie das Protokollbeispiel unten (ich habe vertrauliche Werte mit <ZENSIERT> maskiert). Nennen Sie mir: (1) wiederkehrende Fehlermuster, (2) Konzentration im Laufe der Zeit, (3) wahrscheinlichste Grundursache und (4) 3 Metriken, die ich mir zur Überprüfung ansehen werde. Protokoll: [LINES]
2) Alarmregelgenerierung:
Schreiben Sie eine Alarmregel für Prometheus/Alertmanager: Erzeugen Sie einen [SEVERITY]-Alarm, wenn [THRESHOLD] [METRIC][DAUER] überschreitet. Die Regel sollte aktionsorientiert sein und ein Anmerkungs- und Runbook-Linkfeld enthalten. Erklären Sie PromQL und schreiben Sie, warum dieser Schwellenwert angemessen ist.
3) PromQL-Abfrage schreiben/deklarieren:
Schreiben Sie eine PromQL-Abfrage, die Folgendes misst: [EX. 5xxFehlerrate in Prozent in den letzten 5 Minuten]. Erklären Sie die Abfrage Schritt für Schritt. Sagen Sie mir dann, wie hoch der gesunde Bereich für diesen Wert sein sollte.
4) Dashboard-Design:
Entwerfen Sie ein Grafana-Dashboard für [SERVICE]: Mit welchen Panels soll ich die vier goldenen Signale (Latenz, Verkehr, Fehler, Sättigung) anzeigen? Schlagen Sie Metrik, Visualisierungstyp und angemessenen Schwellenwert für jedes Panel vor. Zweck: Den Gesundheitszustand eines Wachmanns in 10 Sekunden sehen.
Schwache Eingabeaufforderung / Starke Eingabeaufforderung
Schwach: „Was steht in diesem Protokoll?“ (gefolgt von 5000 Zeilen Rohprotokoll, darin Token)
Ergebnis: Sie geben Geheimnisse preis und die KI gibt eine ungezielte, oberflächliche Zusammenfassung.
Stark: „Finden Sie wiederkehrende Fehlermuster und die zeitliche Intensität im Beispiel des maskierten 300-Zeilen-Protokolls unten. Nennen Sie mir die wahrscheinlichste Grundursache und die Metriken, die ich mir zur Überprüfung ansehen werde. Ich habe die Token <ZENSIERT> gemacht.“
Unterschied: Die zweite Eingabeaufforderung gibt ein maskiertes und fokussiertes Beispiel und fordert eine klare Analyseausgabe; Es ist sowohl sicher als auch nützlich.
Häufige Fehler
- Einfügen des Protokolls in AI, ohne es zu maskieren. Das häufigste Leck von geheimen/persönlichen Daten.
- Alarme für alles einstellen. Alarmmüdigkeit verbirgt echten Alarm.
- Nicht umsetzbarer Alarm. Es ist ein Warngeräusch, gegen das niemand etwas unternehmen kann.
- Die Schwelle der KI ohne Frage akzeptieren. Der Schwellenwert sollte entsprechend dem Verlauf Ihres Systems festgelegt werden.
- Ich schaue mir nur die Metrik an. Ohne Protokollierung und Nachverfolgung lässt sich die Ursache meist nicht finden.
- Keine Alarmzeit einstellen (für). Momentane Schwankungen führen zu Fehlalarmen.
Zusammenfassend
Beobachtbarkeit; Dabei handelt es sich um die Fähigkeit, das Innere des Systems anhand von Metriken, Protokollen und Traces von außen zu verstehen. Die vier goldenen Signale (Latenz, Verkehr, Fehler, Sättigung) fassen den Zustand der meisten Dienste zusammen. KI ist sehr leistungsfähig beim Schreiben von PromQL-Abfragen, Alarmregeln und Dashboards sowie beim Zusammenfassen großer Protokollmengen und beim Auffinden von Anomalien. Es liegt jedoch in Ihrer Verantwortung, Alarmschwellenwerte anhand des Verlaufs Ihres eigenen Systems zu überprüfen, Alarme aktionsorientiert zu halten und Protokolle niemals ohne Maskierung weiterzugeben.
Anwendungsaufgabe
Für einen Dienst (oder einen Beispieldienst): (1) Lassen Sie mit der Vorlage „Alarmregelgenerierung“ eine Alarmregel für die Fehlerrate generieren und setzen Sie den vorgeschlagenen Schwellenwert auf „Wie oft wurde er in der Vergangenheit ausgelöst?“ Testen Sie es mit der Frage; (2) Maskieren Sie eine Protokollprobe, die Sie haben, und lassen Sie sie mit der Vorlage „Protokollzusammenfassung“ analysieren. (3) Notieren Sie sich, welche Metrik Sie zur Bestätigung der wahrscheinlichsten Grundursache heranziehen.
Checkliste
- [ ] Ich habe die zu verfolgenden Metriken basierend auf vier goldenen Signalen ausgewählt.
- [ ] Ich habe alle Protokolle, die ich der KI gegeben habe, im Hinblick auf sensible Bereiche maskiert.
- [ ] Ich habe überprüft, ob jeder Alarm handlungsorientiert war und die richtige Dringlichkeit hatte.
- [ ] Ich habe die Alarmschwellen anhand der historischen Daten meines Systems getestet.
- [ ] Ich habe momentane Schwankungen gefiltert, indem ich den Alarmen „for“ (Dauer) hinzugefügt habe.
- [ ] Ich habe Metrik + Protokoll + Trace zusammen verwendet, um die Ursache zu ermitteln.