Monitoring & Logging Cheat Sheet

Updated 2026-04-28

Next Topic: New Relic Observability Platform Cheat Sheet

🧠Study flashcards on this topic120 cards · spaced repetition→

Monitoring and logging form the visibility layer of modern infrastructure, enabling teams to understand system behavior, diagnose failures, and optimize performance. Observability—the ability to infer internal system state from external outputs—organizes four signals: metrics (quantitative time-series), logs (timestamped event records), traces (distributed request paths), and profiles (continuous CPU/memory sampling) into a coherent framework. In 2026, eBPF-based zero-code instrumentation and OpenTelemetry standardization have fundamentally changed how telemetry is collected, removing the need to instrument every service manually. Effective monitoring still requires balancing signal-to-noise ratio: collecting enough data to answer unknown questions, but not so much that costs explode or engineers drown in alerts.

What This Cheat Sheet Covers

This topic spans 34 focused tables and 175 indexed concepts, 120 flashcards. Below is a complete table-by-table outline of this topic, spanning foundational concepts through advanced details.

Table 1: The Four Signals of ObservabilityTable 2: Metric Types and Use CasesTable 3: Log Levels and When to Use ThemTable 4: Structured Logging Best PracticesTable 5: Distributed Tracing ConceptsTable 6: Trace Sampling StrategiesTable 7: Context Propagation StandardsTable 8: Monitoring MethodologiesTable 9: Service Level Objectives (SLOs)Table 10: Metrics Collection ModelsTable 11: Percentiles for Latency AnalysisTable 12: Metric Cardinality ManagementTable 13: Alerting StrategiesTable 14: Alert Notification and RoutingTable 15: Time Series DatabasesTable 16: Log Aggregation PlatformsTable 17: Distributed Tracing BackendsTable 18: Log Shippers and ForwardersTable 19: OpenTelemetry ComponentsTable 20: Application Performance Monitoring (APM)Table 21: Alerting and Incident Management PlatformsTable 22: Monitoring as Code and ConfigurationTable 23: Synthetic MonitoringTable 24: Blackbox vs Whitebox MonitoringTable 25: Log Retention and Storage LifecycleTable 26: Dashboard Best PracticesTable 27: Compliance and Audit LoggingTable 28: Observability Anti-Patterns to AvoidTable 29: Cost Optimization StrategiesTable 30: Continuous ProfilingTable 31: eBPF ObservabilityTable 32: Real User Monitoring (RUM)Table 33: DORA MetricsTable 34: AIOps and AI-Powered Observability

Quick IndexSubscribe to unlock

A jump-to index of every table row in this cheat sheet.

Mind MapSubscribe to unlock

An interactive map of every table and concept in this topic.

Table 1: The Four Signals of Observability

Everything else in this cheat sheet sits on top of four telemetry signals. Metrics tell you what is happening at a glance, logs tell you what happened in detail, traces tell you where a request spent its time, and profiles — the newest addition — tell you why the code itself is slow. Knowing which signal answers which question is the foundation of debugging distributed systems.

Signal	Example	Description
Metrics	`http_requests_total{method="GET", status="200"} 1547`	• Numerical measurements aggregated over time • low-cardinality time-series ideal for dashboards, alerts, and trend analysis.
Logs	`2026-03-03T15:04:05Z ERROR user=12345 msg="payment failed" amount=99.99`	• Timestamped text records of discrete events • provide detailed context for debugging specific failures and understanding application behavior.
Traces	Spans showing request flow: `frontend→auth→payment→db` with latencies	• Visual representation of request execution across distributed services • reveal causal relationships and identify latency bottlenecks in microservices.
Profiles	Flame graph showing 40% CPU in `processPayment()` function	• Continuous sampling of CPU, memory, and goroutine stacks down to line of code • the fourth OTel signal; reveals why code is slow or resource-hungry, not just that it is.

Table 2: Metric Types and Use Cases

Not all numbers behave the same way, and picking the wrong metric type produces misleading dashboards. Counters only ever climb (you read them with rate()), gauges go up and down to snapshot a current value, and histograms and summaries capture distributions so you can compute percentiles — the difference between the two comes down to where the math happens and whether you can aggregate across instances.

Type	Example	Description
Counter	`requests_total{endpoint="/api/users"} 15823`	• Monotonically increasing value that only goes up (or resets to zero) • ideal for rates: requests/sec, errors, or bytes transferred via `rate()`.

The rest of this section is part of the full cheat sheet

Table 3: Log Levels and When to Use Them

Log levels are a severity dial that lets you filter noise from signal — and choosing the right one for each message is a small but consequential discipline. DEBUG is for local development, INFO and WARN narrate normal and degraded operation, while ERROR and FATAL flag failures that need a human. Logging at the wrong level either buries real problems or explodes your storage bill.

Level	Example	Description
DEBUG	`DEBUG user_id=789 cache_hit=true query_ms=12`	• Verbose diagnostic information for local development • disable in production to avoid storage costs and performance impact.

The rest of this section is part of the full cheat sheet

Table 4: Structured Logging Best Practices

Logs are only useful at scale if a machine can parse them, which is why structured (usually JSON) logging has become the norm. Consistent field names, enrichment with trace and version context, redaction of secrets, and flattening of nested objects all make logs searchable and correlatable across services — turning a wall of text into a queryable dataset.

Practice	Example	Description
JSON format	`{"level":"error","user_id":123,"msg":"auth failed"}`	• Machine-parseable format enabling efficient querying and filtering • consistent field extraction across all log aggregators.

The rest of this section is part of the full cheat sheet

Table 1: The Four Signals of Observability

Signal	Example	Description
Metrics	`http_requests_total{method="GET", status="200"} 1547`	• Numerical measurements aggregated over time • low-cardinality time-series ideal for dashboards, alerts, and trend analysis.
Logs	`2026-03-03T15:04:05Z ERROR user=12345 msg="payment failed" amount=99.99`	• Timestamped text records of discrete events • provide detailed context for debugging specific failures and understanding application behavior.
Traces	Spans showing request flow: `frontend→auth→payment→db` with latencies	• Visual representation of request execution across distributed services • reveal causal relationships and identify latency bottlenecks in microservices.
Profiles	Flame graph showing 40% CPU in `processPayment()` function	• Continuous sampling of CPU, memory, and goroutine stacks down to line of code • the fourth OTel signal; reveals why code is slow or resource-hungry, not just that it is.

Table 2: Metric Types and Use Cases

Type	Example	Description
Counter	`requests_total{endpoint="/api/users"} 15823`	• Monotonically increasing value that only goes up (or resets to zero) • ideal for rates: requests/sec, errors, or bytes transferred via `rate()`.

Table 3: Log Levels and When to Use Them

Level	Example	Description
DEBUG	`DEBUG user_id=789 cache_hit=true query_ms=12`	• Verbose diagnostic information for local development • disable in production to avoid storage costs and performance impact.

Table 4: Structured Logging Best Practices

Practice	Example	Description
JSON format	`{"level":"error","user_id":123,"msg":"auth failed"}`	• Machine-parseable format enabling efficient querying and filtering • consistent field extraction across all log aggregators.