OpenTelemetry Collectors lassen sich jetzt auch ohne Alloy verwalten
OpenTelemetry Collectors lassen sich laut Marko Bachvarovski von Grafana jetzt zentral in Grafana Cloud verwalten, ohne zuvor auf Grafana Alloy umzustellen. Nach Angaben von Grafana ist die Unterstützung für das Open Agent Management Protocol (OpAMP), ein Protokoll zur Fernverwaltung von Softwareagenten, in Fleet Management allgemein verfügbar. Die Neuerung erweitert einen bislang auf Alloy ausgerichteten Arbeitsablauf auf unterstützte Upstream-Distributionen des OpenTelemetry Collector, also unterstützte Pakete der von der Community entwickelten Collector-Software.
OpenTelemetry, häufig mit OTel abgekürzt, stellt Werkzeuge zur Erfassung von Telemetriedaten bereit. Das sind Messwerte und Aufzeichnungen, mit denen sich das Verhalten von Software nachvollziehen lässt. Seine Collectors empfangen, verarbeiten und übermitteln diese Informationen. Alloy ist Grafanas Distribution des OpenTelemetry Collector. Für Teams, die bereits andere unterstützte Distributionen betreiben, bedeutet die Ankündigung: Eine zentrale Verwaltung muss nicht damit beginnen, die Collector-Software auszutauschen, die Konfiguration in das Alloy-Format umzuschreiben oder den Ausführungsort der Collectors zu ändern.
Die zugrunde liegende betriebliche Herausforderung geht über einzelne Produkte hinaus: Wenn eine Monitoring-Umgebung wächst, brauchen Teams gemeinsame Regeln, ohne dabei Einstellungen zu verlieren, die nur für bestimmte Dienste oder Umgebungen gelten. Außerdem müssen sie wissen, ob die Collectors selbst funktionieren. Grafanas Umsetzung vereint die gezielte Zuweisung von Konfigurationen und die Überwachung des Collector-Zustands in einem Verwaltungsablauf. OTel YAML, das strukturierte Textformat zur Beschreibung von Collector-Einstellungen, bleibt dabei erhalten.
Gemeinsame Konfiguration ohne identische Workloads
Mit Fleet Management können Teams Telemetrie-Pipelines, also Abfolgen von Erfassungs- und Verarbeitungsschritten, in OTel YAML definieren und passenden Collectors zuweisen. Eine gemeinsame Verarbeitungsregel lässt sich dadurch zentral aktualisieren, während zusätzliche Datenerfassung auf die Teams, Dienste oder Umgebungen beschränkt bleibt, die sie benötigen. Grafana zeigt außerdem einen Konfigurationstest, der eine Syntaxprüfung besteht. Diese prüft die Struktur der Konfiguration, weist aber nicht nach, wie sie sich unter jeder Arbeitslast verhält.
Für Teams, die Infrastructure as Code einsetzen, also Infrastruktur mithilfe gespeicherter Konfigurationsdateien verwalten, beschreibt Grafana die Unterstützung für Terraform, ein Werkzeug zur Anwendung dieser Dateien. Über diesen Arbeitsablauf können Teams YAML-basierte Pipelines erstellen und aktive Collectors registrieren. Konfiguration und Registrierung können so zu wiederholbaren Prozessen werden, die in einer Versionsverwaltung nachverfolgt werden. Ein solches System zeichnet Änderungen an Dateien im Zeitverlauf auf.
Mit der Registrierung wird auch die Selbstüberwachung der Collectors eingerichtet. Laut Grafana senden registrierte OTel Collectors automatisch Metriken, also numerische Messwerte, Logs, also aufgezeichnete Ereignisse, und Traces, also Aufzeichnungen des Wegs von Anfragen durch die Software, an Grafana Cloud. Dies gilt unabhängig vom Betriebssystem oder der Bereitstellungsart. Collectors außerhalb von Kubernetes, einem System zur Verwaltung von Anwendungen, die in Containern verpackt sind, erhalten zusätzlich eine Pipeline zur Host-Überwachung. Damit können Teams neben dem Collector auch den zugrunde liegenden Rechner untersuchen.
Diese Monitoring-Pipelines geben weder unveränderliche Datenziele noch verbindliche Erfassungsrichtlinien vor. Laut Grafana können Teams sie bearbeiten, deaktivieren oder ihre Daten an ein anderes Backend umleiten, also an das empfangende System, das Telemetriedaten speichert oder analysiert. Dieser Unterschied ist wichtig, wenn geprüft wird, welche Daten ein registrierter Collector sendet und wohin sie gelangen.
Warum das Zusammenführen von Konfigurationen mehr als eine Syntaxprüfung erfordert
Ein Collector kann mehrere Fleet Management-Pipelines erhalten und zugleich seine lokale Konfiguration beibehalten. Die daraus entstehenden Einstellungen müssen zusammen funktionieren. Bachvarovski erklärt, dass Alloy Komponenten, also einzelne Bausteine zur Verarbeitung oder Erfassung, in Blöcken definiert, die über Verweise auf ihre Ausgaben miteinander verbunden sind. OTel Collectors definieren Komponenten dagegen auf der obersten Ebene der Konfiguration und verweisen aus einer oder mehreren Telemetrie-Pipelines auf sie.
Es gibt einen zweiten wichtigen Unterschied: Alloy hält lokale und entfernte Konfigurationen getrennt, während OTel Collectors sie zu einer einzigen wirksamen Konfiguration zusammenführen. Wenn mehrere Quellen eine Komponente mit demselben Namen definieren, kann eine Definition eine andere überschreiben und das Verhalten der Pipeline verändern. Unabhängig voneinander erstellte Pipelines können daher miteinander in Konflikt geraten, selbst wenn ihre Autoren für die gleichnamigen Komponenten unterschiedliches Verhalten vorgesehen haben.
Grafana begegnet diesem Problem mit einem Zusammenführungsalgorithmus, einem Verfahren zum Kombinieren von Konfigurationen, das entfernte Einstellungen nachbearbeitet. Es ergänzt die Kennungen von OTel-Pipelines und -Komponenten um den Namen der Fleet Management-Pipeline und aktualisiert anschließend die Verweise auf diese Kennungen. Haben Komponenten sowohl denselben Typ als auch dieselbe Konfiguration, entfernt es die Duplikate und behält eine gemeinsame Definition statt unnötiger Kopien bei. Grafana zeigt außerdem eine schreibgeschützte Ansicht der einem Collector zugeordneten entfernten Konfiguration.
Dieser Mechanismus soll es Teams ermöglichen, entfernte Pipelines als wiederverwendbare Bausteine zu pflegen, statt für jede mögliche Kombination manuell eine separate Konfigurationsdatei zu erstellen. Die übertragbare Erkenntnis lautet: Zentrale Konfiguration braucht ausdrückliche Regeln für Namen, Verweise und die Zusammenführung. Dass gültiges YAML akzeptiert wird, erklärt allein noch nicht, wie getrennt erstellte Konfigurationen zusammenwirken.
Lokale Erfassung von gemeinsamer Verarbeitung trennen
Fleet Management unterstützt unterschiedliche Bereitstellungsmuster. Eine von Grafana beschriebene Option für große oder gemischte Flotten ist das Gateway-Muster, das Collectors auf zwei Ebenen aufteilt. Edge-Collectors in der Nähe der Anwendungen erfassen Telemetriedaten von Diensten, Kubernetes-Pods (Gruppen von Anwendungscontainern) und Nodes (den Rechnern, auf denen diese laufen). Sie leiten die Daten an Gateway-Collectors weiter, die gemeinsame Verarbeitungsschritte ausführen, bevor sie die Daten an ein Backend senden.
Am Gateway können Teams beispielsweise Metriken um Team-Labels ergänzen, Logs filtern oder Tail Sampling auf Traces anwenden. Dabei entscheiden sie erst nach der Beobachtung des Anfrageverlaufs, welche Anfrageaufzeichnungen aufbewahrt werden. Werden diese Richtlinien am Gateway umgesetzt, muss nicht jeder Edge-Collector dieselbe Verarbeitungslogik ausführen. Fleet Management kann Erfassungs-Pipelines gezielt den Edge-Collectors und Verarbeitungs-Pipelines den Gateways zuweisen und beide zentral verwalten, ohne ihre Aufgabenbereiche zu vermischen.
Auf den beiden Ebenen muss nicht dieselbe Software laufen. Laut Grafana können vorhandene Agenten wie Fluent Bit oder Telegraf am Edge bestehen bleiben und Telemetriedaten über kompatible Protokolle an OTel-Gateways weiterleiten. Fleet Management verwaltet dann die unterstützten OTel-Gateways und ihre gemeinsamen Verarbeitungseinstellungen. Dies ist ein schrittweiser Weg zur Einführung von OpenTelemetry und keine Aussage, dass sich jeder vorhandene Agent direkt über Fleet Management verwalten lässt.
Gateways sind optional: Auch unterstützte Collectors, die direkt an ein Backend senden, können den OpAMP-basierten Arbeitsablauf nutzen. Grafana empfiehlt als Einstieg, einen Collector zu registrieren, ihm eine YAML-Pipeline zuzuweisen und seinen Zustand zu prüfen, bevor das Vorgehen auf weitere Umgebungen ausgeweitet wird. Die Ankündigung führt nicht jede unterstützte Distribution auf. Die Kompatibilität sollte daher geprüft und nicht einfach vorausgesetzt werden.
Für Unternehmen, die den Schutz ihrer überwachten Infrastruktur überprüfen, bieten die Managed-Cloud- und Dateninfrastruktur-Dienste von AEU Data einen passenden Anknüpfungspunkt, um neben der Collector-Verwaltung auch das Monitoring und die Unterstützung im Betrieb zu bewerten. Die zentrale Entscheidung bleibt praxisbezogen: das zur Arbeitslast passende Erfassungsmodell beibehalten, das Verhalten zusammengeführter Einstellungen verstehen und die Kontrolle über die Monitoring-Daten behalten, die diese Collectors senden.