Why Building Your Own Prometheus Exporter Can Be the Right Move
Every Prometheus setup reaches the same point. You have node-exporter wired up, kube-state-metrics running and half a dozen community exporters pulled in, and then you notice one stubborn system in the corner of your infrastructure doing important work with zero metrics.
In this case the system was FreeIPA. Someone dusted it off, realized the metrics were missing, and instead of waiting for the "perfect" exporter to appear, did what engineers have done for years: they wrote their own.
FreeIPA isn't glamorous, but it's critical
FreeIPA rarely headlines observability talks. It covers LDAP, identity, Kerberos, replication and certificates, the plumbing behind authentication flows that most people never think about until it breaks. When it does break, it breaks badly.
The author had used FreeIPA before, back in 2015 for an LDAP-backed project. This time there were two instances deployed via Docker with replication between them, and a real need to monitor replication health. At that point the question changes from whether dashboards would be nice to have to why you don't have them already, because replication problems in an identity system are outages waiting to happen.
The exporter instinct
Engineers react to missing metrics in different ways. Some open a GitHub issue, some search for forks, and some duct-tape shell scripts to cron jobs. Others have the exporter instinct: if it doesn't exist, build it.
That is how freeipa-exporter started. The author wasn't trying to launch a product or collect GitHub stars. They needed observability.
"Maybe I went a bit overboard"
The author's own line says a lot, and anyone who has built an exporter knows the slippery slope. You start with basic health checks, a few gauges and maybe replication status. Then you think "while I'm here" and add LDAP stats, some Kerberos counters, certificate validity, user counts and replication lag per peer. Before long you have built a full telemetry layer.
Is that overboard? Maybe, and it is also deeply satisfying. The author openly said it was a great excuse to do something programming-related again and that it felt cool. That kind of enjoyment matters more in infrastructure work than most of us admit.
Monitoring replication was the hard part
The author called out replication monitoring as the main challenge, and anyone who has worked with LDAP or directory systems knows why. Replication health is rarely a single boolean. You need to know:
- Are both sides reachable?
- Is data lagging?
- Are there conflict entries?
- Are there stuck updates?
- Are replication agreements healthy?
Most legacy systems don't expose any of that in a Prometheus-native format, so building the exporter means translating domain-specific state into Prometheus gauges and counters. There is no /metrics endpoint to scrape. You interrogate APIs, parse the responses and decide what "healthy" means, which is real engineering work.
Community energy is the reward
The response was small and friendly. Someone writing a "how to FreeIPA" article, in a language other than English, offered to mention the exporter. The author replied "Will do!" and "You are welcome!" and said they hoped it would be useful.
That is how open source spreads. One person solves a niche problem, another documents FreeIPA for a homelab, and the exporter becomes a footnote in that guide. Later someone might deploy it in production, add metrics or fix a bug. There is no marketing team and no launch announcement, only a useful tool finding its way to the people who need it.
Why building your own exporter still matters
With vendor integrations and prebuilt dashboards everywhere, it's easy to forget that exporters are just code. They are translation layers, and there is nothing sacred or magical about them. When no translation layer exists for your system, you have three options:
- Ignore observability.
- Hack around it.
- Build it properly.
The third option feels like overkill at first, until you are debugging a replication issue at 2AM and actually have metrics. Then it feels heroic.
Exporters are the glue of the ecosystem
Much of Prometheus's power comes from its exporters as well as from the TSDB: the ecosystem of small, focused binaries that expose metrics from databases, queues, hypervisors, load balancers, identity systems and random internal services. Each one translates a system into metrics. Writing one for FreeIPA extends that ecosystem into a corner of infrastructure that had no visibility before. The work is unglamorous, and a lot rests on it.
The hidden value for homelabs and small teams
The thread also points at homelabs: FreeIPA in Docker, replication across two instances, and people writing tutorials about it. These are enthusiasts building identity infrastructure at home and wanting proper metrics for it, which is where community exporters often shine. Vendors don't always care about niche setups and large companies may not prioritize them, but an engineer with a real problem will.
The philosophy behind the joke
"Because real heroes build their own exporters" is tongue-in-cheek, but there is a real idea under it. You shape infrastructure as much as you consume it, and if you depend on a system, you should understand it well enough to instrument it. Writing an exporter forces you to:
- Understand the system's APIs.
- Define what health means.
- Decide what deserves to be a metric.
- Think about cardinality.
- Design labels intentionally.
That exercise deepens your operational awareness even if nobody else ever uses your exporter.
Not every problem needs a vendor
Observability platforms promise turnkey integration for everything, yet the long tail of infrastructure will always exist: niche services, internal tools, legacy systems, side projects, and identity servers you stood up years ago and forgot about. Exporters are how those systems become visible, and sometimes the cleanest way to get one is to write it yourself because you care enough to see the metrics. That is usually where operational maturity starts.