Einverstanden, Freunde. Chris Wade hier, zurück auf agntlog.com, und heute werden wir ein Thema ansprechen, das euch wahrscheinlich den Schlaf raubt: Überwachung. Aber nicht irgendeine Überwachung. Wir sprechen von der Überwachung von Agenten in einer Welt, die zunehmend verteilt, zunehmend flüchtig und ehrlich gesagt, zunehmend kompliziert wird.
Das heutige Datum ist der 19. März 2026, und wenn ihr immer noch über Überwachung wie im Jahr 2016 nachdenkt, seid ihr bereits im Rückstand. Erinnert ihr euch an die guten alten Zeiten, als ihr ein paar Nagios-Checks auf euren EC2-Instanzen hinzugefügt habt und das ausreichend war? Ja, ich auch nicht. Wirklich nicht. Aber es gab eine Zeit, in der Überwachung… einfacher schien. Direkter. Ihr hattet einen Server, er hatte eine IP-Adresse, ihr habt seine CPU und seine Festplatte überprüft. Fertig.
Jetzt? Wir haben Container, die in wenigen Millisekunden starten und stoppen, serverlose Funktionen, die für einige Hundert Millisekunden ausgeführt werden, Agenten, die auf Benutzerendpunkten laufen, die tagelang offline sein können, und Mikrodienste, die über ein Dutzend verschiedener Netzwerke kommunizieren. Die alten Methoden? Sie biegen sich nicht; sie brechen. Stark.
Also, der spezifische und zeitgemäße Winkel, den ich heute ansprechen möchte, ist: Überwachung der flüchtigen Zustände von Agenten in einer serverlosen/containerisierten Welt. Es geht nicht nur darum, „läuft es?“ Es geht darum, „was hat es gerade vor dem Verschwinden gemacht?“ und „warum ist es überhaupt verschwunden?“
Der Geist in der Maschine: Warum flüchtige Agenten ein Überwachungs-Albtraum sind
Seien wir ehrlich. Wenn ihr moderne Anwendungen baut, habt ihr Agenten. Vielleicht sammeln sie Protokolle von euren Fargate-Jobs. Vielleicht führen sie Sicherheitsanalysen auf temporären Kubernetes-Pods durch. Oder vielleicht, wie viele Leute, mit denen ich spreche, setzt ihr benutzerdefinierte Agenten auf Benutzermaschinen oder Edge-Geräten ein, und diese Geräte verbinden sich, trennen sich und ändern ständig ihre IP-Adresse. Sie sehen aus wie digitale Geister – hier eine Minute, in der nächsten verschwunden, kaum eine Spur hinterlassend.
Mein eigener Weg durch diesen besonderen Albtraum begann vor etwa anderthalb Jahren. Wir bauten ein neues System, das den Einsatz eines kleinen benutzerdefinierten Agenten auf VM und von Kunden verwalteten Containern beinhaltete. Die Idee war einfach: sehr spezifische Telemetriedaten sammeln, verschlüsseln und an unseren zentralen Dienst zurücksenden. Das klang auf dem Papier großartig. In der Praxis? Es war ein Albtraum. Unsere ursprüngliche Überwachungsstrategie war schrecklich unzureichend. Wir erhielten Warnungen, dass ein Agent seit 15 Minuten keinen Bericht erstattet hatte. In dem Moment, in dem wir nachschauten, war der Container, in dem er lief, von Kubernetes recycelt worden oder die VM war heruntergefahren. Wir jagten Geistern nach.
Das grundlegende Problem ist, dass die traditionelle Überwachung oft auf langfristige Entitäten fokussiert ist. Ihr überwacht die Verfügbarkeit eines Servers, seine Festplattennutzung über mehrere Stunden, seine Netzwerkverkehrstrends über mehrere Tage. Aber wenn euer „Server“ ein Container ist, der 3 Minuten lebt, oder eine serverlose Funktion, die 300 Millisekunden lebt, bedeuten diese Metriken nichts. Was ihr braucht, ist ein Snapshot seines Zustands zum Zeitpunkt seines Verschwindens, und ein Verständnis des gesamten Lebenszyklus, auch wenn er kurz ist.
Von „Läuft es?“ zu „Was hat es gemacht?“
Dieser Wandel ist grundlegend. Wir gehen von einer Verfügbarkeitsüberwachung zu einer Verhaltensüberwachung über. Für flüchtige Agenten ist „Verfügbarkeit“ eine absurde Metrik. Was euch interessiert, ist:
- Hat es erfolgreich gestartet?
- Hat es seine Aufgabe abgeschlossen?
- Im Falle eines Fehlers, warum?
- Wie viele Ressourcen hat es während seines kurzen Lebens verbraucht?
- Was war sein letzter bekannter Zustand vor der Beendigung?
Das erfordert einen anderen Ansatz zur Datensammlung und -aggregation.
Praktische Strategie #1: Hochgranulare Ereignistelemetrie
Vergesst das Polling. Für flüchtige Agenten benötigt ihr Ereignistelemetrie. Jede bedeutende Zustandsänderung, jeder Abschluss einer Aufgabe, jeder Fehler – das muss ein Ereignis sein, das sofort gesendet wird. Das bedeutet, dass euer Agent selbst gesprächig sein muss, aber auf intelligente Weise.
Anstatt die CPU-Nutzung alle 60 Sekunden zu senden (was länger dauern könnte als das Leben des Agenten!), sendet ein Ereignis, wenn er startet, wenn er eine Unteraufgabe abschließt, wenn er auf einen Fehler stößt, und vor allem, wenn er zur Beendigung gemeldet wird. Dieser letzte Punkt ist entscheidend. Kann euer Agent ein SIGTERM erkennen und eine letzte Nachricht „Ich schalte mich aus“ senden, bevor er verschwindet? Das ist Gold wert.
Hier ist ein vereinfachtes Python-Beispiel, das zeigt, wie ein Agent ein Ereignis beim Start und beim Stoppen senden könnte. Stellt euch vor, das läuft innerhalb eines Containers oder einer serverlosen Funktion:
import os
import requests
import json
import atexit
import signal
import time
# Angenommen, diese URL ist, wo euer zentraler Überwachungsdienst Ereignisse empfängt
MONITORING_ENDPOINT = os.getenv("MONITORING_ENDPOINT", "http://localhost:8080/events")
AGENT_ID = os.getenv("AGENT_ID", "ephemeral-agent-123")
TASK_ID = os.getenv("TASK_ID", "task-xyz-456")
def send_event(event_type, details=None):
payload = {
"agent_id": AGENT_ID,
"task_id": TASK_ID,
"timestamp": time.time(),
"event_type": event_type,
"details": details if details else {}
}
try:
response = requests.post(MONITORING_ENDPOINT, json=payload, timeout=1)
response.raise_for_status()
except requests.exceptions.RequestException as e:
print(f"Fehler beim Senden des Ereignisses {event_type}: {e}")
def on_shutdown(signum, frame):
print(f"Signal empfangen {signum}, versuche sanften Shutdown...")
send_event("agent_shutdown", {"reason": f"signal_{signum}"})
# Führe hier alle Bereinigungsoperationen durch
time.sleep(0.5) # Lass einen Moment Zeit, um das Ereignis zu senden
os._exit(0) # Zwinge den Exit nach der Bereinigung
def main():
send_event("agent_start", {"message": "Agent erfolgreich gestartet"})
# Registriere Signalhandler für einen sanften Shutdown
signal.signal(signal.SIGTERM, on_shutdown)
signal.signal(signal.SIGINT, on_shutdown) # Für lokale Tests
print("Agent läuft, führt die Aufgabe aus...")
try:
# Simuliere Arbeit
time.sleep(2)
send_event("task_progress", {"step": 1, "message": "Daten werden abgerufen"})
time.sleep(1)
# Simuliere einen Erfolg
send_event("task_complete", {"result": "success", "data_processed": 100})
except Exception as e:
send_event("task_error", {"error_message": str(e), "stacktrace": "..."})
finally:
# Wenn der Agent seine Arbeit beendet und natürlich aussteigt
send_event("agent_exit_natural", {"message": "Aufgabe abgeschlossen, Ausstieg."})
if __name__ == "__main__":
main()
Dieser kleine Ausschnitt ist entscheidend. Er verändert unser Überwachungsparadigma von „pinge diese IP“ zu „höre auf diese spezifischen Nachrichten.“
Praktische Strategie #2: Verteiltes Tracing für die Lebenszyklen von Agenten
Wenn ihr Agenten habt, die kurze und verteilte Arbeiten ausführen, wird es unglaublich schwierig, die kausale Kette der Ereignisse zu verstehen. Hier wird verteiltes Tracing, traditionell für Mikrodienste verwendet, für Agenten unerlässlich. Jede „Ausführung“ eines Agenten sollte ein Trace sein oder zumindest einen Scope innerhalb eines größeren Traces darstellen, wenn sie Teil eines umfassenderen Workflows ist.
Stellt euch einen Agenten vor, der durch eine Nachricht in einer Warteschlange ausgelöst wird. In dem Moment, in dem diese Nachricht in die Warteschlange gelegt wird, sollte ein Trace beginnen. Wenn der Agent die Nachricht aufnimmt, sollte er sich in diesen Trace injizieren und einen neuen Scope erstellen. Alle folgenden Ereignisse dieses Agenten (Start, Unteraufgabe, Fehler, Stopp) sollten Teil dieses Scopes sein.
Werkzeuge wie OpenTelemetry sind hier eure besten Verbündeten. Beschränkt euch nicht darauf, nur Nachrichten zu protokollieren; fügt Kontext hinzu. Was ist die ID des übergeordneten Traces? Was ist die ID des Scopes? Was sind die Attribute dieser speziellen Ausführung?
Ich erinnere mich an einen besonders schwierigen Bug, den wir hatten, bei dem ein Agent manchmal einen bestimmten Dateityp nicht verarbeiten konnte. Die Fehlermeldungen waren vage. Erst als wir ihn mit OpenTelemetry instrumentierten, konnten wir den gesamten Lebenszyklus sehen: das S3-Ereignis, das die Lambda ausgelöst hat, die Lambda, die unseren Container-Agenten aufruft, der Agent, der startet, einen externen API-Aufruf tätigt, der abläuft, und dann fehlschlägt. Ohne das Trace, das all diese verschiedenen Teile verbindet, sah es nach zufälligen Fehlern aus. Mit ihm war das Problem offensichtlich.
# Vereinfachtes Beispiel für die Integration von OpenTelemetry (konzeptionell)
from opentelemetry import trace
from opentelemetry.sdk.trace import TracerProvider
from opentelemetry.sdk.trace.export import ConsoleSpanExporter, SimpleSpanProcessor
# Konfigurieren Sie den Tracer (in einer echten Anwendung wäre dies stabiler)
provider = TracerProvider()
processor = SimpleSpanProcessor(ConsoleSpanExporter())
provider.add_span_processor(processor)
trace.set_tracer_provider(provider)
tracer = trace.get_tracer(__name__)
def agent_task_with_tracing(parent_span_context=None):
with tracer.start_as_current_span("agent_execution_cycle", context=parent_span_context) as span:
span.set_attribute("agent.id", AGENT_ID)
span.set_attribute("task.id", TASK_ID)
# Simulieren Sie eine Aufgabe
span.add_event("agent_started")
time.sleep(0.5)
with tracer.start_as_current_span("sub_task_fetch_data"):
span.add_event("fetching_data_from_source")
time.sleep(0.2)
span.add_event("data_fetched", {"records": 100})
span.add_event("agent_completed_successfully")
# So würden Sie es aufrufen, wenn ein übergeordneter Dienst seinen Kontext übergibt
# from opentelemetry.propagate import extract
# headers = {"traceparent": "00-4bf92f3577b34da6a3ce929d0e0e4736-00f067aa0ba902b7-01"}
# context = extract(headers)
# agent_task_with_tracing(context)
# Oder starten Sie einfach eine neue Trace, wenn es der Beginn eines neuen Workflows ist
# agent_task_with_tracing()
Dies ermöglicht es Ihnen, die gesamte „Geschichte“ der Ausführung eines Agenten zu sehen, auch wenn diese Geschichte nur wenige Sekunden dauert und sich über mehrere Dienste erstreckt.
Praktische Strategie #3: Zentrale Protokollaggregation mit reichen Metadaten
Das mag offensichtlich erscheinen, aber für kurzlebige Agenten ist es entscheidend, jedes Protokolldatenstück zu erfassen und sofort an ein zentrales System zu senden. Pufferen Sie die Protokolle nicht über Minuten hinweg. Verlassen Sie sich nicht darauf, dass die zugrunde liegende Plattform dies perfekt erledigt. Ihr Agent sollte seine Protokolle senden, möglicherweise an einen lokalen Sidecar oder direkt an einen Protokollaggregationsdienst, mit so vielen kontextuellen Metadaten wie möglich.
Wenn ein Agent verschwindet, verschwinden seine lokalen Protokolle mit ihm. Wenn Sie sie also nicht gesendet haben, sind sie für immer verloren. Für uns bedeutete das, sicherzustellen, dass unsere Agenten über solide Protokollierungsklienten verfügten, die temporäre Netzwerkpartitionen elegant handhaben konnten, aber darauf abzielten, die Protokolle so schnell wie möglich zu senden.
Metadaten sind ebenfalls wichtig. Jede Protokollzeile sollte idealerweise Folgendes enthalten:
agent_id: Eindeutige Kennung für diese Agenteninstanz.task_id: Die spezifische Aufgabe, die dieser Agent ausführt (falls zutreffend).container_id/pod_name/function_name: Die zugrunde liegende Rechenressource.trace_id/span_id: Für die Korrelation von verteiltem Tracing.customer_id/tenant_id: Falls mehrmandantenfähig.
Dies ermöglicht es Ihnen, Protokolle effizient zu filtern, zu durchsuchen und zu analysieren, selbst wenn Sie Millionen von Protokollzeilen von tausenden von kurzlebigen Agenten betrachten. Ohne diese Metadaten betrachten Sie nur einen Textstrom.
Handlungsanweisungen zur Überwachung des Status kurzlebiger Agenten
Also, Sie haben meine Rede gehört. Was tun Sie jetzt wirklich, wenn Sie an Ihren Schreibtisch zurückkehren?
- Instrumentieren Sie für Ereignisse, nicht nur für Metriken: Ändern Sie das Design Ihres Agenten, um Ereignisse für Lebenszyklusänderungen (Start, Stopp, Fehler, Abschluss der Aufgabe) auszugeben, anstatt sich nur auf traditionelle periodische Metriken zu verlassen. Stellen Sie sicher, dass Ihr Agent versucht, ein „Stopp in Bearbeitung“-Ereignis zu senden, wenn er ein Terminationssignal erhält.
- Adoptieren Sie verteiltes Tracing: Integrieren Sie OpenTelemetry oder ein ähnliches Tracing-Framework in Ihre Agenten. Stellen Sie sicher, dass jede Ausführung des Agenten entweder ein neues Tracing oder ein Span in einem bestehenden Workflow-Tracing ist. Das ist nicht verhandelbar, um die komplexen Interaktionen zu verstehen.
- Kontextuelle und aggressive Protokollversendung: Konfigurieren Sie Ihre Agenten so, dass sie die Protokolle so häufig wie möglich an einen zentralen Aggregator (Loki, ElasticSearch, Splunk, Datadog Logs usw.) senden. Wichtig ist, jede Protokollzeile mit relevanten Metadaten (Agent ID, Task ID, Trace ID, Container ID usw.) anzureichern.
- Alarmieren Sie bei Abwesenheit (intelligent): Obwohl „der Agent hat seit X Minuten nicht gemeldet“ zu grob ist, müssen Sie dennoch wissen, ob ein erwarteter Ereignisfluss stoppt. Konfigurieren Sie Alarme für Szenarien wie „N Abschlussereignisse für den Workflow X erwartet, aber nur M erhalten“ oder „Kein ‚agent_start‘-Ereignis für neue Bereitstellungen.“
- Erstellen Sie Observability-Dashboards für Lebenszyklen: Ihre Dashboards sollten nicht nur die CPU- und Speicherauslastung anzeigen. Sie sollten „Agentenstartereignisse pro Minute“, „Aufgabenabschlussrate“, „Fehlerereignisse nach Typ“ und „Durchschnittliche Lebensdauer des Agenten“ anzeigen. Korrelieren Sie dies mit Ihren Tracing-Daten.
- Testen Sie Ihre Stops: Ernsthaft, hier scheitern die meisten Menschen. Lösen Sie manuell SIGTERM auf Ihren Agenten in Testumgebungen aus. Überprüfen Sie, ob sie sich elegant stoppen und ihre finalen Ereignisse/Protokolle senden. Wenn sie das nicht tun, navigieren Sie im Dunkeln.
Die Überwachung kurzlebiger Agenten besteht nicht darin, eine statische Ressource im Auge zu behalten; es geht darum, die dynamischen und transitorischen Prozesse zu verstehen, die Ihre modernen Anwendungen ausmachen. Es handelt sich um Forensik, nicht nur um den Echtzeitstatus. Setzen Sie diese Strategien um, und Sie werden viel weniger Zeit damit verbringen, digitalen Geistern nachzujagen, und viel mehr Zeit damit, zu verstehen, was Ihre Agenten tatsächlich tun (oder nicht tun).
Das ist alles von mir für heute. Gehen Sie raus und beobachten Sie!
Verwandte Artikel
- Muster für das Versenden von Protokollen von IA-Agenten
- IA-Nachrichten heute: November 2025 – Ihr Update zu zukünftigen Technologien!
- IA-Nachrichten heute, 14. November 2025: Wichtige Entwicklungen & Analyse
🕒 Published: