15

Cross-Signal Correlation: One Investigation, Four Databases

Source: Observability Platform source — section 15, “Correlation: Turning Four Databases into One Investigation”

The enterprise problem and today’s slice

Enterprise problem: Four healthy telemetry backends still force responders to copy identifiers, guess time windows, and reconcile checkout, checkout-api, and commerce-checkout, which lengthens incidents and creates false joins.

Whole-course context: The incoming artifact is a reproducible fixed-time Grafana investigation across Mimir, Loki, Tempo, and Pyroscope; today standardizes the identity and links that preserve context between those views.

Today’s slice: Define canonical resource attributes, exemplars, trace/log/profile links, deployment context, and correlation tests without merging backend authorization or ownership.

End-of-day evidence: Produce one metric-to-trace-to-log-to-profile-to-deployment investigation whose links preserve tenant, service, environment, and time, plus a deliberately mismatched control that fails safely.

Still unsolved: Final capacity, availability, alerting, governance, disaster-recovery, and retirement decisions remain deferred to the complete architecture.

Customer use cases

Correlation that merely opens another page can silently select the wrong service or tenant. These use cases require context-preserving navigation and governed schema rollout.

Use case IDActorCustomer jobSuccess outcomeDenial or recovery evidence
D15-UC-01Incident responderMove from a checkout latency symptom to causal and code evidence without manual re-entryMetric exemplar opens the correct trace, related logs, profile window, and deployment revisionMissing/mismatched identity produces an explicit no-match or warning rather than a cross-tenant or wrong-service result
D15-UC-02Observability schema ownerKeep service and deployment identity consistent across all signals and producersConformance tests pass for canonical attributes and approved mappingsA producer with env=prod or conflicting service identity is quarantined/rejected while conforming telemetry remains queryable

Actor-centred user stories

Shared field names do not guarantee shared meaning, so acceptance must validate actual link inputs and outputs. The stories cover both responder navigation and schema governance.

Story IDUse case IDsUser storyObservable acceptance conditions
D15-US-01D15-UC-01As an incident responder, I want a latency exemplar to carry me through trace, log, profile, and deployment evidence, so that I can test one causal hypothesis without losing contextEvery hop preserves tenant, service.name, environment, absolute time, and trace/deployment identifiers; seeded controls do not join
D15-US-02D15-UC-02As a schema owner, I want producers validated against canonical OpenTelemetry resource attributes, so that differently named records cannot impersonate the same serviceCI or collector policy rejects an incompatible fixture, accepts the canonical fixture, versions aliases, and records rollout evidence

End-to-end product flows

A correlation is a query transformation across ownership boundaries, so each hop must carry only the identifiers needed by the target and re-evaluate authorization there. The flow ends in a reproducible operational action, not merely an open tab.

Flow IDUse case IDsPathTriggerNumbered stepsTerminal evidence
D15-FLOW-01D15-UC-01, D15-UC-02HappyResponder clicks an exemplar on checkout p99 latency1. Grafana opens the Tempo trace for the exemplar trace ID.<br>2. Trace attributes identify payment as the slow service.<br>3. Derived Loki query uses canonical service/environment and trace ID.<br>4. Trace-to-profile link opens the same service and span window.<br>5. Deployment catalog resolves service.version to a reviewed change.<br>6. Responder records action and evidence.Source/destination queries, attributes, trace ID, deployment revision, absolute window, actor, environment, and investigation ID
D15-FLOW-02D15-UC-01, D15-UC-02DeniedA test producer emits conflicting service/environment attributes1. Conformance policy detects the conflict.<br>2. Telemetry is rejected, quarantined, or marked non-correlatable.<br>3. The correlation link shows explicit no-match.<br>4. Canonical control telemetry still completes the chain.<br>5. Cross-tenant access remains denied.Policy reason, rejected fixture, no-match result, successful control chain, tenant denial, and run ID

System design derived from the flows

Hard-coded links scattered through dashboards drift whenever a label changes. Central schema policy, versioned correlation definitions, and conformance fixtures make transformations reviewable and independently revocable.

Use case IDEntry pointResponsible servicesAuthoritative storeFailure evidence
D15-UC-01Grafana exemplar, data link, or correlation actionGrafana correlations/data links, Mimir, Tempo, Loki, Pyroscope, deployment catalog, backend authorizationEach signal backend owns its records; deployment catalog owns release metadata; Grafana owns link definitionsMissing exemplar, wrong mapped field, empty target query, broadened time, permission denial, or mismatched service/tenant assertion
D15-UC-02Instrumentation CI and collector policyOTel SDK/resource config, schema registry, collector transform/validation, conformance runnerVersioned semantic contract and mapping registry owned by observability governanceUnknown alias, conflicting attributes, cardinality-policy failure, rejected telemetry, or control-fixture regression

Data model and ownership

An alias table can aid navigation without becoming an authorization bridge. The target backend must still evaluate the user or service credential independently, and opaque references never transfer authority.

Generated-application database: Not created in this slice — the schema registry, correlation definitions, deployment catalog, and proof records are platform control/evidence state rather than application-domain data.

Record or entityStore and ownerPrimary keyForeign key or opaque referenceTenant keyMaterial constraintLifecycle and deletionUse case IDs
Identity-contract revisionSchema registry owned by observability governancecontract_versionNone — root semantic contract has no parentorganization_idStable canonical meanings, compatibility rule, cardinality class, and sensitivity classificationPropose, approve, deprecate, migrate, retain history, then expireD15-UC-02
Producer conformance resultEvidence store owned by schema governanceconformance_run_idForeign reference to contract version and opaque producer revisionorganization_idPositive and conflicting fixtures are immutable; environment and timestamp requiredCreate in CI/deploy, retain for audit objective, expire with revision policyD15-UC-02
Correlation definitionGrafana provisioning store owned by adminscorrelation_uid/revisionOpaque source/target data-source UIDs and contract versionorganization_idExplicit field mapping, bounded time transform, target authorization, independently revocableReview, provision, roll back, disable, export, deleteD15-UC-01, D15-UC-02
Investigation chain proofPlatform evidence store owned by operationscorrelation_run_idOpaque references to source result, target results, trace ID, and deployment revisionorganization_idEvery hop records input/output context, denial, and control resultCreate per exercise, retain for incident/audit objective, then expireD15-UC-01, D15-UC-02

Canonical identity contract

Similar strings are not reliable joins, so choose canonical resource attributes and define their scope. OpenTelemetry semantic conventions provide shared names across traces, metrics, logs, profiles, and resources.

AttributeMeaning and constraint
service.nameStable logical service name; identical for horizontally scaled instances
service.namespaceStable grouping that makes service names unambiguous
service.instance.idUnique live instance identity; usually metadata, not a Loki index label
deployment.environment.nameStable environment value such as production or staging
service.versionDeployed code/artifact version used to resolve change context
k8s.cluster.nameCluster identity where relevant to telemetry and access policy

Normalize at the producer or collector boundary, publish aliases only for migrations, and reject simultaneous conflicting canonical/legacy values. Do not use deployment.environment.name as part of service uniqueness; the OTel service identity contract is namespace, name, and instance.

Correlation mechanisms and limits

Copying a trace ID manually is slow and error-prone, so use explicit mechanisms: metric exemplars to traces, derived fields or correlations from logs to traces, trace-to-logs queries, trace-to-profile queries, and deployment links from service.version.

Exemplars attach representative trace context to metric observations; they do not imply every metric sample has a trace or that the selected trace explains the aggregate. Profiles are aggregate windows, not request-specific proof. Each hop supplies evidence for or against a hypothesis.

Practical falsification exercise

Happy-path navigation can hide overly broad joins. Seed two tenants with the same service.name, two environments, and one trace ID present only in the authorized tenant.

  1. Click a production checkout exemplar and record the target Tempo query.
  2. Open related payment logs and verify trace ID, tenant, service, and absolute time.
  3. Open a profile narrowed to service and span window.
  4. Resolve service.version to the deployment catalog.
  5. Change one fixture to env=prod and verify explicit no-match or schema rejection.
  6. Attempt the other tenant and verify denial without leaking whether its trace exists.

Key takeaways

Correlation is governed identity plus query transformation, not physical database unification. Keep these rules:

  • Canonical resource semantics matter more than superficially similar label values.
  • Every target backend re-evaluates authorization; links never grant access.
  • Exemplars, logs, traces, profiles, and deployments provide different evidence strengths.
  • Absolute time, tenant, service, environment, and version must survive each hop.
  • A mismatched fixture and cross-tenant denial are required falsifiers.

Checklist

Correlation is unsafe until wrong matches fail visibly. Complete these checks:

  • [ ] Published versioned canonical attributes, aliases, sensitivity, and cardinality classes.
  • [ ] Added producer conformance fixtures for positive and conflicting inputs.
  • [ ] Proved metric-to-trace-to-log-to-profile-to-deployment navigation.
  • [ ] Recorded exact source and target queries plus absolute time at every hop.
  • [ ] Proved mismatched environment no-match and cross-tenant denial.
  • [ ] Verified correlation definitions are versioned, revocable, and do not contain credentials.

Sources

Attribute stability and Grafana link behaviour evolve, so primary specifications and documentation govern implementation. These sources support the lesson: