Weil echte Helden ihre eigenen Exporter bauen, und manchmal ist genau das der richtige Schritt

Jedes Prometheus-Setup erreicht irgendwann diesen Moment. Sie haben node-exporter verkabelt, kube-state-metrics zum Laufen gebracht und ein halbes Dutzend Community-Exporter eingebunden. Und dann fällt Ihr Blick auf ein stures System, das in der Ecke Ihrer Infrastruktur sitzt und unbeachtet seine wichtige Arbeit verrichtet … ganz ohne Metriken.

Dort beginnt diese Geschichte. Jemand hat FreeIPA entstaubt und bemerkt, dass Metriken fehlten. Statt darauf zu warten, dass der „perfekte" Exporter auftaucht, hat diese Person getan, was Engineers seit Jahren ohne viel Aufhebens tun: einen eigenen geschrieben.

FreeIPA ist nicht sexy, aber kritisch

FreeIPA steht normalerweise nicht im Rampenlicht von Observability-Vorträgen. Es geht um LDAP, Identität, Kerberos, Replikation und Zertifikate, also um die Verrohrung hinter Authentifizierungs-Flows, über die die meisten Leute nie nachdenken, bis sie kaputtgeht. Und wenn sie kaputtgeht, dann richtig.

In diesem Fall war FreeIPA schon früher im Einsatz, 2015 für ein LDAP-basiertes Projekt. Heute laufen zwei über Docker bereitgestellte Instanzen mit Replikation, und plötzlich muss man die Gesundheit dieser Replikation tatsächlich überwachen.

In diesem Moment werden Dashboards von „nice to have" zu „warum haben wir das nicht längst?". Replikationsprobleme in Identitätssystemen sind nichts Kosmetisches, sie sind Ausfälle, die nur darauf warten zu passieren.

Der Exporter-Instinkt

Engineers reagieren auf fehlende Metriken ganz unterschiedlich. Manche eröffnen ein GitHub-Issue, manche suchen nach Forks, und manche kleben Shell-Skripte mit Panzertape an Cronjobs. Und dann gibt es den Exporter-Instinkt:

„Wenn es das nicht gibt, baue ich es selbst."

So entstand freeipa-exporter. Niemand wollte ein Produkt starten oder GitHub-Stars hinterherjagen, der Autor brauchte schlicht Observability.

„Vielleicht bin ich etwas übers Ziel hinausgeschossen"

Dieser Satz sagt alles. Jeder Engineer, der jemals einen Exporter gebaut hat, kennt diese schiefe Ebene.

Man fängt an mit:

• grundlegenden Health-Checks
• ein paar Gauges
• vielleicht dem Replikationsstatus

Dann denkt man: „Wo ich schon mal dabei bin …"

• Lass uns ein paar LDAP-Stats exponieren.
• Vielleicht ein paar Kerberos-Counter.
• Was ist mit der Zertifikatsgültigkeit?
• Sollten wir die Nutzerzahlen tracken?
• Ach, und Replikations-Lag pro Peer.

Ehe man sich versieht, hat man eine umfassende Telemetrie-Schicht gebaut. Übertrieben? Vielleicht. Befriedigend? Absolut.

Der Autor gibt auch offen zu, dass es ein guter Vorwand war, mal wieder etwas zu programmieren, und dass es sich einfach cool angefühlt hat. Diese Freude zählt in der Infrastrukturarbeit mehr, als wir zugeben.

Die eigentliche Herausforderung: Replikation überwachen

Der Autor nennt die Überwachung der Replikation ausdrücklich als größte Herausforderung, und wer schon mit LDAP oder Verzeichnisdiensten gearbeitet hat, weiß warum. Replikation ist selten ein einzelner Boolean. Man muss wissen:

• Sind beide Seiten erreichbar?
• Hängen die Daten hinterher?
• Gibt es Konflikteinträge?
• Gibt es festhängende Updates?
• Sind die Replication Agreements gesund?

Die meisten Legacy-Systeme legen das nicht in Prometheus-nativen Formaten offen. Ein Exporter muss deshalb domänenspezifischen Zustand in Prometheus-freundliche Gauges und Counter übersetzen, statt bloß bestehende Metriken zu mappen.

Das ist nicht trivial. Mit dem Scrapen von /metrics ist es hier nicht getan, man muss APIs befragen, Antworten parsen und entscheiden, was „gesund" bedeutet. Das ist Engineering.

Community-Energie ist die eigentliche Belohnung

Großes Trara gab es keins, dafür etwas Besseres. Jemand, der einen „How-to-FreeIPA"-Artikel schrieb, und zwar nicht einmal auf Englisch, bot an, den Exporter zu erwähnen. Der Autor antwortete mit „Mach ich!" und „Gern geschehen!" und hoffte, dass es nützlich ist.

So dreht sich das Open-Source-Schwungrad. Eine Person löst ein Nischenproblem, eine andere dokumentiert FreeIPA für ein Homelab, und der Exporter wird zur Fußnote. Dann setzt ihn vielleicht jemand anderes in Produktion ein, fügt Metriken hinzu oder fixt einen Bug. Ein Marketing-Team oder eine Launch-Ankündigung gibt es nicht, der praktische Nutzen verbreitet sich von selbst.

Warum es noch immer wichtig ist, den eigenen Exporter zu bauen

Im Zeitalter von Hersteller-Integrationen und vorgefertigten Dashboards vergisst man leicht, dass Exporter einfach nur Code sind. Heilig oder magisch sind sie nicht, sie sind Übersetzungsschichten.

Gibt es für das eigene System keine Übersetzungsschicht, bleiben drei Optionen:

1. Observability ignorieren.
2. Sich mit einem Hack behelfen.
3. Es richtig bauen.

Die dritte Option fühlt sich zunächst nach Overkill an, bis man um 2 Uhr nachts ein Replikationsproblem debuggt und tatsächlich Metriken hat. Dann fühlt sie sich heroisch an.

Exporter sind der eigentliche Klebstoff des Ökosystems

Die Stärke von Prometheus liegt neben der TSDB vor allem in den Exportern, diesem Ökosystem kleiner, fokussierter Binaries, die Metriken offenlegen von:

• Datenbanken
• Queues
• Hypervisoren
• Load Balancern
• Identitätssystemen
• irgendwelchen internen Diensten

Jeder Exporter ist ein kleiner Übersetzungsakt. Wenn jemand einen für FreeIPA schreibt, holt das eine weitere Ecke der Infrastruktur, die vorher im Dunkeln lag, in dieses Ökosystem. Spektakulär ist das nicht, aber grundlegend.

Der versteckte Wert für Homelabs und kleine Teams

Der Thread deutet noch auf etwas anderes hin, nämlich Homelabs: FreeIPA in Docker, Replikation über zwei Instanzen und Leute, die Tutorials dazu schreiben. Hier geht es nicht nur um Observability im Enterprise-Maßstab, sondern auch um Enthusiasten, die zu Hause Identitätsinfrastruktur aufbauen und dafür ordentliche Metriken wollen.

Genau da glänzen Community-Exporter oft. Herstellern sind Nischen-Setups nicht immer wichtig, und große Unternehmen priorisieren sie vielleicht nicht, einem Engineer mit einem echten Problem aber schon.

Die Philosophie dahinter

„Weil echte Helden ihre eigenen Exporter bauen." Das ist mit einem Augenzwinkern gemeint, aber darunter steckt eine Philosophie: Infrastruktur konsumiert man nicht passiv, man gestaltet sie. Wer von einem System abhängt, sollte es gut genug verstehen, um es zu instrumentieren.

Einen Exporter zu schreiben zwingt dazu:

• die APIs des Systems zu verstehen
• zu definieren, was Gesundheit bedeutet
• zu entscheiden, was eine Metrik verdient
• über Kardinalität nachzudenken
• Labels bewusst zu gestalten

Allein diese Übung vertieft das eigene operative Verständnis, selbst wenn nie jemand anderes den Exporter nutzt.

Nicht jedes Problem braucht einen Hersteller

In der Observability zeichnet sich gerade ein breiterer Trend ab: Plattformen versprechen schlüsselfertige Integrationen für alles. Den Long Tail der Infrastruktur wird es aber immer geben, mit Nischendiensten, internen Tools, Legacy-Systemen, Nebenprojekten und Identitätsservern, die man vor Jahren aufgesetzt und dann vergessen hat.

Mit Exportern holt man diese Systeme ans Licht, und manchmal schreibt man sie am saubersten selbst. Dafür muss man kein Held sein, es reicht, dass einem die Metriken wichtig genug sind. Meistens beginnt genau dort echte operative Reife.