Watch
0
0
Fork
You've already forked hyperhive
0
hyperhive/hive-jobq-metrics
Repository files (latest commit first)
Filename Latest commit message Latest commit date
atlas f8960dd501 drop the remaining HYPERHIVE_OTEL_METRIC_INTERVAL_MS readers
Nothing sets the variable once otel.metricIntervalMs is gone, so the
turn-metrics, jobq-metrics and vcs-metrics exporters export at a fixed
60s, as hive-c0re's container-resource exporter already does. The
observability doc and the removal warning now say so.
2026-10-17 08:00:14 +02:00
..
src drop the remaining HYPERHIVE_OTEL_METRIC_INTERVAL_MS readers 2026-10-17 08:00:14 +02:00
Cargo.toml wire the authenticated OTLP push into vcs_metrics and hive-jobq-metrics 2026-08-29 11:17:24 +02:00
README.md swarm-controller: extract jobq_metrics into its own hive-jobq-metrics crate 2026-08-19 18:10:22 +02:00

hive-jobq-metrics

OTEL export of a hive-jobq graph's state rollup, using the same hive-jobq-wire state_rollup() counts a viewer's /rollup endpoint would serve — ridden out to the collector on a timer instead of only on request.

Why this is not part of hive-jobq or hive-jobq-wire. Both of those crates are dependency-light on purpose (no tokio, no HTTP client) — the scheduler is logic, the wire crate is presentation, and neither wants to drag the OTEL SDK, an async runtime, and an OTLP HTTP client into every consumer that just wants to run a graph or serialize one to JSON. Metrics export is a third concern with its own weight, so it gets its own crate rather than bloating either of theirs.

spawn_exporter is generic over hive_jobq::scheduler::Scheduler<N, R> — any host's jobq instance can call it, not just one hardcoded caller. It holds no process-global state: call it once per graph you want exported, and keep the returned SdkMeterProvider alive for as long as export should continue (dropping it stops the PeriodicReader).