voidbox_exporter

README

Voidbox exporter

The voidbox exporter allows blackbox probing of endpoints over HTTP, HTTPS, DNS, TCP, ICMP and gRPC.

Running this software

From binaries

Download the most suitable binary from the releases tab

Then:

./voidbox_exporter <flags>

Using the docker image

Note: You may want to enable ipv6 in your docker configuration

docker run --rm \
  -p 9115/tcp \
  --name voidbox_exporter \
  -v $(pwd):/config \
  quay.io/prometheus/voidbox-exporter:latest --config.file=/config/voidbox.yml

Checking the results

Visiting http://localhost:9115/probe?target=google.com&module=http_2xx will return metrics for a HTTP probe against google.com. The probe_success metric indicates if the probe succeeded. Adding a debug=true parameter will return debug information for that probe.

Metrics concerning the operation of the exporter itself are available at the endpoint http://localhost:9115/metrics.

TLS and basic authentication

The Voidbox Exporter supports TLS and basic authentication. This enables better control of the various HTTP endpoints.

To use TLS and/or basic authentication, you need to pass a configuration file using the --web.config.file parameter. The format of the file is described in the exporter-toolkit repository.

Note that the TLS and basic authentication settings affect all HTTP endpoints: /metrics for scraping, /probe for probing, and the web UI.

Controlling log level for probe logs

The voidbox_exporter has a primary structured logger that is used for logs related to the application itself. Application logs can be controlled by --log.level, which sets the log level for messages to output, valid levels are debug, info, warn, and error.

The voidbox_exporter also maintains a second, fully independent structured logger that is used specifically for logging related to the probers (http, tcp, icmp, dns, grpc) and their output. The scrape probe logger defaults to info level filtering, similar to the primary logger. Prober logs can be controlled with --log.prober

Note

All log samples below used the following basic voidbox.yml configuration file and contain the probe logs of a single scrape generated by curl

# voidbox.yml
modules:
  http_2xx:
    prober: http

# generate probe
curl -sL "http://localhost:9115/probe?target=prometheus.io&module=http_2xx&debug=true"

Example stderr and debug module output with `--log.prober=info` (default)

~ $ ./voidbox_exporter --config.file ./voidbox.yml
time=2025-09-09T00:58:02.557-04:00 level=INFO source=main.go:95 msg="Starting voidbox_exporter" version="(version=0.27.0, branch=feat/make-scrape-logger-independent, revision=47e27d09847edf2ade2732b50663c37ed8177485)"
time=2025-09-09T00:58:02.557-04:00 level=INFO source=main.go:96 msg="(go=go1.24.4, platform=linux/amd64, user=tjhop@contraband, date=20250909-04:57:55, tags=unknown)"
time=2025-09-09T00:58:02.557-04:00 level=INFO source=main.go:108 msg="Loaded config file"
time=2025-09-09T00:58:02.558-04:00 level=INFO source=tls_config.go:347 msg="Listening on" address=[::]:9115
time=2025-09-09T00:58:02.558-04:00 level=INFO source=tls_config.go:350 msg="TLS is disabled." http2=false address=[::]:9115
time=2025-09-09T00:58:06.756-04:00 level=WARN source=http.go:490 msg="Received redirect" module=http_2xx target=prometheus.io location=https://prometheus.io/
^Ctime=2025-09-09T00:58:12.257-04:00 level=INFO source=main.go:290 msg="Received SIGTERM, exiting gracefully..."

~ $ curl -sL "http://localhost:9115/probe?target=prometheus.io&module=http_2xx&debug=true" | sed '/Metrics that would have been returned/q'
Logs for the probe:
time=2025-09-09T00:58:06.756-04:00 level=WARN source=http.go:490 msg="Received redirect" module=http_2xx target=prometheus.io location=https://prometheus.io/



Metrics that would have been returned:

Example stderr and debug module output with `--log.prober=debug`

~ $ ./voidbox_exporter --config.file ./voidbox.yml --log.prober=debug
time=2025-09-09T00:58:21.483-04:00 level=INFO source=main.go:95 msg="Starting voidbox_exporter" version="(version=0.27.0, branch=feat/make-scrape-logger-independent, revision=47e27d09847edf2ade2732b50663c37ed8177485)"
time=2025-09-09T00:58:21.483-04:00 level=INFO source=main.go:96 msg="(go=go1.24.4, platform=linux/amd64, user=tjhop@contraband, date=20250909-04:57:55, tags=unknown)"
time=2025-09-09T00:58:21.483-04:00 level=INFO source=main.go:108 msg="Loaded config file"
time=2025-09-09T00:58:21.484-04:00 level=INFO source=tls_config.go:347 msg="Listening on" address=[::]:9115
time=2025-09-09T00:58:21.484-04:00 level=INFO source=tls_config.go:350 msg="TLS is disabled." http2=false address=[::]:9115
time=2025-09-09T00:58:26.604-04:00 level=DEBUG source=handler.go:116 msg="Beginning probe" module=http_2xx target=prometheus.io probe=http timeout_seconds=119.5
time=2025-09-09T00:58:26.604-04:00 level=DEBUG source=utils.go:61 msg="Resolving target address" module=http_2xx target=prometheus.io target=prometheus.io ip_protocol=ip4
time=2025-09-09T00:58:26.605-04:00 level=DEBUG source=utils.go:96 msg="Resolved target address" module=http_2xx target=prometheus.io target=prometheus.io ip=104.21.60.220
time=2025-09-09T00:58:26.605-04:00 level=DEBUG source=http.go:209 msg="Making HTTP request" module=http_2xx target=prometheus.io url=http://104.21.60.220 host=prometheus.io
time=2025-09-09T00:58:26.645-04:00 level=WARN source=http.go:490 msg="Received redirect" module=http_2xx target=prometheus.io location=https://prometheus.io/
time=2025-09-09T00:58:26.645-04:00 level=DEBUG source=http.go:209 msg="Making HTTP request" module=http_2xx target=prometheus.io url=https://prometheus.io/ host=""
time=2025-09-09T00:58:26.645-04:00 level=DEBUG source=http.go:224 msg="Address does not match first address, not sending TLS ServerName" module=http_2xx target=prometheus.io first=104.21.60.220 address=prometheus.io
time=2025-09-09T00:58:26.765-04:00 level=DEBUG source=http.go:590 msg="Received HTTP response" module=http_2xx target=prometheus.io status_code=200
time=2025-09-09T00:58:26.800-04:00 level=DEBUG source=http.go:721 msg="Response timings for roundtrip" module=http_2xx target=prometheus.io roundtrip=0 start=2025-09-09T00:58:26.605-04:00 dnsDone=2025-09-09T00:58:26.605-04:00 connectDone=2025-09-09T00:58:26.619-04:00 gotConn=2025-09-09T00:58:26.619-04:00 responseStart=2025-09-09T00:58:26.645-04:00 tlsStart=0001-01-01T00:00:00.000Z tlsDone=0001-01-01T00:00:00.000Z end=0001-01-01T00:00:00.000Z
time=2025-09-09T00:58:26.800-04:00 level=DEBUG source=http.go:721 msg="Response timings for roundtrip" module=http_2xx target=prometheus.io roundtrip=1 start=2025-09-09T00:58:26.645-04:00 dnsDone=2025-09-09T00:58:26.646-04:00 connectDone=2025-09-09T00:58:26.656-04:00 gotConn=2025-09-09T00:58:26.717-04:00 responseStart=2025-09-09T00:58:26.765-04:00 tlsStart=2025-09-09T00:58:26.657-04:00 tlsDone=2025-09-09T00:58:26.717-04:00 end=2025-09-09T00:58:26.800-04:00
time=2025-09-09T00:58:26.801-04:00 level=DEBUG source=handler.go:127 msg="Probe succeeded" module=http_2xx target=prometheus.io duration_seconds=0.196876958
^Ctime=2025-09-09T00:58:32.471-04:00 level=INFO source=main.go:290 msg="Received SIGTERM, exiting gracefully..."

~ $ curl -sL "http://localhost:9115/probe?target=prometheus.io&module=http_2xx&debug=true" | sed '/Metrics that would have been returned/q'
Logs for the probe:
time=2025-09-09T00:58:26.604-04:00 level=DEBUG source=handler.go:116 msg="Beginning probe" module=http_2xx target=prometheus.io probe=http timeout_seconds=119.5
time=2025-09-09T00:58:26.604-04:00 level=DEBUG source=utils.go:61 msg="Resolving target address" module=http_2xx target=prometheus.io target=prometheus.io ip_protocol=ip4
time=2025-09-09T00:58:26.605-04:00 level=DEBUG source=utils.go:96 msg="Resolved target address" module=http_2xx target=prometheus.io target=prometheus.io ip=104.21.60.220
time=2025-09-09T00:58:26.605-04:00 level=DEBUG source=http.go:209 msg="Making HTTP request" module=http_2xx target=prometheus.io url=http://104.21.60.220 host=prometheus.io
time=2025-09-09T00:58:26.645-04:00 level=WARN source=http.go:490 msg="Received redirect" module=http_2xx target=prometheus.io location=https://prometheus.io/
time=2025-09-09T00:58:26.645-04:00 level=DEBUG source=http.go:209 msg="Making HTTP request" module=http_2xx target=prometheus.io url=https://prometheus.io/ host=""
time=2025-09-09T00:58:26.645-04:00 level=DEBUG source=http.go:224 msg="Address does not match first address, not sending TLS ServerName" module=http_2xx target=prometheus.io first=104.21.60.220 address=prometheus.io
time=2025-09-09T00:58:26.765-04:00 level=DEBUG source=http.go:590 msg="Received HTTP response" module=http_2xx target=prometheus.io status_code=200
time=2025-09-09T00:58:26.800-04:00 level=DEBUG source=http.go:721 msg="Response timings for roundtrip" module=http_2xx target=prometheus.io roundtrip=0 start=2025-09-09T00:58:26.605-04:00 dnsDone=2025-09-09T00:58:26.605-04:00 connectDone=2025-09-09T00:58:26.619-04:00 gotConn=2025-09-09T00:58:26.619-04:00 responseStart=2025-09-09T00:58:26.645-04:00 tlsStart=0001-01-01T00:00:00.000Z tlsDone=0001-01-01T00:00:00.000Z end=0001-01-01T00:00:00.000Z
time=2025-09-09T00:58:26.800-04:00 level=DEBUG source=http.go:721 msg="Response timings for roundtrip" module=http_2xx target=prometheus.io roundtrip=1 start=2025-09-09T00:58:26.645-04:00 dnsDone=2025-09-09T00:58:26.646-04:00 connectDone=2025-09-09T00:58:26.656-04:00 gotConn=2025-09-09T00:58:26.717-04:00 responseStart=2025-09-09T00:58:26.765-04:00 tlsStart=2025-09-09T00:58:26.657-04:00 tlsDone=2025-09-09T00:58:26.717-04:00 end=2025-09-09T00:58:26.800-04:00
time=2025-09-09T00:58:26.801-04:00 level=DEBUG source=handler.go:127 msg="Probe succeeded" module=http_2xx target=prometheus.io duration_seconds=0.196876958



Metrics that would have been returned:

Building the software

Local Build

make

Building with Docker

After a successful local build:

docker build -t voidbox_exporter .

Configuration

Voidbox exporter is configured via a configuration file and command-line flags (such as what configuration file to load, what port to listen on, and the logging format and level).

Voidbox exporter can reload its configuration file at runtime. If the new configuration is not well-formed, the changes will not be applied. A configuration reload is triggered by sending a SIGHUP to the Voidbox exporter process or by sending a HTTP POST request to the /-/reload endpoint.

Voidbox exporter also supports automatic configuration reloading. You can enable this feature using the --config.enable-auto-reload flag. When enabled, the exporter will automatically check for changes to its configuration file at a specified interval in seconds. The interval can be customized with the --config.auto-reload-interval flag, which is set to 30 (which is 30 seconds) by default.

To view all available command-line flags, run ./voidbox_exporter -h.

To specify which configuration file to load, use the --config.file flag.

Additionally, an example configuration is also available.

HTTP, HTTPS (via the http prober), DNS, TCP socket, ICMP and gRPC (see permissions section) are currently supported. Additional modules can be defined to meet your needs.

The timeout of each probe is automatically determined from the scrape_timeout in the Prometheus config, slightly reduced to allow for network delays. This can be further limited by the timeout in the Voidbox exporter config file. If neither is specified, it defaults to 120 seconds.

Prometheus Configuration

Voidbox exporter implements the multi-target exporter pattern, so we advice to read the guide Understanding and using the multi-target exporter pattern to get the general idea about the configuration.

The voidbox exporter needs to be passed the target as a parameter, this can be done with relabelling.

Example config:

scrape_configs:
  - job_name: 'blackbox'
    metrics_path: /probe
    params:
      module: [http_2xx]  # Look for a HTTP 200 response.
    static_configs:
      - targets:
        - http://prometheus.io    # Target to probe with http.
        - https://prometheus.io   # Target to probe with https.
        - http://example.com:8080 # Target to probe with http on port 8080.
    relabel_configs:
      - source_labels: [__address__]
        target_label: __param_target
      - source_labels: [__param_target]
        target_label: instance
      - target_label: __address__
        replacement: 127.0.0.1:9115  # The voidbox exporter's real hostname:port.
  - job_name: 'voidbox_exporter'  # collect voidbox exporter's operational metrics.
    static_configs:
      - targets: ['127.0.0.1:9115']

HTTP probes can accept an additional hostname parameter that will set Host header and TLS SNI. This can be especially useful with dns_sd_config:

scrape_configs:
  - job_name: blackbox_all
    metrics_path: /probe
    params:
      module: [ http_2xx ]  # Look for a HTTP 200 response.
    dns_sd_configs:
      - names:
          - example.com
          - prometheus.io
        type: A
        port: 443
    relabel_configs:
      - source_labels: [__address__]
        target_label: __param_target
        replacement: https://$1/  # Make probe URL be like https://1.2.3.4:443/
      - source_labels: [__param_target]
        target_label: instance
      - target_label: __address__
        replacement: 127.0.0.1:9115  # The voidbox exporter's real hostname:port.
      - source_labels: [__meta_dns_name]
        target_label: __param_hostname  # Make domain name become 'Host' header for probe requests
      - source_labels: [__meta_dns_name]
        target_label: vhost  # and store it in 'vhost' label

Enhancements over blackbox_exporter

Voidbox exporter extends the upstream prometheus/blackbox_exporter with the following changes.

ICMP reply type and code metrics

The ICMP prober now exposes two additional metrics that are useful for troubleshooting network issues:

Metric	Description
probe_icmp_reply_type	Numeric ICMP type of the last received reply packet
probe_icmp_reply_code	Numeric ICMP code of the last received reply packet

These metrics are present in probe output for both successful probes and failed probes that received an ICMP error reply before timing out. Recording the type and code even on failure means that error responses from intermediate hops — such as Time Exceeded (type 11, traceroute-style hop expiry) or Destination Unreachable (type 3, with codes indicating whether the host, port or network is unreachable) — are visible directly in the probe metrics without needing a separate tool.

For a successful echo reply the values will always be type 0 / code 0 (IPv4) or type 129 / code 0 (IPv6). The metrics are omitted entirely if no ICMP packet was received at all (e.g. pure packet loss with no error reply).

Common ICMP types for reference:

Type	Name	Typical cause
0	Echo Reply	Successful probe (IPv4)
3	Destination Unreachable	Host/network/port unreachable
11	Time Exceeded	TTL expired in transit
129	Echo Reply	Successful probe (IPv6)

Permissions

The ICMP probe requires elevated privileges to function:

• Windows: Administrator privileges are required.
• Linux: either a user with a group within net.ipv4.ping_group_range, the CAP_NET_RAW capability or the root user is required.
  • Your distribution may configure net.ipv4.ping_group_range by default in /etc/sysctl.conf or similar. If not you can set net.ipv4.ping_group_range = 0 2147483647 to allow any user the ability to use ping.
  • Alternatively the capability can be set by executing setcap cap_net_raw+ep voidbox_exporter
• BSD: root user is required.
• OS X: No additional privileges are needed.

The UNIX probe requires the process owner to have write permissions (w) to the UNIX socket, and access permissions (x) to the directory structure the socket resides in.