Backend, storage & operations
View All TagsA 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.
A new Error tracking module turns the exceptions already flowing through avuru-obs — span exception events, error spans, and ERROR/FATAL logs — into first-class issues: deduplicated by fingerprint, each with a stack trace, an occurrence timeline, a link to a representative trace, and a triage lifecycle. No code change required.
Installing no longer means cloning the repo. The Helm chart and every image are
now published to GHCR — cosign-signed and built for amd64 + arm64 — so a
single command brings up the whole stack.
avuru obs v0.1.0 is tagged: install the Helm chart on a fresh Kubernetes cluster and watch a live service map appear in under five minutes, zero app changes — a promise enforced in CI, not a demo.
The Profiling screen is live: cluster-wide CPU flame graphs, sampled by
eBPF with zero app changes and stored in the same ClickHouse as your traces,
logs and metrics. Experimental and opt-in for v0.1
(sensor.profiler.enabled=true) — the upstream alpha loader does not support
every kernel yet.
The Nodes screen is live: CPU, memory and network per node, with the busiest pods underneath — collected by the sensor's node agent (kubeletstats), stored in the same ClickHouse as everything else.
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.
Our north star — a fresh Kubernetes cluster showing a live service map in under five minutes, zero app changes — is now a hard CI gate, and the gateway ships as a purpose-built minimal collector.
A new System Status tab (under Settings) gives operators an at-a-glance view of the backend's health.