OTel-Arrow против OpenTelemetry Collector против Fluent Bit (реальные показатели)

OpenTelemetry получила новый конвейер обработки данных, написанный на Rust. Я развернул otap-dataflow (df_engine) от OTel-Arrow на Kubernetes и сравнил его производительность с Collector и Fluent Bit. Apache Arrow переворачивает OTLP с ног на голову: вместо построчного protobuf, где каждая запись пересылает имена своих полей, OTAP выводит телеметрию в столбцы и передает её по одному долгоживущему gRPC-соединению. df_engine — это среда выполнения на Rust, построенная с нуля на основе этой концепции: потоки на ядро, отсутствие разделяемых ресурсов, нулевое копирование, обратное давление по умолчанию. В этом эпизоде: Что такое OTAP на самом деле и почему столбцы превосходят строки в передаче данных Инвентаризация плагинов и честные пробелы (нет filelog, нет сбора данных Prometheus, нет k8sattributes, нет выборки в хвосте) Разработка конвейера Полное развертывание в Kubernetes с использованием OpenTelemetry Astronomy Shop в Dynatrace Наблюдение за самим движком с помощью internal_telemetry + административная конечная точка на :8080 Бенчмарк: Fluent Bit против OTel Collector против OTel-Arrow (OTLP-in) против OTAP (Arrow-in) ЗАГОЛОВОК: СТОИМОСТЬ РАСПАКОВКИ OTAP не удаляет процессор для упаковки/распаковки, а перераспределяет его. Движок Arrow, получающий обычный OTLP, является самым «прожорливым» устройством (~163 mCores в среднем), потому что он тратит ресурсы на декодирование и кодирование. Если подать данные, уже обработанные Arrow, то на конечном узле загрузка процессора снизится до ~10 млн ядер, но на стороне, которая их обработала, будет передаваться ~181 ядро. Общая загрузка ЦП на пути Arrow немного выше, она перекладывается на отправителя. Преимущество OTAP заключается в скорости передачи данных: 8,6 байт/запись против 15,6 у OTLP+zstd, что примерно в 1,8 раза меньше по сравнению с правильно сжатым базовым уровнем. И это окупается: 247 → 59 → ~10 байт/запись по мере увеличения скорости потока, поскольку схема и словарь отправляются один раз. Кратковременные соединения этого не видят. Это выгодно на долговременных, высокообъемных соединениях. Вердикт: наблюдаемо ли это? Да, оно сообщает о себе, включая обратное давление. Готово ли оно стать вашим единственным сборщиком данных? Пока нет. Это инкубационная стадия, формат конфигурации нестабилен, и пробелы реальны. Сегодняшняя честная архитектура — это транспорт Arrow с долгоживущими высокообъемными узлами, а также сборщик Go на периферии для логов подов, сбора данных и метаданных Kubernetes. ⏱️ РАЗДЕЛЫ 00:00 – Введение 00:17 – Приветствие 02:54 – Что такое Otel-arrow и почему это новый движок? 08:44 – Плагины, которые вы действительно получаете, и реальные недостатки 11:28 – Разработка конвейера: это граф, а не список 14:45 – Развертывание в Kubernetes 16:47 – Наблюдение за самим движком 17:48 – Бенчмарк: настройка 22:39 – Заключение 🔗 ССЫЛКИ Репозиторий (конфигурации, руководство, бенчмарк): https://github.com/isItObservable/Ote... Upstream OTel-Arrow: https://github.com/open-telemetry/ote... Образ движка: ghcr.io/isitobservable/df_engine:0.50.0 Демонстрация OpenTelemetry: https://github.com/open-telemetry/ope... 👍 Если это было полезно, поставьте лайк и подпишитесь, чтобы не пропустить остальные серии. 👉 Подписывайтесь на канал, чтобы получать больше информации о мониторинге облачных приложений:    / @isitobservable   👉✅ Оставайтесь на связи! BlueSky: https://bsky.app/profile/isitobservab... LinkedIn:   / isitobservable   Twitter:   / isitobservable   #OpenTelemetry #Observability #Rust #ApacheArrow #Kubernetes #OTel #DevOps #SRE #FluentBit #OTelCollector