Skip to main content

Open-source Kubernetes observability

Nothing runs alone.

Discover your service dependencies with eBPF. Investigate traces, metrics and logs in one self-hosted platform, with no application changes for supported workloads.

Explore your Kubernetes service dependencies

Service mapExample / shop
HealthyDegradedInferred dependency
Illustrative data · select a service to explore its neighbourhoodHow the map is built ↗
eBPFDiscover supported trafficOTLPKeep your instrumentationSelf-hostedYour infrastructure

Same system. A different question.

Change the lens. Keep the context.

Start with a service. Understand what surrounds it, follow a slow request, then explore its footprint.

01

What depends on this?

See callers, downstream services and inferred datastores. Discover the connections worth investigating.

Explore dependencies
02

Which path is slow?

Spot elevated service latency. Open a trace to distinguish a slow dependency from time spent in the application.

Explore latency
03

What is its footprint?

Enable the green module to explore carbon per service. Estimates carry their label; missing data stays missing.

Explore carbon

From the big picture to one request

Follow a request across traces, metrics and logs.

A map shows the relationship. The underlying signals help you investigate it. One engine, one ClickHouse store.

Investigate a slow checkout ↗

Make the first connection

Go from cluster to connected.

Start where you are. Discover supported traffic with eBPF, or bring the telemetry you already collect.

01 / HELM

One place to start.

The Helm chart brings the sensor, gateway, hub, UI and ClickHouse together.

$ helm install avuruobs
Installation requirements ↗
02 / eBPF

Let the calls draw the map.

eBPF observes supported traffic while your applications keep running. Check kernel and protocol support before installing.

How the map is built ↗
03 / OTLP

Bring your existing OpenTelemetry data.

Keep your SDKs and collectors. Add an OTLP destination, validate one service, then expand at your own pace.

HTTP :4318 / gRPC :4317
OTLP adoption & migration ↗

Go deeper, when you need to

A connected view. Room to grow.

Mesh, cost, green, AI and MCP are opt-in. Enable what your team needs, with the collection and access controls to match.

Explore the modules ↗

Open by design

Run observability on your own infrastructure.

AGPL-3.0, with OIDC SSO and project roles in the open edition. You operate the storage and decide which integrations can send data elsewhere.

eBPFOpenTelemetry
Gateway
ClickHouseTelemetry storage
Hub + UIQueries & configuration

A few things before you start.

Do I need to change my application code?

eBPF discovers supported workloads without application changes. Coverage depends on your kernel, runtime and protocols. Use OpenTelemetry when you need custom spans or signals outside that coverage.

Can I keep my existing collectors?

Yes. Send OTLP over HTTP or gRPC to the gateway. During an evaluation, dual-export and check service identity, ingest keys and signal coverage before switching over.

Is every module enabled by default?

No. Green, cost, mesh, AI and MCP are opt-in. CPU profiling is experimental and opt-in too. The module guide lists prerequisites and collection controls.

Does my telemetry stay on my infrastructure?

Storage is self-hosted. Outgoing exporters, webhooks or an assistant connected through MCP can transmit selected data to destinations you configure. Review these integrations against your data policy.

Your system has a shape

Come see it.

Explore the demo, or install the published chart on your cluster. Start with one service and follow its connections.

helm install avuruobs oci://ghcr.io/avuruvision/charts/avuruobs \
  --version 0.16.0 -n avuruobs --create-namespace

Check prerequisites and choose a published chart version in the guide. Startup time depends on your cluster.