Metric Graphs 101: Timeseries Graphs | Datadog

Metric graphs 101: Timeseries graphs

Author John Matson

Published: 3月 1, 2016

This is the first post in a series about visualizing monitoring data. This post focuses on timeseries graphs.

Observability is not just about having monitoring data—that data must be easily available and interpretable. Choosing the right visualization for your data is an important part of providing human-readable representations of the health and performance of your systems. There is no one-size-fits-all solution: you can see different things in the same metric with different graph types.

To help you effectively visualize your metrics, this first post explores four different types of timeseries graphs, which have time on the x-axis and metric values on the y-axis:

For each graph type, we’ll explain how it works, when to use it, and when to use something else.

Line graphs

Line graph

Line graphs are the simplest way to translate metric data into visuals, but often they’re used by default when a different graph would be more appropriate. For instance, a graph of wildly fluctuating metrics from hundreds of hosts quickly becomes harder to disentangle than steel wool. It’s nearly impossible to draw any useful conclusions about your systems from a graph like that.

When to use line graphs

The same metric reported by different scopesTo spot outliers at a glanceCPU idle for each host in a cluster
CPU idle per host
Tracking single metrics from one source, or as an aggregateTo clearly communicate a key metric's evolution over timeMedian latency across all web servers
Median webapp latency
Metrics for which unaggregated values from a particular slice of your infrastructure are especially valuableTo spot individual deviations into unacceptable rangesDisk space utilization per database node
Disk space per node
Related metrics sharing the same unitsTo spot correlations within a systemLatency for disk reads and disk writes on the same machine
Read and write latency
Metrics that have a clear acceptable domainTo easily spot unacceptable degradationsLatency for processing web requests
Key page latency

When to use something else

WhatExampleInstead use...
Highly variable metrics reported by a large number of sourcesCPU from all hosts
Noisy CPU line graph
Heatmaps to make noisy data more interpretable
CPU heatmap
Metrics that are more actionable as aggregates than as separate data pointsWeb requests per second over dozens of web servers
Web server requests per node
Area graphs to aggregate across tagged groups
Web server requests per availability zone
Metrics that are often equal to zeroMetrics tracking relatively rare S3 access errors
Error count
Bar graphs to avoid jumpy interpolations
Error count bar graph

Stacked area graphs

Area graph

Area graphs are similar to line graphs, except the metric values are represented by two-dimensional bands rather than lines. Multiple timeseries can be summed together simply by stacking the bands, but too many bands makes the graph hard to interpret. If each band is only a pixel or two tall, the information conveyed is minimal.

When to use stacked area graphs

The same metric from different scopes, stackedTo check both the sum and the contribution of each of its parts at a glanceLoad balancer requests per availability zone
Load balancer requests per availability zone
Summing complementary metrics that share the same unitTo see how a finite resource is being utilizedCPU utilization metrics (user, system, idle, etc.)
CPU utilization, stacked graph

When to use something else

WhatExampleInstead use...
Unaggregated metrics from large numbers of hosts, making the slices too thin to be meaningfulThroughput metrics across hundreds of app servers
Overloaded stacked area graph
Line graph or solid-color area graph to track total, aggregate value
Solid area graph

Heatmaps to track host-level data
Throughput heatmap
Metrics that can't be added sensiblySystem load across multiple servers
Stacked system load graph
Line graphs, or heatmaps for large numbers of hosts
System load line graph

Bar graphs

Bar graph

In a bar graph, each bar represents a metric rollup over a time interval. This feature makes bar graphs ideal for representing counts. Unlike gauge metrics, which represent an instantaneous value, count metrics only make sense when paired with a time interval (e.g., 13 server errors in the past five minutes).

Bar graphs require no interpolation to connect one interval to the next, making them especially useful for representing sparse metrics. Like area graphs, they naturally accommodate stacking and summing of metrics.

When to use bar graphs

Sparse metrics (e.g., metrics tracking rare events)To convey metric values without jumpy or misleading interpolationsBlocked tasks in Cassandra's internal queues
Blocked tasks bar graph
Metrics that represent a count (rather than a gauge)To convey both the total count and the corresponding time intervalFailed jobs, by data center (4-hour intervals)
Failed jobs bar graph

When to use something else

WhatExampleInstead use...
Metrics that can't be added sensiblyAverage latency per load balancer
Confusingly summed latency metrics
Line graphs to isolate timeseries from each host
Isolated latency metrics
Unaggregated metrics from large numbers of sources, making the slices too thin to be meaningfulCompleted tasks across dozens of Cassandra nodes
Bar graph of completed tasks
Solid-color bars to track total, aggregate metric value
Solid-color bar graph

Heatmaps to track host-level values
Heatmap of completed tasks



Heatmaps show the distribution of values for a metric evolving over time. Specifically, each column represents a distribution of values during a particular time slice. Each cell’s shading corresponds to the number of entities reporting that particular value during that particular time.

Heatmaps are essentially distribution graphs, except that heatmaps show change over time, and distribution graphs are a snapshot of a particular window of time. Distributions are covered in Part 2 of this series.

When to use heatmaps

Single metric reported by a large number of groupsTo convey general trends at a glanceWeb latency per host
Webapp latency heatmap
To see transient variations across members of a groupRequests received per host
Requests per host heatmap

When to use something else

WhatExampleInstead use...
Metrics coming from only a few individual sourcesCPU utilization across a small number of RDS instances
Sparse heatmap of CPU
Line graphs to isolate timeseries from each host
Line graph of CPU
Metrics where aggregates matter more than individual valuesDisk utilization per Cassandra column family
Sparse heatmap of CPU
Area graphs to sum values across a set of tags
Line graph of CPU


By understanding the ideal use cases and limitations of each kind of timeseries graph, you can present actionable information from your metrics more clearly, thereby providing observability into your systems.

In the next article in this series, we’ll explore other methods of graphing and monitoring metrics, including change graphs, ranked lists, distributions, and other visualizations.

Source Markdown for this series is available on GitHub. Questions, corrections, additions, etc.? Please let us know.