Telemetrie sind die Daten, die Anwendungen und Infrastruktur über ihren eigenen Zustand und ihr Verhalten aussenden und die zur Analyse gesammelt und übertragen werden. Im Software-Betrieb umfasst sie Metriken, Logs, Traces und Profile, häufig ergänzt um Ereignisse wie Deployments. Telemetrie ist der Rohstoff von Observability: Ohne sie lassen sich keine Fragen an ein laufendes System stellen.
Was ist Telemetrie?
Das Wort verbindet das griechische tele (fern) und metron (Maß): etwas aus der Ferne messen. In der Software sind Telemetriedaten die Informationen, die Services, Hosts, Container, Browser und Geräte über ihre Tätigkeit senden: wie viele Requests sie verarbeiten, wie lange diese dauern, welche Fehler auftreten, wie viel Speicher und CPU sie belegen und was innerhalb eines einzelnen Requests Schritt für Schritt geschieht.
Telemetrie ist nicht dasselbe wie Observability. Telemetrie sind die Daten; Observability ist die Eigenschaft eines Systems und die Praxis eines Teams, aus diesen Daten den inneren Zustand zu verstehen. Gute Observability braucht Telemetrie, die vollständig, korreliert und bezahlbar genug ist, um sie aufzubewahren.
Die wichtigsten Telemetrie-Signale
| Signal | Was es erfasst | Typische Frage |
|---|---|---|
| Metriken | Numerische Messwerte, über die Zeit aggregiert | Steigen Fehlerrate oder Latenz? |
| Logs | Datensätze einzelner Ereignisse mit Zeitstempel | Was genau ist in diesem Fall passiert? |
| Traces | Der Weg eines Requests über Services hinweg, bestehend aus Spans | Wo in der Aufrufkette entsteht Zeitverlust oder ein Fehler? |
| Profile | Wo Code CPU-Zeit und Speicher verbraucht, bis auf Funktionsebene | Welche Funktion verursacht diese CPU-Spitze? |
| Events | Änderungen wie Deployments, Konfigurationsupdates, Skalierung | Was hat sich kurz vor Beginn des Problems geändert? |
Telemetrie aus Browsern und mobilen Apps, erfasst per Real User Monitoring, ergänzt die Perspektive der Menschen, die das System tatsächlich nutzen.
So fließt Telemetrie: die Pipeline
- Erzeugen: Instrumentierung im Code, Agents für Auto-Instrumentierung, eBPF-basierte Collectors oder eingebaute Exporter in Infrastruktur und Cloud-Services liefern die Daten.
- Sammeln: Agents und der OpenTelemetry Collector empfangen oder scrapen Telemetrie nahe an der Quelle.
- Verarbeiten: Die Pipeline bündelt, reichert an (etwa mit Kubernetes-Metadaten), filtert, sampelt und maskiert sensible Felder.
- Übertragen: Die Daten gehen an ein oder mehrere Backends, zunehmend per OTLP.
- Speichern und analysieren: Das Backend speichert die Daten, macht sie abfragbar und speist Dashboards, Alerts, SLOs und automatisierte Analysen.
Jeder Schritt ist ein Hebel für Qualität und Kosten. Frühe Entscheidungen, etwa welche Attribute erfasst und was verworfen wird, wirken sich am stärksten auf Ihre Rechnung aus und darauf, welche Fragen Sie später beantworten können.
Push- und Pull-Erfassung
Telemetrie erreicht einen Collector auf einem von zwei Wegen. Im Pull-Modell, bekannt durch Prometheus, fragt der Collector in festen Intervallen einen HTTP-Endpunkt jedes Ziels ab. So ist sofort erkennbar, ob ein Ziel ausgefallen ist, und die Anwendung bleibt einfach. Im Push-Modell, das OTLP-Exporter und die meisten Log-Shipper nutzen, sendet die Anwendung oder der Agent Daten nach eigenem Takt. Das passt zu kurzlebigen Jobs, Serverless-Funktionen und Verkehr, der Netzwerkgrenzen überqueren muss. Die meisten Produktionsumgebungen nutzen beides, und der OpenTelemetry Collector kann Prometheus-Endpunkte scrapen und gleichzeitig OTLP-Daten in derselben Pipeline empfangen.
Warum Korrelation wichtiger ist als Volumen
Mehr Telemetrie bedeutet nicht automatisch mehr Erkenntnis. Wertvoll werden Signale erst, wenn sie sich verknüpfen lassen. Gemeinsame Resource-Attribute wie service.name, deployment.environment.name und k8s.pod.name erlauben den Wechsel von einer Metrik zu den Hosts dahinter. Trace- und Span-IDs in Log-Datensätzen führen von einem langsamen Trace zu den Logs, die er erzeugt hat. Exemplars verbinden einen Bucket eines Latenz-Histogramms mit einem konkreten Trace. Die Semantic Conventions von OpenTelemetry vereinheitlichen diese Namen über Programmiersprachen hinweg; ihre Einführung zahlt sich daher schnell aus.
Best Practices
- Setzen Sie bei neuer Instrumentierung auf OpenTelemetry, um herstellerspezifische Agents und Formate zu vermeiden.
- Vergeben Sie
service.name, Version und Umgebung vom ersten Tag an für jedes Signal. - Behandeln Sie Telemetrie wie ein Produkt: mit Verantwortlichen, Namensregeln und einem Budget pro Team.
- Filtern und aggregieren Sie in der Pipeline, statt alles zu speichern und später zu löschen.
- Maskieren Sie personenbezogene Daten, bevor sie Ihr Netzwerk verlassen, besonders in Logs und Span-Attributen.
Typische Fehler
- Jedes Signal in einem eigenen Werkzeug mit unterschiedlichen Service-Namen erfassen, sodass sich nichts korrelieren lässt.
- Die Kosten von Attributen mit hoher Kardinalität ignorieren, bis die Rechnung kommt.
- Nur das Backend instrumentieren und keinen Einblick in das Erleben der Nutzer haben.
- Anwendungen überwachen, aber nicht die Telemetrie-Pipeline selbst, sodass verlorene Daten unbemerkt bleiben.
Wie Obseria unterstützt
Obseria nimmt Telemetrie von OpenTelemetry-SDKs und Collectors entgegen, vom Obseria Agent (Metriken, Logs, Traces, Profile und Security-Signale aus einer Installation pro Host) sowie agentenlos aus über 300 Services von AWS, Azure und GCP. Obseria Pipeline filtert, reichert an und maskiert Daten beim Ingest, und Obseria Lake speichert alle Signale gemeinsam, damit Sie sie in einer Abfrage korrelieren können. Mehr auf der Seite zu OpenTelemetry oder im Artikel Was ist OpenTelemetry?.
