Auf dem Bildschirm einer Plattform-Engineerin liegt an einem Montagmorgen eine YAML-Datei, die seit zwei Jahren niemand angefasst hat: receivers, processors, exporters, Zeile für Zeile gewachsene Collector-Konfiguration. Sie soll auf Maschinen laufen, auf denen Grafana Alloy installiert ist. Muss dafür alles neu geschrieben werden? Muss es nicht, jedenfalls nicht zwingend. Grafana Labs hat die OTel-Engine von Alloy mit Version 1.21.0 in die Public Preview geholt. Sie läuft damit gleichberechtigt neben der Standard-Engine.
Viele Kunden arbeiten mit Alloy, andere schwören auf den OpenTelemetry Collector. Statt sie zu einer Entscheidung zu drängen, packt Grafana beide unter dieselbe Haube. Das Unternehmen beschreibt das selbst als Versuch, die Wahl der Nutzer zu respektieren statt sie zu bevormunden. Wer heute eine OTLP-Pipeline betreibt, kann sie weiterbetreiben und trotzdem nutzen, was Alloy drumherum mitbringt.
Am besten lässt sich das mit einem Hybridantrieb vergleichen. Es ist ein Fahrzeug, ein Chassis, ein Cockpit. Aber es stecken zwei Antriebsstränge darin, und du entscheidest nicht einmalig beim Kauf, sondern je nach Strecke, welcher gerade besser passt. Der Rest dieses Textes erklärt, was die beiden Engines unterscheidet, was die OTel-Engine konkret kann, wo sie noch hakt und wann du zu welchem Antrieb greifst.
Zwei Engines, zwei Grundhaltungen
Die Standard-Engine von Alloy ist im Kern eine Engine über Ökosysteme hinweg. Sie ist nicht an ein einzelnes Wire-Format und nicht an einen Hersteller gebunden. Sie kann eine Prometheus-Pipeline fahren, eine OTLP-Pipeline, eine Loki-Pipeline, und das alles in Alloys eigener Konfigurationssyntax. Deshalb wird sie oft mit einem Taschenmesser verglichen: dieselbe Engine, die Prometheus-Metriken scrapt, nimmt auch Logs über Syslog an, empfängt OTLP und liest Metriken aus eingebetteten Exportern.
Die OTel-Engine geht von einer anderen Beobachtung aus. Die Telemetriewelt bewegt sich in die entgegengesetzte Richtung: Statt zwischen Formaten zu übersetzen, konvergiert die Branche auf ein gemeinsames Modell, das die OpenTelemetry-Spezifikation definiert. Ein OpenTelemetry Collector ist eine Pipeline, die OTLP von Anfang bis Ende als natives Format behandelt. Portabilität und offene Standards stehen dort vor der Übersetzungsarbeit zwischen Ökosystemen. Die OTel-Engine in Alloy ist Grafana Labs‘ eigene Distribution dieses Collectors.
Die eine Engine ist der Dolmetscher, der jede Sprache im Raum spricht. Die andere ist der Muttersprachler, der OTLP nicht übersetzt, sondern einfach spricht. Beide bringen dich ans Ziel. Die Frage ist, ob du unterwegs Übersetzung brauchst oder ob alle Beteiligten dieselbe Sprache schon beherrschen.
Es ist einfach ein Collector: Standard-YAML ohne Übersetzung
Die OTel-Engine führt ganz normales Collector-YAML aus, ohne Übersetzung und ohne Alloy-Syntax. Wenn du bereits eine Collector-Konfiguration hast, hast du bereits eine Konfiguration für die OTel-Engine. Es gibt keine Zwischenschicht, die dir Formatfehler zurückmeldet, und keine Umgewöhnung an eine zweite Schreibweise. Für Teams, die ohnehin Collector-YAML schreiben, ist das der entscheidende Punkt.
Auch die Kommandos drumherum bleiben da, wo man sie kennt. validate, components, print-config und --set verhalten sich wie im upstream Collector. Skripte und CI-Jobs, die heute otelcol validate aufrufen, laufen weiter. Dasselbe gilt für die Werkzeuge, mit denen Collectoren üblicherweise ausgerollt werden. Im upstream Helm-Chart sind es zwei Werte, die gesetzt werden müssen. Beim OpenTelemetry Operator war das früher ein Problem, weil er auf dem Alloy-Image scheiterte, ohne die Möglichkeit, das Container-Kommando zu setzen. Mit spec.command, upstream seit Operator v0.153.0, ist daraus eine einzige Zeile geworden.
Für Installationen ohne Container gibt es ebenfalls einen Weg. Die Alloy-Pakete können beide Engines als Dienst starten. Wer die OTel-Engine als Service installieren möchte, setzt ALLOY_OTEL_MODE=1, und der Dienst fährt die OTel-Engine gegen die config.yaml hoch. Die Details unterscheiden sich je nach Plattform und sind in der Dokumentation nach Betriebssystem aufgeschlüsselt. Wer ohnehin Pakete verteilt, braucht für den zweiten Motor keine neue Infrastruktur.
Fleet Management: viele Hosts, eine Konfiguration
Collector-Konfiguration von Hand zu pflegen funktioniert bis zu einer Handvoll Hosts. Danach wird es mühsam, und diese Lücke war eine der ersten, die Grafana nach dem ersten Release geschlossen hat. Seit Alloy v1.19.0 lässt sich die Konfiguration der OTel-Engine zentral über Fleet Management verwalten. Der OpAMP-Supervisor ist dafür direkt im Alloy-Binary eingebettet und läuft über das neue, noch experimentelle Subkommando otel-supervisor.
In der Praxis heißt das: Du zeigst mit einer Supervisor-Konfigurationsdatei auf deinen Fleet-Management-Endpunkt und die zugehörigen Zugangsdaten, und Alloy kümmert sich um den Rest. Es baut die Verbindung auf, zieht die Pipeline-Konfiguration herunter und wendet Änderungen an, sobald du sie veröffentlichst. Wer fünfzig Collector-Instanzen betreibt, will nicht fünfzig Mal dasselbe YAML anfassen.
Für den Einstieg verweist die Ankündigung auf die Referenz zum otel-supervisor. Wichtig ist die Einordnung: Das Feature ist da, aber es ist Teil einer Engine, die sich selbst noch in der Public Preview befindet. Wer es produktiv einsetzt, sollte wissen, dass sich Details noch bewegen können.
Die alloyengine-Extension als Notausgang
Manchmal gibt es die Komponente, die man braucht, nur in der Standard-Engine. Für diesen Fall gibt es die alloyengine-Extension. Sie führt Alloy-Konfiguration innerhalb desselben Collector-Prozesses aus, sodass du das fehlende Stück mitnehmen kannst, ohne einen zweiten Agenten zu betreiben.
Grafana ist bei der Einordnung deutlich: Die Extension ist experimentell, und man erwartet, dass sie es bleibt. Der Grund ist technischer Natur. Die beiden Engines laufen zwar nebeneinander, können aber keine Daten direkt austauschen. Alles, was die Grenze überquert, geht über das Netz, üblicherweise per OTLP. Das ist funktional, aber es ist keine elegante Dauerlösung.
Deshalb die Bitte: Wenn du zur Extension greifst, sag, warum. Ein Issue im Alloy-Repository mit der Angabe, welche Komponente gefehlt hat, ist der richtige Weg. Diese Liste entscheidet darüber, welche Teile der Standard-Engine als Nächstes zu nativen OpenTelemetry-Collector-Komponenten werden.
Exporter als Receiver: was mit Grafana Cloud und Prometheus passiert
Ein Teil der Arbeit ist noch klar als Experiment gekennzeichnet, und das sollte man ernst nehmen: Nichts davon ist supportet, und in Produktion hat es nichts verloren. Interessant ist es trotzdem, weil es zeigt, wohin die Entwicklung geht. Bei Database Observability funktioniert heute der Weg, die bestehende Alloy-Konfiguration in den Collector zu holen, den man ohnehin betreibt. Die OTLP-Pipelines laufen weiter, die Extension erledigt die Datenbankbeobachtung daneben, und die zugehörige App erkennt keinen Unterschied. Ein nativer Collector-Pfad ist in Arbeit, aber noch weiter entfernt, weil erst entschieden werden muss, wie die Alloy-Komponenten in OpenTelemetry-native Komponenten zerlegt werden.
Bei Cloud Provider Observability ist die Lage ähnlich. Alloys Cloud-Exporter, etwa prometheus.exporter.gcp, laufen über die Extension, und die Daten sind identisch mit denen aus der Standard-Engine. Der interessantere Teil beginnt dort, wo Alloys native Prometheus-Exporter gar nicht mehr gebraucht werden. Grafana arbeitet mit der Prometheus-Community daran, Exporter als Bibliotheken einbettbar zu machen, sodass sie als echte Collector-Receiver laufen und nicht als etwas, das ein Collector scrapen muss. Mit einem entsprechend gebauten Collector ist der GCP-Exporter einfach ein weiterer Receiver.
Über Cloud Provider Observability hinaus gibt es die OpenTelemetry Collector Prometheus Distro, eine offizielle, experimentelle Distribution, die einbettbare Prometheus-Exporter als OpenTelemetry-Receiver ausliefert. Dazu gehören Blackbox, Postgres, Google Cloud Monitoring über den Stackdriver-Exporter und CloudWatch über den yet-another-cloudwatch-Exporter. Wer lieber selbst baut, findet die Receiver im Repository prometheus-opentelemetry-collector und kann sie mit dem OpenTelemetry Collector Builder zusammenstellen. Sobald sie das Stabilitätsmodell durchlaufen haben, sollen sie in die OTel-Engine wandern.
Was als Nächstes kommt und wann sich welcher Motor lohnt
Für die OTel-Engine steht als Nächstes das Debuggen oben auf der Liste. In der Standard-Engine gibt es dafür Support-Bundles, also einen einzelnen Aufruf von /-/support, der Konfiguration, Logs, interne Metriken, Laufzeit-Flags und pprof-Profile in eine Datei packt, die du vor dem Teilen selbst prüfen kannst. Die OTel-Engine hat dafür bislang kein Gegenstück. Eine OTel-native Extension ist in Arbeit.
Die Standard-Engine bleibt derweil nicht stehen. Der größte Teil der Arbeit dort dreht sich um eine Frage: Kommen deine Daten auch dann an, wenn stromabwärts etwas ausfällt? Bei Prometheus betrifft das prometheus.remote_write, also die Komponente, die verhindert, dass Metriken verschwinden, wenn das Backend nicht erreichbar ist. Geplant sind ein kleinerer Speicher-Fußabdruck, das Nachsenden von Daten, die beim Neustart in der Leitung waren, und Remote Write 2.0, das bei den internen Prometheus-Workloads von Grafana die Egress-Kosten um mehr als die Hälfte gesenkt hat. Letzteres ist heute als experimentelles Feature verfügbar und soll upstream stabil werden.
Bei Loki geht es um ein Design, das Alloy von Promtail geerbt hat: Komponenten reichen Logs weiter, ohne zurückmelden zu können, ob die Zustellung geklappt hat. Das erklärt die meisten rauen Kanten, etwa verlorene Logs beim Herunterfahren, eine langsame Stufe, die alles dahinter aufhält, und Dateipositionen, die weiterrücken, bevor eine Zeile wirklich gesendet wurde. Die Pipeline wird so umgebaut, dass Erfolg und Fehler bis zur Quelle zurückfließen. Dateipositionen wandern erst nach der Zustellung, beim Shutdown wird Ausstehendes geleert, und eine langsame Stufe blockiert nicht mehr die gesamte Pipeline. Dazu soll das WAL von loki.write zur allgemeinen Verfügbarkeit kommen, damit Logs einen Ausfall oder Neustart auf der Platte überleben.
Und wann greifst du zu welchem Motor? Die OTel-Engine ist die naheliegende Wahl, wenn du ohnehin in OpenTelemetry denkst, wenn deine Konfiguration als Standard-Collector-YAML vorliegt, wenn du mit dem OpenTelemetry Collector Builder arbeitest oder deine Flotte zentral über Fleet Management steuern willst. Die Standard-Engine bleibt die bessere Wahl, wenn du gemischte Pipelines fährst, Prometheus-Exporter brauchst, Database oder Cloud Provider Observability nutzt oder heute schon auf Support-Bundles angewiesen bist, um Fehler zu finden. Weil beide Engines im selben Binary stecken, ist das keine Entscheidung fürs ganze Haus, sondern eine pro Strecke.
Quelle: grafana.com
