Skip to content
MTTL, Mean Time To Learn

OrganizationPractitioner7 min read

Your observability has no owner

Observability platforms cost more and more, hold sensitive data and serve as evidence before regulators. Yet few organizations can say who is responsible for them. A governance framework in four pillars.

For: architects · team managers · finance, risk and compliance · executives and CIOsPrerequisites: None. The companion white paper details each pillar.

Reading mode

Ask a simple question in your organization: who decides what gets logged? Not who installs the agent (the small piece of software that collects data on each machine), not who manages the contract. Who decides that a log, a line of text written by an application, deserves to be produced, transported, indexed, kept for twelve months and paid for?

The most frequent answer is silence, followed by “it depends on the teams”. That is the symptom of observability without an owner. It works, often well. Yet it drifts: in costs, in formats, in tools, in data nobody should have collected.

This article summarizes a governance framework in four pillars, detailed in the white paper Governing observability.

Changing tools is not enough

Section titled “Changing tools is not enough”

When the bill explodes, the first reflex is to change tools. You migrate from one vendor to another, or to an open source stack (a set of open source tools). A few quarters later, the same symptoms reappear on the new platform, because nothing changed in the way decisions are made.

The shift is to treat observability data as what it is: an enterprise data flow. An enterprise data flow is governed. You define what comes in, in what form, for what purpose, for how long, who can access it and who pays. Data teams have done this for years for their warehouses. Observability simply has not made that journey yet.

Governing does not mean creating a committee that approves every dashboard. Good governance is almost invisible: its rules are coded into pipelines (the chains that carry the data) and into CI, the continuous integration that automatically checks every change before it reaches production. Product teams gain default instrumentation, ready-made dashboards and a readable bill. The guiding principle is the paved road: make the right behavior easier than the wrong one.

Four pillars, four rules

Section titled “Four pillars, four rules”

Organization: the platform has an owner, so does the signal

Section titled “Organization: the platform has an owner, so does the signal”

The model that works is federated. A platform team provides the foundation, the instrumentation libraries and the rules. Each product team remains the owner of its signals, its SLOs (its quality-of-service objectives with a number on them) and its alerts. Around them, a light observability committee meets once a month with a fixed agenda: schema changes, exceptions, budget overruns, tool retirements. The team models compare this organization with the others.

The rule: no signal enters the platform without an attribute naming the owning team.

Standards: OpenTelemetry as the common language

Section titled “Standards: OpenTelemetry as the common language”

OpenTelemetry, the open standard used to produce metrics, logs and traces, separates producing signals from storing them. You instrument once, meaning you add to the code only once what it needs to emit its signals; the backend, the tool that stores and displays the data, becomes a reversible choice. The semantic conventions, common names to describe an HTTP request or a database call, provide the vocabulary, with a nuance many overlook: each convention has a stability status, which says whether its names may still change. The HTTP conventions have been stable since late 2023, the core of the database ones since 2025, whereas the GenAI conventions are still at Development status in 2026.

The rule: only stable attributes can be the basis for an alert, an SLO or a cost allocation. Collector configuration lives in Git, the tool where teams keep the history of their code, like any other code.

Costs: make visible before charging back

Section titled “Costs: make visible before charging back”

Every stored signal results from a choice, often implicit, to keep it. Governance makes that choice explicit. You first measure volumes per team and per service, show each team its own without making it pay (that is showback), then allocate budgets. Actual chargeback only comes once everyone accepts the figures. The technical levers are well known: filtering at the source, tail sampling, cardinality control, tiered retention. Tail sampling keeps only part of the traces, chosen once the request has finished, for example the ones in error. Cardinality is the number of label combinations a metric has, which drives storage growth. Tiered retention puts data on fast storage first, then on cheaper storage as it ages. These levers are detailed in Governing observability data.

The rule: every data class has a minimum and a maximum retention period, set in advance. The maximum matters as much as the minimum.

Compliance and sovereignty: logs are personal data

Section titled “Compliance and sovereignty: logs are personal data”

This is the most often forgotten pillar, as well as the most exposed. Logs contain email addresses, identifiers, IP addresses. The CNIL, the French data protection authority, recommends keeping access logs between six months and one year and minimizing the personal data they contain. DORA, the EU regulation on digital operational resilience in the financial sector, requires financial entities to protect logs against tampering and to monitor logging failures. NIS2, the EU cybersecurity directive, reaches France through the Résilience bill: its floor debate, planned at the Assemblée nationale on 7 October 2026, was withdrawn from the agenda the day before, with no new date so far. The AI Act, the EU regulation on artificial intelligence, will require logging for high-risk AI systems, with application now postponed to 2 December 2027 for most of them (Annex III) and to 2 August 2028 for the others (Annex I).

These texts converge on four requirements: knowing what is logged, keeping it for a justified period, guaranteeing its integrity and controlling access to it. A single governance framework can answer them. Sovereignty, for its part, rests on three conditions: controlled hosting, an open format and reversibility written into contracts. The article Observability and digital sovereignty develops this point.

The rule: personal data is filtered at the gateway, the shared checkpoint all data passes through before it is stored, by rules tested in CI, not at each developer’s discretion.

Where to start?

Section titled “Where to start?”

A realistic roadmap fits in twelve months and three phases.

  1. Lay the foundations (0 to 90 days). Appoint a sponsor (a senior leader who carries the topic) and a platform lead. Inventory tools, agents and volumes. Write a one-page observability charter and the list of mandatory attributes, with two or three pilot teams.
  2. Make the rule executable (months 3 to 6). Deploy shared OpenTelemetry gateways, apply personal data filtering and schema validation there, publish showback per team, validate retention periods with the DPO (the data protection officer).
  3. Steer (months 6 to 12). Checks in CI and at ingestion (when the platform receives the data), budgets per team, immutable storage for evidence logs, a tested exit plan for each backend.

Three traps come up often:

  • Starting with bans. Governance that forbids before offering a paved road gets bypassed at the first emergency.
  • Charging back too early. Allocating costs on disputed figures destroys trust in the whole approach.
  • Confusing governance with tool selection. A tender is not an observability policy. Governance comes before the tool and outlives it.

Finally, measure. A dozen indicators are enough. My favorite: the share of stored data that has never been read. It directly reveals data produced out of habit rather than need.

To go further

Section titled “To go further”

Observability has long been a tooling topic. It has become a decision topic: about money, personal data, evidence and vendor dependency. Technique remains necessary, though it is no longer enough. What is most often missing, more than a collector or a backend, is someone who decides, written rules and pipelines that apply them.

The white paper Governing observability details this framework: RACI matrix (who does the work, who decides, who is consulted, who is informed), mandatory attributes, cost levers, regulatory table, five-level maturity model, roadmap, indicators, sample charter and a checklist for bringing a new team on board (onboarding).

When you don’t know, you ask; when you know, you share. Your field experience is welcome.

Sources

Section titled “Sources”