Ein Collector-Fleet aktuell halten

Einen Collector zu enrollen, ist der leichte Teil. Der Teil, den niemand auf die Roadmap setzt, ist, das Fleet aktuell zu halten – und es ist der Ort, an dem aus „machen wir später” still und heimlich Versions-Drift, eine ungepatchte CVE oder ein Processor wird, den Sie brauchen und der nur in einem neueren Release ausgeliefert wird.

Manuelle Collector-Upgrades sind riskant, und zwar genau auf die Art, die Menschen sie vermeiden lässt. Per SSH auf jeden Host, ein Binary tauschen, neu starten, hoffen, dass es zurückkommt. Erwischen Sie die falsche Version, und es stürzt beim Start ab. Upgraden Sie einen OpenTelemetry Collector ohne seinen Supervisor, und Sie bekommen einen Crashloop durch eine Protokoll-Fehlanpassung. Machen Sie das über fünfzig Hosts hinweg, und Sie sind einen schlechten Batch von einem schlechten Nachmittag entfernt.

Also driften die meisten Fleets. In diesem Beitrag geht es darum, das nicht zuzulassen – veraltete Collectors zu erkennen und sie sicher zu aktualisieren, mit einem Health-Gate und automatischem Rollback, ohne so zu tun, als würden die zwei gängigen Runtimes auf dieselbe Weise upgraden.

Erst einmal die Drift sehen

Sie können nicht beheben, was Sie nicht sehen können. LinkMesh erfasst die Version, die jeder Collector ausführt, und vergleicht sie mit der Version, die es für diese Runtime validiert hat, und stellt die Antwort dann direkt in die Fleet-Ansicht.

Zwei Badges, zwei Bedeutungen:

• Update – eine neuere, von LinkMesh validierte Version ist verfügbar. Informativ. Upgraden Sie, wenn Sie bereit sind.
• Unvalidated – der Collector führt eine Version aus, die LinkMesh nicht getestet hat. Das ist die, auf die Sie achten sollten: Meist bedeutet es, dass jemand einen Build ausserhalb der Liste von Hand installiert hat, und ungetestete Versionen sind genau der Ort, an dem sich eine Supervisor-/Collector-Fehlanpassung versteckt. Pinnen Sie ihn erneut auf eine validierte Version.

Kein Badge bedeutet, dass der Collector auf der aktuellen validierten Version ist. Der Aktualitätsstand des gesamten Fleets ist jetzt eine Spalte, die Sie überfliegen können, keine Tabelle, die Sie pflegen.

Grafana Alloy an Ort und Stelle upgraden – mit einem Sicherheitsnetz

Für einen Grafana-Alloy-Collector, der über remotecfg mit einem am selben Host platzierten Agenten verwaltet wird, upgradet LinkMesh das Binary an Ort und Stelle. Sie klicken auf Upgrade; der Agent auf diesem Host erledigt den heiklen Teil:

1. Den gepinnten Build holen (vom Package-Manager des Hosts oder als verifizierter Download).
2. Das Binary tauschen und Alloy neu starten.
3. Es etwa 30 Sekunden lang beobachten.
4. Wenn es nicht gesund zurückkommt, automatisch auf das vorherige Binary zurückrollen.

Dieser letzte Schritt ist der, der Upgrades langweilig macht – im guten Sinne. Ein schlechtes Release lässt einen Collector nicht bäuchlings liegen; es lässt ihn die Version ausführen, die er bereits hatte, und die UI sagt Ihnen, dass das Upgrade fehlgeschlagen ist. Ihre Konfiguration wird nie angefasst: Alloy holt sie nach dem Neustart erneut über remotecfg, sodass die Pipelines genau so weiterlaufen, wie sie waren.

Hier gibt es eine stille Design-Entscheidung, die es wert ist, hervorgehoben zu werden: das Rollback lebt auf dem Host, nicht auf dem Server. Der Agent, der den Tausch vornimmt, ist derselbe Prozess, der ihn health-checkt und zurücknimmt. Der Server gibt die Absicht aus; der Host besitzt das Ergebnis. Deshalb kann es wirklich automatisch sein, statt ein „Fehler erkennen, dann versuchen, ihn aus der Ferne rückgängig zu machen”-Tanz.

Über eine Gruppe hinweg ausrollen, Batch für Batch

Ein Collector ist ein Button. Ein Fleet ist ein Rollout, und Rollouts wollen eine Bremse.

Für eine Collector-Gruppe führt LinkMesh ein health-gated Rolling Upgrade durch: Wählen Sie eine Batch-Grösse, und es upgradet so viele Mitglieder auf einmal, wartet, bis jedes einzelne als gesund meldet, und rückt dann zum nächsten Batch vor. Wenn ein Mitglied fehlschlägt, hält der Rollout an – dieses Mitglied rollt zurück, und die Collectors, die es noch nicht erreicht hat, bleiben unangetastet auf ihrer aktuellen Version. Sie beheben die Ursache und starten erneut; alles, was bereits auf der Zielversion ist, wird übersprungen.

Beginnen Sie mit einer Batch-Grösse von eins für den vorsichtigsten Rollout, und weiten Sie sie aus, sobald Sie dem Release vertrauen. So oder so stoppt eine schlechte Version die Linie, statt das Fleet lahmzulegen.

Warum otelcol anders ist – und warum wir es nicht vorgetäuscht haben

Hier kommt der Teil der ehrlichen Ingenieurskunst.

Der OpenTelemetry Collector unter OpAMP wird vom vorgelagerten opampsupervisor beaufsichtigt, und dieser Supervisor wendet keine Remote-Binary-Updates an. Die Fähigkeit ist in der Spezifikation definiert, aber nicht implementiert – die Config-Management-Seite funktioniert, die Package-Management-Seite ist Zukunftsarbeit.

Wir hätten das übertünchen können. Haben wir aus einem konkreten Grund nicht getan: Der Supervisor verwaltet den Collector als Kindprozess, und er ist ausserordentlich empfindlich gegenüber allem, was er nicht selbst getan hat. Pushen Sie ihm ein Angebot, das er nicht einlösen kann, oder überholen Sie ihn, indem Sie das Binary unter ihm austauschen, und er scheitert nicht sauber – er stockt oder gerät in einen Crashloop. Der Collector und der Supervisor teilen sich ausserdem über Releases hinweg ein Wire-Protokoll, sodass das Upgraden des einen ohne das andere sein eigener Absturz ist. Ein servergesteuertes Upgrade hier vorzutäuschen, würde ein sichtbares „Sie müssen einen Befehl ausführen” gegen ein unsichtbares „Ihr Collector ist jetzt down” eintauschen.

Also tut LinkMesh für OpAMP-Collectors das Nützliche, das es zuverlässig kann: Es zeigt Ihnen einen einfügefertigen Befehl, der den Installer erneut ausführt, gepinnt auf die validierte Version – und den Collector und seinen Supervisor gemeinsam, auf dieselbe Version upgradet, weil sie zusammenpassen müssen. Ein Befehl, beide Binaries, ein zueinander passendes Paar. Machen Sie einen Host, bestätigen Sie, dass er gesund ist und Telemetrie fliesst, und rollen Sie dann den Rest aus.

Eine gemischte Gruppe – teils Alloy, teils otelcol – wird ebenfalls ehrlich behandelt: Das Rolling Upgrade upgradet die Alloy-Mitglieder und markiert die otelcol-Mitglieder als übersprungen, mit einem Link zu ihrem Re-Pin-Befehl. Nichts wird still ignoriert, nichts still kaputt gemacht.

Die operative Leichtigkeit, die sich tatsächlich aufaddiert

Nichts davon ist glamourös, und das ist der Punkt. Collectors aktuell zu halten, ist die Art von Pflichtaufgabe, die leicht aufzuschieben und teuer aufgeschoben zu haben ist. Sie zu einem Spalte-überfliegen-, Upgrade-klicken-, health-gated-, umkehrbaren Vorgang zu machen, ist das, was aus „wir sollten die mal aktualisieren” etwas macht, das Sie tatsächlich tun – bevor eine CVE oder ein fehlender Processor Ihnen im denkbar-schlechtesten Moment die Hand zwingt.

Zwei Runtimes, zwei Upgrade-Pfade, eine Fleet-Ansicht – und ein Rollback, das automatisch ist, wo es sein kann, und ein Matched-Pair-Befehl, wo es sein muss.

---

Weiterlesen:

• Die operative Schritt-für-Schritt-Anleitung: Collectors upgraden
• Grafana Alloy vs. OpenTelemetry Collector: Die richtige Wahl treffen
• OpAMP erklärt: OpenTelemetry Collectors im grossen Massstab remote verwalten