What is cloud monitoring?

What is cloud monitoring?

Cloud monitoring is the continuous collection and review of metrics, logs, traces and events from workloads and managed services running on a public cloud such as AWS, Google Cloud or Azure, or on a hybrid mix. The data feeds dashboards, alerts and incident workflows, so a team knows when a service is unhealthy, slow or costing more than expected, and where to look first.

How cloud monitoring differs from on-prem monitoring and APM

• Cloud monitoring reads provider-native sources (CloudWatch, Google Cloud Monitoring, Azure Monitor, load balancer and database metrics) and copes with short-lived compute such as containers and functions. Tags (account, region, service, environment) drive the grouping, because the individual host keeps changing.
• On-prem monitoring watches fixed hardware, usually with per-host agents and protocols such as SNMP.
• Application performance monitoring instruments your code and reports latency and errors per endpoint, wherever it runs.

Most cloud teams need the first and the third together: cloud monitoring for the infrastructure, APM for the application. Observability is the broader practice of using all these signals to investigate problems you did not predict.

What cloud monitoring covers

• Compute: VM CPU, memory and disk; container counts, restarts and pending pods.
• Managed services: database connections and latency, cache hit rate and evictions, queue depth, object storage errors, load balancer target response time.
• Serverless: function invocations, duration, errors, throttles and concurrency.
• Network and edge: CDN cache hit rate, NAT and VPC traffic, DNS query volume.
• Cost: daily spend per account, service or tag, with alerts when it jumps. See cloud governance for the policy side.
• Security and audit: audit-trail events and threat-detection findings, as an early warning rather than a replacement for a security tool.

Key cloud monitoring metrics

1. Availability per service: healthy target count, instance state, rolled up to the target you promise users.
2. Latency per component: load balancer response time at p50, p95 and p99, database query latency.
3. Error rate per layer: 5xx counts at the load balancer, function errors, dead-letter queue depth.
4. Saturation: CPU and credit balance on burstable instances, database connection usage, cache evictions, autoscaling group desired versus in-service.
5. Throughput: requests per second per service, messages per minute through queues and streams.
6. Cost per request: spend divided by useful work, a long-term efficiency measure.

How to run cloud monitoring

Start with the provider's own metrics and send them to one place you will actually look at, whether that is the provider's console or a central backend such as Grafana or Datadog. Tag every resource consistently (service, environment, team, cost center) so one dashboard query can slice by any of them. Add logs and traces next. Route alerts to an on-call tool, one rotation per service, and alert on symptoms users feel (errors, latency) before causes (CPU). Review metrics and alerts now and then and delete the ones nobody owns: custom metrics and log volume are billed by most providers.

Cloud dashboards only show what happens inside your account. Synthetic monitoring checks the service from outside, the way a user reaches it, and API monitoring does the same for endpoints. LoadFocus API monitoring checks status codes, response bodies and latency on a schedule from 25 cloud regions, with alerts to email, Slack, Microsoft Teams, PagerDuty and other channels. For more on what to watch and alert on, see monitoring best practices for DevOps teams.

Cloud monitoring and load testing

Monitoring tells you how the system behaves today. Load testing and spike testing show how it behaves under traffic you have not seen yet. Run the test from outside your network, watch the cloud dashboards while it runs, and note which component saturates first: database connections, autoscaling lag or queue depth. LoadFocus load testing runs JMeter, k6 and no-code tests from 25 cloud regions, so the timestamps of a run line up with your dashboards.

Common cloud monitoring mistakes

• Inconsistent tags. Untagged resources vanish from every filtered dashboard and cost report.
• Alerting on every metric. Noisy alerts get muted. Page on user-visible symptoms and keep the rest as dashboards.
• Only monitoring from inside. A healthy dashboard does not prove users can reach the service.
• Averages only. A fine average latency can hide a slow tail. Watch percentiles.
• Forgetting the monitoring bill. Log ingestion and custom metrics grow quietly. Review them.

FAQ: Cloud monitoring

What is the difference between cloud monitoring and observability?

Cloud monitoring watches known signals and alerts when they cross a threshold. Observability is the ability to ask new questions of your metrics, logs and traces when something unexpected breaks. Monitoring feeds observability.

Is the provider's built-in monitoring enough?

It is the right starting point, and for a single cloud it can be enough. Teams usually add an outside check, because provider tools see inside the account but not what a user in another region experiences, and a central backend if they run more than one cloud.

What should I alert on first?

Availability and error rate of the user-facing service, then latency percentiles, then saturation of the shared resources behind it such as database connections and queues.

Does cloud monitoring replace APM?

No. Cloud monitoring shows the health of infrastructure and managed services. APM shows which endpoint or code path is slow. They answer different questions.

How do I keep cloud monitoring costs down?

Tag resources so you can see who owns what, remove metrics and logs nobody reads, set retention periods, and avoid high-cardinality labels on custom metrics.