Issue
The rustlib HTTP server serves /readyz, /healthz, and /metrics, but
downstream consumers (dfe-docker compose, K8s manifests) often probe
/health/ready -- which may or may not exist depending on each binary's
HTTP wiring.
In dfe-docker, the compose healthchecks for dfe-receiver, dfe-fetcher,
dfe-archiver, dfe-loader, dfe-transform-vector, dfe-transform-vrl
all use /health/ready. None of those are guaranteed by rustlib; they
happen to work or not work per binary depending on what extra routes
that binary installed on top of the rustlib defaults.
This is partly a documentation gap (the canonical endpoint paths are not
prominently documented) and partly a consistency gap (some binaries may
expose legacy /health/ready aliases, others may not).
Proposed solution
- Document the canonical rustlib HTTP endpoints in the rustlib README
and STATE.md:
/healthz -- liveness/readyz -- readiness/startupz -- startup (if implemented)/metrics -- Prometheus scrape
- Confirm every DFE binary built on rustlib exposes the same set with
no aliases. Add a CI check (smoke test against the built image)
that hits each endpoint and asserts 200/503 as expected.
- Either drop any legacy
/health/ready route, or document it as a
permanent alias of /readyz and add a corresponding smoke test.
- Once the rustlib side is settled, dfe-docker compose can switch
every healthcheck to /readyz in one PR.
Additional info
This blocks a clean healthcheck rewrite in dfe-docker. The compose
files currently all point at /health/ready and nobody has audited
whether each binary actually serves it. Need the canonical answer
from rustlib before doing the dfe-docker fix.
Observed: rustlib 2.7.1 + DFE 2.2 components.
Issue
The rustlib HTTP server serves
/readyz,/healthz, and/metrics, butdownstream consumers (dfe-docker compose, K8s manifests) often probe
/health/ready-- which may or may not exist depending on each binary'sHTTP wiring.
In dfe-docker, the compose healthchecks for
dfe-receiver,dfe-fetcher,dfe-archiver,dfe-loader,dfe-transform-vector,dfe-transform-vrlall use
/health/ready. None of those are guaranteed by rustlib; theyhappen to work or not work per binary depending on what extra routes
that binary installed on top of the rustlib defaults.
This is partly a documentation gap (the canonical endpoint paths are not
prominently documented) and partly a consistency gap (some binaries may
expose legacy
/health/readyaliases, others may not).Proposed solution
and STATE.md:
/healthz-- liveness/readyz-- readiness/startupz-- startup (if implemented)/metrics-- Prometheus scrapeno aliases. Add a CI check (smoke test against the built image)
that hits each endpoint and asserts 200/503 as expected.
/health/readyroute, or document it as apermanent alias of
/readyzand add a corresponding smoke test.every healthcheck to
/readyzin one PR.Additional info
This blocks a clean healthcheck rewrite in dfe-docker. The compose
files currently all point at
/health/readyand nobody has auditedwhether each binary actually serves it. Need the canonical answer
from rustlib before doing the dfe-docker fix.
Observed: rustlib 2.7.1 + DFE 2.2 components.