Как диагностировать, что рост потребления памяти и нестабильность Prometheus вызваны высокой кардинальностью, и как смягчить проблему без полного редизайна метрик?

Короткий ответ

Диагностика через встроенные метрики prometheus_tsdb_head_series, prometheus_tsdb_symbol_table_size_bytes и запросы вида topk(10, count by (__name__)({__name__=~".+"})), показывающие метрики с наибольшим числом рядов; смягчить можно через metric_relabel_configs с drop/labeldrop для проблемных labels без изменения кода приложения.

Как это работает подробнее

резкий рост prometheus_tsdb_head_series (число активных временных рядов в памяти) при том же количестве сервисов обычно означает, что кто-то начал слать метрику с новым высококардинальным label (например, после деплоя новой версии приложения). Запрос topk(10, count by (__name__)({__name__=~".+"})) в самом Prometheus показывает, какие именно метрики дают наибольшее число рядов, что сразу сужает область поиска до конкретного job/метрики.

Пример кода

config.yamlКопировать

scrape_configs:
  - job_name: "app"
    static_configs:
      - targets: ["app:8080"]
    metric_relabel_configs:
      - source_labels: [request_id]
        regex: '.+'
        action: labeldrop

Что использовать на практике

• Практика. быстрое смягчение без изменения кода приложения — добавить metric_relabel_configs в scrape_config с действием labeldrop для убийственного label или drop для целой метрики, если она не нужна. Это временная мера; правильное решение — убрать высококардинальный label из инструментации приложения и, при необходимости, перенести эти данные в логи/трейсы, где высокая кардинальность не создаёт той же проблемы.
• Практика. После применения такой конфигурации и reload Prometheus (kill -HUP или /-/reload) метрика http_requests_total продолжит собираться, но без label request_id; метрика prometheus_tsdb_head_series должна стабилизироваться или снизиться в течение следующих нескольких scrape-циклов, что подтверждает устранение источника кардинальности.

Подводные камни

• Частые ошибки. сразу увеличивать ресурсы (RAM) Prometheus вместо диагностики источника кардинальности — это лечит симптом, но проблема вернётся при дальнейшем росте; применять metric_relabel_configs слишком агрессивно и терять нужные данные по другим labels того же имени метрики; не мониторить саму кардинальность на постоянной основе, из-за чего проблема обнаруживается только в момент инцидента (OOM Prometheus), а не превентивно.