Если вам говорили «используйте OpenTelemetry Collector», вы, возможно, заметили, что единого файла для скачивания не существует. Существует компактная сборка по умолчанию. Есть гораздо более крупный репозиторий, содержащий сотни созданных сообществом компонентов. Есть инструмент сборки, позволяющий скомпоновать собственный бинарный файл. И есть растущий набор вендорских дистрибутивов, каждый из которых предварительно упакован и готов к установке.
Это сделано намеренно. Проект OpenTelemetry сознательно выбрал такую структуру, и как только вы поймете почему, эта экосистема станет гораздо понятнее. В этой статье мы подробно рассмотрим каждый вариант, связанные с ним компромиссы и то, как принять решение, о котором вы не пожалеете через полгода.
Что такое OpenTelemetry Collector?
Представьте себе OpenTelemetry Collector как небольшую программу, которая располагается между вашими приложениями и бэкендами наблюдаемости. Это уровень трансляции и маршрутизации, который позволяет вашему коду инструментирования оставаться независимым от платформы, используемой для хранения и анализа телеметрии.
Внутри каждый Collector работает по одной и той же пятикомпонентной модели:
- Получатели (Receivers) извлекают или принимают телеметрию из источника. Примеры включают приложение, отправляющее OTLP, эндпоинт Prometheus для сбора метрик или топик Kafka для чтения.
- Процессоры (Processors) преобразуют данные по мере их прохождения. Типичные примеры включают батчинг, фильтрацию, маскирование конфиденциальных атрибутов и обогащение спанов метаданными ресурсов.
- Экспортеры (Exporters) отправляют результат в один или несколько бэкендов, таких как платформа вендора, объектное хранилище или другой Collector.
- Коннекторы (Connectors) объединяют два пайплайна, выступая в роли экспортера для одного и получателя для следующего. Например, коннектор spanmetrics преобразует спаны трейсов в метрики запросов, ошибок и длительности, а коннектор маршрутизации отправляет данные по разным пайплайнам на основе их атрибутов.
- Расширения (Extensions) добавляют сквозные возможности за пределами пайплайна, такие как проверки работоспособности (health checks), эндпоинты профилирования и zpages для отладки в реальном времени.
Вы связываете их вместе в секции сервиса YAML, чтобы объявить именованные пайплайны для трейсов, метрик и логов. Сила заключается в том, что создает такое разделение: вашему коду инструментирования не нужно знать, куда отправляется телеметрия.
Если ваш код инструментирования знает о конкретном вендоре, вы потеряли главное преимущество стандарта OpenTelemetry. Collector — это то, что поддерживает это обещание.
Почему не существует единого Collector?
Collector имеет открытый исходный код, но вы не поставляете репозиторий с исходным кодом. Вы поставляете его сборку — скомпилированный бинарный файл или образ контейнера, который включает определенный набор компонентов. Различные сборки включают разные компоненты, и выбранная вами сборка является вашим дистрибутивом.
Это тот момент, который упускают большинство команд. Когда кто-то говорит «мы используем OTel Collector», они неявно выбирают дистрибутив. Этот выбор определяет, какие получатели и экспортеры доступны, насколько они стабильны, как выглядит путь обновления и какая часть пайплайна принадлежит вашей команде и поддерживается ею. Это фундаментальное решение, а не второстепенная деталь реализации.
В этой статье основное внимание уделяется четырем вариантам, с которыми чаще всего сталкиваются команды: Core (бинарный файл otelcol), Contrib (otelcol-contrib), пользовательская сборка через OCB и дистрибутив вендора.
Проект OpenTelemetry также поддерживает три дополнительных специализированных дистрибутива: otelcol-k8s, сборку для Kubernetes, которая включает только нейтральные по отношению к вендорам компоненты, имеющие отношение к Kubernetes; otelcol-otlp, минимальную сборку, ограниченную получателями и экспортерами OTLP; и otelcol-ebpf-profiler, специализированный дистрибутив для непрерывного профилирования через eBPF. Все три варианта представляют собой целевые дистрибутивы, созданные с использованием того же шаблона OCB, который рассматривается здесь, а не отдельную категорию выбора.
Core: консервативная основа
Core (выпускаемый как otelcol) — это компактная, намеренно минимальная сборка, поддерживаемая проектом OpenTelemetry. В нее входят только самые необходимые компоненты: получатели и экспортеры OTLP, экспортер отладки (debug), процессоры batch и memory_limiter, а также небольшой набор расширений, таких как health_check, pprof и zpages. Такая сдержанность и является сутью.
Core намеренно минималистичен. Проверяйте текущую степень готовности компонентов и примечания к релизу для развертываемой версии, особенно если ваш пайплайн зависит от конкретного сигнала или компонента. Если ваши источники телеметрии уже используют OTLP и ваша топология проста, Core может стать хорошей отправной точкой, поскольку меньший набор компонентов по умолчанию может упростить понимание пайплайна.
Contrib: полная библиотека компонентов
Contrib (выпускаемый как otelcol-contrib) — это то место, где живет экосистема OpenTelemetry. Он включает сотни компонентов, созданных сообществом и вендорами, таких как Prometheus, Kafka, Jaeger, AWS, Azure, GCP, MongoDB, MySQL и многие другие. Если вам нужно принимать данные из определенной системы или экспортировать их в нее, в Contrib почти наверняка найдется соответствующий компонент.
Обратной стороной является стабильность. Каждый компонент имеет собственный уровень зрелости (development, alpha, beta или stable), и этот уровень может различаться в зависимости от типа сигнала (логи, метрики или трейсы). Получатель может быть стабильным для метрик, но находиться на стадии альфа-версии для логов. Некоторые возможности скрыты за флагами функций (feature flags), которые требуют явного включения.
Contrib полезен для изучения того, что возможно. Перед использованием Contrib в продакшене проверьте уровень зрелости и статус поддержки каждого входящего в состав компонента, удалите ненужные компоненты и протестируйте выбранную сборку в своем окружении.
Создание собственной сборки с помощью Collector Builder
Как только вы узнаете, какие компоненты Contrib вам действительно нужны, OpenTelemetry Collector Builder (OCB) позволит вам собрать собственный дистрибутив, содержащий ровно эти компоненты. Вы описываете сборку в файле manifest.yaml, запускаете OCB и на выходе получаете бинарный файл или образ контейнера, которым полностью управляете.
Пользовательская сборка может уменьшить количество включенных компонентов и зависимостей. В зависимости от реализации это может упростить инвентаризацию и аудит. Проверьте безопасность, производительность при запуске, требования комплаенса и поведение при обновлении в вашей среде.
OCB — это стандартный ответ, когда организация достаточно зрелая, чтобы знать свой список компонентов и хочет осуществлять жесткий операционный контроль над тем, что она поставляет.
После подготовки манифеста сам процесс сборки состоит из двух шагов. Установите OCB с помощью команды go install go.opentelemetry.io/collector/cmd/builder@v0.120.0, затем укажите путь к вашему манифесту: ocb --config otelcol-builder.yaml. OCB извлекает только те модули, которые вы объявили, компилирует их вместе и записывает единый готовый к запуску бинарный файл в указанный вами параметр output_path. Примеры носят иллюстративный характер; перед использованием сверяйте имена компонентов, степень их зрелости и версии с актуальной документацией OpenTelemetry. Исходный код и релизы OCB находятся на GitHub. Если вам нужно найти дополнительных получателей, процессоры или экспортеры для добавления в ваш манифест, полный реестр компонентов доступен на GitHub.
Дистрибутивы от вендоров: готовая упаковка и опции поддержки
Дистрибутивы от поставщиков представляют собой предварительно собранные сборки. В зависимости от поставщика и предложения они могут включать поддержку, подписанные артефакты, тестирование на совместимость или задокументированные инструкции по обновлению. Проверьте условия и практику конкретного дистрибутива, прежде чем полагаться на него.
Дистрибутивы от поставщиков могут стать наименее затратным путем, снижающим объем работ по упаковке и обслуживанию за счет предоставления тщательно отобранной сборки и модели поддержки. Оцените компоненты, включенные поставщиком, практику выпусков и условия поддержки на предмет соответствия вашим требованиям.
Прежде чем принимать окончательное решение, сверьте опубликованный манифест компонентов поставщика с реальными потребностями вашего конвейера. Дистрибутивы от поставщиков создаются на базе OCB и включают тщательно отобранный поднабор Contrib, но не весь целиком. Если ваш конвейер зависит от компонента, который не вошел в сборку поставщика, вы обнаружите этот пробел на этапе настройки, а не во время оценки. Получатель или экспортер Kafka — распространенный пример: он присутствует в Contrib, но не каждый дистрибутив от поставщика включает его. Изучите манифест, сопоставьте его со своими получателями и экспортерами и сообщите о любых пробелах поставщику, прежде чем создавать зависимость от его дистрибутива.
Как выбрать дистрибутив OpenTelemetry?
Практичный способ выбора — начать с широкого охвата на этапе оценки, а затем сузить круг задач по мере уточнения требований. Contrib поможет вам понять, какие получатели, процессоры и экспортеры вам необходимы. Как только список компонентов стабилизируется в непроизводственной среде, решите, какую часть ответственности за сборку, выпуск и поддержку ваша команда готова взять на себя.
Если у вашей организации есть инженерный потенциал для поддержки конвейера сборки и вы хотите осуществлять точный контроль над версией каждого компонента, OCB может стать следующим правильным шагом. Если вы предпочитаете тщательно отобранный дистрибутив с моделью поддержки от поставщика, оцените, подходят ли вам набор компонентов, практика выпусков и условия поддержки этого поставщика.
Несколько полезных привычек сослужат вам хорошую службу независимо от выбранного пути:
- Фиксируйте версии компонентов.
- Выполняйте поэтапное обновление так же, как и любые другие изменения в инфраструктуре.
- Следите за метками зрелости компонентов, от которых вы зависите.
- Не включайте компоненты, которые вы не используете, поскольку каждый компонент в вашем бинарном файле — это компонент, который вы неявно поддерживаете.
Что дальше?
Выбор дистрибутива решает первую проблему. В масштабе командам могут потребоваться процессы или дополнительные инструменты для скоординированных обновлений, распространения конфигураций, мониторинга состояния и видимости парка. Требования различаются в зависимости от модели развертывания и уже используемых возможностей управления.
Этому посвящена следующая статья в нашей серии: управление OTel Collectors в масштабе.
