Клиенты часто спрашивают нас о показателе p99 (99-й процентиль).
Это определенно разумная просьба, и мы планируем добавить аналогичный функционал в VividCortex (подробнее об этом позже).
Но в то же время, когда клиенты спрашивают об этом, они имеют в виду что-то очень конкретное — что-то, что может стать проблемой.
Они не просят 99-й процентиль по какому-то показателю, они просят Показатель 99-го процентиля .
Это характерно для таких систем, как Графит , но всё это не даёт того результата, который ожидается от таких систем.
Этот пост расскажет вам, что у вас могут быть неправильные представления о процентилях, о точной степени ваших заблуждений и о том, что вы еще можете сделать правильно в этом случае.
(Это перевод статьи который я написал Барон Шварц .
) Давайте откажемся от среднего В последние несколько лет многие сразу заговорили о том, что существует ряд проблем в мониторинге по средним значениям.
Хорошо, что эта тема сейчас стала активно обсуждаться, поскольку долгое время средние значения параметров в мониторинге формировались и принимались без какого-либо пристального анализа.
Средние значения представляют собой проблему и мало помогают, когда дело доходит до мониторинга.
Если вы просто посмотрите на средние значения, вы, скорее всего, упустите данные, которые оказывают наибольшее влияние на вашу систему: при поиске каких-либо проблем события, которые особенно важны для вас, по определению будут выбросами.
Есть две проблемы со средними значениями, когда есть выбросы:
- Средние значения скрывают выбросы, и вы их не видите.
- Выбросы сдвигают средние значения, так что в системе, в которой существуют выбросы, средние значения больше не отражают нормальное состояние системы.
Кстати, работа большинства программных систем просто кишит экстремальными выбросами.
Просмотр выбросов, расположенных в длинный хвост по частоте встречаемости очень важно, поскольку в некоторых редких случаях показывает, насколько плохо вы справляетесь с запросами.
Вы не увидите этого, если будете работать только со средними значениями.
Как сказал Вернер Фогельс из Amazon на открытии re:Invent, единственное, что могут сказать вам средние показатели, это то, что вы обслуживаете половину своих клиентов еще хуже.
(Хотя это утверждение абсолютно верно по духу, оно не совсем отражает реальность: здесь правильнее было бы сказать о медиане (она же 50-й процентиль) – именно эта метрика обеспечивает указанное свойство) Optimize опубликовал пост на эта почта Несколько лет назад. Она отлично объясняет, почему средние значения могут привести к неожиданным последствиям:
«Хотя средние значения очень легко понять, они также могут вводить в заблуждение.Брендан Грегг также хорошо объяснено Этот:Почему? Потому что наблюдение за средним временем ответа похоже на измерение средней температуры в больнице.
А что вас действительно волнует, так это температура каждого пациента и особенно то, какой пациент нуждается в вашей помощи в первую очередь».
«Как статистическая характеристика средние значения (в том числе среднее арифметическое) имеют много преимуществ в практическом применении.Вперед к процентилям Процентили (квантили в более широком смысле) часто рекламируются как средство преодоления этого фундаментального недостатка средних значений.Однако возможность описать распределение ценностей не входит в их число».
Смысл 99-го процентиля — собрать весь набор данных (другими словами, всю коллекцию измерений системы) и отсортировать их, затем отбросить самый большой 1% и взять из оставшихся наибольшее значение.
Полученное значение имеет два важных свойства:
- Это максимальное значение, которое получается в 99% случаев.
Если это значение, например, является показателем времени загрузки веб-страницы, то оно отражает услугу наихудшего случая, которая предоставляется как минимум при 99% посещений вашей службы.
- Это значение устойчиво к действительно большим выбросам, возникающим по разным причинам, включая ошибки измерения.
Распространенными вариантами являются 90-й, 95-й и 99,9-й (или даже более высокие девятки) процентили.
А теперь вы предполагаете: средние значения — это плохо, а процентили — это здорово — давайте посчитаем процентили для метрик и сохраним их в нашем хранилище временных рядов ( ТСДБ )? Но это не так просто.
Как именно TSDB хранят и обрабатывают метрики? Существует большая проблема с процентилями в данных временных рядов.
Проблема в том, что большинство TSDB почти всегда хранят агрегированный показатели на временных интервалах, а не весь образец измеряемые события.
Впоследствии ЦДБ средний эти показатели с течением времени в ряде случаев.
Самое важное:
- Они усредняют метрики, если дискретность времени в вашем запросе отличается от дискретности времени, которая использовалась при агрегации данных при сохранении.
Если вы хотите отобразить график ежедневных показателей, например, шириной 600 пикселей, тогда каждый пиксель будет представлять 144 секунды данных.
Это усреднение является неявным, и пользователи о нем не знают. А на самом деле эти службы должны были вынести предупреждение!
- TSDB усредняют данные при их долговременном хранении с более низким разрешением, что на самом деле и делает большинство TSDB.
Вы снова имеете дело с некоторой формой усреднения.
Усреднение процентилей не работает, поскольку для расчета процентилей в новом масштабе необходима полная выборка событий.
Все расчеты на самом деле неверны.
Усреднение процентилей не имеет смысла.
(Последствия этого могут быть произвольными.
Я вернусь к этому позже.
) 
К сожалению, некоторые распространенные продукты мониторинга с открытым исходным кодом поощряют использование процентильных показателей, которые фактически затем будут пересчитываться при сохранении.
Например, StatsD позволяет вычислить нужный процентиль, после чего генерирует метрику с именем типа foo.upper_99 и периодически сбрасывает их для сохранения в Graphite. Все хорошо, если дискретность времени не меняется во время просмотра, но мы знаем, что это все равно происходит. Непонимание того, как происходят все эти расчеты, чрезвычайно распространено.
Прочитав ветку комментариев по этому поводу Билет StatsD на GitHub прекрасно это иллюстрирует. Некоторые товарищи там говорят о вещах, не имеющих ничего общего с реальностью.
— Сьюзи, сколько будет 12+7? - Миллиард! - Спасибо! -.Возможно, самым кратким способом сформулировать проблему было бы сказать следующее: Процентили рассчитываются на основе набора измерений и должны полностью пересчитываться при каждом изменении этого набора.эээ, но это не может быть правдой, не так ли? - она сказала то же самое про 3+4
БСДБ периодически усредняют данные за разные периоды времени, но при этом не хранят исходную выборку измерений.
Другие способы расчета процентилей Но если для расчета процентилей на самом деле требуется полная выборка исходных событий (например, каждый раз при загрузке каждой веб-страницы), то у нас возникает большая проблема.
Проблема «Больших Данных» — правильнее было бы сказать так.
Вот почему настоящий расчет процентилей чрезвычайно дорог.
Существует несколько способов расчета «приблизительных» процентилей, которые почти так же эффективны, как хранение полной выборки измерений с последующей их сортировкой и расчетом.
Вы можете найти множество научных исследований в различных областях, включая:
- гистограммы, которые делят всю коллекцию событий на диапазоны (или сегменты) и затем точно вычисляют, сколько событий попадает в каждый из диапазонов (групп)
- примерные структуры и алгоритмы потоковой передачи данных (подсчет скетчей, «эскизов»)
- сохраняет выборку из набора событий, чтобы предоставить приблизительные ответы
- решения с ограничениями по времени, количеству или тому и другому
На основе информации о распределении вы можете рассчитать приблизительные процентили, а также некоторые другие интересные показатели.
Опять же из блога Optimizely, вот интересный пример распределения времени ответа, а также среднего и 99-го процентиля: 
Существует много способов расчета и хранения приблизительных распределений, но гистограммы особенно популярны из-за их относительной простоты.
Некоторые решения для мониторинга поддерживают гистограммы.
Цирконус например, один из этих.
Тео Шлосснагл, генеральный директор Circonus, часто пишет о преимуществах гистограмм.
В конечном счете, распределение исходной коллекции событий полезно не только для расчета процентилей, но и позволяет выявить некоторые вещи, о которых процентили не могут вам рассказать.
В конце концов, процентиль — это просто число, которое просто пытается собрать много информации о данных.
Я не пойду так далеко, как сделал Тео, когда он написал в Твиттере что «99 — не лучше среднего» , потому что здесь я согласен с поклонниками процентилей в том, что процентили гораздо более информативны, чем средние значения, в представлении некоторых важных характеристик исходной выборки.
Однако процентили не говорят вам так много о ваших данных, как более подробные гистограммы.
Иллюстрация выше из Optimizely содержит на порядки больше информации, чем любое отдельное число.
Еще лучшие процентили в TSDB Лучший способ расчета процентилей в TSDB — собирать показатели по диапазонам.
Я сделал это предположение, потому что многие TSDB на самом деле представляют собой просто коллекции ключей и значений с метками времени без возможности хранения гистограмм.
Метрики диапазона предоставляют те же возможности, что и последовательность гистограмм с течением времени.
Все, что вам нужно сделать, это выбрать пределы, которые будут разделять значения на диапазоны, а затем посчитать все метрики отдельно для каждого из диапазонов.
Метрика будет та же, что и для гистограммы: а именно количество событий, значения которых попадают в этот диапазон.
Но в целом выбор диапазонов для разделения – непростая задача.
Как правило, хорошим выбором являются диапазоны с логарифмически прогрессивными размерами или диапазоны, обеспечивающие хранение грубых значений для ускорения вычислений (за счет отказа от плавного роста счетчика).
Но диапазоны одинаковых размеров вряд ли будут хорошим выбором.
Есть дополнительная информация по этой теме в записке Брендана Грегга .
Существует фундаментальное противоречие между объемом хранимых данных и их точностью.
Однако даже грубое распределение по диапазонам обеспечивает лучшее представление данных, чем среднее значение.
Например, Станция Пассажир Юнион Фьюжн показывает ранжированные показатели задержки в 11 диапазонах.
(Я не думаю, что иллюстрация вообще ясна; значение по оси Y немного сбивает с толку; на самом деле это трехмерный график, нелинейно проецируемый в 2D. Однако он все равно дает больше информации, чем среднее значение.
бы.
) 
Как этого можно достичь, используя популярные продукты с открытым исходным кодом? Вы должны определить диапазоны и создать столбцы в виде стопок, как показано на рисунке выше.
Но вычислить процентиль по этим данным теперь будет гораздо сложнее.
Вам придется пройти все диапазоны в обратном порядке, от большего к меньшему, попутно суммируя счетчики количества событий.
Как только вы получите сумму количества событий, превышающую 1% от общего числа, в этом диапазоне будет храниться значение процентиля 99%.
Здесь много нюансов – неточные равенства; как именно обрабатывать пограничные случаи, какое значение выбрать для процентиля (диапазон вверху или внизу? или, может быть, посередине? или, может быть, взвешенный из всех?).
И вообще, такие расчеты могут сильно запутать.
Например, вы можете предположить, что вам нужно 100 диапазонов для расчета 99-го процентиля, но реальность может быть иной.
Если у вас всего два диапазона и 1% всех значений попадает в верхний, то можно получить процентиль 99% и так далее.
(Если вам это кажется странным, подумайте о квантилях в целом; я думаю, понимание того, что такое квантили, очень ценно.
) Так что не все так просто.
Теоретически это возможно, но на практике это сильно зависит от того, поддерживает ли хранилище необходимые типы запросов для получения приблизительных значений процентилей для метрик диапазона.
Если вы знаете репозитории, в которых это возможно, напишите в комментариях (на сайте автора - ок.
переулок ) Хорошо то, что в таких системах, как Graphite (то есть в тех, которые полагаются на то, что все метрики могут свободно усредняться и пересчитываться) все метрики диапазона абсолютно устойчивы к такого рода преобразованиям.
Вы получите правильные значения, поскольку все вычисления коммутативны по времени.
За пределами процентилей: тепловые карты Процентиль — это просто число, такое же, как и среднее значение.
Среднее значение показывает центр масс выборки, процентиль показывает верхнюю отметку уровня указанной пропорции образца.
Думайте о процентилях как о волнах на пляже.
Но, хотя процентиль отображает верхние уровни, а не только центральный тренд в качестве среднего, он все же не столь информативен и подробен по сравнению с распределением, которое, в свою очередь, описывает всю выборку.
Встречайте тепловые карты — это на самом деле трехмерные графики, на которых гистограммы поворачиваются и складываются вместе с течением времени, а значения отображаются в цвете.
И снова Цирконус представляет собой отличный пример.
С другой стороны, насколько мне известно, Graphite пока не предоставляет возможности создавать тепловые карты на основе метрик дальности.
Если я ошибаюсь и это можно сделать с помощью какого-то трюка, дайте мне знать (автор статьи — ок.
).
Тепловые карты также отлично подходят для отображения формы и, в частности, плотности задержки.
Другим примером тепловой карты задержки является сводка потоковой доставки из Компания Фастли .
Даже некоторые древние инструменты, которые вам уже кажутся примитивными, позволяют создавать тепловые карты.
Например, Smokeping использует затемнение для отображения диапазонов значений.
Ярко-зеленый цвет означает среднее значение: 
Но действительно ли плохо хранить показатели по процентилям?
Что ж, после всех упомянутых сложностей и нюансов, которые необходимо учитывать, возможно, старая добрая метрика StatsD Upper_99 для показа процентилей покажется вам не такой уж плохой.
В конце концов, это очень просто, удобно и готово к использованию.
Неужели этот показатель настолько плох? Все зависит от обстоятельств.
Они отлично подходят для различных случаев использования.
Я имею в виду, что вы все равно ограничиваете себя, потому что процентили не всегда хорошо описывают данные.
Но если вас это не волнует, то ваша самая большая проблема — это избыточная выборка этих показателей, а это значит, что вы будете иметь дело с неверными данными.
Но измерения совершенно неправильные - в любом случае, и к тому же, многое из того, что по сути неправильно, тем не менее в чем-то полезно.
Например, я мог бы вам сказать, что добрая половина метрик, на которые смотрят люди, на самом деле уже намеренно искажены.
Например, показатель средней нагрузки на системы.
Эта опция, несомненно, полезна, но как только вы узнаете Как именно готовится эта «колбаска»? , поначалу вы можете почувствовать шок.
(На хабе есть отличная статья о расчете ЛА - ок.
) Аналогичным образом, многие системы отображают различные показатели своей производительности в одинаковой краткой форме.
Многие метрики Cassandra являются результатом работы библиотеки Metrics (Coda Hale) и фактически представляют собой плавающие средние значения ( экспоненциальное взвешенное плавающее среднее ), к которому многие люди испытывают сильные чувства отвращение .
Но вернемся к процентильным показателям.
Если вы сохраните метрику p99, а затем уменьшите масштаб и посмотрите на среднюю версию за длительный период времени – хотя она может быть не «правильной» и даже может быть так, что график будет сильно отличаться от фактического значения 99-го процентиля, то, что он будет неверным, не обязательно означает, что этот график нельзя использовать по прямому назначению, а именно для понимания худших случаев взаимодействия пользователя с вашим приложением.
Так что все зависит от конкретного случая.
Если вы понимаете, как работают процентили и что усреднять процентили неправильно, и вас это устраивает, то сохранение процентилей может быть приемлемым и даже полезным.
Но здесь вы вносите моральную дилемму: таким подходом вы можете сильно запутать ничего не подозревающих людей (возможно, даже своих коллег).
Посмотрите еще раз комментарии к заявке на StatsD: сразу заметно непонимание сути процесса.
Позвольте мне привести вам не очень хорошую аналогию: иногда я ем из холодильника то, что никогда бы не предложил другим.
Просто спроси об этом мою жену.
(Жена автора - ок.
).
Если вы дадите людям бутылку с надписью «алкоголь», содержащую метанол, эти люди ослепнут. Но некоторые спросят: «Что за алкоголь содержится в этой бутылкеЭ» Вам лучше придерживаться такого же уровня ответственности по отношению к таким вопросам.
Что именно делает VividCortex? В настоящее время наша TSDB не поддерживает гистограммы, а также мы не поддерживаем расчет или хранение процентилей (хотя вы можете просто отправить нам любой ваши показатели , если необходимо).
В будущем мы планируем поддерживать хранение метрик диапазона высокого разрешения, то есть метрик с большим количеством диапазонов.
Мы сможем реализовать что-то подобное, потому что большинство диапазонов, скорее всего, будут пустыми, и наша TSDB сможет эффективно обрабатывать разреженные данные (также вероятно, что после усреднения по времени они больше не будут такими разреженными - ок.
).
Это даст нам возможность создавать гистограммы раз в секунду (все наши данные хранятся с разрешением 1 секунда).
Показатели диапазона будут преобразованы с разрешением в 1 минуту по истечении периода, указанного в настройках, который по умолчанию равен 3 дням.
В этом случае показатели диапазона будут преобразованы с разрешением в 1 минуту без каких-либо математических проблем.
И в результате из этих метрик диапазона мы сможем получить любой желаемый процентиль, показать оценку ошибки, показать тепловую карту и показать кривую распределения.
Это будет небыстро реализовать и потребует от инженеров немало усилий, но работа уже началась и система уже спроектирована с учетом всего этого.
Не могу обещать, когда именно это будет реализовано, но считаю необходимым поговорить о наших долгосрочных планах.
выводы Пост получился немного длиннее, чем я планировал изначально, но затронул много тем.
- Если вы планируете рассчитать процентили за определенный интервал, а затем сохранить результат в виде временного ряда, как это делают некоторые существующие магазины, вы можете получить не совсем то, что ожидаете.
- Точный расчет процентилей требует больших вычислительных затрат.
- Приблизительные значения процентилей можно рассчитать на основе гистограмм, показателей диапазона и других полезных вычислительных методов.
- Такие данные также позволят построить распределения и тепловые карты, которые будут даже более информативными, чем простые процентили.
- Если ничего из этого сейчас недоступно или вы не можете себе это позволить, используйте процентильные показатели, но помните о последствиях.
P.S.
- Кто-то упомянул об эффекте в Твиттере: «Ой-ой, оказывается, я все делаю как-то не так.
Но я перешел на расчет процента запросов, выполненных за меньшее/большее время, чем указанное значение, и сохранил эту метрику вместо предыдущей».
Но это тоже не работает. Подход расчета средних по долям (а процент — это доля) до сих пор не работает. Вместо этого сохраните метрику цифры запросы, которые не выполняются в течение желаемого времени.
Это сработает.
- Мне потребовалось некоторое время, чтобы найти отличный пост от Тео на эту тему.
А вот и он: http://www.circonus.com/problem-math/
-
Оптимизируйте Свои Ядра
19 Oct, 24 -
Активные Пользователи
19 Oct, 24 -
Пресловутый «Опыт»
19 Oct, 24 -
Коллтрекинг С Оплатой За Лид, А Не За Номер
19 Oct, 24
