Git, CI/CD & GitOpsCVII · Production Infrastructure Delivery ArchitectureObservability
The observability flow — what we see and what we do not
What you'll learn
- Identify the four signals of observability: metrics, logs, traces, audit trail
- Distinguish what observability answers (what is happening) from what auditability answers (why it is running)
- Recognise the gap between observability and auditability in incident reconstruction
- Design a unified observability and audit pipeline that closes the why gap
Prerequisites
Verified against Git 2.55.x teaching target; 2.40+ minimum · GitHub Actions continuous service; Aug 2026 documentation baseline · Argo CD v3.5.x teaching target; v3.0+ minimum · Flux v2.9.x · Sigstore Cosign v3.1.x · SLSA v1.2 · OCI Distribution Specification v1.1 · Git LFS v3.7.1 · Kubernetes (cross-course target) 1.36.x
Observability and auditability are often conflated, but they answer different questions. Observability answers “what is happening?” - what the system is doing now, what it did ten seconds ago, what it did last Tuesday at 14:23. Auditability answers “why is this running?”
- which commit, which pipeline, which approver, which rationale. A team with rich observability but no auditability sees the symptom but not the cause. A team with auditability but no observability has the history of decisions but no view of the runtime. The reference architecture requires both; the unification is the audit trail.
The four signals
flowchart LR
A["Cluster runtime"] -->|"emit"| B["Metrics"]
A -->|"emit"| C["Logs"]
A -->|"emit"| D["Traces"]
A -->|"annotations"| E["Audit trail\n(receipts)"]
B --> F["What is happening"]
C --> F
D --> F
E --> G["Why this is happening"]
The four signals:
- Metrics. Numerical samples aggregated over time: latency, error rate, throughput, saturation.
- Logs. Discrete events with a timestamp and payload.
- Traces. Distributed spans correlating a request across services.
- Audit trail. A reconstruction of decisions from receipts, PRs, and change tickets.
The first three are runtime signals; the fourth is a derived signal whose source is the receipts stamped at apply time.
What observability sees
Observability sees the runtime. A Prometheus query returns a time series of latency samples. A Loki query returns log lines. A Tempo query returns a trace. None tells the auditor why the latency spiked at 14:23.
NS=payments
APP=checkout
PROMETHEUS=https://prom.example.com
curl -G --data-urlencode "query=histogram_quantile(0.99, sum by (le) (rate(http_request_duration_seconds_bucket{app=\"$APP\",ns=\"$NS\"}[5m])))" \
"$PROMETHEUS/api/v1/query" | jq .
The query returns a percentile; the operator’s next question is “why?”. The query engine does not answer; observability was never designed to.
What auditability sees
Auditability sees the decisions. The receipts on the running resources record what was applied and when. The PRs record what was reviewed and by whom. The change tickets record what was approved and why.
NS=payments
APP=checkout
kubectl get deployment "$APP" -n "$NS" \
-o jsonpath='{.items[*].metadata.annotations.deploy\.time/revision}'
The output is the commit SHA. From there, the auditor walks to the commit, the PR, the approver, and the ticket.
The unification
The unification is a queryable audit trail whose
entries are joined on a common key. The key is the
receipt’s revision annotation: the commit SHA.
Given a runtime anomaly (spike in error rate), the
operator queries the audit trail for receipts with that
revision and retrieves the PR, the approver, and the
rationale. Given an audit question (which commit is
running?), the auditor queries the runtime for the
receipt.
APP=checkout
NS=payments
REV=$(kubectl get deployment "$APP" -n "$NS" \
-o jsonpath='{.items[*].metadata.annotations.deploy\.time/revision}')
echo "running commit: $REV"
gh pr list --state merged --search "$REV" --json url,title,number,mergedBy,body
The first reads the receipt; the second queries the forge. The join key is the commit SHA.
A team that has observability and auditability but does not join them has two parallel systems that cannot answer questions that span both.
Production discipline
- Observability and auditability are separate systems with a join key. Do not collapse them; the join key is what closes the gap.
- Receipts are stamped at apply time, not retroactively. A receipt stamped after an incident is a receipt whose contents the operator chose.
- The audit trail is queryable, not human-readable. A wiki page is not an audit trail.
Cross-course references
- This course, Part LXIV (Auditability) - the six links the audit trail walks.
- This course, Part CVI (ChangeMgmt) - the change record whose queries feed the audit trail.
- Kubernetes for Production Sysadmins - Parts XXXVIII-XL cover the runtime signals and the audit annotations.
Quiz
Knowledge check · 4 questions
Q1. A team has rich observability: Prometheus, Loki, Tempo, and Grafana. Six months after a production incident, an auditor asks 'why is this running?'. What does observability not answer?
Q2. Observability and auditability are the same plane in the reference architecture.
Q3. Name the four signals of observability and the join key that unifies observability and auditability.
Q4. Diagnose the observability-auditability gap and recommend the join.
A team has Prometheus, Loki, Tempo, and Grafana. Six months after a deployment, an auditor runs the reconstruction drill. The auditor reads the `deploy.time/revision` annotation and walks to the PR. The PR description is empty and the linked Jira ticket is archived. The on-call says: 'I can show you the latency, error rate, and trace, but I cannot tell you why this version was chosen.'
Passing score: 75%. Answers are checked in this browser.