We begin Chapter 24: Observability, one of the skills that most distinguishes a professional who knows how to operate in production. Having an application running is not enough: you need to know what's happening inside it at all times. Is it going well? Are there errors? Is it overloaded? That's what observability is for, and in AWS the central tool is CloudWatch. Let's start with its three pillars: logs, metrics, and alarms.

Imagine you have your application deployed in production. Users are using it. And suddenly... it starts to slow down, or some users report errors. Without observability, you are blind:

• How many errors are occurring? You don't know.
• Is the server overloaded with CPU? No idea.
• What exactly happened when it failed? There's no trace.
• When did the problem start? Impossible to know.

Operating like this is like driving with your eyes closed. Observability is the dashboard instruments of your application: they tell you what's happening, so you can react.

CloudWatch is the AWS observability service: it collects and displays information about the operation of your resources and applications. It's where you look to see if everything is going well. It has several components; in this subchapter we look at the three fundamental ones.

Logs are the text messages that your applications and services write about what they are doing. They are your application's journal:

CloudWatch Logs collects and stores these messages centrally. Instead of having logs scattered on each server (and losing them if the server shuts down), they all go to CloudWatch, where you can search, filter, and query them.

Analogy: logs are like the ship's logbook: the captain writes down everything that happens ("10:00 set sail", "12:00 storm in sight", "12:30 leak repaired"). If something goes wrong, you check the logbook to understand what happened and when. CloudWatch Logs is the place where all those logbooks are kept together, ready to consult.

Logs are your first tool when something fails: you go to the logs from the time of the failure and read what happened.

Metrics are numerical values measured over time: CPU usage, amount of memory, number of requests per second, errors per minute... While logs are text ("what happened"), metrics are numbers ("how much"):

CloudWatch automatically collects many metrics from your resources (EC2 CPU, ALB requests, Lambda invocations...) and you can send your own (business metrics, like "orders completed per minute"). With metrics you see trends and detect when something is out of the ordinary.

Analogy: metrics are like the dashboard indicators in a car: speed, RPM, engine temperature, fuel level. They are numbers you glance at to know if everything is okay. If the temperature needle rises too much, you know there's a problem before the engine breaks down.

Here's the piece that makes observability proactive. You can't be watching metrics 24 hours a day. An alarm monitors a metric for you and automatically notifies you when it crosses a threshold you define:

When an alarm is triggered, it can notify you (by email, Slack, etc., using SNS, remember subchapter 15.2) or even trigger an automatic action (like adding more servers with an Auto Scaling Group, remember subchapter 13.3).

Analogy: an alarm is like the red warning light on the dashboard that comes on when the engine temperature is dangerous, accompanied by a beep. You don't have to constantly watch the needle: the car alerts you when something important needs your attention.

The three pillars work as a team so you operate with your eyes open:

The typical incident flow: an alarm goes off ("high errors!"), you look at the metrics to see the scope and when it started, and you go to the logs from that moment to understand the exact cause and fix it.

Real-world example: an online store has an alarm on the "HTTP 500 errors" metric. On a Sunday night, a change introduces a bug and errors spike. The alarm goes off and notifies the on-call team via Slack in one minute. The engineer checks the metrics: errors started right after the last deployment, at 22:14. They go to the logs from 22:14 and see: "ERROR: 'price' field null in cart". In 10 minutes they identify and revert the change. Without observability, they would have found out the next morning from customer complaints and lost sales.

• Operating without observability is driving with your eyes closed; you need to know what's happening inside your application at all times.
• CloudWatch is AWS's observability service, with three fundamental pillars:
• Logs: the text messages your apps write ("what happened"), collected and queryable centrally. They are the logbook.
• Metrics: numerical values over time ("how much": CPU, requests, errors...). They are the dashboard indicators; they reveal trends.
• Alarms: monitor a metric and automatically alert you (or trigger actions) when it crosses a threshold. They are the red warning light that alerts you without having to look.
• They work as a team: alarms alert, metrics show the scope, logs explain the cause.

In the next subchapter, we'll see how to bring all these metrics together in visual panels with CloudWatch Dashboards.