Наблюдаемость и SRE

Высокая кардинальность

Определение

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

Также ищут: High cardinality · cardinality explosion · series explosion

Зачем это знать

Неограниченный идентификатор в метках делает приём данных и запросы дороже и может исчерпать память раньше, чем закончится место на диске.

Связи из словаря

Карта понятия

Высокая кардинальность
Доказательная часть

Что подтверждено

  1. Prometheus прямо не рекомендует метки с неограниченным набором значений, например идентификаторами пользователей и адресами электронной почты.

    Граница применимости: Практика работы с метриками Prometheus; расследование отдельных событий следует вести по журналам, трассировкам или в другой системе.

  2. Добавление измерения с высокой кардинальностью увеличивает число хранимых рядов даже при неизменной частоте сбора.

    Граница применимости: Хранение рядов Prometheus с метками; точный расход ресурсов зависит от сменяемости, срока хранения и нагрузки запросов.

  3. Если каждый запрос получает новый request_id и этот идентификатор включён в метки метрики, повторное обращение создаёт новое сочетание меток вместо продолжения прежнего ряда. При неизменном интервале сбора растут число рядов и расходы на их обслуживание.

    Граница применимости: Редакторское применение модели Prometheus к уникальному идентификатору запроса. Момент отказа и расход байтов не выводятся из одного имени метки.

  4. Для метрики запросов шаблон /orders/{id} с ограниченным набором маршрутов позволяет считать операции вместе. Полный путь /orders/уникальный-id создаёт новые значения по заказам; подробности отдельных запросов лучше связывать с журналом или трассировкой.

    Граница применимости: Редакторская рекомендация для маршрутов приложения. Шаблон должен браться из ограниченного набора; случайный текст запроса не становится безопасным от переименования метки.

  5. Сокращение срока хранения уменьшает историю, но не ограничивает число новых сочетаний меток, создаваемых сейчас. При уникальном идентификаторе каждого запроса сначала ограничивают измерения; точный бюджет памяти и диска проверяют нагрузкой.

    Граница применимости: Редакторское разделение потока новых рядов и политики удаления истории. Не утверждается, что одно изменение меток само по себе обеспечивает заданную производительность.

Перед спецификацией

Что проверить

  1. Запретите идентификаторы пользователя, сеанса и запроса в метках метрик.
  2. Следите за числом активных рядов и их сменяемостью.
  3. Поиск по отдельным объектам выносите в журналы или трассировки.
Открытые основания

Первоисточники

  • Стандарт1
  • Документация2
  • Официальная документация
    Metric and Label Naming Prometheus Authors · Prometheus best practices, checked 29 August 2026 · проверено

    Определяет каждую unique комбинацию label pairs как отдельную time series и запрещает unbounded high-cardinality labels.

    Утверждения: 01 · 02 · 03 · 04 · 05

  • Официальная документация
    Prometheus Storage Prometheus Authors · Prometheus latest documentation, checked 29 August 2026 · проверено

    Документирует time/size retention, oldest-first deletion, capacity formula и временный disk overhead compaction.

    Утверждения: 02 · 03 · 05

  • Первичная спецификация
    OpenTelemetry Specification Overview OpenTelemetry · OpenTelemetry Specification 1.60.0 · проверено

    Описывает signals, raw measurements, aggregation, resources и context propagation.

    Утверждения: 04

Подтвердите действие