Metrics¶
The mirror exposes Prometheus metrics on the /metrics endpoint of its
HTTP server (see Configuration → http).
Three service-specific metrics, plus the standard Go runtime and
process_* metrics from the default Prometheus client.
Labels and cardinality¶
The two labelled metrics use feed as the label name; its value is the
subdir of the upstream that produced the sample. Cardinality is
therefore bounded by the number of upstreams configured under
upstreams — typically a handful,
at most a few dozen.
Is the service up?¶
| Metric | Type | Meaning |
|---|---|---|
up |
gauge | Set to 1 once Run starts. Absence (scrape failure) means the service is not reachable. |
The metric does not flip back to 0 on shutdown; rely on scrape
liveness rather than this gauge to alert on a stopped service.
When did each upstream last finish?¶
| Metric | Type | Meaning |
|---|---|---|
oxfeed_mirror_upstream_loaded_time_seconds{feed} |
gauge | Unix timestamp of the last successful completion of the mirror cycle (snapshots + deltas + codes + feed.json written) for this upstream. |
Operators use this to alert on a mirror that has stopped advancing.
The healthz stale_data check covers a similar concern with a 24-hour
threshold; this metric is the one to drive tighter Prometheus alerts.
How much disk is each upstream using?¶
| Metric | Type | Meaning |
|---|---|---|
oxfeed_mirror_upstream_subdir_size{feed} |
gauge | Total size in bytes of all files in the upstream's subdir at the end of the last cycle. |
Useful for capacity planning and for catching runaway feeds.
# Total bytes across all mirrored feeds
sum(oxfeed_mirror_upstream_subdir_size)
# Growth rate over 24h, per feed
deriv(oxfeed_mirror_upstream_subdir_size[24h])
Process and runtime metrics¶
The default Prometheus Go client also exposes the usual go_* and
process_* metrics: heap and stack sizes, goroutine count, GC
durations, open file descriptors, CPU time, resident memory. Use these
for the standard "Is the process healthy?" panels; the mirror does not
override any of them.