Обычно мы подключаем сбор метрик в prometheus к нашим web‑приложениям с помощью каких‑то клиентских библиотек, которые отдают метрики на /metrics. В этой статье я хочу рассказать как визуализировать Latency с помощью Histogram метрики. Будет полезно тем, кто еще не строил метрики из Prometheus, а так же тем, кто хочет понять как их интерпретировать. На картинке «четыре золотых сигнала» (four golden signals) показан набор метрик, которые Google рекомендует отслеживать в SRE (Site Reliability Engineering) подходе. Это latency, traffic, errors и saturation. Мониторинг этих «четырех золотых сигналов» может помочь инженерам оперативно реагировать на проблемы, связанные с производительностью и надежностью системы, а также помочь в определении бутылочных горлышек и планировании масштабирования. Prometheus — это открытая система мониторинга и оповещения, которая была разработана SoundCloud. В среде распределенных систем Prometheus широко используется для сбора и визуализации метрик в реальном времени. Prometheus собирает и хранит метрики в виде данных временных рядов, каждый временной ряд идентифицируется именем и набором лейблов (пары, ключ, значение и т. д.).  Метрика — количественный показатель, используемый для измерения и оценки работы системы. Сбор метрик. Prometheus использует pull‑модель для сбора метрик, которая предполагает, что Prometheus сам инициирует процесс сбора информации с сервисов, которые мониторит. Это отличает его от push‑модели, где сервисы самостоятельно отправляют свои метрики на сервер мониторинга. Однако у prometheus есть push‑gateway. Latency (или задержка) — время, которое требуется для обработки запроса. В контексте веб‑сервисов, это обычно время, затраченное на обработку HTTP‑запроса. Мониторинг latency важен, так как он напрямую влияет на пользовательский опыт. Важно не просто отслеживать среднее время задержки, но и изучать его распределение, чтобы понять, как ведет себя система в условиях различной нагрузки. Для демонстрации создадим простое приложение, Grafana находится на 3000 порту, логин/пароль — admin/admin. Нужно добавить источник данных — http://prometheus:9090.    Prometheus собирает данные по latency при помощи наблюдателей (observers) в клиентских библиотеках. В мире Prometheus существует четыре основных типа наблюдателей: Counter, Gauge, Summary и Histogram. Для измерения задержки обычно используется Histogram. Histogram подсчитывает наблюдения (samples), например, HTTP‑запросы, которые он сортирует в настраиваемые сегменты (buckets) по длительности. Он также считает общее количество наблюдений и сумму всех наблюдаемых значений. Например, вы можете определить сегменты следующим образом: 0.1, 0.2, 0.3, 0.4, 0.5 секунды. Каждый раз, когда Prometheus получает новое значение latency, он увеличивает счетчик для соответствующего сегмента. Например в клиенте prometheus_client предлагается такое значение: Дефолтные сегменты не всегда имеют смысл для вашего приложения. Я бы рекомендовал выбирать сегменты относительно SLO (целевой уровень обслуживания). А так же несколько сегментов выше/ниже SLO. Например, если SLO для микросервисов составляет около 500 мс. Слишком меньшие сегменты (5 мс, 10 мс, 25 мс, 50 мс) и слишком большие сегменты (2500 мс, 5000 мс, 7500 мс, 10 000 мс) бесполезны. Histogram состоит из трех элементов:  <имя>_count, подсчитывающий количество наблюдений;  <имя>_sum, сумма всех наблюдаемых значений;  набор из сегментов <имя>_bucket с меткой le (меньше или равно), которые содержат количество наблюдений, значение которых меньше или равно числовому значению, содержащемуся в сегменте. Сегмент le="0.1" указывает, что 2 запроса завершились за 0.1 секунду или быстрее. Частоты для каждого отдельного сегмента, сообщаемые клиентом Prometheus, являются кумулятивными. Это означает, что счетчик для сегмента le="0,4" также включает счетчик для сегментов le="0,3", le="0,2", le="0,1". По Histogram можно посчитать квантили(перцентили). Квантиль — значение, которое заданная случайная величина не превышает с фиксированной вероятностью. Если вероятность задана в процентах, то квантиль называется процентилем или перцентилем. Если 25% всех наблюдений лежат ниже или равны значению, мы можем сказать, что значение является 25-м перцентилем, и это значение может быть представлено как p25. Перцентиль(процентиль) — это статистическая мера, которая показывает, какой процент наблюдений в группе не превышает определенного значения. Перцентили используются в статистике для дачи более полного понимания распределения наблюдений. В контексте latency, перцентили обычно используются для описания распределения времени ответа системы. Рассмотрим пример. Пусть у вас есть веб-сервер, и вы замерили время ответа сервера на 1000 запросов. Вы записали эти времена ответа и отсортировали их по возрастанию. Пусть 50-й перцентиль (или медиана) равен 200 миллисекундам. Это означает, что 50% всех запросов были обработаны за 200 миллисекунд или быстрее. Если 95-й перцентиль равен 500 миллисекундам, это означает, что 95% всех запросов были обработаны за 500 миллисекунд или быстрее, а 5% запросов требовали больше времени на обработку. 99-й перцентиль, который может быть равен, например, 800 миллисекундам, показывает, что 99% всех запросов были обработаны за 800 миллисекунд или быстрее, а самые медленные 1% запросов требовали больше времени на обработку. Таким образом, перцентили предоставляют важное понимание о том, как система ведет себя не только в среднем, но и в крайних условиях, позволяя определить как нормальную работу системы, так и ее поведение в условиях пиковой нагрузки. Для графика Latency будем использовать перцентиль 95%, можно так же построить и другие перцентили. Для визуализации в Grafana нужно выполнить PromQL (Prometheus Query Language) запрос: request_latency_seconds_bucket — временной ряд из Prometheus. rate — используется для вычисления средней скорости изменения для временных рядов в указанный промежуток времени, как часто определенное событие происходит в течении определенного времени. Грубо говоря, как производная в математике. sum — оператор агрегации, который суммирует значения по группе элементов. Используется для получения общей суммы значений для всех подходящих временных рядов. histogram_quantile — ищет значение, которое не превышает определенный процент всех запросов. Интерпретировать можно так: «N% всех запросов обрабатывается быстрее, чем это значение». Для построения Latency, можно использовать выражение: Это выражение дает вам 95-й перцентиль Latency запроса за последнюю минуту. Это значит, что 95% всех измеренных запросов за последнюю минуту имели задержку, которая была меньше или равна вычисленному значению. Histogram не являются эффективным инструментом для точного измерения задержки, особенно на границах сегментов. Так как если latency уменьшился на 20 мс, будет ли это заметно на графике — зависит от настроенных сегментов. Данный график можно использовать в широком смысле для качественной оценки оптимизации, но не для количественной. Не стоит использовать очень много сегментов, так как каждый сегмент образует свой временной ряд в БД Prometheus'a. Материалы статьи  Мой тг канал, где я пишу заметки/мысли о backend, system design, архитектуре и проектировании  Senior backend-разработчик: go, postgres, kafka