CS Techie
Comments
courseAWS

CloudWatch Metrics And CloudWatch Alarms

CloudWatch Metrics — Overview

CloudWatch Metrics are numerical time-series data points that describe the performance and health of AWS resources and applications. You use metrics to observe trends, detect anomalies, and drive alarms and dashboards.

Metric types

  • AWS metrics: emitted automatically by AWS services (EC2 CPUUtilization, RDS FreeStorageSpace).
  • Custom metrics: published by you via PutMetricData, SDKs, CloudWatch agent, or Embedded Metric Format (EMF).
  • High-resolution metrics: 1-second granularity for latency-sensitive telemetry.
  • Distributed metrics via integrations: Container Insights, Lambda insights, Application/Host agents.

Metric structure

  • Namespace: logical container (e.g., AWS/EC2 or MyApp).
  • Metric name: identifier for the measurement (e.g., RequestCount).
  • Dimensions: key/value pairs to slice metrics (InstanceId, AutoScalingGroup).
  • Unit: optional (Seconds, Bytes, Percent).
  • Timestamp: when the measurement occurred.

Statistics & aggregates

  • Basic statistics: SampleCount, Sum, Minimum, Maximum, Average.
  • Percentiles: pNN (e.g., p90, p99) for latency distributions.
  • Metric math: combine metrics with arithmetic and functions (SUM, AVG, RATE, INSIGHT_RULE, etc.) to create derived metrics.
  • Resolution: standard (60s) and high-resolution (1s). Use the proper resolution for your workload.

Retention and granularity

  • High-resolution (1s) data: retained at 1‑second granularity for 3 hours.
  • 1‑minute data: retained for 15 days.
  • 5‑minute aggregates: retained for 63 days.
  • 1‑hour aggregates: retained for 455 days (15 months).

How to publish

  • PutMetricData API / AWS CLI.
  • CloudWatch Agent (EC2/ECS/EKS) and CloudWatch Logs + EMF.
  • SDKs from applications.
  • Service integrations (Lambda, ELB, RDS, etc.).

Common monitoring targets (examples)

  • EC2: CPUUtilization, DiskReadOps, NetworkIn.
  • ALB/ELB: RequestCount, TargetResponseTime, HTTPCode_Target_5XX_Count.
  • RDS: CPUUtilization, FreeStorageSpace, DatabaseConnections.
  • Lambda: Duration, Invocations, Errors, Throttles.
  • Kinesis: GetRecords.IteratorAgeMilliseconds, IncomingRecords.



CloudWatch Alarms — Overview

CloudWatch Alarms evaluate metric data against thresholds and trigger actions when conditions occur. Use alarms to notify teams or automate remediation.

Alarm types

  • Metric alarms: single metric or metric math expressions.
  • Composite alarms: boolean combinations of other alarms (AND/OR/NOT) to reduce noise and express complex conditions.
  • Anomaly detection alarms: dynamic thresholds created from a model trained on historical metric data.

Alarm states

  • OK — metric is within the configured threshold.
  • ALARM — metric breaches the threshold.
  • INSUFFICIENT_DATA — not enough data to determine state (can be for new metrics or missing samples).

Core configuration settings

  • Metric (or metric math expression) and namespace.
  • Statistic or percentile (Average, Sum, p99, etc.).
  • Period: evaluation interval in seconds (e.g., 60).
  • EvaluationPeriods: number of consecutive periods to evaluate.
  • DatapointsToAlarm: number of datapoints within evaluation periods that must breach (for resilient detection).
  • Comparison operator: GreaterThanThreshold, LessThanThreshold, etc.
  • TreatMissingData: how missing samples affect the alarm (missing, ignore, breaching, notBreaching).

Alarm actions

  • Notification: SNS topic for email, pager, webhook.
  • Auto Scaling: scale out/in actions.
  • EC2 actions: recover or stop/terminate instances (when supported).
  • Systems Manager: runbooks via EventBridge or SSM Automation for remediation.
  • EventBridge (CloudWatch Events): route alarm transitions to custom workflows, Lambda, or Step Functions.

Best practices for alarms

  • Alert on symptoms, not noise. Monitor error rates or SLO breaches rather than single resource spikes.
  • Use appropriate period and evaluation windows to avoid flapping. Short period for fast signals; longer windows for noisy metrics.
  • Use DatapointsToAlarm to avoid false positives on transient spikes.
  • Use composite alarms to suppress low-value alerts and combine related conditions.
  • Apply anomaly detection for metrics with strong seasonality or variable baselines.
  • Ensure alarms have clear runbooks and links to dashboards and logs.
  • Use tags and naming conventions for ownership and routing.
  • Use dashboards to provide context for alarms (recent metric history, related logs/traces).