In her presentation at QCon San Francisco, Yao Yue calls for a rethinking of how systems measurement data is presented. The line chart, which has become the default format for most monitoring dashboards, may be suitable for clean, continuous data, but it becomes less useful when time series proliferate, noise increases, or the question being asked is not fundamentally time-related.
Yue draws on 15 years of operating large-scale systems, including seven years spent working on rotation for a tier-one service, as well as her previous experience at Twitter, where she led the caching team and then created the performance team. After November 2022, she co-founded IOP Systems, a company that works to improve software efficiency and reliability through intelligent performance engineering.
The Problem Is Not the Line Itself
Yue explains that a line chart does not merely display measurement points; it also draws lines between every two consecutive points. This means adding visual elements that do not actually exist in the data, or what she describes as extrapolation—the interpolation between measurements. This may be useful when data is regular, but it can suggest the existence of a path between two measurements about which we have no direct information, particularly for metrics where we do not know what happened between them.
The problem increases in systems that contain a large number of replicas or time series. The abundance of lines and colors may give a monitoring dashboard a rich appearance, but it does not make answers to questions such as “Did the throughput change?” or “Did the new deployment cause a noticeable degradation?” any clearer. In many cases, only an experienced engineer can interpret the chart after spending a long time staring at the details—a pattern Yue considers unsuitable for dependable engineering.
Choosing the Format According to the Nature of the Measurement
The speaker proposes starting with three considerations: the shape of the data, the type of measurement, and what the team wants to learn from it. When data is crowded, averages within time windows can be used, or the minimum, maximum, and average can be calculated to reduce noise and highlight trends. However, this transformation should serve the question being asked, rather than merely being a way to beautify the chart.
Yue warns that summarizing data can conceal important differences. She cites the idea of “Datasaurus,” in which datasets can share the same mean and standard deviation despite having radically different shapes when the raw values are plotted. Therefore, displaying points without lines may be more honest in some cases, because it shows the actual measurements and does not add an uncertain visual path.
According to the presentation, most measurement data falls into three main types: counters, gauges, and histograms. Counters that increase over time may be suited to lines, but what is often displayed in monitoring applications is not the raw counter, but the difference between two consecutive values, such as the request or error rate. Yue believes that representing this difference as segments or bars may show cumulative change and variation more accurately.
Gauges, by contrast, guarantee nothing about the period between two readings. The value may rise or fall between the measurements without that appearing in the data. For this reason, the speaker prefers displaying the points as they are, with as little extrapolation as possible. For latency, she emphasizes that a single value is insufficient because it represents a distribution, not an individual number. Histograms are a better way to retain tail information, such as P99 and P99.9, rather than reducing it to a single line.
What Changes in Practice?
The most important point in the presentation is not about replacing all line charts, but about connecting visualization to the operational question. If the question concerns the effect of load on a service-level agreement, data can be grouped into load ranges, such as ranges of 500 or 5,000 requests per second, and then linked to latency distributions. The chart then becomes a direct relationship between load and latency, rather than an inspection of different days in search of the moment when load reached its peak.
Similarly, when comparing two software versions, measurements can be grouped by version and the distributions or percentiles compared without making time the primary axis of the analysis. When choosing hardware types, the idea is to combine performance data with other information, such as instance type and price, to produce a table comparing what actually matters to the scaling decision.
A certi.news Perspective
This perspective reveals a limitation in the architecture of monitoring tools as much as it reveals a problem in visual design. Measurement-storage systems are usually built around the metric name and its labels on one side, and values and timestamps on the other. This makes queries related to a value over time relatively easy, but makes it difficult to link the values of one metric to those of another, such as linking latency to load or comparing performance by software version.
In practice, this means that improving a monitoring dashboard does not always begin with choosing a new color or chart; it begins by identifying the decision the dashboard should support. Teams may need to regroup data or combine sources outside the time-series database. At the same time, the session does not offer a single recipe that works for everyone: it emphasizes that the measurement’s type and shape, along with the question being asked, determine the most appropriate representation, and that the source does not establish that every current monitoring tool provides these transformations automatically. Experimentation, access to raw data, and an understanding of the limits of each summary therefore remain open practical questions for reliability and performance-engineering teams.