С OpenTelemetry Collector легко собрать proof of concept: принять telemetry, добавить processor, отправить данные в backend и увидеть trace. В production появляются другие вопросы. Что произойдет, если backend замедлится? Кто отвечает за retry? Можно ли масштабировать pipeline, не сломав tail sampling? Как команда узнает, что сам Collector теряет данные?
Я отношусь к Collector как к production-инфраструктуре, а не как к прозрачной трубе. Конфигурация важна, но topology, поведение при отказах и собственная наблюдаемость важнее.
Topology я выбираю по границам отказа
Обычно я разделяю agent и gateway responsibilities. Agent рядом с workload отвечает за локальный сбор и resource context. Gateway tier — за централизованную обработку, sampling и exports. Конкретная схема зависит от Kubernetes, виртуальных машин, сетей и compliance-границ; важно явно определить владельца и влияние каждого отказа.
До добавления processors я рисую путь metrics, logs и traces. Для каждого перехода фиксирую transport, authentication, ожидаемый объем, buffering и поведение при недоступности следующего узла. Это находит больше production-проблем, чем полировка одного большого YAML.
У queues и retries должен быть бюджет
OpenTelemetry дает sending queues и retry helpers для временных сбоев. Включить их недостаточно. Queue имеет конечную capacity, расходует memory и в итоге переполняется. Я рассчитываю ее под конкретное окно недоступности и проверяю поведение после превышения этого окна.
Для данных, которые нельзя восстановить, я рассматриваю persistent write-ahead log и отдельно проверяю storage при рестартах. Еще я заранее решаю, какой signal можно деградировать первым. Попытка считать каждый byte одинаково критичным часто создает неконтролируемый отказ вместо понятной политики.
Backpressure — архитектурное решение. Если его не приняла команда, во время инцидента его примет runtime.
Масштабирование не всегда stateless
Многие Collector pipelines можно горизонтально масштабировать за load balancer. Но постоянные gRPC connections требуют подходящей балансировки: простой L4 balancer может оставить трафик на одном backend. Stateful processing требует еще больше внимания.
Tail sampling, span-to-metrics и другим stateful components нужно, чтобы связанная telemetry попадала на один Collector instance. Там, где это требуется, я использую consistent routing и проверяю распределение нагрузочным тестом. Добавление replicas без сохранения affinity может выглядеть здоровым, одновременно незаметно меняя результат обработки.
Я наблюдаю за самим telemetry pipeline
Production Collector должен показывать, принимает ли он данные, отказывает, ставит в очередь, повторяет отправку или теряет их. Я слежу за queue size относительно capacity, enqueue failures, exporter failures, processor refusals, memory pressure и рестартами. Эти сигналы попадают в небольшой operational view с явным владельцем.
Версия конфигурации и deployment events также должны быть видимы. Когда меняется объем или cardinality, responder должен сразу видеть, совпало ли это с rollout Collector или изменением config.
- Queue size, capacity и enqueue failures
- Accepted и refused spans, metrics и log records
- Exporter errors, retries и destination latency
- Memory limiter, CPU, memory и restarts
- Версия конфигурации и rollout status
Мой production gate
Перед широким rollout я провожу failure tests: замедляю или останавливаю destination, перезапускаю Collector, заполняю queue и отправляю заведомо некорректный payload. Затем проверяю, что нужный alert сработал, заявленная loss policy соответствует реальности, а recovery не создает вторую перегрузку.
Только после этого я расширяю покрытие сервисов. Так OpenTelemetry превращается из удачной интеграции в управляемый telemetry layer с понятными ограничениями и предсказуемым поведением.
