Многие пользователи Grafana Cloud любят Alloy за его возможности, но мы также видим растущую базу пользователей, которые так же относятся к OpenTelemetry Collector. Мы хотим упростить для клиентов принятие наиболее подходящего решения независимо от их предпочтений.
Когда мы представили движок OpenTelemetry для Grafana Alloy, нашей целью было дать командам возможность запускать нативные конвейеры OTLP без потери мощи и гибкости, присущих Alloy. С тех пор мы продолжали разработку: отлаживали поддержку установки службы, добавляли управление парком устройств (Fleet Management) и учитывали отзывы первых пользователей. Сегодня, начиная с версии Alloy v1.21.0, мы рады сообщить, что движок OTel перешел в статус публичной предварительной версии (Public Preview) и работает прямо рядом с уже знакомым вам стандартным движком.
В этой статье мы подробно рассмотрим, в каких случаях стоит выбирать каждый из движков, разберем некоторые из самых интересных сценариев использования, с которыми мы столкнулись, и приоткроем завесу тайны над тем, куда оба движка будут развиваться дальше.
Мотивация создания каждого из движков
Прежде чем погружаться в конкретные новые функции, давайте напомним, почему в Alloy два движка.
Стандартный движок
Стандартный движок по своей сути является межэкосистемным; он не привязан к какому-то одному формату передачи данных или вендору. Он с одинаковым успехом может выполнять конвейер Prometheus, конвейер OTLP или конвейер Loki, причем все они определяются с помощью собственного синтаксиса конфигурации Alloy. Именно эта гибкость делает его швейцарским ножом: тот же движок, который собирает метрики Prometheus, может принимать логи через syslog, обрабатывать OTLP, собирать метрики Prometheus из встроенных экспортеров и направлять все это туда, куда необходимо.
Движок OpenTelemetry
Есть много преимуществ в том, чтобы уметь говорить на языке любой экосистемы. Однако сам ландшафт телеметрии движется в противоположном направлении. Вместо перевода из одного формата в другой индустрия все больше сходится на единой общей модели, определяемой спецификацией OpenTelemetry. Именно это собой и представляет OpenTelemetry Collector: конвейер, который рассматривает OTLP как нативный формат от начала и до конца, отдавая приоритет переносимости и открытым стандартам, а не переводу между экосистемами. По своей сути движок OTel в Alloy — это собственная дистрибуция OpenTelemetry Collector от Grafana Labs.
Запуск движка OTel
Это просто коллектор
Движок OTel представляет собой дистрибутив OpenTelemetry Collector, поставляемый внутри Alloy. Он запускает стандартный YAML-файл коллектора без трансляции и без синтаксиса Alloy. Если у вас уже есть конфигурация коллектора, у вас уже есть конфигурация движка OTel.
Остальная часть интерфейса командной строки (CLI) также совпадает. validate, components, print-config и --set работают так же, как и в оригинальной версии, поэтому скрипты и CI, вызывающие otelcol validate, продолжают работать.
То же самое относится и к инструментам, с помощью которых вы развертываете коллекторы. В оригинальном Helm-чарте это всего два значения:
Оператор OpenTelemetry раньше выдавал ошибку на образе Alloy, поскольку в нем не было способа задать команду контейнера. Мы добавили spec.command в исходный репозиторий (Operator v0.153.0 и новее), так что теперь это всего одна строка:
Для установки без использования контейнеров пакеты Alloy могут запускать любой из движков в качестве службы. Установите ALLOY_OTEL_MODE=1, и служба запустит движок OTel с файлом config.yaml. Прочитайте нашу документацию для получения дополнительной информации о настройке для различных платформ.
Управление парком устройств (Fleet Management)
Управление конфигурацией коллекторов вручную не масштабируется после того, как у вас появляется больше нескольких хостов, поэтому удаленная конфигурация была одним из первых пробелов, которые мы закрыли после первоначального релиза. Начиная с версии Alloy v1.19.0, вы можете централизованно управлять конфигурацией движка OTel с помощью Fleet Management. Сущность OpAMP supervisor встроена в бинарный файл Alloy и запускается через новую экспериментальную подкоманду otel-supervisor: укажите ей конечную точку Fleet Management и учетные данные с помощью файла конфигурации супервизора, и Alloy обработает соединение, загрузит конфигурацию конвейера и применит изменения по мере их публикации. Для начала работы обратитесь к справочнику по alloy otel-supervisor в Alloy.
Запасной выход: расширение alloyengine
Иногда нужный вам компонент сегодня существует только в стандартном движке. Расширение alloyengine запускает конфигурацию Alloy внутри того же процесса коллектора, так что вы можете использовать этот единственный элемент без запуска второго агента.
Оно является экспериментальным, и мы ожидаем, что таким и останется. Два движка работают бок о бок, но не могут напрямую передавать данные друг другу, поэтому все, что пересекает эту границу, отправляется по сети, обычно через OTLP.
Если вы используете его, расскажите нам почему. Откройте issue в репозитории Alloy, указав компонент, который вам понадобился. Именно по этому списку мы решаем, какие части стандартного движка станут нативными компонентами OpenTelemetry collector в будущем.
Эксперименты с продуктами Grafana Cloud
Предупреждение: ничто в этом разделе не поддерживается, и вам не следует запускать это в продакшене. Часть того, над чем мы работаем с движком OTel, — это то, как продукты Grafana Cloud ведут себя, когда конвейер сквозной на базе OTel. Вот в каком состоянии находятся два из них.
Предупреждение: ничто в этом разделе не поддерживается, и вам не следует запускать это в продакшене. Часть того, над чем мы работаем с движком OTel, — это то, как продукты Grafana Cloud ведут себя, когда конвейер сквозной на базе OTel. Вот в каком состоянии находятся два из них.
Наблюдаемость баз данных (Database Observability). Сегодня рабочий путь заключается в добавлении вашей существующей конфигурации Alloy к уже запущенному коллектору. Ваши конвейеры OTLP продолжают выполнять свою работу, а расширение запускает наблюдаемость баз данных рядом с ними. Приложение Database Observability не видит разницы:
Нативный путь для коллектора находится в разработке, но он еще впереди, поскольку мы решаем, как выделить компоненты Alloy в нативные компоненты OpenTelemetry.
Наблюдаемость облачных провайдеров (Cloud Provider Observability). Экспортеры облачных провайдеров в Alloy, такие как prometheus.exporter.gcp, работают через расширение точно так же. Данные будут идентичны при запуске в расширении alloyengine и в стандартном движке Alloy. Более интересный результат — это то, что происходит вообще без нативных экспортеров Prometheus от Alloy.
Мы работаем с сообществом Prometheus над тем, чтобы сделать экспортеры встраиваемыми в виде библиотек, чтобы они работали как реальные получатели (receivers) коллектора, а не как что-то, что коллектор опрашивает. В коллекторе, созданном с учетом этого, экспортер GCP становится просто еще одним получателем:
Глядя за пределы Cloud Provider Observability, OpenTelemetry Collector Prometheus Distro представляет собой официальный экспериментальный дистрибутив коллектора, который поставляет встраиваемые экспортеры Prometheus в качестве получателей OpenTelemetry, включая blackbox, Postgres, Google Cloud Monitoring с экспортером stackdriver и CloudWatch через экспортер yet-another-cloudwatch. Получатели доступны в prometheus-opentelemetry-collector, если вы предпочитаете собрать собственный с помощью Open Telemetry Collector Builder (OCB). По мере их продвижения по модели стабильности OpenTelemetry мы рассмотрим возможность их добавления в движок OTel.
Взгляд в будущее
Движок OTel
Что же ждет движок OTel теперь, когда он находится в публичной предварительной версии? Обеспечение возможности полноценной отладки вашего коллектора стоит на первом месте в списке. Пакеты поддержки (Support bundles) являются ключевой функцией для этого в стандартном движке — один запрос к /-/support упаковывает вашу конфигурацию, логи, внутренние метрики, флаги среды выполнения и профили pprof в один файл, который можно изучить перед отправкой. В движке OTel на сегодняшний день нет эквивалента, поэтому мы создаем нативное для OTel расширение, аналогичное ему. Следите за новостями на этом фронте!
Мы также хотим узнать, что заставляет вас возвращаться к стандартному движку через расширение движка Alloy. Расширение служит запасным вариантом, но мы планируем выделить эти части в нативные компоненты коллектора, как мы это сделали с экспортерами Prometheus. Если вы использовали это расширение или воздержались от перехода на движок OTel, потому что чего-то не хватало, расскажите нам, чего именно.
Стандартный движок
Стандартный движок не стоит на месте. Большая часть предстоящей работы сводится к одному: гарантировать, что ваши данные всегда доходят до места назначения, даже если в нижестоящей системе что-то идет не так.
Prometheus: улучшенный Remote Write
Сегодня prometheus.remote_write — это то, что защищает ваши метрики от исчезновения при сбое бэкенда, и для его улучшения ведется большая работа:
- Меньший объем занимаемой памяти. Сохранение данных в памяти и на диске минимальными для помощи в высоконагруженных средах и минимизации задержек при перезапуске.
Меньший объем занимаемой памяти. Сохранение данных в памяти и на диске минимальными для помощи в высоконагруженных средах и минимизации задержек при перезапуске.
- Продолжение с того места, где вы остановились. Данные, которые находились в процессе передачи при перезапуске Alloy, все равно должны быть отправлены.
Продолжение с того места, где вы остановились. Данные, которые находились в процессе передачи при перезапусках Alloy, все равно должны быть отправлены.
- Remote Write 2.0. Когда мы перевели на него собственные внутренние рабочие нагрузки Prometheus, расходы на исходящий трафик для этой телеметрии сократились более чем вдвое. Вы можете опробовать его в prometheus.remote_write уже сегодня в качестве экспериментальной функции, и мы помогаем продвигать его к стабильной версии в вышестоящем репозитории.
Remote Write 2.0. Когда мы перевели на него собственные внутренние рабочие нагрузки Prometheus, расходы на исходящий трафик для этой телеметрии сократились на
. Вы можете опробовать его в prometheus.remote_write уже сегодня в качестве экспериментальной функции, и мы помогаем продвигать его к стабильной версии в вышестоящем репозитории.
Поскольку prometheus.remote_write опирается на вышестоящий Prometheus, большая часть этой работы выполняется на верхнем уровне, что приносит пользу всей экосистеме Prometheus, а не только Alloy.
Loki: конвейеры, которые знают о сбоях
Конвейеры логов в Alloy по-прежнему используют архитектуру, унаследованную от Promtail, где компоненты передают логи без возможности сообщить, была ли доставка успешной. Именно с этим связаны большинство шероховатостей, с которыми вы могли столкнуться: потеря логов при выключении Alloy, медленный этап, тормозящий все остальные процессы, и позиции файлов, которые смещаются до того, как строка фактически отправлена. Мы перестраиваем конвейер так, чтобы информация об успехе и сбоях возвращалась к источнику:
- Никаких незамеченных пропусков. Позиция файла смещается только после доставки его строк, а Alloy очищает логи в полете при выключении, вместо того чтобы сбрасывать их.
Никаких незамеченных пропусков. Позиция файла смещается только после доставки его строк, а Alloy очищает логи в полете при выключении, вместо того чтобы сбрасывать их.
- Масштабируемая пропускная способность. Медленный этап перестает блокировать весь конвейер, поэтому выделение Alloy дополнительных ресурсов ЦП действительно увеличивает пропускную способность.
Масштабируемая пропускная способность. Медленный этап перестает блокировать весь конвейер, поэтому выделение Alloy дополнительных ресурсов ЦП действительно увеличивает пропускную способность.
- Надежный журнал WAL. Мы работаем над устранением известных проблем, чтобы перевести WAL loki.write в статус общей доступности (GA), обеспечивая сохранность логов на диске при сбоях или перезапусках.
Надежный журнал WAL. Мы работаем над устранением известных проблем, чтобы перевести WAL loki.write в статус общей доступности (GA), обеспечивая сохранность логов на диске при сбоях или перезапусках.
Оба движка формируются на основе отзывов пользователей, поэтому расскажите нам, на чем нам сосредоточиться в следующий раз. Создайте задачу в репозитории Alloy или найдите нас в #alloy в сообществе Grafana Slack.
