DevOps Monitoring and Logging Syllabus

Monitoring and Logging syllabus — full chapter and topic list

Expand any chapter to see its topics and sub-topics. This is the whole examinable outline for Monitoring and Logging in DevOps, not a summary of it.

1. 1

   Introduction to Monitoring

   2 topics

   • Monitoring Concepts and Practices
   • Benefits of Monitoring
2. 2

   Monitoring Tools

   4 topics

   • Prometheus
   • Grafana
   • Nagios
   • Datadog
3. 3

   Introduction to Logging

   2 topics

   • Logging Concepts and Practices
   • Benefits of Logging
4. 4

   Logging Tools

   3 topics

   • ELK Stack (Elasticsearch, Logstash, Kibana)
   • Splunk
   • Graylog

Monitoring and Logging flashcards for DevOps

19 of 51 cards from the Monitoring and Logging deck — real questions with worked answers.

1. What is monitoring in the context of DevOps and IT systems?

   Monitoring is the continuous, automated collection, aggregation, and analysis of metrics and signals from systems and applications to observe their health, performance, and availability, and to detect or alert on abnormal conditions.

2. What are the three pillars of observability?

   Metrics, logs, and traces. Metrics are numeric measurements over time, logs are timestamped records of discrete events, and traces follow a request across services.

3. How does monitoring differ from observability?

   Monitoring tells you whether a system is working (watching predefined metrics/alerts for known failure modes), while observability is the ability to understand the internal state of a system from its outputs, including diagnosing unknown/unexpected problems.

4. What is the difference between white-box and black-box monitoring?

   White-box monitoring uses internal signals exposed by the system (metrics, logs, instrumentation). Black-box monitoring tests the system externally as a user would (e.g., probing an endpoint) without knowledge of internals.

5. What are the four 'golden signals' of monitoring defined by Google SRE?

   Latency, Traffic, Errors, and Saturation.

6. What does the USE method focus on for monitoring resources?

   For every resource, monitor Utilization, Saturation, and Errors. It is well-suited to infrastructure/hardware resources like CPU, memory, and disks.

7. What does the RED method monitor for services?

   Rate (requests per second), Errors (number/rate of failed requests), and Duration (latency distribution of requests). It is request-centric and suited to microservices.

8. How is system availability typically calculated as a formula?

   $$\text{Availability} = \frac{\text{MTBF}}{\text{MTBF} + \text{MTTR}}$$ where MTBF is mean time between failures and MTTR is mean time to repair.

9. How is availability expressed using uptime and downtime?

   $$\text{Availability} = \frac{\text{Uptime}}{\text{Uptime} + \text{Downtime}}$$ usually expressed as a percentage (e.g., 'three nines' = $99.9\%$).

10. Approximately how much downtime per year does each availability 'nines' level allow?

    $99\%$ (two nines) $\approx 3.65$ days/year; $99.9\%$ (three nines) $\approx 8.76$ hours/year; $99.99\%$ (four nines) $\approx 52.6$ minutes/year; $99.999\%$ (five nines) $\approx 5.26$ minutes/year.

11. Define MTTR, MTBF, and MTTF.

    MTTR (Mean Time To Repair/Recovery) is the average time to restore service after a failure. MTBF (Mean Time Between Failures) is the average operational time between failures. MTTF (Mean Time To Failure) is the average lifespan of a non-repairable component until it fails.

12. What is an error rate and how is it computed?

    The error rate is the fraction of requests that fail: $$\text{Error rate} = \frac{\text{Failed requests}}{\text{Total requests}} \times 100\%.$$

13. What is a percentile latency such as p95 or p99, and why is it preferred over the mean?

    The pN latency is the value below which N% of requests complete (e.g., p99 = 99% of requests are faster). Percentiles are preferred over the mean because they expose tail latency / worst-case user experience that averages hide.

14. Define SLI, SLO, and SLA.

    SLI (Service Level Indicator) is a measured metric of service quality (e.g., availability). SLO (Service Level Objective) is the target value/range for an SLI. SLA (Service Level Agreement) is a contractual commitment to customers, often with penalties, built on SLOs.

15. What is an error budget and how is it derived from an SLO?

    An error budget is the allowed amount of unreliability: $$\text{Error budget} = 1 - \text{SLO}.$$ For a $99.9\%$ availability SLO, the error budget is $0.1\%$ of time/requests in which failures are tolerated before action is required.

16. What is the difference between proactive and reactive monitoring?

    Proactive monitoring predicts and prevents issues before they impact users (trend analysis, capacity forecasting, synthetic checks). Reactive monitoring responds to problems after they occur via alerts and incident response.

17. List several key benefits of monitoring.

    Early detection of issues, reduced downtime (lower MTTR), improved performance and capacity planning, better reliability/availability, faster root-cause analysis, data-driven decisions, and meeting SLAs.

18. What is alert fatigue and how is it mitigated?

    Alert fatigue is desensitization caused by too many alerts (especially false positives), leading engineers to ignore them. It is mitigated by alerting on symptoms not causes, tuning thresholds, deduplication, grouping, and prioritizing actionable alerts.

19. What is the difference between a metric, a threshold, and an alert?

    A metric is a measured value over time; a threshold is a boundary value that defines acceptable behavior; an alert is a notification triggered when a metric crosses its threshold (or meets an alerting condition).

See more Monitoring and Logging flashcards →

Planning Monitoring and Logging for DevOps

Monitoring and Logging (DevOps) FAQ