Cloud workloads need monitoring beyond traditional server metrics. The combination of managed services, ephemeral infrastructure, and distributed systems makes "is the server up?" insufficient.
Modern monitoring uses three pillars: metrics, logs, traces. Plus alarming on top. This page covers what to instrument and how to choose tooling.
Numerical measurements over time: request rate, error rate, latency, CPU, memory, queue depth.
Time-series databases (CloudWatch, Prometheus, Datadog) store metrics. Dashboards visualize. Alarms fire on threshold crossings.
For cloud workloads, monitor at multiple layers:
The four golden signals (Google SRE):
If you have these for each service, you cover most operational concerns.
Discrete events with detail. Application logs, access logs, error logs.
Modern logs are structured (JSON) so they can be queried:
{
"timestamp": "2026-04-26T12:00:00Z",
"level": "ERROR",
"service": "orders",
"request_id": "abc123",
"user_id": "u456",
"message": "Order validation failed",
"error": "amount must be positive"
}
Log aggregators (CloudWatch Logs Insights, Datadog Logs, ELK stack) index and query at scale. Without aggregation, logs across many instances are unmanageable.
Records of requests across multiple services. Each service contributes spans; the trace is the assembled tree.
Distributed tracing tools (AWS X-Ray, Datadog APM, Jaeger, OpenTelemetry) link spans across services. Essential for debugging in microservices.
A trace shows:
For services that span multiple components, traces are the tool that makes debugging tractable.
Alarms convert metrics to notifications. The hard part: making alarms actionable, not noisy.
Good alarms:
Bad alarms:
Alarm fatigue is real; teams ignore alarms that fire too often. Tune aggressively.
CloudWatch covers metrics, logs, alarms, dashboards, basic tracing (X-Ray).
Pros:
Cons:
For pure-AWS workloads, CloudWatch covers a lot. For multi-cloud or sophisticated needs, dedicated platforms are better.
The premium option. Comprehensive: metrics, logs, traces, RUM, security. Excellent UX. Expensive.
Use when you have the budget and need the breadth of features.
Open-source stack for self-hosting. Loki for logs, Tempo for traces, Prometheus for metrics, Grafana for visualization.
Use when self-hosting is feasible and budget is constrained.
Mature alternatives to Datadog. Each has different strengths; evaluate based on specific needs.
OpenTelemetry (OTel) is the emerging standard for instrumentation. Vendor-neutral SDKs and protocols.
The shift: instrument code with OTel; send to any compatible backend (Datadog, Grafana, Honeycomb, etc.). Switching backends doesn't require re-instrumenting.
For new projects, instrument with OTel from day one.
Monitoring costs grow with:
At scale, monitoring can be 5-15% of cloud spend. Manage by:
For a new cloud workload:
Skip the rest until needed.