Хроносфера спонсировала этот пост.
Примечание редактора: Следующая статья представляет собой отрывок из главы 1 книги Мэннинга: «Fluent Bit with Kubernetes», руководства по настройке ведения журналов, метрик и конвейеров трассировки Kubernetes. В этом отрывке основное внимание уделяется взаимосвязи Fluent Bit с OpenTelemetry и его эволюции в сборе не только журналов, но и локальных показателей, таких как использование ЦП, памяти и хранилища. Чтобы более подробно изучить, как Fluent Bit и OTel выполняют различные функции, загрузите полную версию книги.
Как появилась на свет OpenTelemetry
До появления OpenTelemetry (OTel) основные спецификации, определяющие наблюдаемость метрик, трассировок и журналов, были созданы в результате нескольких усилий по стандартизации в рамках Cloud Native Computing Foundation (CNCF) в форме OpenTracing, OpenCensus и — неявно, учитывая его доминирование — Fluentd, а также, по ассоциации, Fluent Bit для структуры журналирования.
Разные стандарты часто требуют разных инструментов для сбора таких данных. Fluent Bit всегда собирал некоторые данные метрик; Экосистема Интернета вещей (IoT) должна обеспечивать небольшой размер программного обеспечения, поэтому предпочтительнее использовать один сервис, собирающий как журналы, так и метрики. В результате для Fluent Bit имело смысл собирать не только журналы, но и локальные показатели, такие как использование ЦП, памяти и хранилища.
Объединение всех этих источников данных привело к упрощению оперативного мониторинга, что привело к быстрому внедрению и оказалось разрушительным. Поддержка Fluent Bit стандартов OTel и его способность работать в экосистеме OTel не потребовали каких-либо радикальных изменений, хотя они привели к некоторым обновлениям некоторых частей его реализации. В некотором смысле обновления формализовали то, что Fluent Bit уже делал. Благодаря такому согласованию Fluent Bit имеет все возможности для поддержки внедрения стандартов OTel, не навязывая их, что позволяет его внедрению быть более постепенным.
Уроки из более поздних глав книги Мэннинга
В будущих главах, когда мы начнем углубляться в возможности ввода и вывода Fluent Bit, мы более подробно рассмотрим отношения с OTel и ведущими продуктами в области наблюдаемости, такими как Prometheus, который помог продвинуть OTel вперед, и Grafana. Мы также рассмотрим коммерческих поставщиков, которые работали над поддержкой стандартов OTel, создавая быстро растущую экосистему подключаемых инструментов мониторинга.
Примечание: Если вам нужен краткий справочник по аббревиатурам и терминологии, вы можете найти удобный глоссарий здесь. Кроме того, в Приложении Б перечислено несколько отличных ресурсов. (Загрузите книгу, чтобы просмотреть Приложение Б.)
Как OTLP и OTel сочетаются друг с другом
Сердцем OTel является протокол OpenTelemetry (OTLP), который детализирует структуры данных, кодирование и передачу телеметрических данных.
В настоящее время OTLP поддерживает передачу с использованием удаленного вызова процедур (gRPC) с HTTP/2 с использованием буфера протокола (Protobuf) и JSON с синхронным HTTP. OTLP продвигает использование gRPC в качестве основного подхода к общению, а JSON — в качестве перехода на более низкий уровень или резервного варианта.
OTel как проект выходит далеко за рамки определения OTLP. Он также предоставляет реализации функций, описанных в стандарте (иногда называемых эталонной реализацией), а также инструменты и библиотеки.
Инструменты и библиотеки реализованы на нескольких языках; мы можем использовать их, чтобы внедрить логику в приложения и быстро заставить приложения данных создавать трассировки. OTel также имеет такие функции, как приложения журналов, которые позволяют платформам ведения журналов отправлять журналы с использованием спецификации OTLP.
Как Fluent Bit вписывается в решение OpenTelemetry
Чтобы понять, как Fluent Bit может вписаться в решение OTel, давайте посмотрим, что может сделать Fluent Bit, используя терминологию OTel:
- Благодаря своей способности собирать данные мониторинга и наблюдения из различных источников и преобразовывать их в структуру OTLP, Fluent Bit может выполнять роль сборщика OpenTelemetry.
- Поскольку Fluent Bit был создан для работы в распределенной среде и может передавать данные в формате OTLP любому другому коллектору, совместимому с OpenTelemetry (который может быть узлом Fluent Bit или другим продуктом), мы можем описать Fluent Bit как средство экспорта OTLP.
На рисунке 1 показано, как Fluent Bit может вписаться в среду OpenTelemetry благодаря своей способности обрабатывать журналы (L), метрики (M) и трассировки (T), созданные приложением с помощью библиотек или инструментов OTel или без них, а также возможность взаимодействия с сборщиком OpenTelemetry.
Коллекционер против экспортера: выбор правильной роли для Fluent Bit
Поскольку OTel предоставляет реализации возможностей сборщика и экспортера, вызов Fluent Bit сборщиком OpenTelemetry или экспортером OpenTelemetry может стать источником путаницы. Сам стандарт называется OTLP, поэтому называть Fluent Bit OTLP-совместимым более понятно, хотя и менее очевидно в отношении задачи, для выполнения которой мы можем использовать Fluent Bit.
Кроме того, в сообществе OpenTelemetry существует некоторая чувствительность к разнице между собственной реализацией сборщика проекта (называемой OpenTelemetry Collector) и другими реализациями этой возможности. Мы ошибаемся, описывая Fluent Bit как сборщик OTLP (в конце концов, соответствие протоколу является ключом к функции сборщика) и уменьшая двусмысленность среди проектов CNCF.
Рис. 1. Связь Fluent Bit с OpenTelemetry: приложения генерируют журналы, метрики и трассировки OTel, а Fluent Bit облегчает их передачу в точку агрегирования или обработки, совместимую с OTel. Приложения могут отправлять данные OTLP напрямую или через компонент OTel, а мы можем направлять данные в другие службы OTel или инструменты анализа.
Буферы протоколов (Protobuf)
Буферы протоколов — это ключевая технология gRPC, которую использует OTel. Буферы протокола имеют кратко определенную схему, которая используется с инструментом Protobuf для генерации кода для отправки и получения полезных данных. Четко определенная схема позволяет инструменту создавать код, создающий сжатое двоичное представление полезной нагрузки. Эта схема является одновременно сильной стороной и потенциальным ограничением.
Сила достигается за счет эффективной передачи полезной нагрузки. Обратной стороной является то, что изменение схемы влияет как на поставщика, так и на потребителя и усложняет реализацию шаблона интеграции толерантного читателя. Кроме того, учитывая, что полезная нагрузка, сгенерированная Protobuf, представляет собой сжатый двоичный формат, ее гораздо сложнее внедрить в любое коммуникационное промежуточное программное обеспечение, которое может выполнять преобразование. Ссылки на OTel, Protobuf и связанные с ними технологии находятся в Приложении B.
Заглядывая в будущее: изучайте Fluent Bit и OTel еще дальше
По мере изучения книги «Fluent Bit with Kubernetes», которую можно скачать целиком здесь, мы более подробно рассмотрим, как Fluent Bit и OpenTelemetry выполняют различные функции. Обратите внимание, что поддержка протокола OpenTelemetry до Fluent Bit v3 была ограничена HTTP и JSON. Версия 3 содержит улучшения, поддерживающие HTTP/2, позволяющие Fluent Bit использовать gRPC. Это, в свою очередь, означает, что Fluent Bit может обеспечить полностью совместимую реализацию OTLP без необходимости перехода на HTTP и JSON.
Хроносфера — это платформа наблюдения, созданная для контроля в современном контейнерном мире. Признанная крупными аналитическими фирмами лидером, ChronSphere дает клиентам возможность сосредоточиться на данных и знаниях, которые важны для снижения сложности данных, оптимизации затрат и более быстрого устранения проблем. Узнайте больше Последние новости ChronSphere ТЕНДЕНЦИОННЫЕ ИСТОРИИ YOUTUBE.COM/THENEWSTACK Технологии развиваются быстро, не пропустите ни одной серии. Подпишитесь на наш канал YouTube, чтобы смотреть все наши подкасты, интервью, демонстрации и многое другое. ПОДПИСАТЬСЯ Группа, созданная в Sketch. Написав для Chronography, Фил Уилкинс проработал более 30 лет в индустрии программного обеспечения, имея обширный опыт работы в бизнесе и средах: от транснациональных корпораций до стартапов по разработке программного обеспечения, от потребительских организаций до консалтинга. Он начинал как разработчик критически важных систем реального времени… Подробнее от Фила Уилкинса.
