14

Grafana: One Investigation Surface, Many Backends

Source: Observability Platform source — section 14, “Grafana: The Investigation Surface”

The enterprise problem and today’s slice

Enterprise problem: Responders lose time and context when dashboards, logs, traces, and profiles live in separate tools with inconsistent permissions, time ranges, and service identities.

Whole-course context: The incoming artifacts are independently proven Mimir, Loki, Tempo, and Pyroscope paths; today makes them usable through one governed investigation surface without pretending Grafana owns their telemetry.

Today’s slice: Provision data sources, folders, dashboards, Explore access, and query evidence while preserving each backend’s tenant, retention, and query-language responsibility.

End-of-day evidence: Produce a shareable fixed-time investigation that opens authorized metrics, logs, traces, and profiles with matching service/environment context.

Still unsolved: Automated cross-signal identity contracts and the final end-to-end platform architecture remain deferred.

Customer use cases

A single UI can still expose inconsistent data or excessive authority. These use cases require a repeatable responder workflow and an independently governed provisioning path.

Use case IDActorCustomer jobSuccess outcomeDenial or recovery evidence
D14-UC-01Incident responderInvestigate checkout degradation across four signals without losing time or service contextA fixed-time Explore/dashboard link reproduces authorized Mimir, Loki, Tempo, and Pyroscope viewsA restricted data source or tenant remains inaccessible while permitted views still work
D14-UC-02Grafana administratorProvision data sources and dashboards safely across environmentsVersioned configuration creates healthy connections with least-privilege credentials and rollback evidenceInvalid credential/config health fails visibly; rollback restores the last known-good revision

Actor-centred user stories

“One pane of glass” is not acceptance evidence because it says nothing about access, reproducibility, or backend health. These stories define the observable surface and its administration.

Story IDUse case IDsUser storyObservable acceptance conditions
D14-US-01D14-UC-01As an incident responder, I want one fixed-time investigation with four authorized data sources, so that another responder can reproduce the same evidenceShared link preserves absolute time, service/environment filters, queries, and panels; unauthorized source access is denied
D14-US-02D14-UC-02As a Grafana administrator, I want data sources and dashboards provisioned from reviewed revisions, so that changes are auditable and recoverableHealth checks pass for four sources, secrets remain external, an invalid revision fails, and rollback restores previous UIDs

End-to-end product flows

A dashboard panel can render stale or partial data without proving its source, so flows start with a visible responder action and finish with query metadata and access evidence. Grafana orchestrates queries; it does not merge the storage engines into one database.

Flow IDUse case IDsPathTriggerNumbered stepsTerminal evidence
D14-FLOW-01D14-UC-01, D14-UC-02HappyResponder opens the checkout incident dashboard at a fixed absolute time1. Grafana authenticates the user.<br>2. Folder/data-source permissions are evaluated.<br>3. Variables resolve canonical service/environment values.<br>4. Each panel queries its owning backend.<br>5. Explore preserves query and time context.<br>6. Responder shares a reproducible link.User, role, data-source UIDs, queries, absolute window, result timestamps, environment, and shared-link ID
D14-FLOW-02D14-UC-01, D14-UC-02RecoveryAdministrator deploys a bad Loki credential revision1. Data-source health check fails.<br>2. Metrics, traces, and profiles remain available.<br>3. Deployment is rolled back.<br>4. Loki health and the fixed investigation recover.<br>5. A restricted user remains denied.Failed health response, unaffected-source controls, rollback revision, recovered query, denial result, and run ID

System design derived from the flows

Giving Grafana one superuser credential across every backend creates a large blast radius and erases tenant attribution. Each data source receives the narrowest service identity and backend scope needed for its audience.

Use case IDEntry pointResponsible servicesAuthoritative storeFailure evidence
D14-UC-01Dashboard, Explore, and shared-link routesGrafana auth/RBAC, dashboard service, Explore, data-source proxy, Mimir, Loki, Tempo, PyroscopeGrafana database for UI objects; each telemetry backend remains authoritative for its signalPermission denial, panel/query error, stale timestamp, wrong tenant, missing UID, or link reproduction failure
D14-UC-02Provisioning pipeline and data-source health APIGit review, secret manager, Grafana provisioning, data-source plugins, rollback controllerGit for intended configuration; secret manager for credentials; Grafana database for applied stateRevision rejection, health-check failure, secret-resolution error, UID drift, or rollback failure

Data model and ownership

If dashboard metadata is confused with telemetry authority, backup and deletion procedures can remove the wrong state or leave credentials behind. Grafana owns presentation and provisioning state; each backend owns its telemetry.

Generated-application database: Not created in this slice — Grafana’s own configuration database and external telemetry stores are sufficient; no customer application data belongs here.

Record or entityStore and ownerPrimary keyForeign key or opaque referenceTenant keyMaterial constraintLifecycle and deletionUse case IDs
Data-source definitionGrafana database/provisioning owned by Grafana adminsdatasource_uidOpaque endpoint and secret referenceorganization_idStable UID, least-privilege access, no inline secret, health check requiredProvision, update, roll back, disable, delete; revoke secret independentlyD14-UC-01, D14-UC-02
Dashboard revisionGit plus Grafana database owned by service/platform teamdashboard_uid/revisionForeign reference to folder UID and data-source UIDsorganization_idStable UIDs, reviewed queries, bounded variables, no embedded credentialsCreate, version, restore, archive, export, and deleteD14-UC-01, D14-UC-02
Folder permissionGrafana authorization store owned by adminsfolder_uid/subject_idOpaque identity-provider subject referenceorganization_idExplicit least-privilege role; independently revocableGrant, review, revoke, retain audit event, expire with subject lifecycleD14-UC-01, D14-UC-02
Investigation proofPlatform evidence store owned by operationsinvestigation_run_idOpaque references to user, revisions, UIDs, queries, and shared linkorganization_idAbsolute time and result/denial digests are immutableCreate per exercise, retain for audit objective, then expireD14-UC-01, D14-UC-02

Dashboards, Explore, and reproducibility

Relative “last hour” links change after handoff, so incident evidence must preserve an absolute time window. Dashboards provide curated views; Explore supports iterative query work, side-by-side sources, query inspection, and fixed-time sharing.

A panel is a data source, query, optional transformation, and visualization. Record the data-source UID and inspect the actual request when results surprise you. Mixed-source panels can be useful, but independent panels often make ownership and partial failure clearer.

Provisioning and access checks

Manual UI changes drift and are hard to recover, so provision stable UIDs and reviewable configuration where practical. Store credentials in an external secret mechanism and scope each data source to the required tenant and API.

Test two identities: an authorized responder and a restricted user. The restricted user must be denied the protected folder or data source without inheriting backend access merely through Grafana membership. Also test direct backend exposure; Grafana RBAC cannot protect an independently reachable backend endpoint.

Practical investigation

A dashboard that shows four green panels does not prove cross-signal usefulness. Seed one checkout degradation and capture:

  1. Mimir p99 latency and error-rate panels for a fixed time.
  2. Loki timeout logs for the same service/environment window.
  3. A Tempo trace whose payment span dominates.
  4. A Pyroscope profile that names a hot function or falsifies local CPU.
  5. A shared absolute-time Explore/dashboard link opened by a second authorized user.
  6. A denied attempt from the restricted identity.

Key takeaways

Grafana unifies investigation interaction, not storage ownership. Preserve these rules:

  • Mimir, Loki, Tempo, and Pyroscope remain specialized authoritative telemetry backends.
  • Stable data-source and dashboard UIDs make provisioning and links recoverable.
  • Absolute time, query text, variables, and data-source identity make evidence reproducible.
  • Grafana permissions and backend permissions are distinct boundaries.
  • Partial data-source failure should remain visible while unaffected signals continue working.

Checklist

A polished dashboard can conceal unsafe credentials or irreproducible evidence. Complete these checks:

  • [ ] Provisioned stable data-source, folder, and dashboard UIDs.
  • [ ] Kept credentials outside dashboard and provisioning source.
  • [ ] Used least-privilege identities for each backend.
  • [ ] Reproduced a four-signal investigation with absolute time.
  • [ ] Injected one data-source failure and proved unaffected controls.
  • [ ] Proved restricted-user denial at Grafana and backend boundaries.

Sources

Grafana roles and correlation features evolve, so use current primary documentation. These sources support the surface and provisioning model: