Infrastructure Monitoring Basics: Metrics, Logs, Alerts and Uptime

Without monitoring, the first sign of trouble is usually a customer email. Infrastructure monitoring gives you the data to spot problems early, find their cause quickly and prove that fixes worked. This guide covers the four building blocks, metrics, logs, alerts and uptime checks, and shows how to assemble a sensible starter setup without drowning in dashboards.

Monitoring answers three questions #

It helps to think about monitoring in terms of the questions it must answer during an incident:

1. Is something wrong? Alerts and uptime checks tell you.
2. Where is it wrong? Metrics and dashboards narrow it down to a service, host or dependency.
3. Why is it wrong? Logs, and traces if you have them, show the specific errors and events.

Every tool and practice below exists to answer one of those questions faster.

Metrics: the numbers over time #

Metrics are numeric measurements sampled at intervals: CPU utilization every minute, requests per second, disk free space. They are cheap to store, fast to query and ideal for graphs and alert thresholds.

What to measure at each layer

Two helpful frameworks

The USE method (Utilization, Saturation, Errors) works well for resources such as CPUs, disks and network interfaces. The RED method (Rate, Errors, Duration) works well for request-driven services. Google’s Site Reliability Engineering book describes a similar set called the four golden signals: latency, traffic, errors and saturation. Any of these gives you a starting list so you do not have to invent one.

Watch latency percentiles rather than averages. An average response time can look healthy while one request in a hundred takes ten seconds.

Logs: the detailed record #

Logs are timestamped records of individual events: an HTTP request, an exception, a failed login. They carry the detail metrics cannot, which is why they answer the “why” question.

Make logs useful

• Centralize them. Logs scattered across servers are lost when an instance is replaced. Ship them to CloudWatch Logs, Azure Monitor Logs, Cloud Logging, or a self-hosted stack such as Grafana Loki or OpenSearch.
• Structure them. Write JSON with consistent fields (timestamp, level, service, request ID) so you can filter and aggregate rather than grep free text.
• Correlate them. Include a request or trace ID that follows a request across services.
• Keep secrets out. Never log passwords, tokens or full payment details.
• Set retention deliberately. Log ingestion and storage are often among the larger line items in an observability bill. Keep verbose debug logs briefly and audit logs longer.

Security-relevant logs, such as cloud audit trails, deserve separate handling and protection. Our cloud account security checklist covers which audit logs to enable and how to protect them.

A note on traces

Distributed tracing records the path of a single request through multiple services, with timing for each step. It becomes valuable once you run more than a handful of services. OpenTelemetry is the vendor-neutral standard for generating metrics, logs and traces, and most monitoring backends accept its data.

Alerts: turning data into action #

An alert should mean a human needs to do something. If an alert fires and the right response is to ignore it, that alert is training your team to ignore alerts.

Alert on symptoms, investigate causes

Page people for things users feel: elevated error rates, high latency, failed health checks, a job queue that stopped draining. Treat underlying causes, like high CPU on one host, as dashboard information or low-priority notifications unless they reliably predict an outage.

The thresholds above are illustrations. Derive yours from your own baseline and service level objectives.

Route alerts sensibly

• Separate urgent pages (phone, on-call tool) from informational notices (chat channel, email).
• Give each alert an owner and a short runbook link explaining what to check first.
• Use a duration window so brief spikes do not wake anyone.
• Review noisy alerts monthly and tune or delete them.

Include billing and budget alerts in the same routing. A sudden cost spike is an operational signal too, as our guide to cloud cost management explains.

Uptime checks: the outside view #

Internal metrics can look perfect while users cannot reach you, because of DNS errors, an expired TLS certificate or a routing problem. External uptime checks (also called synthetic or black-box monitoring) probe your public endpoints from several locations and alert when they fail.

• Check a real health endpoint that touches critical dependencies, not just a static page.
• Require failures from more than one location before alerting, to avoid false alarms from a single probe’s network.
• Monitor TLS certificate expiry and domain renewal dates.
• Consider a multi-step check for your most important user journey, such as login.

AWS CloudWatch Synthetics, Azure Monitor availability tests, Google Cloud uptime checks and DigitalOcean uptime checks all provide this, as do many independent services. Running the check from outside your own cloud is a useful safeguard.

Choosing tools #

Provider-native tools are the fastest start and integrate with managed services automatically. Prometheus is the common open source choice for metrics, especially around Kubernetes. Whatever you choose, instrumenting with OpenTelemetry keeps you free to switch backends later.

A starter setup for a small team #

1. Install the provider’s monitoring agent on every VM so memory and disk metrics are collected.
2. Build one dashboard per service showing request rate, error rate, latency and saturation.
3. Ship application logs centrally in structured JSON with a request ID.
4. Create an external uptime check for each public endpoint, plus TLS expiry monitoring.
5. Set three to five symptom-based alerts per service, each with an owner and a runbook link.
6. Add a billing budget alert and route it with the others.
7. Review alert noise and dashboard usefulness after the first month.

This setup is also the foundation you want in place before a move, as described in our cloud migration planning guide. For provider specifics, see the AWS documentation for CloudWatch and the DigitalOcean documentation for its monitoring and uptime features. Our AWS platform overview and DigitalOcean overview put those tools in context.

Frequently asked questions #

What is the difference between monitoring and observability?

Monitoring tracks known signals and alerts on known failure modes. Observability is the broader ability to understand unexpected behavior from the data your systems emit, usually metrics, logs and traces together. Good monitoring is the first step toward observability.

How many alerts should a service have?

Fewer than most teams start with. A handful of symptom-based alerts covering errors, latency, availability and resource exhaustion is usually enough. Every alert should be actionable.

Is the provider’s built-in infrastructure monitoring enough?

For many single-cloud workloads it is a solid start, especially with the guest agent installed. Teams often add open source or hosted tools later for multi-cloud visibility, longer retention or more flexible dashboards.

How long should I keep metrics and logs?

Keep high-resolution metrics for days to weeks and downsampled metrics for longer trend analysis. Keep application logs as long as they help debugging and any compliance rules require. Balance retention against storage cost.