OpenTelemetry Collector Transparenz für komplexe IT-Architekturen

Der OpenTelemetry Collector ist zu einem zentralen Werkzeug für die Verarbeitung von Telemetriedaten in verteilten IT-Systemen geworden. Durch seine offene Architektur ermöglicht er zukunftsfähiges Observability-Management – auch bei KI.

IT-Infrastruktur heißt heute: Hybride und Cloud-native IT-Umgebungen von unterschiedlichen Anbietern mit komplexen Softwarearchitekturen, verteilten Systemen und stetig wachsenden Datenmengen. Um einen Überblick darüber zu gewinnen, müssen Telemetriedaten gesammelt und verarbeitet werden, also Logs, Metriken und Traces.

• Logs (Protokolle) sind Dateien mit aufgezeichneten Systemereignissen.

• Metriken sind Messdaten aus der Infrastruktur, etwa von einzelnen Hosts oder Anwendungen.

• Traces entstehen beim Verfolgen von Prozessen. Sie enthalten zum Beispiel Bezeichner von Systemen und Diensten, Zeitstempel, Protokolle, Ereignisse und einiges mehr.

Diese Daten werden üblicherweise von einer Observability-Plattform verarbeitet, analysiert und visualisiert. Zum Sammeln der Daten hat sich das OpenTelemetry-Ökosystem als Standard etabliert. Er wird auch abgekürzt als OTel bezeichnet und ist eine Sammlung aus Tools und APIs, die als Projekt der „Cloud Native Computing Foundation CNCF“ entstanden ist.

Datendrehscheibe mit zwei Betriebsmodi

Ein zentraler Teil des Ökosystems ist der OpenTelemetry Collector. Er empfängt und verarbeitet als zentrale Datendrehscheibe Telemetriedaten aus unterschiedlichen Quellen und leitet sie an definierte Backends weiter, etwa einer Observability-Plattform. Er verfügt dafür über zwei Betriebsmodi: den agentenbasierten und den eigenständigen Betriebsmodus.

Im agentenbasierten Betriebsmodus arbeitet der Collector direkt auf dem jeweiligen Host oder Container, auf dem auch die zu überwachende Anwendung läuft. So werden die Daten ohne Umwege erfasst. Dieser Modus ist einfach zu konfigurieren, aber in erster Linie für kleine oder homogene Umgebungen gedacht. In großen oder stark verteilten Systemen steigt der Verwaltungsaufwand, da zahlreiche Instanzen gepflegt und auf dem neuesten Stand gehalten werden müssen.

Im eigenständigen Betriebsmodus arbeitet der Collector dagegen als zentraler Dienst und aggregiert Daten aus vielen Quellen. Diese Variante eignet sich vor allem für komplexe IT-Architekturen, in denen es Telemetriedaten aus verschiedenen Regionen und Clouds gibt. Für diese Situation hat ein eigenständiger Collector-Prozess Vorteile. Doch zugleich steigt die Abhängigkeit von der Stabilität der Netzwerkverbindungen, da bei instabilen Übertragungen Datenverluste entstehen.

Flexible Integration über standardisierte Protokolle

Seine Aufgaben erfüllt der OpenTelemetry Collector mit dem OpenTelemetry Protocol (OTLP). Es benutzt den standardisierten Datenaustausch über HTTP oder gRPC. Damit lassen sich Telemetriedaten aus vielen unterschiedlichen Programmiersprachen und Frameworks integrieren, darunter Java, Python, .NET, Ruby, Node.js und viele mehr. Bestehende Anwendungen können also ohne proprietäre Agenten angebunden werden.

Das OTLP-Format ist besonders hilfreich in komplexen Umgebungen mit heterogenen Technologie-Stacks, etwa Microservices oder Serverless-Funktionen. Durch synchrones und asynchrones Streaming lassen sich Echtzeitdaten effizient übertragen, ohne die Performance produktiver Systeme zu beeinträchtigen.

Der Collector erlaubt es, einzelne Metriken oder Traces eindeutig bestimmten Anwendungen, Services oder Instanzen zuzuordnen. Durch eine Filterfunktion lassen sich sensible Informationen wie personenbezogene Daten entfernen oder irrelevante Daten wie wiederholte gleiche Messwerte verwerfen. Zudem kann das System auch externe Kontextdaten wie Kubernetes-Labels hinzufügen.

5 Do’s & Don’ts für erfolgreiche Observability

Monitoring reicht nicht – Observability muss liefern

Transparenz durch Dashboards und Self-Monitoring

Zu den Fähigkeiten des OpenTelemetry Collectors gehört deshalb auch die Selbstüberwachung. Hierfür gibt es vorkonfigurierte Dashboards: eines für die Übersicht aller Collector-Instanzen und eines für die detaillierte Analyse einzelner Instanzen.

Das Multi-Collector-Dashboard zeigt aggregierte Metriken über alle Collector-Instanzen hinweg. Es kann beispielsweise einen plötzlichen Anstieg des Speicherverbrauchs in mehreren Instanzen erkennen und mit gezielten Maßnahmen wie horizontaler Skalierung oder Lastverteilung reagieren. Diese Informationen helfen bei der Kapazitätsplanung und erkennen potenzielle Engpässe frühzeitig. Ein zentraler Aspekt ist die Überwachung von Telemetriesignalen (Alerts, Ereignisse und so weiter). Das Dashboard zeigt, ob alle eingehenden Daten korrekt verarbeitet wurden oder es zu Datenverlusten kam.

Das Single-Collector-Dashboard erlaubt den Drilldown auf eine einzelne Instanz. Hier sind beispielsweise der Speicherverbrauch und die Auslastung der Warteschlange besonders wichtig. Wenn sich die Anzahl der abgelehnten Datensätze erhöht, ist das ein Hinweis auf eine Überlastung des Collectors, etwa durch zu kleine Speicherbereiche oder eine zu geringe Verarbeitungskapazität. Die Visualisierung solcher Zusammenhänge erlaubt es, den Collector gezielt zu skalieren und so Datenverluste zu vermeiden.

Diese Dashboards bieten einen guten Überblick über die Abläufe innerhalb des Collectors, müssen jedoch immer noch manuell überwacht werden. Eine wichtige Funktion ist deshalb die Definition von Alerts. Auslösende Faktoren sind statische Schwellwerte, automatisch festgelegte Grenzwerte oder ein saisonales Baseline-Modell. Wenn ein Alert ausgelöst wird, verständigt er das IT-Team mit E-Mails, der Nachrichtenfunktion oder über die Funktionen eines vorhandenen Incident-Management-Tools.

Telemetrie für Sprachmodelle und generative KI

Die Vorteile der offenen Architektur des OpenTelemetry-Collectors zeigen sich vor allem bei der Integration von neuen Anwendungsbereichen wie generativer KI in das Ökosystem. Sie bringt besondere Herausforderungen für IT-Teams mit sich, zum Beispiel die mangelnde Transparenz bei der Ausführung der Modelle, die oft als Blackboxes agieren. Hinzu kommen schwer kalkulierbare Kosten pro Anfrage, variable Antwortzeiten sowie die Notwendigkeit, personenbezogene Daten entsprechend der DSGVO zu behandeln.

Ein zuverlässiges Monitoring sollte daher nicht nur die üblichen Leistungs- und Verfügbarkeitsdaten umfassen, sondern auch Transparenz in den Bereichen Modellverhalten, Konfiguration und Nachhaltigkeit bringen. Die Kontributoren zum OpenTelemetry-Ökosystem entwickeln im Moment standardisierte Kennzahlen für die systematische Überwachung unterschiedlicher GenAI-Systeme. So sind beispielsweise Metriken für Prompt-Latenzzeiten, Antwortgrößen oder Fehlerraten der Sprachmodelle notwendig.

Mit Blick auf die Erweiterbarkeit eignet sich der OpenTelemetry Collector besonders für Unternehmen, die ihre bestehende Monitoring-Strategie zukunftssicher erweitern wollen. Sie sind dabei nicht auf proprietäre Schnittstellen angewiesen, sondern erhalten mit dem Collector ein leistungsfähiges Werkzeug für ihre heterogenen und dynamischen IT-Landschaften.

Über den Autor

Roman Spitzbart ist VP EMEA Solutions Engineering bei Dynatrace.

(ID:50544844)