Observability Foundation study plan
Observability Foundation · Give each week a clear focus.
8 weeks · About 6 hours per week
Observability culture and principles (Three Pillars, why monitoring alone is not enough) & OpenTelemetry standards, distributed tracing, traces and spans
Define the three pillars (metrics, logs, traces) in your own words and contrast what each answers that the others cannot
Explain to a hypothetical colleague why threshold-based monitoring fails to explain novel failure modes, using a concrete example you construct
Map the OpenTelemetry signal types (traces, metrics, logs, baggage) to the pillar each one feeds and note where they overlap
Distinguish observability as a property of a system from monitoring as an activity performed on it
Your checkpoint
A one-page written primer (roughly 400 words) defining the three pillars, the monitoring-versus-observability distinction, and two failure scenarios where monitoring alone would miss the cause
OpenTelemetry standards, distributed tracing, traces and spans
Describe the anatomy of a trace: trace ID, span ID, parent-child relationships, and how context propagates across service boundaries
Differentiate span kinds (client, server, producer, consumer, internal) and identify which kind fits a given call pattern you invent
Explain sampling strategies (head-based, tail-based, probabilistic, rate-limiting) and the trade-offs each makes on cost versus diagnostic completeness
Trace a single user request through a three-service architecture you sketch, labeling every span and its parent
Your checkpoint
A hand-drawn or text-based trace diagram of a three-service request with every span labeled by kind, parent, and timing, plus a short paragraph justifying your sampling choice
OpenTelemetry standards, distributed tracing, traces and spans & Observability culture and principles (Three Pillars, why monitoring alone is not enough)
Write the semantic attributes you would attach to an HTTP server span and justify each against the OpenTelemetry semantic conventions
Explain how trace context links logs and metrics back to a single request (exemplars, log correlation IDs)
Identify what span status, events, and links are for and when to use events versus child spans
Describe the collector pipeline (receivers, processors, exporters) and where sampling and batching belong
Your checkpoint
A written instrumentation spec for one fictional service: span names, attributes, sampling policy, collector configuration outline, and the reasoning behind each decision
Full-stack observability, DevSecOps and AIOps impact on observability & Organizational observability maturity, network and container-level observability
Break down full-stack observability into its layers (infrastructure, network, container, application, user experience) and state what each layer can and cannot reveal
Explain how container orchestration changes observability: ephemeral identities, sidecar collection, and label-based correlation
Describe the network layer signals worth capturing (flow logs, DNS, latency, packet-level) and when packet capture is justified versus excessive
Articulate how DevSecOps shifts observability left: security telemetry, audit trails, and shift-left detection
Your checkpoint
A layered observability matrix (table) mapping each stack layer to its key signals, collection method, and a blind spot you accept at that layer
Full-stack observability, DevSecOps and AIOps impact on observability
Explain what AIOps adds to observability: anomaly detection, correlation, and noise reduction, and where it fails without good telemetry
Contrast rule-based alerting with ML-driven detection on false-positive behavior and explainability
Describe how AI-assisted investigation consumes traces, logs, and metrics differently and what data quality it demands
Identify the risks of over-trusting automated root-cause suggestions and the human-review checkpoints you would keep
Your checkpoint
A comparison write-up (roughly 350 words) of rule-based versus AIOps-driven alerting on one realistic incident, including where each approach would have helped or misled
Organizational observability maturity, network and container-level observability & Observability culture and principles (Three Pillars, why monitoring alone is not enough)
Define an observability maturity model with at least four levels and concrete criteria for advancing between them
Assess a fictional organization against your model and identify its single highest-leverage next step
Explain the cultural practices that make observability stick: blameless postmortems, shared dashboards, service ownership, and SLO review cadence
Connect SLOs and error budgets to observability investment decisions
Your checkpoint
A maturity self-assessment for a fictional 40-person engineering org, scoring each domain and naming the one initiative that would move it up a level
Observability culture and principles (Three Pillars, why monitoring alone is not enough) & OpenTelemetry standards, distributed tracing, traces and spans & Organizational observability maturity, network and container-level observability
Design an end-to-end observability architecture for a containerized, multi-service system, choosing collection points and sampling at each hop
Justify cost controls: retention tiers, sampling rates, cardinality limits, and which signals deserve full fidelity
Explain how to instrument a legacy service that cannot be rebuilt, using auto-instrumentation and proxies
Draft the alerting philosophy: which signals page a human, which create tickets, and which only feed dashboards
Your checkpoint
A complete architecture diagram with a written rationale (roughly 400 words) covering collection, sampling, retention, and alert routing decisions
Observability culture and principles (Three Pillars, why monitoring alone is not enough) & OpenTelemetry standards, distributed tracing, traces and spans & Full-stack observability, DevSecOps and AIOps impact on observability & Organizational observability maturity, network and container-level observability
Synthesize all four domains into a single incident narrative: detection, triage, root cause, and follow-up, naming the signal used at each step
Revisit and correct your week-one primer using everything learned, noting what you got wrong initially
Practice explaining observability trade-offs to a non-technical stakeholder in plain language
Build a personal checklist for evaluating an observability stack against the four domains
Your checkpoint
A full incident walkthrough document (roughly 500 words) tracing one failure from alert to postmortem, plus a revised one-page primer and a 10-item evaluation checklist
Milestones
Week 2: You can draw the span tree for any request you describe and correctly assign parent, kind, and timing to each span without notes
Week 4: Your layered matrix covers all five stack layers, and you can name at least one accepted blind spot per layer
Week 6: Your maturity model has four or more levels with falsifiable criteria, and your self-assessment names a single next step with a rationale
Week 8: Your incident walkthrough cites a specific signal from each of the four domains and your revised primer corrects at least two week-one misconceptions