Topology & dependencies
View All Tagsv0.8.0 is about the screen people actually look at. The service map has been the product's front page since v0.1 and a graph of circles for just as long. This release taught it to say more — and it needed no new collection: everything below is drawn from telemetry that was already arriving.
v0.7.0 is about the words your data is filed under and the surfaces that read it. v0.6 opened both ends of the pipe; what arrived was only as useful as the vocabulary available to slice it — and, it turned out, as truthful as the map drawing it.
A node used to turn red the moment any error happened in the window — never telling you whether the service was actually in trouble. The service map now answers that question, and a few more.
The service map now shows connection-level health on its edges: per-edge TCP RTT and failed/reset connections, measured in the kernel by OBI — no traces, no SDKs, no app changes. A link that's slow or refusing connections is now visible on the same topology you already watch.
A new Service Health board rolls each service's RED health up into consolidated group status — with criticality tiers and a rule that a service can't read green while a critical dependency is red. It is derived from the traces you already send: no health checks, no probes, no new storage.
Installing the Helm chart now deploys a per-node sensor that observes every service on the cluster — eBPF traces, RED metrics and log collection with no SDK, no sidecar, no app changes.
The service map went from disconnected dots to an actual topology.