Capstone: the data-platform observability checklist

At a glance

Learning objectives

• Assemble the full stack — metrics, alerts, traces, lineage, catalog
• Gate schedule and column changes pre-merge with SLA and impact checks
• Run the incident drill from memory

What you need

• [object Object]
• Every surface from lessons 2-9 wired — metrics, alerts, lineage, catalog

Steps

1. Metrics layer — the metrics model and PromQL semantics pages settle how to express and alert on pipeline metrics. (from ref-prometheus-docs )
2. Alert layer — alerting semantics, no-data handling and evaluation intervals, documented in precise, citable terms. (from ref-grafana-docs )
3. Instrumentation layer — the semantic-conventions pages define standard attribute names worth citing exactly. (from ref-otel-docs )
4. Lineage layer — an open specification for lineage events, which is what makes cross-tool lineage possible. (from ref-openlineage-docs )
5. Catalog layer — the metadata model explains how to represent ownership and lineage consistently across tools. (from ref-datahub-docs )
6. Contract layer — every source carries a declared freshness SLA; changes that silently widen it are warned against. (from hook-freshness-pre-merge )
7. Change layer — before merging, walk the impact set from the changed node to the published marts; report owner, criticality, earliest SLA. (from skill-lineage-explainer )

Check yourself

• You can draw the stack — metrics, data signals, traces, lineage, catalog — and name one tool per layer.
• You can run the incident drill — breach, source, impact set, owner — without notes.

Worked example

□ Freshness SLA declared per source; staleness metric + alert rule
□ No-data handling explicit — silence pages, it does not pass
□ Evaluation interval chosen against the SLA window
□ Every rule names the SLA it defends

□ Lineage events emitted per job, queryable from the store
□ Technical and business lineage both readable for any asset
□ Column change → impact set before merge (owner, criticality, earliest SLA)

Sourced from

• Prometheus Documentation
• Grafana Documentation
• OpenTelemetry Documentation
• OpenLineage Documentation
• DataHub Documentation
• Freshness Pre-Merge Check
• Lineage Explainer

Security scan

Last sweep 2026-10-24: 0 finding(s), 0 marked as examples.

Common gotchas

• Every layer has a standard — metrics and traces (Prometheus, OpenTelemetry), lineage (OpenLineage), ownership (DataHub); inventing one per tool is how drift starts.
• A checklist skipped under deadline pressure is the incident you will have instead — automate the gates where possible.
• The pre-merge gates are the cheapest lines on the page — one prevented incident pays for all of it.

Production considerations

• Rehearse the incident drill quarterly — lineage reads fast only for people who have walked it.
• Review the checklist when a tool changes — the standards above move slowly, the integrations do not.

Diagram

the observability stack, gated
   |
   |- metrics (Prometheus) ── alerts (Grafana, no-data set)
   |- traces (OpenTelemetry, semantic conventions)
   |- lineage (OpenLineage events) ── catalog (DataHub: owner & SLA)
   |
   |- pre-merge gates:
   |     schedule change ──▶ worst-case lag vs declared SLA ──▶ warn
   |     column change   ──▶ impact set ──▶ owner, criticality, earliest SLA
   |
    --> pager pages a named owner about a breached contract

Registry stats