---
title: "Metric graphs 101: Timeseries graphs"
description: "To help you effectively visualize your metrics, this post explores 4 types of timeseries graphs: Line graphs, stacked area graphs, bar graphs, and heat maps"
author: "John Matson"
date: 2016-03-01
tags: ["metrics", "monitoring 101"]
blog_type_id: the-monitor
locale: en
---

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

[Observability](https://en.wikipedia.org/wiki/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:

- [Line graphs](#line-graphs)
- [Stacked area graphs](#stacked-area-graphs)
- [Bar graphs](#bar-graphs)
- [Heatmaps](#heatmaps)

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

## Line graphs

![Line graph](https://web-assets.dd-static.net/42588/1776359136-timeseries-metric-graphs-101-key-pg-classic.png)

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

| What | Why | Example |
| --- | --- | --- |
| The same metric reported by <strong>different scopes</strong> | To spot outliers at a glance | CPU idle for each host in a cluster<ContentImage src="cpu-idle-host.png" alt="CPU idle per host" popup="true" /> |
| Tracking <strong>single metrics</strong> from one source, or as an aggregate | To clearly communicate a key metric’s evolution over time | Median latency across all web servers<ContentImage src="latency-spike.png" alt="Median webapp latency" popup="true" /> |
| Metrics for which <strong>unaggregated values</strong> from a particular slice of your infrastructure are especially valuable | To spot individual deviations into unacceptable ranges | Disk space utilization per database node<ContentImage src="cass-disk-rising.png" alt="Disk space per node" popup="true" /> |
| <strong>Related metrics</strong> sharing the same units | To spot correlations within a system | Latency for disk reads and disk writes on the same machine<ContentImage src="disk-lat.png" alt="Read and write latency" popup="true" /> |
| Metrics that have a clear <strong>acceptable domain</strong> | To easily spot unacceptable degradations | Latency for processing web requests<ContentImage src="key-pg-lat.png" alt="Key page latency" popup="true" /> |

### When to use something else

| What | Example | Instead use... |
| --- | --- | --- |
| Highly variable metrics reported by a <strong>large number of sources</strong> | CPU from all hosts<ContentImage src="cpu-bad.png" alt="Noisy CPU line graph" popup="true" /> | Heatmaps to make noisy data more interpretable<ContentImage src="cpu-good.png" alt="CPU heatmap" popup="true" /> |
| Metrics that are <strong>more actionable as aggregates</strong> than as separate data points | Web requests per second over dozens of web servers<ContentImage src="nginx-bad.png" alt="Web server requests per node" popup="true" /> | Area graphs to aggregate across tagged groups<ContentImage src="nginx-good.png" alt="Web server requests per availability zone" popup="true" /> |
| Metrics that are <strong>often equal to zero</strong> | Metrics tracking relatively rare S3 access errors<ContentImage src="errors-bad.png" alt="Error count" popup="true" /> | Bar graphs to avoid jumpy interpolations<ContentImage src="errors-good.png" alt="Error count bar graph" popup="true" /> |

## Stacked area graphs

![Area graph](https://web-assets.dd-static.net/42588/1776359140-timeseries-metric-graphs-101-areas-3.png)

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

| What | Why | Example |
| --- | --- | --- |
| The same metric from <strong>different scopes</strong>, stacked | To check both the sum and the contribution of each of its parts at a glance | Load balancer requests per availability zone<ContentImage src="elb-req.png" alt="Load balancer requests per availability zone" popup="true" /> |
| Summing <strong>complementary metrics</strong> that share the same unit | To see how a finite resource is being utilized | CPU utilization metrics (user, system, idle, etc.)<ContentImage src="cpu-spiky.png" alt="CPU utilization, stacked graph" popup="true" /> |

### When to use something else

| What | Example | Instead use... |
| --- | --- | --- |
| <strong>Unaggregated metrics</strong> from large numbers of hosts, making the slices too thin to be meaningful | Throughput metrics across hundreds of app servers<ContentImage src="stack2-bad.png" alt="Overloaded stacked area graph" popup="true" /> | Line graph or solid-color area graph to track total, aggregate value<ContentImage src="stack4-good.png" alt="Solid area graph" popup="true" /> ---- Heatmaps to track host-level data<ContentImage src="stack8-good.png" alt="Throughput heatmap" popup="true" /> |
| Metrics that <strong>can’t be added</strong> sensibly | System load across multiple servers<ContentImage src="sys4-load-bad.png" alt="Stacked system load graph" popup="true" /> | Line graphs, or heatmaps for large numbers of hosts<ContentImage src="sys4-load-good.png" alt="System load line graph" popup="true" /> |

## Bar graphs

![Bar graph](https://web-assets.dd-static.net/42588/1776359145-timeseries-metric-graphs-101-errors-bars.png)

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

| What | Why | Example |
| --- | --- | --- |
| <strong>Sparse metrics</strong> (e.g., metrics tracking rare events) | To convey metric values without jumpy or misleading interpolations | Blocked tasks in Cassandra’s internal queues<ContentImage src="bar-blocked.png" alt="Blocked tasks bar graph" popup="true" /> |
| Metrics that represent a <strong>count</strong> (rather than a gauge) | To convey both the total count and the corresponding time interval | Failed jobs, by data center (4-hour intervals)<ContentImage src="failed-jobs2.png" alt="Failed jobs bar graph" popup="true" /> |

### When to use something else

| What | Example | Instead use... |
| --- | --- | --- |
| Metrics that <strong>can’t be added</strong> sensibly | Average latency per load balancer<ContentImage src="bar-bad.png" alt="Confusingly summed latency metrics" popup="true" /> | Line graphs to isolate timeseries from each host<ContentImage src="bar-good.png" alt="Isolated latency metrics" popup="true" /> |
| <strong>Unaggregated metrics</strong> from large numbers of sources, making the slices too thin to be meaningful | Completed tasks across dozens of Cassandra nodes<ContentImage src="cass-bad.png" alt="Bar graph of completed tasks" popup="true" /> | Solid-color bars to track total, aggregate metric value<ContentImage src="cass-good-bars.png" alt="Solid-color bar graph" popup="true" /> ---- Heatmaps to track host-level values<ContentImage src="cass-good-heat.png" alt="Heatmap of completed tasks" popup="true" /> |

## Heatmaps

![Heatmap](https://web-assets.dd-static.net/42588/1776359149-timeseries-metric-graphs-101-heat.png)

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](https://docs.datadoghq.com/graphing.md#distribution), 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

| What | Why | Example |
| --- | --- | --- |
| <strong>Single metric</strong> reported by a large number of groups | To convey general trends at a glance | Web latency per host<ContentImage src="web-latency-heat.png" alt="Webapp latency heatmap" popup="true" /> |
|  |  |  |
|  | To see transient variations across members of a group | Requests received per host<ContentImage src="web-req.png" alt="Requests per host heatmap" popup="true" /> |

### When to use something else

| What | Example | Instead use... |
| --- | --- | --- |
| Metrics coming from only a <strong>few individual sources</strong> | CPU utilization across a small number of RDS instances<ContentImage src="heat-bad-rds.png" alt="Sparse heatmap of CPU" popup="true" /> | Line graphs to isolate timeseries from each host<ContentImage src="heat-good-rds.png" alt="Line graph of CPU" popup="true" /> |
| Metrics where <strong>aggregates matter more</strong> than individual values | Disk utilization per Cassandra column family<ContentImage src="heat-bad-cf.png" alt="Sparse heatmap of CPU" popup="true" /> | Area graphs to sum values across a set of tags<ContentImage src="heat-good-cf.png" alt="Line graph of CPU" popup="true" /> |

## Conclusion

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](https://www.datadoghq.com/blog/summary-graphs-metric-graphs-101.md) in this series, we'll explore other methods of graphing and monitoring metrics, including change graphs, ranked lists, distributions, and other visualizations.