Skip to main content
Hivenet Router exports router, agent, inference-engine, hardware, policy, quota, and HTTP metrics in Prometheus format.
The metrics server runs separately from the main HTTP API and listens on port 2112 by default.
The metrics endpoint does not have built-in authentication.Restrict it to Prometheus and trusted operators through a private network, firewall, reverse proxy, or equivalent network control.

Start the metrics server

The router starts the Prometheus endpoint automatically. The default address is:
Change it with:
The metrics endpoint is then available at:

Configure Prometheus

A minimal scrape configuration is:
Reload Prometheus after changing its configuration. With the repository’s Docker Compose stack, Prometheus reaches the router through the internal Compose network:
Port 2112 does not need to be published to the host when Prometheus runs in the same Compose network.

Check the scrape target

From the Prometheus interface, open:
Or query the Prometheus API:
A healthy target reports:
Check that Hivenet Router metrics exist:

How metrics reach the router

Prometheus scrapes only the router. Agents send operational information to the router through:
  • frequent routing-signal updates
  • periodic heartbeats
  • request outcomes
The router then exposes this information through its own Prometheus registry. You do not need to configure Prometheus to scrape every agent directly. For supported engines, each agent scrapes its local backend’s /metrics endpoint and forwards the resulting values to the router.

Metric groups

Metric labels and cardinality

Several metrics include labels such as:
  • peer_id
  • model
  • tenant_id
  • key_id
  • deployment_id
  • organization
  • machine
  • region
  • engine
These labels make operational breakdowns possible, but each distinct label combination creates another Prometheus time series. Admission-control metrics use only model, or reason and model. They do not expose tenant or key identity.
Do not use unbounded or frequently changing values for agent metadata.Values such as machine, organization, region, and deployment_id should remain stable. Avoid putting request IDs, user IDs, timestamps, or other high-cardinality data into agent metadata.

Routing metrics

Registered agents

These gauges use:
as labels.
The value is 1 while an agent is registered. Count registered agents:
Count agents by model:

Agent health

Values are: Count healthy agents by model:
Find unhealthy agents:

Last heartbeat

The value is a Unix timestamp in milliseconds. Show seconds since the most recent heartbeat:

Routed requests

Labels:
Request rate by model:
Request rate by region and engine:

Failed routing

This counts inference requests that the router could not forward successfully. Failure rate:

Per-agent metrics

These metrics use:
as labels.

Successful and failed requests

Request rate by agent:

Success rate

The value ranges from 0.0 to 1.0. Find agents below 95%:
A new agent may not expose a meaningful success rate until it has completed requests.

Capacity utilization

The value is:
For non-streaming requests, the slot normally remains occupied until the response completes. For streaming requests, the current implementation releases the agent capacity slot when response headers arrive and streaming begins, while backend generation can continue.
Do not use hivenet_router_agent_capacity_utilization as the authoritative count of ongoing streaming generations.For streaming-heavy workloads, compare it with engine running and waiting requests, KV-cache pressure, TTFT, and ITL.
Show agents above 80%:

Tokens

Token rate by model:

Capacity rejections

This increases when Hivenet Router tries to acquire a capacity slot and the agent is already full.

Disconnections and health failures

Compare agent-process and backend failures:

Smoothed latency

These follow the RFC 6298 smoothed round-trip-time calculation. Show SRTT by agent:
Find high or unstable latency:
SRTT reflects the request path observed by Hivenet Router. It includes more than raw network latency.

Persistence and resets

Current agent metadata, health, hardware, and engine snapshots are held in memory. Per-agent lifetime counters and latency history are also stored in BadgerDB and reseeded into Prometheus when an agent registers again. These include:
  • successful and failed request counts
  • input and output tokens
  • capacity rejections
  • disconnections and failure counters
  • SRTT and RTTVAR
The router’s default persistent-entry lifetime is 30 days. Reset these values through:
This clears persisted per-agent lifetime counters, latency history, matching in-memory state, and their Prometheus series.It does not reset tenant quota counters or every router-level metric.

Engine metrics

Engine metrics use:
as labels. Availability depends on the backend: A metric is absent until the agent reports it.

Cache and queue state

Agents under cache pressure:
Agents with backend queues:

Preemptions

Despite the _total suffix, this series is exported as a gauge representing the backend’s latest cumulative value. Use a change function to detect growth:
Do not assume ordinary counter-reset behavior across every backend restart.

Per-agent TTFT and ITL gauges

These are convenient for viewing one agent. For fleet-wide percentiles, use the histogram metrics instead of averaging per-agent percentile gauges.

Finish reasons

Additional label:
For vLLM, common values include:
Completion rate by finish reason:

llama.cpp throughput

These expose the latest reported generation and prompt-ingestion throughput from llama.cpp.

Engine histograms

The current router re-exports raw engine histogram buckets for vLLM agents. SGLang and llama.cpp can contribute scalar average and P90 values, but their raw histogram buckets are not currently re-exported through Hivenet Router. The vLLM-backed histogram families are:
Prometheus exposes each histogram as:

Fleet P90 TTFT

P90 TTFT by model

Fleet P90 ITL

P90 prompt length

P90 generation length

Use histogram_quantile() over aggregated buckets for fleet percentiles.Averaging several per-agent P90 gauges does not produce a valid fleet P90.

GPU metrics

GPU metrics use:
as labels.
Unlike policy gates, the Prometheus utilization value uses a 0 to 100 scale.

GPU utilization

Average utilization by model:

VRAM percentage

Temperature

Power

CPU-only agents do not expose GPU series.

CPU and memory metrics

Labels:
CPU usage:
Memory use:
Available GiB:

Policy metrics

Primary and fallback routing

All use the model label. Local fallback rate by model:
Provider fallback rate:
Policy exhaustion:
This counter describes an exhausted policy path, not one guaranteed final HTTP status. A request can proceed to provider fallback, and a failed provider call can end with a provider or backend error rather than a local 503.

Stale connection resets

Labels:
A sustained rate can indicate repeated router-agent connection loss:

Policy reloads

Labels:
Current values include:
Failed reloads:

Queue metrics

These metrics describe the per-model queue used when eligible agents exist but all declared capacity slots are occupied. They do not describe the router’s global pending-request channel, requests waiting for --max-concurrent, or work already forwarded to a backend.

Current queue depth

Label:

Queue wait duration

P95 queue wait by model:

Tenant and quota metrics

Tenant metrics attribute activity to clients and deployments.

Label defaults

A pre-routing failure cannot have a selected deployment, so its deployment_id is:

Successful and failed requests

Labels:
Request count by tenant and deployment:

Token use

Token rate by tenant and model:

Request-rate rejection

Labels:

Token-budget rejection

Labels:
phase is:

Flat quota limits

Label:
A value of 0 means unlimited. These gauges describe keys using the flat quota shape.

Per-model quota limits

Labels:
The RPM gauge reflects the current effective ceiling:
It can change as agent health and fleet size change.

Tokens used today

Label:
The value resets at midnight UTC. Token-budget utilization for flat quotas:

Last request timestamp

Labels:
Most recent request per API key:
Seconds since last request:

Tenant request duration

Labels:
P95 by tenant and model:

Quota persistence errors

This increases when the Badger-backed daily token limiter cannot flush quota state to disk.
A persistence error may leave the in-memory quota path working while daily usage is not safely stored for restart recovery.Investigate any increase rather than treating it as a harmless background error.

Admission-control metrics

The LLM admission gates publish one rejection counter and four live pool gauges: The reason label identifies the gate: The budget and backstop gauges can change as healthy replicas join or leave. Existing reservations remain visible in the occupancy gauges while the new denominators affect subsequent admissions. POST /v1/messages/count_tokens, embedding, and reranking requests do not enter B1 through B4, so they do not change these occupancy gauges. See Admission control metrics for panel queries and alert interpretation.

Per-request duration by agent

Labels:
P95 duration by agent:

HTTP server metrics

Request duration

Labels:
P95 by route:
Error rate by route:

Active requests

Labels:

Provider HTTP metrics

Labels:
P95 provider latency:
Provider responses by status:
Network failures use:

Alerting examples

The thresholds below are examples. Adjust them to your hardware, workload, and service objectives.

Agent unhealthy

High routing failure rate

KV-cache pressure

GPU temperature

Policy exhaustion

Quota persistence failure

Recording rules

Recording rules can simplify expensive or frequently reused dashboard queries.

Troubleshooting

Prometheus cannot reach the router

Check the endpoint directly:
Check the router logs:
For Docker Compose:
Check firewall and container-network rules.

A metric is missing

A series often appears only after the relevant event or data has occurred. For example:
  • tenant metrics appear after requests
  • engine metrics appear after a successful engine scrape
  • TTFT and ITL appear after completions
  • GPU metrics require NVML and visible NVIDIA devices
  • policy counters appear after routing activity
  • per-model quota gauges appear when those quota paths are used or seeded
Search by prefix:

An engine metric is missing

Check the backend endpoint locally on the agent host:
Confirm the engine-specific requirement:
  • SGLang needs --enable-metrics
  • llama.cpp needs --metrics
  • Ollama, Infinity, and custom engines do not currently supply engine metrics
Inspect the agent logs for scrape errors. A failed metrics scrape does not stop request forwarding.

Prometheus shows duplicate or stale agents

The peer_id label identifies the agent. If an agent starts with a new identity after every restart, Prometheus sees a new series. Configure a persistent:
and preserve the file or mounted volume across restarts.

Tenant labels show anonymous or default

In no-auth mode:
Static API keys currently use:
because stable key IDs belong to dynamic registry entries. deployment_id="unset" is expected before an agent is selected or when the agent does not advertise a deployment ID.

Histogram queries return no data

Check that the corresponding _bucket series exists:
Use rate() over a window that contains completed observations. A new or idle engine may not have enough data yet.

Counter graphs drop after a restart

Prometheus counters are process-local series. Some per-agent lifetime counters are reseeded from BadgerDB when agents register again, but other router, policy, HTTP, tenant, and queue metrics begin again with the new router process. Use rate() or increase() rather than graphing raw counter values when restart behavior matters.

Next steps

Grafana dashboards

Explore the provisioned dashboards, data sources, variables, and panels.

Audit logging

Query structured request records through Loki or local JSONL files.

Hardware metrics

Review how agents collect GPU, CPU, and memory data.