telemetry

Pre-Alpha. This page describes behavior that may change.

Ze can expose internal metrics in Prometheus format over HTTP. The telemetry { prometheus { } } block configures the listener, the HTTP path, and whether the endpoint is active. When enabled, any Prometheus-compatible scraper can collect counters and gauges from Ze without extra exporters.

A minimal setup

telemetry {
    prometheus {
        enabled true;

        server default {
            ip 0.0.0.0;
            port 9273;
        }
    }
}

With this configuration, Ze serves metrics at http://0.0.0.0:9273/metrics.

Configuration reference

Path	Type	Default	Description
telemetry/prometheus/enabled	boolean	false	Enable the Prometheus metrics endpoint.
telemetry/prometheus/server <name>	list	--	Named listen endpoint, keyed by instance name.
telemetry/prometheus/server/ip	ip-address	0.0.0.0	Listen IP address (IPv4 or IPv6).
telemetry/prometheus/server/port	uint16	9273	Listen TCP port.
telemetry/prometheus/path	string	/metrics	HTTP path where metrics are served.

Multiple server entries are supported. Each creates a separate HTTP listener, useful when you need metrics on both a management VRF address and a loopback.

YANG structure

The YANG module ze-telemetry-conf defines the schema:

container telemetry {
    container prometheus {
        leaf enabled    { type boolean; default false; }

        list server {
            key "name";
            leaf name { type string; }
            leaf ip   { type ip-address; default "0.0.0.0"; }
            leaf port { type uint16;     default 9273; }
        }

        leaf path { type string; default "/metrics"; }
    }
}

CLI startup alternative

The --pprof flag starts a Go pprof HTTP server on a given address, but it is separate from the Prometheus endpoint. pprof exposes Go runtime profiling data (goroutines, heap, CPU profiles) and is meant for debugging, not operational monitoring.

ze --pprof :6060

The pprof listener is restricted to loopback addresses for safety. It does not serve Prometheus metrics. For Prometheus metrics, use the telemetry { prometheus { } } configuration block.

What metrics are exposed

The Prometheus endpoint exports counters and gauges from two layers:

• Engine metrics. BGP sessions, prefix counts, message rates, RPKI validation states, forwarding pool utilisation, per-peer overflow depth, system resource usage. These ship with the core binary.
• Plugin-owned metrics. Each Go plugin can register its own counters and gauges through a ConfigureMetrics callback. The plugin keeps ownership of the metric objects and updates them directly. Today, bgp-rib, bgp-watchdog, bgp-rpki, bgp-persist, fib-kernel, and sysrib each ship with their own metric sets exposed on the same endpoint, so a single scrape gets everything.

Metric names follow the ze_{scope}_{subject}_{detail} convention. Counters end in _total, gauges do not. The plugin authoring side is documented under Go plugins — Prometheus metrics. The full catalogue of exposed metrics is in operation/monitoring.md.

A quick test:

curl -s http://127.0.0.1:9273/metrics | head -20

Custom path and port

Override the defaults when the standard /metrics path or port 9273 conflicts with other services on the host:

telemetry {
    prometheus {
        enabled true;
        path "/ze/metrics";

        server mgmt {
            ip 10.255.0.1;
            port 9274;
        }
    }
}

See also

• Overview for the surrounding config model.
• Monitoring for the full list of exposed metrics.
• System for listener configuration patterns.