// the find
prometheus/blackbox_exporter
Blackbox prober exporter
Blackbox exporter is the Prometheus-native way to do synthetic monitoring — you point it at HTTP endpoints, DNS names, TCP ports, ICMP targets, or gRPC services, and it exports probe results as Prometheus metrics. It fits into any existing Prometheus setup with no extra tooling, and the multi-target pattern means one exporter instance handles hundreds of targets via relabeling.
The multi-target exporter pattern is implemented correctly — targets come in via query params rather than being baked into config, so you can dynamically expand targets from service discovery without restarting anything. The dual-logger architecture (separate prober log vs. application log, independently configurable) is genuinely useful when you need to debug a single failing probe without drowning in noise. Hot config reload via SIGHUP or HTTP POST, plus optional auto-reload polling, means you can update probe definitions in production without downtime. The debug=true query param that returns probe logs inline with the metrics scrape is one of the better debugging UX choices in the Prometheus ecosystem.
ICMP requires elevated privileges (CAP_NET_RAW or root on Linux, full Administrator on Windows) — in containerized environments this often means a privileged pod, which security teams will push back on hard. The configuration file is flat YAML with no concept of inheritance or templating, so if you have 50 nearly-identical HTTP probe modules differing only by auth headers, you're repeating yourself 50 times. There's no built-in probe history or trend data — you get pass/fail and timing right now, and if you want to answer 'how often did this fail last week', you're entirely dependent on your Prometheus retention. gRPC probing is limited to health checks via the standard gRPC health protocol; if your service doesn't implement that, gRPC probing is essentially useless.