Loading content
OpenTelemetry ist ein offener Standard und ein Ökosystem für das Sammeln, Weiterleiten und Konfigurieren von Telemetriedaten (Traces, Metriken, Logs). Es ermöglicht herstellerunabhängige Instrumentierung von Anwendungen und bietet Sammler, SDKs und Exporter für Cloud- und On-Premises-Betrieb. Dadurch lassen sich Performance-Probleme präziser diagnostizieren…
Nutze diesen Steckbrief, um den Baustein kurz zu verstehen, ihn im Modell einzuordnen und verwandte Bausteine zu öffnen.
Technischer Baustein: kann automatisiert, integriert oder betrieben werden.
Konkretes Rädchen im System, das in größeren Zusammenhängen wirkt.
OpenTelemetry ist ein offener Standard und ein Ökosystem, das Telemetriedaten (Traces, Metriken und Logs) über APIs/SDKs, einen Collector und Exporter sammelt, weiterleitet und plattformübergreifend konfigurierbar macht.
OpenTelemetry entstand als Weiterentwicklung aus den Projekten OpenTracing und OpenCensus und wurde durch deren Zusammenführung zu einem gemeinsamen, CNCF-unterstützten Observability-Ansatz. Ziel war eine herstellerneutrale Instrumentierung: Code wird über eine einheitliche API/SDK-Seite verbunden, während die Ziel-Backends über Export-Konfigurationen wechseln können.
Stell dir OpenTelemetry als Telemetrie-„Verkehrssystem“ mit drei Bereichen vor: (1) Im Code erzeugen Instrumentierungs-APIs/SDKs Events wie Traces, Metriken und Logs. (2) Ein OpenTelemetry Collector nimmt diese Daten über eine Pipeline entgegen, filtert/sortiert sie und bereitet sie für das Weiterleiten auf. (3) Exporter bringen die Daten zu einem oder mehreren Observability-Backends; dabei ist wichtig, dass Kontext zwischen Services propagiert wird, damit sich Traces, Metriken und Logs entlang des Requestpfads wieder zusammenführen lassen.
Anwendungscode wird über eine gemeinsame API/SDK-Schicht instrumentiert, sodass Backends austauschbar bleiben.
Traces, Metriken und Logs können über gemeinsamen Kontext, der zwischen Services weiterfließt, zusammenhängend betrachtet werden.
Der Collector verarbeitet Telemetrie systematisch (z. B. entgegnen, filtern/route-planen) und stellt sie für Exporte bereit.
Exporter übertragen Telemetriedaten in Observability-Ziele wie Jaeger, Prometheus, kommerzielle Systeme oder eigene Lösungen.
Offene Spezifikationen definieren APIs/SDKs und das Wire-Protocol (OTLP), über das Telemetrie zwischen Komponenten läuft.
OpenTelemetry passt besonders, wenn du einheitliche Instrumentierung für mehrere Plattformen, Sprachen oder Observability-Backends brauchst und ohne Codeänderungen zwischen Zielsystemen wechseln möchtest. Praktisch wichtig sind dafür: die korrekte Einrichtung von Collector/Export sowie belastbare Kontext-Propagation, damit Korrelation über Servicegrenzen hinweg funktioniert. Der Ansatz bringt zusätzliche Komponenten (Collector und Konfigurations-/Exportpfade) mit, die betrieben und abgestimmt werden müssen.
Wo dieser Baustein im Themenmodell verortet ist.
Erkunde, wie dieser Wissensbaustein mit Konzepten, Methoden, Technologien und Tools verbunden ist.
Diese Quellen belegen den Begriff und seine fachliche Bedeutung.
Alle direkten Verbindungen des aktuellen Wissensbausteins in einer kompakten, textuellen Darstellung.
Diese Einordnung zeigt, in welchem Kontext der Baustein typischerweise relevant wird, wie anspruchsvoll er ist und welche Wirkung er im Modell hat.
Die Ebene innerhalb der Organisation (Unternehmen, Domäne, Team), auf der der AssetBlock angewendet wird.