Эксплуатация OTel Collector: надёжность, version skew, режимы отказа и управление

Collector падает. Ошибки приложения растут, но алерты не срабатывают, трассировки не появляются в бэкенде. Дежурный инженер проверяет дашборды — всё зелёное, потому что дашборды зависят от того же Collector, который только что упал. Самомониторинг OTel — не опция.

Паттерны надёжности

HA-шлюз — минимум 3 реплики: отказ одного gateway pod теряет все буферизованные в нём спаны в полёте. Три реплики означают, что отказ одного pod переживаем при повторных попытках клиента. За Kubernetes Service или облачным балансировщиком нагрузки; loadbalancing exporter на агентах использует эндпоинт сервиса, поэтому масштабирование прозрачно для агентов.

Persistent queue — расширение file_storage предоставляет буфер на диске, переживающий перезапуски Collector. Конфигурируйте его на экспортных пайплайнах шлюза для поглощения 5-15 минут замедления бэкенда без потери спанов:

extensions:
  file_storage:
    directory: /var/otel/queue

exporters:
  otlp/primary:
    endpoint: backend:4317
    sending_queue:
      storage: file_storage
      queue_size: 10000

Health checks — liveness и readiness-пробы против расширения health_check на порту 13133. Не позволяйте медленному или перегруженному Collector считаться готовым — он продолжит получать спаны, которые не может обработать.

Самомониторинг — скрейпить эндпоинт /metrics Collector (порт 8888) и алертить на:

• otelcol_processor_dropped_spans rate > 0 — memory_limiter срабатывает; предупреждать немедленно
• otelcol_receiver_refused_spans rate > 0 — backpressure на receiver; коррелирует с давлением памяти
• otelcol_exporter_send_failed_spans rate > 0 — проблема с подключением к бэкенду
• otelcol_exporter_queue_size / ёмкость очереди > 80% — накопление бэклога экспортёра; бэкенд медленный
• otelcol_processor_tail_sampling_count_traces_on_memory vs num_traces — приближение к исчерпанию буфера
• process_resident_memory_bytes vs настроенный лимит — приближение к OOM

Размер ресурсов — обычный gateway pod (4 CPU, 8 ГБ RAM) обрабатывает ~100-200к спанов/с с tail sampling. Размер для пика + 2x headroom. Устанавливайте низкие CPU requests и жёсткие limits/requests RAM (memory_limiter должен срабатывать раньше Linux OOM killer).

Version skew и стратегия стабильности

OTel — это множество независимо версионированных компонентов: спецификация (v1.x), каждый языковой SDK (по-разному), каждый бинарник Collector (v0.x с частыми релизами), каждый домен Semantic Conventions (HTTP 1.x, DB 1.x и др.).

Совместимость: SDK прямо совместимы с более новыми Collector в нескольких минорных версиях; OTLP стабилен. Collector имеет понятие стабильных и бета-компонентов — production-конфигурации придерживаются стабильных receivers, processors, exporters.

Стратегия:

1. Фиксировать версии SDK и Collector в манифестах развёртывания
2. Обновлять ежеквартально с канарейкой перед fleet-wide rollout
3. Отслеживать версии Semantic Conventions по сервисам, чтобы дашборды знали, какие имена атрибутов ожидать
4. Использовать OTel Operator для обновлений Collector: обновление CRD запускает rolling restart, нулевое время простоя

Production-режимы отказа

(a) OOM Collector при tail sampling: буфер шлюза растёт выше лимита памяти из-за слишком длинного decision_wait или всплеска объёма трассировок. Меры защиты: memory_limiter перед tail_sampling; алерт на dropped_spans; правильный размер num_traces для пиковой скорости × decision_wait × 2.

(b) Перераспределение tail-sample при масштабировании: пул шлюзов масштабируется вверх, кольцо хэшей loadbalancing exporter перетасовывается, трассировки в полёте теряют часть спанов. Меры защиты: предварительный прогрев новых podов, консервативное масштабирование, использование более длинных окон конвергенции на loadbalancing exporter.

(c) Несовпадение версий OTLP: Collector, обновлённый раньше SDK, встречает неизвестное поле в более новом OTLP proto; может незаметно удалять атрибуты или всю запись. Меры защиты: матрица совместимости SDK и Collector; поэтапные обновления; никогда не обновлять Collector раньше SDK, от которых он принимает данные.

(d) Регрессия из-за авто-инструментирования: новая минорная версия OTel Java Agent добавляет инструментирование, замедляющее критичную библиотеку. Меры защиты: канарейка обновления агента; мониторинг p99 задержки затронутого сервиса; использование per-instrumentation флагов отключения (OTEL_INSTRUMENTATION_X_ENABLED=false).

(e) Утечка кардинальности через авто-инструментирование: авто-инструментированный HTTP-клиент добавляет url.full (raw URL с параметрами запроса) как атрибут, взрывая кардинальность в бэкенде метрик. Меры защиты: конфигурировать инструментирование использовать http.route (шаблонный) вместо url.full; удалять строки запроса через процессор attributes на Collector.

Управление Semantic Conventions

Semantic Conventions — то, как телеметрия всех команд компонируется в масштабе флота. Сбои управления дорогостоящи:

• Команда-A называет поле route
• Команда-B называет его http_route
• Команда-C называет его http.route (правильное имя Semantic Convention)
• Кросс-командные дашборды используют http.route — команды A и B невидимы

Паттерн: платформенная команда публикует языково-специфичную обёртку, предварительно конфигурирующую извлечение атрибутов Semantic Conventions. Новые сервисы импортируют обёртку; CI-линтер отклоняет прямое использование SDK в новом коде. Обёртка обрабатывает:

• Извлечение HTTP-маршрута (совпавший шаблон, а не raw URL)
• Тегирование системы БД (db.system=postgresql, не “psql”)
• Deny-листы редактирования
• Примешивание trace-context к логам

Ежеквартальный аудит: проверять 10 наиболее часто используемых имён атрибутов по сервисам на дрейф от Semantic Conventions. Результат аудита — бэклог платформенной команды.