Защита от взрыва кардинальности метрик в OpenTelemetry

Иногда приложения могут создать метрики с лейблами в которых тысячи и сотни значений. Хороший пример, когда в лейбл кладут URL. И оказывается у вас на сайте десятки тысяч, сотни тысяч товаров, в момент когда приходит поисковый робот это все обходить - количество метрик растет в геометрической прогрессии. Чем больше у вас измерений, тем больше данных - это как разница между 2D и 3D. Если 2 измерения x и y, в которых по 10 и 20 значений, то получим 10*20=200 строк метрик. Если же мы добавили еще одну метку z (измерение) в которой 30 значений, то получим 10*20*30=6000 рядов. А теперь в моменте в z оказывается 30000 разных значений, получаем 10*20*30000=6 000 000 рядов.

Мы такое ловили у себя при подсчете метрик по логам http-сервера в vector.dev, после чего поставили трансформ для защиты tag_cardinality_limit - он как раз отбрасывает метки, если в них слишком много значений. То что он отбрасывает значения можно увидеть по внутренним метрикам vector.dev

Для OpenTelemetry часто используют свои компоненты для обработки. Коллектор OpenTelemetry отвечает за прием и обработку данных, он поддерживает разные процессоры (аналог трансформа в vector.dev) чтобы преобразовывать данные как нужно вам. С метриками тут может также случиться эта беда. Для защиты от взрыва кардинальности метрик появился https://github.com/YElayyat/otel-cardinality-processor процессор OpenTelemetry

Случались ли у вас взрывы кардинальности метрик? Как предотвращали?

#observability #metrics #cardinality #наблюдаемость #opentelemetry