smokeping_prober, latency monitoring as Prometheus histograms

What the prober measures and what it exports

smokeping_prober is described as a Prometheus style smokeping prober, and the overview says it sends a series of ICMP or UDP pings to a target and records the responses in Prometheus histogram metrics.

That design decision is the whole project. SmokePing, the original tool this is modelled on, is a web application with its own database, its own charting and its own user interface for arranging pings into graphs. This one keeps the measuring and drops the application, exporting what it finds as metrics that Prometheus scrapes. You get the latency and packet loss data in the same system as everything else you monitor, and you get alerting, recording rules and long-term retention without writing them.

The metric names follow the Prometheus conventions, with a smokeping prefix. The README's table lists smokeping_requests_total as a counter of pings, and the histograms carry the duration information. Because the buckets are configurable, the resolution of the latency distribution is your choice rather than a fixed default.

The default bucket list is worth reading because it tells you the intended scale. It runs from 5e-05 up to 26.2144 seconds, in a doubling progression, which is an unusual range for a network latency probe. Almost all of it is below a second, with a handful of coarse buckets above that to catch timeouts and black holes. If your targets are local or on a fast datacentre link, most of your traffic lands in the first few buckets and you are paying for resolution you do not need, and narrowing the list is a normal configuration change.

The project is Apache-2.0 licensed, written in Go, on the master branch, with the last push on 2026-10-11 and releases v0.10.0 in April 2025, v0.11.0 in March 2026 and v0.12.0 in June 2026.

The container image is on Quay rather than Docker Hub, which is a detail worth knowing before you go looking for it in the wrong registry.

Configuration, flags and reloading

The prober takes its targets and parameters from the command line or from a YAML configuration file, and the README gives the file format.

---
targets:
- hosts:
  - host1
  - host2
  interval: 1s # Duration, Default 1s.
  network: ip # One of ip, ip4, ip6. Default: ip (automatic IPv4/IPv6)
  protocol: icmp # One of icmp, udp. Default: icmp (Requires privileged operation)
  size: 56 # Packet data size in bytes. Default 56 (Range: 24 - 65535)
  source: 127.0.1.1 # Souce IP address to use. Default: None (automatic selection)

Each host group takes an optional interval, network and protocol, with the network setting choosing between automatic, ip4 and ip6, and the protocol choosing between icmp and udp. The interval is in Go duration syntax, and the size and source options control the packet itself.

The command line flags mirror this. There is a config.file option for the YAML path, the ping.interval and ping.size flags, and a privileged flag for ICMP mode. The web side has web.listen-address with a default of :9374, a web.telemetry-path of /metrics, and a web.systemd-socket option to use systemd socket activation instead of port listeners on Linux. There is also an experimental web.config.file that can enable TLS or authentication.

The logging flags are conventional, with a severity threshold and a format choice of logfmt or json, which matters if you run more than one of these and want to correlate their output.

The reload behaviour is the part worth noting. The config is read on startup and can be reloaded with the SIGHUP signal, or with an HTTP POST to the URI path /-/reload. That means you can change the target list without restarting the prober and without dropping the metrics history, and the second option is the one to use when the prober runs in a container where sending a signal is awkward.

The hosts are positional arguments, so the simplest invocation is the binary followed by the names to ping, and everything else is configuration.

Privileges, CPU pinning and the container deployment

The operational details are specific and they matter.

Building requires Go 1.22 or newer. Installing it and granting the capability is two steps:

go install github.com/SuperQ/smokeping_prober@latest
sudo setcap cap_net_raw=+ep ${GOPATH}/bin/smokeping_prober

The setcap call grants the capability to open raw sockets, which is what unprivileged ICMP needs, and there is a --privileged flag for running the whole thing with privileges instead. The README notes that the ICMP protocol requires privileged operation, and the UDP protocol is the alternative when you cannot get it.

The CPU advice is the part that surprises people. On multi-cpu systems it is typically more efficient to limit the prober to one CPU in order to reduce the number of cross-cpu context switches and packet copies from the kernel to the prober, which is done with the GOMAXPROCS environment variable or with container cgroup limits:

export GOMAXPROCS=1
./smokeping_prober <targets>

The reason is that each ping is a packet in and a packet out, and the kernel hands it to whichever thread is polling. With several threads polling the raw socket, the packet gets copied to a thread on a different core than the one doing the work, and the context switch cost dominates. Pinning to one core means the packet is delivered to the thread that is already waiting for it.

The Docker form carries the same advice:

docker run \
  -p 9374:9374 \
  --privileged \
  --env GOMAXPROCS=1 \
  quay.io/superq/smokeping-prober:latest \
  some-ping-target.example.com

Note that the container needs --privileged, which is broader than the setcap approach on the host. Where you can, the binary with a file capability is the better option, because the container form grants the process more than it needs.

One thing you will need to decide is what the exposed port serves, since the metrics path and the web interface share it. The web.listen-address flag is repeatable, so you can bind the metrics to one interface and the web interface to another, which matters if the web interface is a view of the live ping data and you do not want that reachable from everywhere.

How it fits against the alternatives

The direct alternative is SmokePing itself, and the difference is where the data lives. SmokePing is a complete application with a database, a web interface for arranging graphs and its own alerting. It is a good fit when you want a dedicated latency monitoring system with a UI you do not have to build. The cost is a second system to run, a second place to look when something is down, and a second set of alerts to maintain.

The other alternative is doing it with the node_exporter and ICMP or blackbox exporter. Those are the standard Prometheus components for exactly this job, and the blackbox exporter in particular supports ICMP, TCP and HTTP probes. The difference is that the exporter model is one probe process per target, orchestrated by Prometheus itself, while smokeping_prober is a single process that takes a list of targets and exports a histogram per target. For a handful of targets the exporter model is simpler and better integrated; for a few hundred targets, a single prober with one connection to Prometheus is a lot less configuration.

A third option is a synthetic monitoring service, which is what most commercial products are. The difference is that the measurement runs in your network rather than in the vendor's, which is the point for internal latency but also means you run it.

The case for this tool is specific and it is about the histogram. Exporting latency as a Prometheus histogram rather than as a gauge of the last ping means you can compute percentiles across a window, alert on a sustained degradation rather than a single spike, and see a distribution rather than a number. The bucket list is configurable, so the resolution is yours to choose.

The costs are the ones already listed. It needs privileges, so it is not something you run in an unprivileged Kubernetes pod without thinking. The packet loss measurement is the interesting part, because a ping that gets no reply is indistinguishable from a host that is down, and the histogram alone does not tell you which. That distinction is what a full network monitoring tool gives you and what a Prometheus-style prober does not, so a team that needs to tell the two apart needs something else as well.

It is also a monitoring component, not a monitoring system. There is no dashboard, no alert manager and no history beyond what Prometheus keeps for you, which is the trade for fitting into the stack you already run.

Editorial conclusion

Adopt smokeping_prober if you want network latency and packet loss as Prometheus metrics alongside your application metrics, and you are willing to run a component that needs raw socket privileges. Skip it if you already run a full network monitoring stack with its own time series storage and alerting. Verify first by starting it against a handful of targets with the setcap step applied, then scraping the metrics endpoint and checking the histogram buckets are populated and the target list is being reloaded as you expect.

Frequently asked questions

Official sources

1. Issues
2. License: Apache-2.0
3. README
4. Releases
5. SuperQ/smokeping_prober on GitHub