Метрики и cardinality: cost-модель time-series database

Команда добавляет label customer_email к counter request_total, чтобы отслеживать частоту ошибок по клиентам. Через два часа Prometheus исчерпывает память, и 15 минут алертов теряются. Label выглядел безобидно.

Как хранится метрика

Каноническая модель — Prometheus. Метрика идентифицируется парой (metric_name, label_set), где label_set — небольшой фиксированный набор пар key=value. Каждая уникальная комбинация значений label создаёт одну time series — поток сэмплов (timestamp, value), обычно собираемых каждые 15 с.

Четыре стандартных типа метрик:

• Counter — монотонно возрастающее целое. Осмысленна только скорость изменения (в секунду). Пример: http_requests_total.
• Gauge — мгновенное значение, может расти и падать. Пример: memory_used_bytes, queue_depth.
• Histogram — распределяет наблюдения по предопределённым bucket’ам для percentile-запросов. Пример: http_request_duration_seconds с bucket’ами [0.01, 0.05, 0.1, 0.5, 1.0, 5.0].
• Summary — предвычисленный перцентиль на реплике. Редко используется для новой инструментации: нельзя агрегировать между репликами.

Cardinality: главный драйвер стоимости

Каждая уникальная комбинация значений label создаёт отдельную time series в TSDB. Математика мультипликативная:

• route (20 шаблонов) × method (5 методов) × status_class (4 класса) = 400 series — нормально.
• Та же метрика + user_id (100 к активных пользователей) = 100к × 20 × 5 × 4 = 40 миллионов series — Prometheus падает с OOM на 16 ГБ.

Prometheus хранит около 3 КБ на активную series в head block. При 40 М series — 120 ГБ, что далеко за пределами памяти любого рядового сервера.

Правило: label ставь только на значения из небольшого фиксированного набора — шаблоны маршрутов, а не полные URL; классы статусов, а не коды статусов; сегменты клиентов, а не ID клиентов. Всё с неограниченными значениями — в логи (cardinality бесплатна) или в трейсы (сэмплированы), не в метрики.

Exemplar: мост метрика → трейс

Когда histogram записывает медленное наблюдение, клиент может прикрепить один exemplar — trace_id запроса, создавшего это наблюдение. Grafana отображает exemplar’ы как точки на тепловой карте histogram; клик по точке открывает соответствующий трейс.

Exemplar’ы (стандартизированы в Prometheus 2.32, начало 2022) устраняют разрыв: «метрики говорят, что что-то медленно, но нет конкретного запроса для дальнейшего анализа.» Они позволяют не добавлять user_id в label метрик — cardinality остаётся управляемой — и при этом навигировать от агрегированного всплеска к одному конкретному запросу через трейс.