OTel Collector для трёх клиентов: как единый стандарт убирает эксплуатационный мусор

Где-то в начале этого года мы обнаружили, что у нас на managed-сопровождении три клиента - и у каждого свой зоопарк агентов мониторинга. Один собирает метрики через Prometheus node-exporter, трейсы через Jaeger-агент, логи через Filebeat. Второй - Telegraf плюс Zipkin плюс Fluentd. Третий - вообще что-то кастомное, написанное предыдущей командой и частично задокументированное. Поддерживать это всё одновременно - значит держать в голове три разные модели данных, три разных формата конфигурации и три разных точки отказа при обновлении стека.

Решение очевидное, но не быстрое: перевести всех на OpenTelemetry Collector.

Почему именно сейчас

OpenTelemetry сам по себе существует давно - слияние OpenCensus и OpenTracing произошло в 2019-м, и с тех пор проект рос. Но именно в этом году ощущение сдвинулось: крупные корпоративные заказчики в РФ начали включать OTel в технические требования к новым системам, несколько отечественных APM-вендоров заявили о поддержке OTLP как основного протокола приёма, а коллектор наконец дошёл до статуса stable по всем трём сигналам - traces, metrics и logs.

Stable в контексте OpenTelemetry означает конкретное: API зафиксирован, breaking changes не будет без major-версии, receiver/exporter для основных протоколов прошли нагрузочное тестирование. До этого момента мы держались - логи в OTel Collector дольше всего оставались в beta, и несколько раз менялась схема обработки log records. Теперь этого риска нет.

Как выглядела унификация на практике

Начали с клиента, у которого стек был чище всего - Prometheus + Jaeger + Loki. Там смысл унификации максимально очевидный: три процесса сбора данных заменяются одним коллектором, который умеет принимать и тот, и другой формат на входе, а на выходе отдавать куда нужно.

Схема, к которой пришли:

Приложения/системы
    |
    v
OTel Collector (gateway mode)
    |-- Prometheus receiver (scrape метрик)
    |-- OTLP receiver (traces от сервисов)
    |-- Filelog receiver (логи с хостов)
    |
    v
Бэкенды: Prometheus/Mimir (метрики), Tempo (трейсы), Loki (логи)

Коллектор запускается в режиме gateway - один экземпляр (или небольшой кластер для HA) принимает всё, нормализует и отправляет дальше. Для клиентов с Kubernetes поставили дополнительный collector как DaemonSet - он собирает метрики и логи с нод и отправляет на gateway.

Второй клиент был сложнее: там Telegraf активно использовался для сбора метрик с нестандартного железа через SNMP. OTel Collector имеет SNMP receiver, но он на момент внедрения был в beta и с несколькими известными quirks. Приняли решение оставить Telegraf только для SNMP, выход с него направить в OTLP через Telegraf OpenTelemetry output plugin, и дальше всё идёт уже через коллектор. Компромисс, но рабочий - не ломаем то, что работает, при этом в pipeline данные нормализуются на входе.

Третий клиент с кастомным стеком занял больше всего времени: сначала нужно было просто понять, что именно там собирается и куда идёт. Оказалось, что часть метрик вообще никуда не смотрелась последние полгода - дашборды были, данных не было, и никто не заметил. Это отдельный разговор, но к теме: унификация заставила инвентаризировать то, что существовало по инерции.

Что сократилось, а что нет

Эксплуатационные накладные расходы действительно упали - но не равномерно.

Упало заметно:

• Количество конфигурационных файлов агентов на сопровождении. Вместо трёх-четырёх конфигов разных форматов на клиента - один otelcol.yaml с понятной структурой receivers/processors/exporters.
• Время диагностики при проблемах со сбором данных. Раньше нужно было понять, какой именно агент проблемный, и лезть в его специфический формат логов. Теперь смотрим в один коллектор.
• Обновления. Один бинарь вместо трёх. Коллектор выходит в двух дистрибутивах - core и contrib, contrib содержит все receiver-ы и exporter-ы. Одна задача в Ansible вместо трёх.

Не упало и не должно было:

• Время на настройку processors. OTel Collector мощный, но и processors pipeline для фильтрации, трансформации атрибутов, семплирования трейсов - это всё нужно думать и конфигурировать. Здесь работы меньше не стало.
• Ведение бэкендов. Prometheus, Tempo, Loki сами по себе никуда не делись, и их поддержка - отдельный объём работы.

Отдельно стоит отметить: переход дал неожиданный бонус с трейсами. У второго клиента раньше трейсы через Zipkin собирались только с Java-приложений - остальные сервисы не поддерживали протокол. После перехода добавили OTLP-инструментацию на Python-сервисы, которые до этого были «слепым пятном». Не то чтобы без OTel это было невозможно, просто раньше не доходили руки, а тут инфраструктура уже была готова принять данные.

Где коллектор ещё сырой

Честно: логи в OTel Collector работают, но Filebeat по-прежнему богаче в части парсинга. Filelog receiver умеет multiline, regex-парсинг, операторы для структурирования - этого достаточно для большинства задач, но если у кого-то сложные grok-паттерны под десятки форматов приложений, миграция потребует аккуратной переработки.

SNMP receiver, как уже сказал - в beta, с ограничениями по MIB-поддержке. Для инфраструктурного мониторинга железа Telegraf пока объективно полнее.

Документация коллектора местами расходится с реальным поведением - особенно в части processor-цепочек и порядка применения трансформаций. Спасает то, что сообщество активное и большинство нюансов уже разобрано на GitHub issues.

Где сейчас

Все три клиента переведены, работаем уже несколько месяцев. Managed-сопровождение стало немного спокойнее в части мониторинга именно потому, что унификация убрала ситуации «а у этого клиента по-другому». Конфигурации стали шаблонизируемыми - появился внутренний baseline, который адаптируется под клиента, а не пишется с нуля каждый раз.

OpenTelemetry - не серебряная пуля и не замена пониманию того, что ты мониторишь. Но как инфраструктурный стандарт для сбора и транспорта сигналов он сейчас в достаточно зрелом состоянии, чтобы строить на нём.