Cardinality проблемы
Тема дорожной карты · Prometheus
Кардинальность в Prometheus — общее количество уникальных временных рядов, хранящихся в TSDB, которое определяется количеством различных комбинаций значений меток по всем метрикам. Высокая кардинальность возникает, когда метки несут значения с неограниченным или очень большим доменом — например, при использовании user_id, request_id или полного URL-пути в качестве метки — и может вызвать значительные накладные расходы по памяти и ЦП, поскольку Prometheus должен отслеживать и индексировать каждый уникальный ряд. Мониторинг кардинальности критически важен для поддержания здорового развёртывания Prometheus; встроенная метрика prometheus_tsdb_head_series показывает текущее количество активных рядов, а эндпоинт HTTP API /api/v1/label/__name__/values помогает определить метрики, вносящие наибольший вклад в проблему. Для контроля проблем кардинальности следует избегать меток с высокой кардинальностью, использовать metric_relabel_configs для удаления ненужных значений меток до приёма данных и рассматривать агрегацию данных у источника. Когда проблемы кардинальности вызывают сбои из-за нехватки памяти или медленные запросы, такие инструменты, как Thanos или Cortex/Mimir с объектным хранилищем, помогут распределить нагрузку на хранилище.
Как это работает
Cardinality проблемы: вертикально (больше VM с диском + RAM) до ~5-10M активных series. За пределами: federation (один Prometheus скрейпит summaries с других), remote_write на long-term backend (Thanos, Mimir, VictoriaMetrics), или sharding (несколько Prometheus каждый скрейпит подмножество, запрос через Thanos Query / Cortex). VictoriaMetrics обычно проще Thanos на том же масштабе.
Когда применять
Сначала вертикально — больше RAM + SSD намного проще, чем введение Thanos. Federation работает для site/cluster-агрегации, но это не scale-out. Для long retention + horizontal scale выбирайте: VictoriaMetrics (простейший), Mimir (родной для Grafana stack), Thanos (object-storage-based). Capacity планируйте по числу active series, не объёму данных.
Типичные ошибки
Ловушки Cardinality проблемы: введение Thanos / Cortex преждевременно (операционный overhead больше проблемы); чтение из federated Prometheus вместо remote_write на query-слой (federation-запросы медленные); high cardinality на "scale-out"-backend всё равно стоит — сначала решите cardinality.