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.
Sie haben kube-state-metrics zum Laufen gebracht.
Sie haben ein halbes Dutzend Community-Exporter eingebunden.
Und dann schauen Sie auf ein stures System, das in der Ecke Ihrer Infrastruktur sitzt, still seine wichtige Arbeit verrichtet … ohne jegliche Metriken.
Genau dort beginnt diese Geschichte.
Jemand hat FreeIPA entstaubt. Bemerkt, dass Metriken fehlten. Und anstatt darauf zu warten, dass der „perfekte" Exporter auftaucht, haben sie getan, was Engineers seit Jahren still und leise tun:
Sie haben ihren eigenen geschrieben.
FreeIPA ist nicht sexy — aber kritisch
FreeIPA steht normalerweise nicht im Rampenlicht von Observability-Vorträgen.
Es ist LDAP. Identität. Kerberos. Replikation. Zertifikate. Die Verrohrung hinter Authentifizierungs-Flows, über die die meisten Leute nie nachdenken, bis sie kaputtgeht.
Und wenn sie kaputtgeht, geht sie richtig kaputt.
In diesem Fall war FreeIPA schon vorher im Einsatz – 2015, für ein LDAP-basiertes Projekt. Vorspulen bis heute: zwei über Docker bereitgestellte Instanzen, Replikation im Spiel, und plötzlich besteht die Notwendigkeit, die Gesundheit dieser Replikation tatsächlich zu überwachen.
Das ist der Moment, in dem Dashboards von „nice to have" zu „warum haben wir das nicht längst?" werden.
Replikationsprobleme in Identitätssystemen sind nicht kosmetisch. Sie sind Ausfälle, die nur darauf warten zu passieren.
Der Exporter-Instinkt
Es gibt eine bestimmte Art von Engineer-Reaktion auf fehlende Metriken.
Manche eröffnen ein GitHub-Issue.
Manche suchen nach Forks.
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 wurde freeipa-exporter geboren.
Nicht, weil jemand ein Produkt starten wollte.
Nicht, weil sie GitHub-Stars hinterherjagten.
Weil sie Observability brauchten.
„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.
Bevor man sich versieht, hat man eine umfassende Telemetrie-Schicht gebaut.
Ist das übertrieben?
Vielleicht.
Ist es befriedigend?
Absolut.
Und in diesem Fall gibt der Autor offen zu, dass es ein guter Vorwand war, mal wieder etwas mit Programmieren zu tun zu haben – und dass es sich einfach cool angefühlt hat.
Diese Freude zählt mehr, als wir in der Infrastrukturarbeit zugeben.
Die eigentliche Herausforderung: Replikation überwachen
Der Autor nennt die Replikationsüberwachung explizit als die Hauptherausforderung.
Wer schon mit LDAP oder Verzeichnisdiensten gearbeitet hat, weiß warum.
Replikation ist selten ein einzelner Boolean.
Es ist:
- Sind beide Seiten erreichbar?
- Hängen die Daten hinterher?
- Gibt es Konflikteinträge?
- Gibt es festhängende Updates?
- Sind die Replication Agreements gesund?
Und die meisten Legacy-Systeme legen das nicht in Prometheus-nativen Formaten offen.
Einen Exporter zu bauen bedeutet also nicht nur, bestehende Metriken zu mappen.
Es geht darum, domänenspezifischen Zustand in Prometheus-freundliche Gauges und Counter zu übersetzen.
Das ist nicht trivial.
Hier wird nicht einfach /metrics gescraped.
Hier werden APIs befragt, Antworten geparst und entschieden, was „gesund" bedeutet.
Das ist Engineering.
Community-Energie ist die eigentliche Belohnung
Die Reaktion war kein großes Trara.
Es war etwas Besseres.
Jemand, der einen „How-to-FreeIPA"-Artikel schrieb, bot an, den Exporter zu erwähnen. Nicht einmal auf Englisch.
Die Antwort des Autors?
„Mach ich!"
„Gern geschehen!"
Hoffe, es ist nützlich.
Das ist das Open-Source-Schwungrad in Bewegung.
Eine Person löst ein Nischenproblem.
Eine andere Person dokumentiert FreeIPA für ein Homelab.
Der Exporter wird zur Fußnote.
Dann setzt ihn vielleicht jemand anderes in Produktion ein.
Vielleicht fügen sie Metriken hinzu.
Vielleicht fixen sie einen Bug.
Es gibt kein Marketing-Team.
Keine Launch-Ankündigung.
Nur praktischer Nutzen, der sich still verbreitet.
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.
Sie sind nicht heilig.
Sie sind nicht magisch.
Sie sind Übersetzungsschichten.
Und wenn es für das eigene System keine Übersetzungsschicht gibt, gibt es drei Optionen:
- Observability ignorieren.
- Sich mit einem Hack behelfen.
- 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 zur Verfügung hat.
Dann fühlt es sich heroisch an.
Exporter sind der eigentliche Klebstoff des Ökosystems
Prometheus' Stärke liegt nicht nur in der TSDB.
Sie liegt in den Exportern.
Dieses Ökosystem kleiner, fokussierter Binaries, die Metriken offenlegen von:
- Datenbanken
- Queues
- Hypervisoren
- Load Balancern
- Identitätssystemen
- Irgendwelchen internen Diensten
Jeder Exporter ist ein kleiner Übersetzungsakt.
Und wenn jemand einen für FreeIPA schreibt, erweitert das dieses Ökosystem um eine weitere Ecke der Infrastruktur, die vorher im Dunkeln lag.
Das ist nicht spektakulär.
Aber es ist fundamental.
Der versteckte Wert für Homelabs und kleine Teams
Der Thread deutet auf noch etwas anderes hin: Homelabs.
FreeIPA in Docker.
Replikation über zwei Instanzen.
Leute, die Tutorials schreiben.
Das ist nicht nur Observability im Enterprise-Maßstab.
Es sind Enthusiasten, die zu Hause Identitätsinfrastruktur aufbauen und dafür ordentliche Metriken wollen.
Und genau da glänzen Community-Exporter oft.
Herstellern sind Nischen-Setups nicht immer wichtig.
Große Unternehmen priorisieren sie vielleicht nicht.
Aber ein Engineer mit einem echten Problem schon.
Die subtile Philosophie dahinter
„Weil echte Helden ihre eigenen Exporter bauen."
Das ist mit einem Augenzwinkern gemeint.
Aber darunter steckt eine Philosophie.
Infrastruktur ist nichts, das man passiv konsumiert.
Es ist etwas, das man gestaltet.
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 eigenen Exporter nutzt.
Nicht jedes Problem braucht einen Hersteller
Es gibt gerade einen breiteren Trend in der Observability.
Plattformen versprechen schlüsselfertige Integration für alles.
Aber der Long Tail der Infrastruktur wird immer existieren.
Nischendienste.
Interne Tools.
Legacy-Systeme.
Nebenprojekte.
Identitätsserver, die man vor Jahren aufgesetzt und dann vergessen hat.
Exporter sind der Weg, diese Systeme ans Licht zu bringen.
Und manchmal ist der sauberste Weg dahin, es selbst zu schreiben.
Nicht, weil man ein Held ist.
Weil es einem wichtig genug ist, die Metriken zu sehen.
Und genau da beginnt meist echte operative Reife.