Hallo zusammen, hier ist Tom Lin, zurück auf BotClaw.net. Ich hoffe, ihr habt alle eine gute Woche, egal ob ihr ein kniffliges kinematisches Problem debuggt oder einfach mit einer besonders hartnäckigen Abhängigkeit kämpft.
Heute möchte ich über etwas sprechen, das mich in letzter Zeit sehr beschäftigt, besonders nach der letzten Reihe von nächtlichen Störungsanrufen. Wir werden Überwachung erkunden, aber nicht nur die Art der grundlegenden Überwachung, die fragt „funktioniert es?“. Ich spreche von dem, was ich „prediktive Post-Mortem-Überwachung“ nenne – denn wenn eure Überwachung euch nicht hilft, potenzielle Ausfälle vorherzusagen, bevor sie sich in vollständige Ausfälle verwandeln, dokumentiert ihr in Wirklichkeit nur ein Problem, nachdem es euch bereits ins Gesicht geschlagen hat.
Erinnert euch daran: Wir waren alle schon mal dort. Das Pager klingelt um 3 Uhr morgens. Euer Bot, der vor ein paar Stunden Daten gesammelt oder seine zugewiesene Aufgabe ausgeführt hat, erzeugt jetzt Fehler oder, noch schlimmer, schlägt stillschweigend fehl. Ihr eilt herbei, überprüft die Protokolle, startet die Dienste neu und schließlich findet ihr den Übeltäter. Vielleicht war es ein Memory Leak, das das System langsam erstickt hat. Vielleicht hat eine externe API begonnen, fehlerhafte Daten zurückzugeben. Oder, und das ist mein Lieblingsteil, ein neues Deployment hat eine subtile Race-Bedingung eingeführt, die nur unter bestimmten Lastbedingungen auftritt.
Das Post-Mortem-Meeting findet statt, und alle zeigen auf eine Grafik, die plötzlich angestiegen oder gefallen ist. „Ach, hätten wir das doch nur früher gesehen!“ klagt jemand. Hier kommt die prediktive Post-Mortem-Überwachung ins Spiel. Es geht darum, ein Überwachungssystem zu bauen, das nicht nur zeigt, was schiefgelaufen ist, sondern aktiv versucht, euch zu zeigen, was schiefgehen wird, oder zumindest euch unglaublich früh warnt, dass die Dinge zu kippen beginnen.
Über grundlegende Gesundheitsprüfungen hinaus: der Geruchs-Test
Als ich vor ein paar Jahren anfing, meinen ersten autonom arbeitenden Reinigungsbot zu bauen – den ich liebevoll „Dusty“ nannte, bevor er beschloss, ein Stromkabel zu essen – war meine Überwachung eher rudimentär. Ping-Checks, CPU-Auslastung, Speicherverbrauch. Die üblichen Verdächtigen. Und für einen einfachen Prototyp war das in Ordnung. Aber als Dusty sich weiterentwickelte, zusätzliche Sensoren erhielt, komplexere Navigationen und ein cloudbasiertes Berichtssystem erwarb, waren diese grundlegenden Metriken nicht mehr genug.
Ich erinnere mich an einen Vorfall im Besonderen. Dusty begann immer länger zu brauchen, um seine Reinigungszyklen abzuschließen. Die CPU-Auslastung schien normal, der Speicher war stabil, die Netzwerklatenz war in Ordnung. An der Oberfläche schien alles in Ordnung zu sein. Aber die tatsächliche Bearbeitungszeit nahm zu. Ich konnte letztendlich eine schleichende Leistungsminderung des Laserscanners aufgrund von Staub auf der Linse zurückverfolgen. Die Rohdaten schienen korrekt, aber die Verarbeitungszeit dieser Daten stieg an, da die Punktwolke geräuschvoller wurde, was mehr Filterung und Verarbeitung erforderte, um die Hindernisse zu identifizieren.
Das war ein Alarmzeichen. Meine Überwachung konzentrierte sich nicht auf die richtigen Dinge. Ich überprüfte den Motor, aber nicht die Reifen, den Kraftstoffverbrauch oder die Straßenqualität. Die prediktive Post-Mortem-Überwachung besteht darin, euren „Geruchs-Test“ zu erweitern, um betriebliche Metriken einzubeziehen, die nicht laut „FEHLER!“ schreien, sondern leise „Probleme brauen sich zusammen“ flüstern.
Wesentliche Säulen der prediktiven Post-Mortem-Überwachung
So gehe ich vor, wenn ich ein solches System für meine Bots und Backend-Dienste baue:
1. Erkennung von operativer Drift
Hier findet meine Anekdote über Dusty ihren Platz. Es geht nicht um einen Fehler, sondern um ein Verhaltensänderung. Für einen Bot könnte das Folgendes sein:
- Bearbeitungszeit der Aufgabe: Nimmt die durchschnittliche Zeit, um eine spezifische Aufgabe abzuschließen (z. B. eine Datenmenge von Sensoren zu verarbeiten, einen bekannten Weg zu navigieren, auf eine Benutzeranfrage zu reagieren), allmählich zu?
- Baselines für Ressourcennutzung: Erhöhen sich der Speicherbedarf, die CPU-Nutzung oder die Netzwerkbandbreite subtil über die Zeit für eine bestimmte Arbeitslast, auch wenn sie „innerhalb der Grenzen“ bleiben?
- Metriken zur Datenqualität: Für Bots, die externe Daten verarbeiten, steigt die Anzahl der „fehlerhaften“ Datensätze, der fehlerhaften Nachrichten oder der unerwarteten Werte, selbst wenn das System technisch gesehen immer noch damit arbeitet?
Ich benutze Prometheus für den Großteil meiner Zeitreihendaten- Sammlung. Für die operativen Drifts setze ich nicht nur statische Schwellenwerte. Ich suche nach Abweichungen von historischen Normen. Die Alarmierungsfunktionen von Grafana, kombiniert mit der Abfragesprache von Prometheus (PromQL), ermöglichen relativ ausgeklügelte Kontrollen. Zum Beispiel, um eine Drift in der Bearbeitungszeit der Aufgaben zu erkennen:
# Alarm auslösen, wenn die durchschnittliche Bearbeitungszeit der Aufgabe 'cleaning_cycle' in der letzten Stunde
# 1,5 Mal so hoch ist wie der Durchschnitt der letzten 24 Stunden.
- alert: HighCleaningCycleTimeDrift
expr: avg_over_time(bot_task_completion_seconds_bucket{task="cleaning_cycle"}[1h]) > 1.5 * avg_over_time(bot_task_completion_seconds_bucket{task="cleaning_cycle"}[24h])
for: 15m
labels:
severity: warning
annotations:
summary: "Die Bearbeitungszeit des Reinigungszyklus driftet nach oben für den Bot {{ $labels.instance }}"
description: "Die durchschnittliche Zeit für den Abschluss eines Reinigungzyklus hat im Vergleich zum 24-Stunden-Durchschnitt erheblich zugenommen."
Diese Art von Alarm wird nicht ausgelöst, wenn es einen plötzlichen Anstieg gibt (der durch einen Standard-Schwellenwert-Alarm erfasst werden würde), aber sie erkennt den schleichenden und langsamen Anstieg, der oft vor einem großen Problem auftritt.
2. Anomalieerkennung bei „nicht Fehler“-Metriken
Manchmal liegt das Problem nicht in der Drift der Durchschnitte, sondern in einem unerwarteten Muster in den Daten, das nicht direkt einen Fehler darstellt. Denkt an einen Bot, der eine Kamera für die Objekterkennung verwendet. Wenn sich die Lichtverhältnisse dramatisch ändern, können die Vertrauenspunkte für die Objekterkennung erheblich fallen, auch wenn die Kamera selbst funktioniert und Bilder sendet. Der Bot kann technisch gesehen weiterhin Objekte „erkennen“, aber mit viel weniger Sicherheit, was zu suboptimalen Entscheidungen führt.
Hier kommen fortgeschrittene Techniken zur Anomalieerkennung ins Spiel. Ihr benötigt nicht unbedingt eine komplette Machine-Learning-Plattform dafür. Einfache statistische Methoden können oft einen weiten Weg gehen. Zum Beispiel, um die Standardabweichung bestimmter Sensorablesungen oder Vertrauenspunkte zu überwachen. Ein unerwarteter Anstieg der Varianz könnte auf ein Problem hinweisen.
Hier ist ein vereinfachtes Beispiel in Python, um eine ungewöhnliche Varianz in einem Fluss von Vertrauenspunkten zu erkennen:
import collections
import numpy as np
class AnomalyDetector:
def __init__(self, window_size=100, std_threshold=3.0):
self.window = collections.deque(maxlen=window_size)
self.std_threshold = std_threshold
def add_data_point(self, value):
self.window.append(value)
if len(self.window) == self.window.maxlen:
current_std = np.std(list(self.window))
current_mean = np.mean(list(self.window))
# Einfache Anomaliekontrolle: Wenn der aktuelle Wert zu weit vom Durchschnitt entfernt ist, basierend auf der historischen Standardabweichung
if abs(value - current_mean) > self.std_threshold * current_std:
print(f"Anomalie erkannt! Wert: {value}, Durchschnitt: {current_mean:.2f}, Standardabweichung: {current_std:.2f}")
return True
return False
# Beispielverwendung für den Vertrauenspunkter eines Bots bei Objekterkennung
detector = AnomalyDetector()
confidence_scores = [0.9, 0.88, 0.91, 0.89, 0.92, 0.87, 0.1, 0.89, 0.90] # 0.1 ist eine Anomalie
for score in confidence_scores:
detector.add_data_point(score)
Das ist nicht perfekt, aber es ist ein guter Ausgangspunkt. Für komplexere Szenarien könntet ihr euch Bibliotheken wie Prophet für die Vorhersage und Anomalieerkennung bei Zeitreihen oder sogar einfachere Ansätze auf der Grundlage von EWMA (exponentiell gewichtete gleitende Durchschnitte) anschauen.
3. Gesundheit von Abhängigkeiten und Datenverträgen
Bots leben selten in einem Vakuum. Sie konsumieren APIs, interagieren mit Datenbanken und sind auf externe Dienste angewiesen. Ein häufiges Ausfallrisiko, das ich beobachtet habe, ist, wenn eine Abhängigkeit beginnt, gültige, aber unerwartete Daten zurückzugeben oder subtil ihr Verhalten zu ändern, ohne dass eine explizite API-Version aktualisiert wird.
Meine Lösung dafür ist zweigleisig:
- Überprüfungen der Gesundheit von Abhängigkeiten mit Datenvalidierung: Über das bloße Überprüfen, ob ein API-Endpunkt 200 OK zurückgibt, mache ich jetzt Stichprobenaufrufe, die die Struktur und eine Teilmenge des Inhalts der Antwort validieren. Wenn ein erwartetes Feld fehlt oder ein Zahlenwert als Zeichenkette zurückkommt, ist das ein Alarm.
- Synthetische Transaktionen: Für kritische Pfade habe ich spezielle “Canary”-Bots oder -Prozesse, die eine vollständige End-to-End-Transaktion gegen das Live-System ausführen, einschließlich aller externen Abhängigkeiten. Wenn diese synthetische Transaktion fehlschlägt oder ihre Abschlusszeit zu driftet, ist das ein frühes Warnsignal. Zum Beispiel hätte ein Bot, der ein Produktkatalog abruft, verarbeitet und einen lokalen Cache aktualisiert, eine synthetische Transaktion, die genau das macht, von Anfang bis Ende, und überwacht seine Latenz und Erfolgsquote.
Das mag nach viel Aufwand aussehen, aber glauben Sie mir, es ist weniger belastend, als Ihrem Chef zu erklären, warum der Bot gescheitert ist, weil eine Anbieter-API begonnen hat, Daten im Format `YYYY/MM/DD` anstelle von `YYYY-MM-DD` zurückzugeben und Ihre Parsing-Logik leise gescheitert ist.
Konkrete Maßnahmen zur Überwachung Ihres Bots ergreifen
Also, wie anfangen, einige dieser Ideen umzusetzen, ohne von einer überwältigenden Menge neuer Warnmeldungen überwältigt zu werden? Hier sind meine Tipps:
- Überprüfen Sie Ihre aktuellen Metriken: Gehen Sie Ihre bestehenden Dashboards und Warnungen durch. Konzentrieren Sie sich nur auf CPU, Speicher und grundlegende Fehlerraten? Oder erfassen Sie Metriken, die die tatsächliche Arbeit, die Ihr Bot leistet, und die Qualität seiner Ausgabe widerspiegeln?
- Identifizieren Sie wichtige operationale Metriken: Fragen Sie sich für jede kritische Funktion Ihres Bots: “Wie sieht ‘normal’ für diesen Vorgang aus?” und “Welche subtilen Änderungen könnten darauf hinweisen, dass ein Problem entsteht?” Das könnte die Latenz von Aufgaben, die Erfolgsraten spezifischer Unterprogramme, die Vertrauenspunkte von ML-Modellen oder sogar die Abnahme der Batterieleistung sein.
- Implementieren Sie Drift-Erkennung: Beginnen Sie mit ein oder zwei wichtigen operationale Metriken und richten Sie Warnungen ein, die nach Abweichungen von historischen Durchschnittswerten suchen, nicht nur nach statischen Schwellenwerten. Prometheus und Grafana sind hervorragende Tools dafür.
- Validieren Sie externe Datenverträge: Wenn Ihr Bot von externen APIs oder Datenströmen abhängt, implementieren Sie Überprüfungen, die über einfache HTTP-Statuscodes hinausgehen. Validieren Sie die Struktur und den erwarteten Inhalt der Antworten.
- Berücksichtigen Sie synthetische Transaktionen: Für Ihre kritischsten End-to-End-Workflows setzen Sie einen leichten “Canary”-Prozess ein, der eine echte Interaktion eines Benutzers oder Bots imitiert und seinen Erfolg und seine Latenz überwacht.
- Iterieren und verfeinern: Überwachung ist niemals “abgeschlossen.” Überprüfen Sie regelmäßig Ihre Warnungen. Sind sie zu laut? Versäumen sie kritische Probleme? Passen Sie Schwellenwerte an, fügen Sie neue Metriken hinzu und entfernen Sie alte, während Ihr Bot sich weiterentwickelt.
Meine Erfahrungen mit Dusty haben mir gezeigt, dass die größten Bedrohungen nicht immer die lauten und dramatischen Fehler sind. Oft sind es die apathischen und heimtückischen Veränderungen, die langsam die Leistung, Zuverlässigkeit oder Genauigkeit untergraben. Indem wir unseren Fokus von reaktiver Problemlösung zu proaktiver Erkennung und Antizipation dieser subtilen Veränderungen verlagern, können wir stärkere und widerstandsfähigere Bots bauen, die weniger Zeit in der digitalen Notaufnahme verbringen und mehr Zeit mit dem, wofür sie geschaffen wurden.
Das ist alles für mich diese Woche. Gehen Sie voran, bauen Sie intelligentere Bots und halten Sie diese Sensoren am Laufen!
— Tom Lin, BotClaw.net
🕒 Published: