В этом материале
Уникальный request ID не подходит для metric label. Ограниченные категории и отдельная корреляция traces сохраняют наблюдаемость без взрыва числа рядов.
Кажется удобным добавить request ID в labels и затем искать любой медленный запрос через метрику. Но каждый новый идентификатор создаёт новые комбинации рядов. Вместе с model, replica, outcome и histogram buckets объём может расти быстрее полезности панели. Для inference-провайдера нужен бюджет cardinality, который отделяет статистические группы от уникальных диагностических записей и учитывает изменение каталога моделей.
Назовите вопрос каждого label
Prometheus о naming рекомендует сохранять осмысленные единицы и labels, избегая неограниченных измерений. Перед добавлением поля спросите, какое сравнение оно позволяет выполнить. Если ответ сводится к поиску одного запроса, вероятнее нужен log или trace, а не новая статистическая группа.
Model может быть полезной ограниченной категорией, но набор динамических alias тоже требует управления. Полный пользовательский prompt, URL с уникальным параметром и случайный request ID не становятся безопасными labels только потому, что библиотека позволяет записать строку. Их пространство значений принципиально отличается от статуса или режима.
Посчитайте произведение комбинаций
Оцените число model values, replicas и outcomes, затем учтите выбранный тип histogram. Для classic histogram дополнительные buckets увеличивают число серий вместе с sum и count. Это расчёт структуры метрик, а не прогноз полезного трафика. Даже редкое событие способно породить новую комбинацию.
Сохраните таблицу допустимых значений и ожидаемого роста. При появлении новой модели или версии проверьте бюджет снова. Удалённая реплика может оставлять исторические ряды в хранилище, поэтому текущий список процессов не описывает полностью объём уже накопленных данных за период retention.
Разделите счётчики и диагностику
Рекомендации instrumentation связывают метрики с типом сервиса и наблюдаемыми операциями. Для сводок полезны запросы, ошибки, latency и in-progress. Их определения должны оставаться стабильными, чтобы изменение cardinality не сопровождалось незаметной сменой смысла измерений.
Уникальные сведения сохраняют в разрешённой диагностической записи с контролем доступа. OpenTelemetry context propagation помогает связать операции через trace context. Такая связь не требует помещать trace ID в metric label каждого observation и не превращает metadata в разрешение хранить содержание пользователя.
Проверьте неизвестные значения
Fixture добавляет неожиданный outcome или неизвестный model identifier. Решите, создаётся ли отдельное ограниченное значение unknown, отклоняется ли метрика либо применяется другая документированная политика. Молчаливое удаление наблюдения может улучшить график именно тогда, когда появилась новая ошибка.
Тестовый набор должен также показывать, что уникальные IDs не расширяют labels. Сгенерируйте ограниченное число разных request identifiers и сравните число серий до и после. Важно проверять фактический exporter output, потому что дополнительные labels может добавлять другой слой instrumentation.
Сохраните бюджет с релизом
Запишите allowlist labels, их владельца, тип метрики и правила миграции. После изменения exporter повторите synthetic fixture. При превышении бюджета сначала исследуйте источник новых комбинаций, а не удаляйте наугад измерение, от которого зависит правильный denominator или разделение моделей.
Связанные темы — мониторинг GPU и отчётность операций. Итог — управляемая статистическая схема и отдельный путь детализации, без обещаний нулевой стоимости observability или готового мониторинга неизвестной инфраструктуры.