Agent (Observability-Agent)

Was ein Observability-Agent ist

Ein Observability-Agent läuft direkt neben Ihren Workloads und macht aus lokalen Signalen Telemetrie, mit der ein Backend arbeiten kann. Auf einer virtuellen Maschine ist er meist ein Systemdienst, in Kubernetes läuft er in der Regel als DaemonSet, sodass auf jedem Node genau ein Agent-Pod startet. Der Agent liest Systemzähler, verfolgt Logdateien, nimmt Traces und Metriken von Anwendungen über lokale Ports entgegen und versendet alles gebündelt.

Der Begriff wird für unterschiedliche Software verwendet. Klassische Monitoring-Agents erfassen Host-Metriken wie CPU, Speicher, Festplatte und Netzwerk. Log-Shipper wie Fluent Bit oder Vector konzentrieren sich auf Dateien und Streams. Der OpenTelemetry Collector lässt sich im „Agent-Modus“ auf jedem Node betreiben, im Unterschied zum „Gateway-Modus“, bei dem ein zentraler Collector-Pool Daten vieler Agents empfängt. Manche Anbieter nennen auch sprachspezifische Bibliotheken im Prozess „Agent“, etwa einen Java-Agent, der per -javaagent geladen wird und Bytecode beim Laden instrumentiert.

So arbeitet ein Agent

Unabhängig vom Produktnamen folgen die meisten Agents derselben Pipeline:

1. Empfangen oder abfragen. Metriken von Endpunkten wie einem Prometheus-Pfad /metrics abrufen, Statistiken aus /proc und cgroups lesen, Container-Logdateien verfolgen oder OTLP-Daten instrumentierter Anwendungen auf localhost:4317 (gRPC) und 4318 (HTTP) annehmen.
2. Anreichern. Resource-Attribute wie host.name, k8s.pod.name, k8s.namespace.name oder die Cloud-Region anhängen, damit sich jedes Signal später korrelieren lässt.
3. Verarbeiten. Verrauschte Daten filtern, sensible Felder entfernen oder hashen, bündeln und komprimieren.
4. Puffern und exportieren. Daten im Speicher oder auf der Platte halten, wenn das Backend langsam oder nicht erreichbar ist, mit Backoff erneut senden und weiterleiten.

Agents mit eBPF können zusätzlich Netzwerkflüsse, Systemaufrufe oder CPU-Stacks direkt im Kernel beobachten, ohne den Anwendungscode zu ändern. So arbeiten viele Continuous Profiler und Netzwerk-Monitore. Voraussetzung ist ein ausreichend aktueller Kernel und die passende Berechtigung, etwa die Linux-Capabilities CAP_BPF und CAP_PERFMON oder ein privilegierter Container.

Agent, Gateway und agentlose Erfassung

Ansatz	Wo er läuft	Typischer Einsatz
Agent	Auf jedem Host oder Node	Host-Metriken, lokale Logdateien, lokaler OTLP-Endpunkt, Profiling
Gateway	Zentraler Collector-Pool	Tail-based Sampling, Routing, zentrale Richtlinien, Zugangsdaten
Agentlos	Backend ruft Provider-APIs ab	Managed Cloud-Services, SaaS-APIs, synthetische Checks

Die Ansätze ergänzen sich. Auf einer Managed-Datenbank oder einem Load Balancer lässt sich kein Agent installieren, diese Dienste werden über Cloud-APIs überwacht. Umgekehrt sieht nichts außerhalb des Hosts CPU-Nutzung pro Prozess oder lokale Logdateien so genau wie ein Agent.

Beispiel: OpenTelemetry Collector im Agent-Modus

Eine beispielhafte Minimalkonfiguration für einen Node-Agent, der OTLP empfängt, Host-Metriken erfasst und alles an ein Gateway weitergibt:

receivers:
  otlp:
    protocols: { grpc: {}, http: {} }
  hostmetrics:
    collection_interval: 30s
    scrapers: { cpu: {}, memory: {}, filesystem: {}, network: {} }
processors:
  memory_limiter: { check_interval: 1s, limit_percentage: 80 }
  resourcedetection: { detectors: [env, system] }
  batch: {}
exporters:
  otlp:
    endpoint: gateway.observability.svc:4317
service:
  pipelines:
    metrics: { receivers: [otlp, hostmetrics], processors: [memory_limiter, resourcedetection, batch], exporters: [otlp] }
    traces:  { receivers: [otlp], processors: [memory_limiter, resourcedetection, batch], exporters: [otlp] }

Wichtig ist der memory_limiter an erster Stelle: Er schützt den Node bei Lastspitzen vor dem Agent selbst.

Best Practices

• Ressourcenlimits setzen. Geben Sie dem Agent explizite CPU- und Speicher-Requests und -Limits sowie einen internen Memory Limiter, damit er die beobachteten Workloads nie ausbremst.
• Den Agent selbst überwachen. Beobachten Sie Queue-Länge, verworfene Daten und Exportfehler. Ein stummer Agent sieht genauso aus wie ein gesunder, ruhiger Service.
• Offene Protokolle bevorzugen. Agents, die OTLP sprechen, erlauben einen Backend-Wechsel ohne neue Instrumentierung.
• Rollout standardisieren. Verwalten Sie Versionen und Konfiguration als Code über Helm, einen Operator oder Configuration Management, nicht von Hand auf einzelnen Hosts.
• Am Rand wenig rechnen. Günstiges Anreichern und Filtern gehört in den Agent, aufwendige, zustandsbehaftete Verarbeitung wie Tail-based Sampling in ein Gateway.

Typische Fehler

Mehrere überlappende Agents pro Host, einer pro Tool, verursachen häufig unnötigen Overhead und widersprüchliche Metadaten. Ein weiterer Fehler ist, „sicherheitshalber“ alles in maximaler Auflösung zu sammeln, was Kosten nur von Rechenleistung zu Speicher verschiebt. Und oft werden Agent-Versionen nicht fixiert, sodass ein Node-Upgrade unbemerkt Metriknamen oder Labels ändert. Schließlich unterschätzen viele Teams den Speicherbedarf beim Puffern: Fällt das Backend länger aus, wächst die Queue, bis der Agent Daten verwirft oder vom Kernel wegen Speichermangels beendet wird. Legen Sie deshalb fest, wie groß der Puffer sein darf und welche Daten im Zweifel zuerst verworfen werden.

Wie Obseria unterstützt

Der Obseria Agent wird einmal pro Host oder als DaemonSet installiert und erfasst Metriken, Logs, Traces, Profile und Security-Signale in einem Prozess, angereichert mit der Topologie, die Obseria TopoGraph automatisch erstellt. Er nimmt OTLP aus Ihren bestehenden SDKs an, sodass Ihre OpenTelemetry-Instrumentierung weiter funktioniert, und unterstützt Kubernetes Monitoring sowie Continuous Profiling ohne zusätzliche Sidecars.