Как из метрик Prometheus построить график Latency11.07.2023 18:01

Обычно мы подключаем сбор метрик в prometheus к нашим web‑приложениям с помощью каких‑то клиентских библиотек, которые отдают метрики на /metrics. В этой статье я хочу рассказать как визуализировать Latency с помощью Histogram метрики. Будет полезно тем, кто еще не строил метрики из Prometheus, а так же тем, кто хочет понять как их интерпретировать.

На картинке «четыре золотых сигнала» (four golden signals) представляют собой набор метрик, которые Google рекомендует отслеживать в SRE (Site Reliability Engineering) подходе. Это latency, traffic, errors и saturation. Мониторинг этих «четырех золотых сигналов» может помочь инженерам оперативно реагировать на проблемы, связанные с производительностью и надежностью системы, а также помочь в определении бутылочных горлышек и планировании масштабирования.

Prometheus

Prometheus — это открытая система мониторинга и оповещения, которая была разработана SoundCloud. В среде распределенных систем Prometheus широко используется для сбора и визуализации метрик в реальном времени.

Prometheus собирает и хранит метрики в виде данных временных рядов, каждый временной ряд идентифицируется именем и набором лейблов (пары, ключ, значение и т. д.).

# Пример метрики с /metrics
request_latency_seconds_bucket{le="0.1"} 32.0

Что такое метрика

Сбор метрик. Prometheus использует pull‑модель для сбора метрик, которая предполагает, что Prometheus сам инициирует процесс сбора информации с сервисов, которые мониторит. Это отличает его от push‑модели, где сервисы самостоятельно отправляют свои метрики на сервер мониторинга. Однако у prometheus есть push‑gateway.

Latency (или задержка) — время, которое требуется для обработки запроса. В контексте веб‑сервисов, это обычно время, затраченное на обработку HTTP‑запроса. Мониторинг latency важен, так как он напрямую влияет на пользовательский опыт. Важно не просто отслеживать среднее время задержки, но и изучать его распределение, чтобы понять, как ведет себя система в условиях различной нагрузки.

Web-приложение на fast-api

Для демонстрации создадим простое приложение, Grafana находится на:3000 порту, логин/пароль — admin/admin. Нужно добавить источник данных — http://prometheus:9090.

Код приложения на 28 строк:)

import time
from typing import Union

from prometheus_client import Histogram, make_asgi_app
from fastapi import FastAPI

app = FastAPI()

metrics_app = make_asgi_app()
app.mount("/metrics", metrics_app)

REQUEST_LATENCY = Histogram(
    name='request_latency_seconds',
    documentation='Time spent processing a request',
    buckets=(.1, .2, .3, .4, .5)
)


@app.get("/")
def read_root():
    return {"Hello": "World"}


@app.get("/items/{item_id}")
@REQUEST_LATENCY.time()
def read_item(item_id: int, q: Union[str, None] = None):
    time.sleep(item_id / 100)
    return {"item_id": item_id, "q": q}

Dockerfile для приложения

FROM python:3.10

WORKDIR /code

COPY ./requirements.txt /code/requirements.txt

RUN pip install --no-cache-dir --upgrade -r /code/requirements.txt

COPY ./app /code/app

CMD ["uvicorn", "app.main:app", "--host", "0.0.0.0", "--port", "8000"]

Docker-compose

version: '3.9'

services:
  web:
    build: .
    ports:
      - 8000:8000

  prometheus:
    image: prom/prometheus
    volumes:
      - ./prometheus.yml:/etc/prometheus/prometheus.yml
    ports:
      - 9090:9090
    depends_on:
      - web

  grafana:
    image: grafana/grafana
    ports:
      - 3000:3000
    depends_on:
      - prometheus

Как собирать метрики для построения Latency

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, он увеличивает счетчик для соответствующего сегмента.

Как выбрать распределение сегментов

DEFAULT_BUCKETS = (.005, .01, .025, .05, .075, .1, .25, .5, .75, 1.0, 2.5, 5.0, 7.5, 10.0, INF)

Histogram состоит из трех элементов:

• <имя>_count, подсчитывающий количество наблюдений;

• <имя>_sum, сумма всех наблюдаемых значений;

• набор из сегментов <имя>_bucket с меткой le (меньше или равно), которые содержат количество наблюдений, значение которых меньше или равно числовому значению, содержащемуся в сегменте.

Было два запроса по 30 ms — данные с /metrics

Сегмент le="0.1" указывает, что 2 запроса завершились за 0.1 секунду или быстрее.

Сделали еще один запрос на 468 ms — данные с /metrics

Частоты для каждого отдельного сегмента, сообщаемые клиентом Prometheus, являются кумулятивными. Это означает, что счетчик для сегмента le="0,4" также включает счетчик для сегментов le="0,3", le="0,2", le="0,1".

По Histogram можно посчитать квантили (перцентили).

Что такое перцентиль

Выполним запросы к web-приложению

Получим такие метрики с /metrics

Как построить график Latency в Grafana

Для графика Latency будем использовать перцентиль 95%, можно так же построить и другие перцентили. Для визуализации в Grafana нужно выполнить PromQL (Prometheus Query Language) запрос:

histogram_quantile(
    0.95,
    sum(
      rate(
        request_latency_seconds_bucket[1m]
      )
    ) by (le)
)

request_latency_seconds_bucket — временной ряд из Prometheus.

rate — используется для вычисления средней скорости изменения для временных рядов в указанный промежуток времени, как часто определенное событие происходит в течении определенного времени. Грубо говоря, как производная в математике.

Средняя скорость изменения в сегментах

sum — оператор агрегации, который суммирует значения по группе элементов. Используется для получения общей суммы значений для всех подходящих временных рядов.

Суммируем, в нашем случае ничего не изменилось :)

histogram_quantile — ищет значение, которое не превышает определенный процент всех запросов. Интерпретировать можно так: «N% всех запросов обрабатывается быстрее, чем это значение».

95% запросов выполняются быстрее

50% запросов выполняются быстрее

Вывод

Для построения Latency, можно использовать выражение:

histogram_quantile(0.95, sum(rate(request_latency_seconds_bucket[1m])) by (le))

Это выражение дает вам 95-й перцентиль Latency запроса за последнюю минуту. Это значит, что 95% всех измеренных запросов за последнюю минуту имели задержку, которая была меньше или равна вычисленному значению.

Histogram не являются эффективным инструментом для точного измерения задержки, особенно на границах сегментов. Так как если latency уменьшился на 20 мс, будет ли это заметно на графике — зависит от настроенных сегментов. Данный график можно использовать в широком смысле для качественной оценки оптимизации, но не для количественной.

Не стоит использовать очень много сегментов, так как каждый сегмент образует свой временной ряд в БД Prometheus’a.

Материалы

Материалы статьи

Мой тг канал, где я пишу заметки/мысли о backend, system design, архитектуре и проектировании

© Habrahabr.ru