Observability Mesh
A vendor-free architectural practice and operating model for federated observability ownership — logs, metrics, traces, and SLO catalog & dashboard as part of the application, not a shared platform every team feeds into.
The practice
In large enterprises, observability often lives with a central platform and expensive tooling that only the high-traffic services fully justify. Small applications still get pulled onto the same stack so cost can be shared. Startups face the opposite problem: they need reliable operations without buying an enterprise suite or hiring a dedicated SRE team on day one.
Observability Mesh is the answer in between — a service reliability catalog assembled from open-source tools, wired so each team can run a full stack the same way data mesh thinking lets teams own data products without waiting on a central warehouse.
Categories
Browse by topic — the three observability pillars, the SLO control plane, and the federated ownership model that ties them together.
Two entry points
The full mesh covers the three pillars and the SLO workflow end to end. The stripped path focuses on SLO authoring and the SLO catalog — enough to build trust with users and make reliability decisions from data.
Application teams get isolated observability tenants. The platform team publishes the golden catalog, instrumentation contract, SLO workflow, and upgrade path. Telemetry flows through a single collector per tenant; SLO documents live in that tenant’s catalog.
01 · Logs
Instrumented services export logs over OTLP to the tenant collector. The logs pipeline lands in OpenSearch so teams can investigate incidents without sharing a global log estate.
OTLP → Collector → OpenSearch → Dashboards
02 · Metrics
Metrics follow the same OTLP path into Prometheus. Alerting is metric-based — PromQL rules and burn rates — not log scraping. Cardinality and retention stay inside the tenant boundary.
OTLP → Collector → Prometheus → Grafana / Alertmanager
03 · Traces
Distributed traces land in Tempo and open from Grafana Explore. Each service sets OTEL_SERVICE_NAME; the mesh keeps the shared OTLP contract so replacing a demo workload with your own services is mechanical.
OTLP → Collector → Tempo → Grafana Explore
SLO workflow
Developers author, validate, and version OpenSLO documents through the SLO authoring service. A provisioner polls the catalog, compiles documents with Sloth into Prometheus recording and burn-rate rules, and reloads the tenant Prometheus. Grafana ships an SLO Overview dashboard for objective, SLI attainment, burn rate, and error budget.
You do not need the full telemetry estate on day one to change how teams talk about reliability. An SLO catalog — authored documents, a provisioned rules path, and a dashboard — lets developers define commitments users can see and leadership can use for data-driven decisions.
Published SLOs turn vague “we’re reliable” claims into measurable objectives. When error budget is visible, support and product conversations share the same language as engineering.
Burn rate and remaining budget tell you when to freeze features, when to invest in resilience, and when a service is healthy enough to take risk — without waiting for a war room.
The team that ships the service authors the OpenSLO documents. Platform publishes the catalog building blocks; application teams own SLI quality and day-2 review of their own dashboards.
Minimal path
Use the SLO authoring service and provisioner as a focused reliability workflow. Seed SLIs and SLOs for HTTP success and latency (as in the Petstore demo), generate traffic, and watch Sloth-derived series appear in Grafana: error ratios, current burn, and period error-budget remaining.
When you are ready, expand the same tenant into the full mesh — logs and traces plug into the same operating model without rewriting ownership.
Operating model
At scale, reliability work rarely lives in one central blob or only inside product teams. The pattern that shows up most often is federated: a central platform publishes golden paths and contracts; domain and application teams own outcomes for their services. Observability Mesh is that pattern applied to telemetry and SLOs — not a replacement for your whole reliability org.
The target deployment is one isolated tenant per application team — not a shared observability platform where every service feeds the same Prometheus. If a team emits high-cardinality labels or writes SLIs that do not match their metrics, that stays their problem. It does not affect other teams.
Sets the contract. Publishes the catalog. Does not phase out.
Compose the mesh beside their services and own day-2.
Same catalog, different audiences
Federated ownership is what makes multi-audience reliability workable. Engineering leadership and application owners rarely want the same documents; they should not fight over a single shared dashboard or a single shared Prometheus.
A comparable portfolio set — availability, latency, error-budget burn across critical services — for investment, risk, and cross-team standards.
Service- and journey-shaped SLOs — checkout success, scan latency, “can a user complete X” — for user trust and data-driven product decisions.
Platform publishes the authoring and provisioning building blocks. Teams author the documents their stakeholders need. Same OpenSLO path; different commitments, visible to the people who act on them.
Open reference
The reference implementation and a lightweight Petstore demo are open on GitHub. Run Compose, explore the SLO catalog and dashboards, then keep the mesh while swapping in your own workloads.