Почему ваша панель мониторинга может кормить вас фантомными показателями
13 декабря 2022 г.Являетесь ли вы DevOps, SRE или просто специалистом по данным, вы, вероятно, зависимы от информационных панелей и показателей. Мы смотрим на наши показатели, чтобы увидеть, как работает наша система, будь то на уровне инфраструктуры, приложения или бизнеса. Мы доверяем нашим показателям, чтобы показать нам состояние нашей системы и где она ведет себя неправильно. Но показывают ли наши показатели то, что произошло на самом деле? Вы удивитесь, как часто это не так.
В этом посте я рассмотрю математику и механику, лежащие в основе метрик, некоторые распространенные заблуждения, что нужно для получения точных метрик и есть ли вообще такие вещи.
Основные показатели
Метрики — это, по сути, сводки необработанных событий. Во время этого процесса сведения события преобразуются в точки числовых данных. Простым примером являются ошибки, возникающие в системе, с простой метрикой для подсчета ошибок. Метрики также могут включать несколько переменных, например количество запросов со временем ответа более 1 секунды. При измерении во времени эти точки данных образуют временной ряд.
Метрики могут быть разных типов, таких как счетчики, датчики и гистограммы. Счетчики используются для совокупного подсчета событий, как мы видели в приведенных выше примерах. Датчики обычно представляют последнее значение измерения. Кроме того, существуют более сложные типы, такие как гистограммы, которые могут отображать распределение значений метрик путем подсчета событий в настраиваемых «сегментах» или «корзинах». Например, вам может потребоваться узнать процент использования памяти, сегментированный модулями в вашем кластере, в заданные моменты времени.
Механика показателей
В идеальном мире мы бы получали и сохраняли все необработанные события, а затем вычисляли метрики по времени запроса. Это позволит нам нарезать и нарезать события любым нужным нам способом и задавать любые специальные вопросы, которые мы пожелаем.
Однако в реальном мире хранение всех необработанных событий в течение длительных периодов времени может быть непомерно дорогим из-за больших объемов данных. Чтобы преодолеть это, события часто объединяются в метрики в конвейере сбора, при этом необработанные события отбрасываются или сохраняются только на короткие периоды времени. Часто это вопрос простой настройки агента сбора метрик.
Помимо снижения затрат, агрегирование при сборе может повысить производительность аналитики в реальном времени за счет более высокой скорости передачи и приема метрик с более высокой частотой, а также за счет исключения тяжелых агрегаций и вычислений во время запроса.
Кратко о метриках
Этот процесс объединения включает в себя некоторые математические расчеты. Мы можем захотеть вычислить среднее значение или медиану времени отклика, или, может быть, процентиль или агрегацию по временному окну. Мы также можем захотеть объединить несколько событий в одну составную метрику. Например, мне может понадобиться рассчитать 95-й процентиль (известный как P95) всех модулей определенного сервиса в моем кластере.
Даже если вы не любите математику, вы не сможете избежать ее с помощью метрик. Вам необходимо понимать различные функции агрегирования и связь между вопросом, который вы хотите задать, и метрикой и агрегацией, которые вам нужны, чтобы ответить на него. Давайте посмотрим на функцию Average в качестве примера, так как многие склонны начинать именно с нее. Средние значения по определению сглаживают ситуацию и менее подходят для выявления аномального поведения и выбросов. Например, при исследовании проблем с задержкой будет совершенно бесполезно смотреть на средние значения метрик, и вам лучше смотреть на процентили.
Определите свои вопросы, соответствующим образом разработайте свои показатели
В некотором смысле эти показатели можно рассматривать как сжатие с потерями, во время которого мы теряем данные и контекст необработанных событий. Если мы не храним необработанные события, нам нужно заранее определить, что для нас важно. Например, если я вычисляю только среднее значение по данным, я не смогу позже спросить о P95 (95-й процентиль) по предварительно агрегированным данным.
Вам нужно определить, на какие вопросы вы хотите ответить, что важно для вас, и соответствующим образом разработать свои показатели и агрегации. Распространенной ошибкой является то, что люди избегают этого этапа проектирования и просто используют предустановленные метрики и значения по умолчанию, предоставляемые из коробки с выбранным ими сборщиком метрик. Хотя вы можете подумать, что эти значения по умолчанию представляют собой некий отраслевой стандарт, зачастую они являются довольно устаревшими и в большинстве случаев не соответствуют вашим конкретным потребностям.
https://youtu.be/t9hpWv7fVSk?t=555?embedable=true
Проблема измерения
Как и в физике, проблема измерения возникает, когда мы измеряем (на первый взгляд) непрерывное свойство через дискретные интервалы, часто называемые интервалом выборки, который определяет частоту выборки. > Это создает искаженное представление, когда метрика может фактически не отражать первоначально измеренное свойство. Например, если мы будем измерять загрузку ЦП каждые 60 секунд, то любые выбросы ЦП, происходящие между этими точками выборки, будут для нас невидимы.
Более того, чтобы нарисовать последовательную линию, инструменты визуализации часто усредняют последовательные точки данных, что создает обманчивое впечатление плавной линии. В некоторых случаях может произойти обратное, когда вы можете получить артефакты в своих метриках, которые не являются реальными, например пики в ваших метриках, которых на самом деле не существует. Это может произойти при выполнении агрегирования в серверной части хранилища из-за того, в котором выполняются вычисления.
Среднее время обнаружения
Период выборки также влияет на то, насколько быстро изменения в системе будут видны в показателях. Большинству алгоритмов требуется пять точек данных для обнаружения тренда. Если интервал выборки составляет 60 секунд, то простая математика определяет, что пройдет пять минут (то есть 60 секунд X 5 точек данных), прежде чем мы увидим, что что-то не так. Могли бы вы позволить себе подождать 5 минут, чтобы узнать, что ваша система вышла из строя? Использование более коротких интервалов выборки (т. е. более высокой частоты выборки) сократит этот период и позволит нам быстрее обнаруживать и реагировать. Конечно, более высокая частота дискретизации влечет за собой нагрузку на ЦП и хранилище, поэтому нам нужно найти конфигурацию, которая обеспечивает правильный баланс для наших нужд.
Разное разрешение и уменьшение масштаба
Распространенной практикой является сохранение метрик в разных разрешениях в многоуровневом подходе, чтобы снизить затраты. Например, вы можете сохранить метрику каждые 10 секунд в первый день, затем каждые 5 минут в течение следующей недели и, возможно, каждый час в течение следующего месяца или более. Эта практика предполагает, что нам нужна самая высокая степень детализации для периода, близкого к реальному времени, который может нам понадобиться, если в системе возникнет проблема, в то время как для расследований в течение более длительных периодов требуются более масштабные тенденции.
Различные степени детализации могут быть достигнуты за счет уменьшения масштаба метрик, а именно вычисления менее детализированной метрики из более высокой детализации. Хотя это звучит вполне разумно, здесь может вмешаться математика, поскольку некоторые функции агрегации несовместимы с определенными вычислениями и поэтому не могут быть агрегированы позже. Например, процентили не являются аддитивными и не могут быть суммированы. Таким образом, следуя приведенному выше примеру, если у вас есть процентиль P99, выбранный с разрешением 10 секунд, вы не можете свернуть их до 5-минутного разрешения. Важно помнить о совместимости функций агрегирования, а при использовании несовместимых функций, таких как процентили, принимать проектные решения о требуемом разрешении и заранее рассчитывать эти временные ряды.
Различное разрешение не ограничивается только временным фактором. Другой пример — сохранение данных для каждого модуля, а затем желание «группировать по» узлам или кластерам. Здесь применяется то же ограничение, означающее, что если мы ожидаем, что будем заинтересованы в нарезке и нарезке метрики на основе процентилей для каждого узла, региона, пространства имен или всего кластера, нам необходимо выполнить предварительное агрегирование соответствующим образом.
Другой подход состоит в том, чтобы отказаться от точности измерений, чтобы получить совместимость в вычислениях, используя гистограммы. Вы можете взять гистограммы нескольких серверов и суммировать их, или гистограммы нескольких временных окон и суммировать их, а затем масштабировать. Проблема в том, что в этом случае процентили будут скорее оценочными, чем точными. Также важно отметить, что гистограммы требуют больше времени для хранения и пропускной способности, поскольку каждая выборка представляет собой не просто одно число, а несколько выборок (по одной на сегмент).
Обзор
Метрики — это эффективный способ мониторинга наших приложений. Но они не обязательно отражают фактическое состояние системы. Требуется понимание математики и природы метрик, а также тщательного проектирования, чтобы убедиться, что наши метрики действительно полезны для ответа на нужные нам вопросы. Всегда хорошо иметь доступ к необработанным данным в дополнение к метрикам, так как это, в конечном счете, источник истины.
Хотите узнать больше? Посмотрите выпуск OpenObservability Talks: Все метрики неверны, некоторые полезны на Spotify , Подкасты Apple< /a> или другие приложения для подкастов .
Эта статья изначально была здесь. п
Оригинал