Monitoring & Logging

With compute, storage, networking, IAM, and databases now covered, this chapter is about how you actually see what's happening across all of them. "Check the logs and metrics" is usually step one of any real investigation — this is genuinely foundational support-work material.

Metrics vs. Logs vs. Traces — Three Different Signals

Sometimes called the "three pillars of observability" — each answers a genuinely different question:

This chapter focuses mainly on metrics and logs — tracing is more specifically a distributed-systems/microservices topic, worth knowing exists but not covered in depth here.

The Terminology Map

• AWS — CloudWatch, with Metrics, Logs, and Alarms as its components.
• Azure — Azure Monitor, with Metrics, Log Analytics, and Alerts.
• GCP — Cloud Monitoring and Cloud Logging (formerly both branded "Stackdriver" — a rename still worth knowing, since older documentation and community content commonly still references the old name), plus Alerting policies.

What Gets Monitored Automatically vs. What You Have to Configure

Baseline infrastructure metrics — CPU, disk, network — are typically collected automatically for compute resources at a basic level. Application-level or custom metrics need to be explicitly instrumented and pushed by your own code — they don't appear on their own.

Log Aggregation

Rather than SSHing into individual instances to read local log files one by one, cloud logging services centralize logs from VMs, containers, and managed services into one searchable place. Organizing structures differ by name — log groups/streams (AWS), workspaces (Azure), logging buckets (GCP) — but the underlying idea is identical. Logs aren't kept forever by default; retention settings are configurable and directly affect storage cost, echoing Chapter 4's lifecycle-policy material and feeding directly into Chapter 9's cost chapter.

Querying Logs

Each provider has its own log query language — CloudWatch Logs Insights, Azure's KQL (Kusto Query Language), and GCP's Cloud Logging query language. Unlike SQL's broad portability across relational databases (Chapter 7), these are genuinely different syntaxes — another place where cross-provider knowledge doesn't transfer directly, worth flagging honestly rather than glossing over. The single most useful, universally applicable query pattern regardless of syntax: filtering by time range plus a specific error pattern or status code — the backbone of most real support investigations.

Alerting Basics

An alert defines a threshold or condition on a metric or log pattern that triggers a notification — email, SMS, chat integration, or paging. The right things to alert on are symptoms that actually matter to users — error rate, latency — rather than every possible internal metric a system happens to expose. Dashboards provide the "at a glance" view, built from the same underlying metrics as alerts.

A Support Workflow — Where to Look First

A practical two-step pattern: check the relevant metrics first for an obvious spike or drop around the reported time — a fast, high-level signal for narrowing down when and roughly where something went wrong. Then drill into logs for the specific detail once a rough time window and affected component are identified — logs explain what actually happened. Course 2's own cloud2-4 ("Reading Logs & Metrics Under Pressure") builds directly on this exact two-step pattern.

Hands-On Exercises