Yao Yue в рамках своей презентации на QCon San Francisco призывает пересмотреть способ отображения данных измерений систем. Линейный график, ставший форматом по умолчанию для большинства панелей мониторинга, может подходить для чистых и непрерывных данных, но становится менее полезным, когда временных рядов становится слишком много, возрастает уровень шума или поставленный вопрос вообще не связан со временем.
Yue опирается на 15 лет эксплуатации крупномасштабных систем, включая семь лет работы по сменному графику в службе первого уровня, а также на свой предыдущий опыт в Twitter, где она руководила командой кэширования, а затем создала команду производительности. После ноября 2022 года она участвовала в основании IOP Systems — компании, которая занимается повышением эффективности и надёжности программного обеспечения с помощью интеллектуальной инженерии производительности.
Проблема не в самой линии
Yue объясняет, что линейный график отображает не только точки измерений, но и проводит линии между каждой парой последовательных точек. Это означает добавление визуальных элементов, фактически отсутствующих в данных, или того, что она описывает как extrapolation — экстраполяцию, то есть интерполяцию между измерениями. Это может быть полезно, когда данные регулярны, но способно создать впечатление о наличии траектории между двумя измерениями, о промежутке между которыми у нас нет прямой информации, особенно в случае метрик, для которых неизвестно, что происходило между замерами.
Проблема усиливается в системах с большим количеством экземпляров или временных рядов. Множество линий и цветов может придавать панели мониторинга насыщенный вид, но не делает более ясными ответы на такие вопросы, как «Изменился ли темп выпуска?» или «Привёл ли новый релиз к заметному ухудшению?». Во многих случаях интерпретировать график способен только опытный инженер, который тратит много времени на изучение деталей, и Yue считает такой подход неподходящим для создания надёжной инженерной системы.
Выбор формы в соответствии с природой измерения
Докладчица предлагает начать с трёх соображений: формы данных, типа измерения и того, что именно команда хочет из них узнать. Когда данные перегружены, можно использовать средние значения в рамках временных окон или рассчитывать минимальное, максимальное и среднее значения, чтобы уменьшить шум и выделить тенденции. Однако это преобразование должно служить поставленному вопросу, а не быть просто способом сделать график привлекательнее.
Yue предупреждает, что обобщение данных может скрывать важные различия. Она ссылается на идею «Datasaurus», согласно которой наборы данных могут иметь одинаковые среднее значение и стандартное отклонение, но при отображении исходных значений радикально различаться по форме. Поэтому в некоторых случаях отображение точек без линий может быть более честным: оно показывает фактические измерения и не добавляет неподтверждённую визуальную траекторию.
Согласно презентации, большинство данных измерений делится на три основных типа: счётчики, мгновенные показатели и гистограммы. Счётчики, увеличивающиеся со временем, могут хорошо отображаться линиями, но в приложениях мониторинга обычно показывается не исходный счётчик, а разница между двумя последовательными значениями — например, скорость запросов или количество ошибок. Yue считает, что представление этой разницы в виде отрезков или столбцов может точнее показать совокупное изменение и вариативность.
Мгновенные показатели, напротив, ничего не гарантируют о периоде между двумя измерениями. Значение может вырасти или снизиться между замерами, не отразившись в данных. Поэтому докладчица предпочитает отображать точки как есть, сводя экстраполяцию к минимуму. Что касается времени отклика, она подчёркивает, что одного значения недостаточно, поскольку оно представляет распределение, а не отдельное число. Гистограммы лучше сохраняют информацию о хвосте, например P99 и P99.9, вместо того чтобы сводить её к одной линии.
Что меняется на практике?
Главная идея презентации заключается не в том, чтобы заменить все линейные графики, а в том, чтобы связать визуализацию с операционным вопросом. Если вопрос касается влияния нагрузки на соглашение об уровне обслуживания, данные можно сгруппировать по диапазонам нагрузки, например по диапазонам в 500 или 5000 запросов в секунду, а затем связать их с распределениями времени отклика. В этом случае график непосредственно показывает связь между нагрузкой и временем отклика, вместо того чтобы просматривать разные дни в поисках момента пикового значения нагрузки.
Аналогичным образом, при сравнении двух версий программного обеспечения измерения можно сгруппировать по версии, а затем сравнить распределения или процентильные значения, не делая время главным измерением анализа. При выборе типа оборудования предлагается объединять данные о производительности с другой информацией, такой как тип экземпляра и цена, чтобы получить таблицу, сопоставляющую параметры, действительно важные для решения о масштабировании.
Взгляд certi.news
Этот подход выявляет ограничение в архитектуре инструментов мониторинга в той же мере, в какой он указывает на проблему визуального дизайна. Системы хранения измерений обычно построены вокруг имени метрики и её атрибутов, с одной стороны, и значений и временных меток — с другой. Это делает запросы, связанные со значением во времени, относительно простыми, но усложняет сопоставление значений одной метрики со значениями другой — например, связывание времени отклика с нагрузкой или сравнение производительности по версии программного обеспечения.
На практике это означает, что улучшение панели мониторинга не всегда начинается с выбора нового цвета или графика: сначала следует определить решение, которому она должна помогать. Командам может потребоваться заново сгруппировать данные или объединить источники за пределами базы данных временных рядов. При этом сессия не предлагает единого рецепта, подходящего всем: она подчёркивает, что тип и форма измерения, а также поставленный вопрос определяют наиболее подходящее представление, и что источник не утверждает, будто каждый современный инструмент мониторинга автоматически предоставляет такие преобразования. Поэтому возможность экспериментировать, доступ к исходным данным и понимание ограничений каждого обобщения остаются открытыми практическими вопросами для команд надёжности и инженерии производительности.