17 posts tagged with "Service map"

The service map becomes the application entry point: select a service, keep the map in view, and step into its callers, dependencies, traces and logs from one inspector.

A namespace row that says STRICT is reporting a claim. A strict policy that is enforced and one that is not — a workload that never enrolled, a selector that matches nothing, a rule disabling TLS underneath — look identical from configuration and from traces. Only the proxy that terminated the connection knows, and until now nothing asked it.

v0.15.0 puts, on one row, what your mesh's configuration says about a workload and what its proxy actually did — and gives every workload the cluster runs a row, whether or not it ever sent a span.

v0.16.0 makes a workload's page on the mesh screen read like the cluster's own record of it, and puts its logs on it — its own lines, and the lines the node proxy and its waypoint wrote about it, joined by the hub that knows its pods.

The Mesh screen could tell you whether your proxies were healthy and whether your control plane was still pushing config. On a cluster where the mesh runs without sidecars, that is two rows and four numbers. It now reads like a console for the fabric.

v0.14.0 closes the gaps between what v0.12 claimed for an agent and what an operator actually got — and turns the Mesh screen into a console for the fabric underneath your services.

A service page could name what calls a service and what it calls. It could not show you the shape of it. Now it draws it.

v0.13.0 draws the connections the service page could only list — and finishes the work of making every image an install pulls clean at the source rather than excused by a registry.

v0.10.0 answers a question that comes from outside the platform team: what is this cluster costing, and how much of it is buying nothing? A Kubernetes cluster is sized by what its workloads reserve, not by what they use — and until now avuru obs only knew the second half of that sentence.

v0.9.0 is for clusters where the network is not a straight line. A service mesh intercepts every call, so a dependency graph either draws hops that are not dependencies or draws nothing at all — and the kernel underneath has been seeing faults nobody was asking it for.