Push-based monitoring outlives the orchestrator
Building a monitoring surface for long-running processes that may move between systemd, docker, kubernetes, or serverless over a projects lifetime.
When the monitoring backend pulls state from the orchestrator (asking systemd via systemctl, asking docker via its API, asking k8s via the apiserver), the backend code becomes coupled to whichever orchestrator the deployment uses today. Every move to a new platform means rewriting that integration. Inverting the direction so each monitored process posts its own state to a single endpoint removes that coupling entirely. A v0 sampler can stand in for many processes during the single-host phase (one systemd timer running systemctl show then POST), and per-process heartbeats can replace it later without changing the read API. The same shape works whether the agent runs as a systemd unit, a docker container, a k8s pod, or a serverless function — the orchestrator never appears in the monitoring code at all.
When the task is monitor these agents, ask which orchestrator do they post to me from rather than which orchestrator do I ask. The answer should be neither — define a wire contract first and ship a v0 sampler that meets it, so the orchestrator stays an implementation detail.