Задержка — это очевидный показатель, который почти всегда приходит на ум, когда речь идет о мониторинге наших сервисов.
Будь то простой контроллер, воркёр, считывающий событие из очереди, или сервис, делающий бэкап вашей монги — любой логический кусок кода, производительность которого нам важна.
Рассмотрим простой пример: у вас есть сервис, который принимает запросы от пользователей и возвращает необходимые данные в UI. Если этот сервис находится в разработке и вы уже представляете достаточно зрелый проект, вполне вероятно, что вы уже настроили метрики и отслеживаете их.
А может быть, вы даже настроили оповещения, пейджер-дежурство, назначили дежурных инженеров и раз в месяц отчитываетесь о выполнении своих SLA. Почти наверняка одно из ваших предупреждений будет основано на задержке этой службы.
И я попробую угадать — вы в качестве статистики используете процентили.
Вы правильно догадались? А что, если я скажу вам, что это не лучший вариант? Что, если я пойду дальше и утверждаю, что процентили могут скрыть серьезные изменения задержки после следующего развертывания? Давайте по порядку.
Давайте начнем с краткого обсуждения процентилей: что это такое и как инженеры используют их ежедневно для мониторинга работоспособности сервисов, поиска причин и следствий во время сбоев, автоматического отката к предыдущему коммиту во время развертывания с помощью вашего рефакторинга после прочтения Фаулера.
, проснуться в 3 часа ночи (утра?) от звонка телефона с выключенным звуком, показа начальству красивых, аккуратных графиков трёх девяток.
процентили
И так, у нас есть сервис и мы очень хотим отслеживать, как быстро он отвечает. В данном случае под задержкой мы чаще всего подразумеваем время от получения запроса до момента, когда сервис будет готов вернуть результат (хотя есть команды, которые включают в задержку и другие вещи: например, окончание этого периода времени — считается момент получения ответа пользователем.В нашем случае это не лучшая идея, потому что в эту метрику будет входить, например, скорость передачи данных по сети, а также все, что связано с шифрованием/дешифрованием для шифрования) .
Собирая данные об этом значении для всех запросов пользователей, мы можем отслеживать, насколько быстро работает наш сервис, а также как наши новые коммиты влияют на эту скорость.
И есть множество исследований, показывающих прямую связь между скоростью обслуживания и удовлетворенностью пользователей (которая может выражаться, например, в конверсии новых пользователей в платящих пользователей), что добавляет ценности.
Пока все просто.
Теперь предположим, что сервис очень загружен, 100 тысяч запросов в секунду.
Чтобы не отправлять данные об этой метрике в систему мониторинга с одинаковой периодичностью, мы хотим сделать что-то умнее: на стороне сервиса мы собираем данные в течение 10 секунд, агрегируем их, а затем отправляем в систему мониторинга.
И вот мы наконец дошли до процентилей — это та самая статистика, которую мы используем для агрегирования всех данных, чтобы отправлять в систему мониторинга одно значение каждые 10 секунд. По сути, мы просто отсекаем некоторые из самых длинных запросов, которые могут исказить нашу картину, чтобы примерно представить то, что видит основная часть наших пользователей.
Например, p99 показывает максимальное значение после удаления 1% самых длинных запросов.
Или другими словами: p99 превышает 99% всех значений, которые мы используем для агрегирования этой статистики.
Предположим, мы настроили оповещение с условием, что три значения подряд не должны превышать 200мс.
После месяца работы над новой версией сервиса наконец пришло время развертывания! Сказано-сделано, разворачивайте и заходите в графану проверять графики! Красная линия показывает момент развертывания.
Заметили разницу? Мне не.
Пойдем, покажем менеджеру график и отсутствие оповещений, и получим повышение? Нет. Или, что менее критично, не так быстро.
Соблюдение соглашений об уровне обслуживания — это хорошо, но мы также хотим понять динамику наших показателей после внесенных нами изменений.
На первый взгляд все в порядке.
Если, конечно, р99 дает нам достаточно информации о динамике.
Давайте посмотрим на две точки на этом графике: зеленую и фиолетовую.
Зеленый — последнее значение метрики перед развертыванием.
Фиолетовый — первое значение сразу после развертывания.
А вот реальные значения задержки, которые привели к этим двум точкам после агрегации по метрике p99: 
Упс! Я уверен, что теперь вы можете увидеть разницу.
Хотя p99 тот же, очевидно, что задержка после развертывания существенно изменилась.
Хоть эти графики и выдуманные, немного утрируя для красоты, можно сказать, что запросы пользователей стали обрабатываться в два раза дольше!
Проблема
Попробуем описать проблему простыми словами: процентили как статистика дают информацию об одной точке.Подумайте об этом: p90 показывает значение одной точки, которое превышает 90% всех значений.
То есть, применяя эту статистику, мы теряем информацию обо всех значениях, кроме одного — остальные мы просто не учитываем.
На графике выше мы увидели, что эта метрика недостаточно чувствительна, чтобы отражать изменения среди этих 90% значений.
Теперь подумайте о пользовательском опыте: существует множество бизнесов, для которых столь значительное увеличение задержки просто неприемлемо! Можем ли мы как-то улучшить ситуацию?
Усеченное среднее
Может! Статистика усеченного среднего позволяет отслеживать среднее значение среди выбранного диапазона данных, давая более точную картину реального положения дел.Например, TM90 — это среднее значение после удаления 10% наибольших значений (чтобы исключить колебания: значения не были найдены в кеше и их пришлось отправлять в базу данных, или нижестоящим службам требовалось много времени для ответа, или GC решил, что пора действовать).
Усеченное среднее более чувствительно к изменениям, которые невозможно увидеть при использовании процентилей! Поиграв с этой метрикой, вы сможете получить хорошее представление о пользовательском опыте.
Например, TM(99%: ) показывает среднее значение для 1% самых медленных запросов, а TM99 показывает среднее значение для 99% самых быстрых запросов.
Чтобы продемонстрировать разницу, давайте посмотрим на предыдущий график, добавив к нему значения статистики TM90. 
Нетрудно заметить, что изменения после нашего развертывания не остались незамеченными! При правильно настроенном откате, развертывании и нагрузочных тестах проблемный коммит может даже не дойти до рабочих серверов.
А разве не этого мы все хотим? :) Надеюсь, эта статистика когда-нибудь будет добавлена во все популярные системы мониторинга.
Например, Амазон уже добавлено в КлаудВотч.
Наслаждайтесь загрузкой! Теги: #Высокая производительность #Системный анализ и проектирование #мониторинг #Распределенные системы #задержка #производительность #высокая нагрузка #усеченное среднее #процентиль
-
Как Не Стать Спамером
19 Oct, 24 -
3 Простых Совета По Созданию Блога
19 Oct, 24 -
Советы По Удалению Вирусов
19 Oct, 24 -
Дайджест Joomla За Июнь-Июль 2019 Года
19 Oct, 24 -
Табло В Розничной Торговле, Правда?
19 Oct, 24
