Time Series

A time series associates observations with timestamps. In operational monitoring, each observation usually contains a numeric value, while identifying attributes describe what was measured and where it originated. For example, CPU utilization sampled every minute for one virtual machine forms a time series. The same measurement for another virtual machine forms a different series. Samples can arrive regularly or irregularly; evenly spaced measurements are common, but they are not required by the concept.

Series identity is fundamental. Monitoring systems typically combine a metric name with attributes such as service, instance, environment, or region. In Amazon CloudWatch, within an AWS account and Region, a metric is uniquely identified by its namespace, metric name, and complete set of dimensions. A namespace groups related metrics, while dimensions are name-value pairs that distinguish series. For example, a custom namespace named Checkout, a metric named RequestLatency, and dimensions Environment=production and Operation=payment identify one metric. Changing or adding a dimension creates a different metric rather than updating descriptive metadata on the existing one.

This distinction affects aggregation. CloudWatch does not automatically aggregate custom metrics across dimension combinations. Publishing separate series for individual instances does not automatically create a dimensionless fleet-wide metric. Engineers must explicitly publish suitable aggregate metrics or query the individual series using supported mechanisms such as metric math or Metrics Insights. Some AWS services publish metrics with multiple dimension combinations, but this behavior should not be assumed for custom metrics.

Collection interval, storage resolution, and query period describe different choices. Collection interval determines how often a producer measures or sends data. Storage resolution determines the supported granularity of stored measurements. A query period groups observations into time windows for statistics. CloudWatch custom metrics support standard resolution of 60 seconds and high resolution of 1 second, selected through StorageResolution. Selecting high resolution does not make a producer collect more frequently; the producer must actually supply finer-grained measurements.

Aggregation changes what a chart or alarm reveals. A five-minute average can hide a ten-second CPU spike, whereas a maximum can expose it. For request counts published as interval totals, Sum usually answers how many requests occurred. For a cumulative counter, calculate an appropriate increase or rate while accounting for resets rather than summing successive counter readings. Latency percentiles can expose slow requests that averages conceal, but an average of instance-level percentiles is not a valid fleet-wide percentile. Preserve raw observations or a suitable distribution representation when percentile analysis is required.

Retention also changes available detail. CloudWatch retains data points with periods below 60 seconds for three hours, one-minute data for 15 days, five-minute data for 63 days, and one-hour data for 455 days. Older data is aggregated into coarser periods, so a long-term graph cannot recover the original second-level behavior. Export or independently retain measurements when investigations require longer access to fine-grained history.

Dimension design introduces a cost and scalability trade-off called cardinality: the number of distinct series. Stable attributes such as deployment environment and operation are often useful, while request IDs or unbounded customer identifiers can create excessive numbers of metrics. Keep detailed event context in logs and extract bounded operational measurements for metrics. Finally, missing data is not automatically zero: it might indicate an idle workload, a failed collector, delayed delivery, or a stopped resource. Align timestamps, synchronize clocks, and configure alarm missing-data behavior according to the measurement's meaning.