Metrics + logs + traces
symptom ↓ scope ↓ hypotheses ↓ correlated evidence
DevOps · Operate · Diagnose · Reliability
Observability Fundamentals
Understand what a running system is doing and diagnose failures from evidence. Build from telemetry mental models through metrics and Prometheus, PromQL, Grafana, structured logs, OpenTelemetry and tracing, then correlate signals into actionable alerts, SLOs and a production-shaped incident investigation.
My Learning progress
0% complete
0 of 12 curriculum modules completed · 0/12 currently published modules complete · 0 with lab + knowledge-check evidence.
Investigation loop
Start with the symptom. Build and test hypotheses.
Observability is not a collection of dashboards. The course teaches a repeatable investigation loop that uses telemetry to narrow uncertainty and prove recovery.
Diagnose and verify
evidence ↓ mitigation + rollback ↓ numeric recovery criteria ↓ follow-up
Course modules
Build observability from signal design to reliability decisions.
01
Observability mental model and signals
Build the mental model: observability uses telemetry and system context to answer questions about internal behavior, especially when the failure was not predicted in advance.
Open module →02Metrics and instrumentation
Understand counters, gauges, histograms, labels and cardinality so metrics describe behavior without overwhelming the monitoring system.
Open module →03Prometheus architecture and scraping
Learn the Prometheus pull model, scrape targets, service discovery concepts, time-series storage and why target health is part of telemetry reliability.
Open module →04PromQL for investigation
Use PromQL to turn raw time series into rates, ratios, grouped views and latency distributions without hiding the failing dimension.
Open module →05Grafana dashboards and visualization
Design dashboards that answer operational questions, preserve context and avoid decorative panels that encourage false certainty.
Open module →06Logs and structured events
Turn application events into searchable, correlatable evidence using levels, timestamps, stable fields and safe data-handling practices.
Open module →07OpenTelemetry and the Collector
Understand vendor-neutral telemetry APIs/SDKs, OTLP, semantic conventions and the Collector pipeline used to receive, process and export signals.
Open module →08Distributed tracing
Follow one request across services using traces, spans, parent-child relationships, attributes and status so latency and errors can be localized.
Open module →09Correlating metrics, logs and traces
Use shared dimensions, timestamps and trace identifiers to move from service-wide symptoms to one concrete failing request and back again.
Open module →10Alerting and incident diagnosis
Design alerts that are actionable, symptom-oriented and routed with enough context to begin diagnosis rather than merely announce that a threshold changed.
Open module →11SLIs, SLOs and error budgets
Connect telemetry to reliability objectives by defining measurable indicators, explicit targets and an error budget that informs risk decisions.
Open module →12Capstone — production incident diagnosis
Investigate a production-shaped checkout incident from synthetic metrics, logs, traces and an alert; reject a plausible wrong hypothesis, propose mitigation and prove recovery with numeric evidence.
Open module →Signals and tools
Learn the signal first; learn the tool in context.
Prometheus, Grafana and OpenTelemetry are concrete tools for transferable observability concepts. The core learning path does not require external services or credentials.
Signal / practiceQuestionPrimary toolingCourse emphasis
SignalMetricsQuestionWhat is changing across a population?ToolingPrometheus · PromQLEmphasisrates · ratios · histograms
SignalLogsQuestionWhat event happened and with what context?ToolingStructured eventsEmphasisstructure · safety · correlation
SignalTracesQuestionWhere did one request spend time?ToolingOpenTelemetryEmphasisspans · critical path · sampling
SignalSLOsQuestionIs reliability meeting the user target?ToolingSLIs · error budgetsEmphasistargets · budgets · decisions
Two lab modes
Prove the fundamentals before adding infrastructure.
Every core lab is local/account-free. A separate optional Docker Compose stack lets you inspect real Prometheus, Grafana and OpenTelemetry Collector behavior without affecting the main validation gate.
Account-free simulations
Bash, Python, JSON/CSV and synthetic telemetry teach metric types, cardinality, queries, correlation, SLO math and incident reasoning.
Real local tooling
Pinned Prometheus, Grafana and OpenTelemetry Collector containers expose health, targets, PromQL and OTLP ingestion. No cloud account is required.
Evidence boundary
Core simulations say what they simulate. Runtime validation is claimed only when the optional stack is actually executed.
Prerequisites
A shell and Python are enough for the core path.
Linux and networking basics are recommended. Docker/Kubernetes/Cloud courses provide useful context but are not mandatory.
Core lab OS
Linux, macOS, or Windows 11 with WSL2.
Required tools
bash, Python 3 and standard command-line utilities.
Optional tool stack
Docker Engine + Compose plugin. The stack is disposable and explicitly training-only.
Knowledge assessment
Prove you can interpret evidence, not just name tools.
The assessment selects 30 questions from an 84-question bank spanning foundations, metrics/Prometheus, PromQL/dashboards, structured logs, OpenTelemetry/tracing, alerting/SLOs and correlation/troubleshooting. Pass mark: 75%. Time limit: 35 minutes.
12 MODULES→30 RANDOM QUESTIONS · 35 MIN→PASS ≥ 75%→OPTIONAL CERTIFICATION
Maximum two attempts per 24 hours. Learning and assessment are free. A passing result enables the optional ₹499 GST-inclusive Certificate of Successful Completion pathway.
2–3 hour incident capstone
Diagnose a failure from metrics, logs, traces and alert evidence.
The capstone validator requires multi-signal evidence, a rejected competing hypothesis, rollback-ready mitigation and numeric recovery criteria. It deliberately rejects an unsupported CPU-saturation diagnosis.
Symptom→Hypotheses→Correlate evidence→Mitigate→Prove recovery