Инженеры Google Cloud включили Google Cloud Observability и, в частности, Cloud Trace, для поддержки приема данных трассировки по протоколу OpenTelemetry (OTLP) для почти прямого и более независимого от поставщика приема данных трассировки.
Теперь, когда пользователи могут отправлять свои данные трассировки с помощью OTLP через API телеметрии (OTLP), Google Cloud рекомендует этот подход во многих случаях, в том числе для пользователей, которые ожидают больших объемов данных трассировки в сочетании с OpenTelemetry Collector. Принятие и интеграция протокола Google потребовала значительной инженерной работы, а метрики и журналы имеют отдельные пути поддержки и доступности OTLP, которые различаются в зависимости от продукта и региона.
В то же время подход Google аналогичен подходам Microsoft Azure и Amazon Web Services. Azure и AWS также поддерживают OTLP, не требуя сторонних инструментов или поставщиков, включая поддержку Azure Monitor OTel, AWS Distro для OpenTelemetry и прием X-Ray OTLP.
Ключевые преимущества встроенной интеграции OTLP
Согласно документации Google, поддержка OTLP для Google Cloud Observability, определяемая как протокол обмена данными, предназначенный для передачи телеметрии из источника в пункт назначения независимо от поставщика, снижает предварительные требования к разработчикам по интеграции экспортеров конкретного поставщика во многих случаях. Это помогает гарантировать, что основной конвейер телеметрии остается стандартизированным и легко взаимодействующим со всеми серверами наблюдения, поддерживающими OTLP, при соответствующей настройке.
По мнению Google, основные отношения определяются как устранение необходимого этапа преобразования и перенос сложности со стороны клиента (сборщика) на облачный бэкэнд.
На этой схеме показано, как конфигурации на основе процесса и сборщика могут использовать собственные средства экспорта протокола OpenTelemetry для передачи данных телеметрии. (Источник: Google Cloud)
В блоге Google Cloud, опубликованном в сентябре и написанном менеджерами по продуктам компании Суджаем Соломоном и Китом Ченом, отмечаются преимущества интеграции OTLP для отправки данных отслеживания. Эти преимущества включают в себя:
- Независимые от поставщика конвейеры телеметрии: Согласно сообщению Google, использование собственных экспортеров OTLP из внутрипроцессных или сборщиков устраняет необходимость использования экспортеров конкретного поставщика в ваших конвейерах телеметрии.
- Целостность данных телеметрии: Гарантии того, что данные телеметрии поддерживают модель данных OpenTelemetry во время передачи и хранения без преобразования в собственные форматы.
- Взаимодействие с выбранными вами инструментами наблюдения: Возможность отправлять телеметрию на один или несколько серверов наблюдения, которые поддерживают собственный OTLP, без дополнительных экспортеров OTel.
- Уменьшение сложности на стороне клиента и использования ресурсов: Возможность изменять логику обработки телеметрии, например применять фильтры к серверной части наблюдения, уменьшая необходимость в пользовательских правилах и, следовательно, накладные расходы на обработку на стороне клиента с помощью Google Cloud Observability.
Новая роль коллектора OTel в наблюдаемости облака Google
Страница исследования трассировки в Cloud Trace с выделенными полями, использующими семантику OpenTelemetry. (Источник: Google Cloud)
Недавнее добавление встроенного приема OTLP в Google Cloud Observability напрямую и критически связано с сборщиком OpenTelemetry, поскольку оно фундаментально меняет основную роль и конфигурацию сборщика для Google Cloud Observability. Очевидным преимуществом, описанным выше, является отсутствие этапа преобразования, поэтому сборщику требуется сравнительно минимальная настройка для получения данных трассировки из серверной части Google Cloud Observability.
OpenTelemetry Collector используется в качестве фильтра для мониторинга телеметрии. Он применим в тех случаях, когда задействовано несколько приложений или микросервисов, особенно из соображений безопасности. Таким образом, сборщик OpenTelemetry подпадает под категорию агента наблюдения. До этого объявления пользователи могли использовать агенты наблюдения, такие как Fluent Bit, Vector и другие, для приема данных отслеживания с помощью Google Cloud Observability.
Роль агентов наблюдения и сбор данных
Агенты наблюдаемости играют решающую роль в основных принципах наблюдаемости. Они управляют транспортировкой данных, чтобы обеспечить точную передачу данных телеметрии. Агенты обычно обеспечивают сбор, обработку и транспортировку данных, играя решающую роль в мониторинге производительности системы. Они помогают выявлять неизвестные неизвестные для устранения неполадок и устранения проблем с производительностью до того, как они станут проблемами. Это золотой стандарт функциональности наблюдаемости.
Таким образом, агент наблюдения при использовании для сбора данных собирает данные, отправленные ему из одного или нескольких источников. Помимо получения данных, он отправляет данные в конечную точку, например, для визуализации с помощью панели Grafana. Агент можно настроить для сбора определенных типов журналов, трассировок и показателей для обеспечения наблюдаемости.
Первоначально вы можете отказаться от использования агента наблюдения, если вы уже развертываете приложение, предназначенное для отправки данных телеметрии непосредственно на платформу наблюдения. Коллекторы могут быть полезны при мониторинге приложения, которое невозможно инструментировать.
Без функции сбора наблюдаемых данных требуется настройка каждого бэкэнда или мониторинга пользователей отдельно для них, что может оказаться обременительным. Напротив, сборщик наблюдаемости служит единой конечной точкой для всех микросервисов, упрощая доступ к приложениям и микросервисам через единую точку, поддерживаемую сборщиком. Используя агент наблюдения в качестве сборщика, вы можете просматривать микросервисы и управлять ими коллективно, предлагая консолидированное представление на такой платформе, как Grafana. Хотя Grafana предоставляет некоторые альтернативы без сборщика OpenTelemetry, сборщик значительно упрощает этот процесс.
Статус поддержки OTLP для журналов и метрик
Следует отметить, что анонс Google Cloud касается OpenTelemetry для отслеживания. Журналы и метрики, и особенно журналы, все еще находятся в стадии разработки из-за ряда потенциальных препятствий, включая внедрение контроля доступа на основе ролей (RBAC), проблемы соответствия требованиям и необходимые инженерные работы.
В настоящее время Azure и Google Cloud, входящие в тройку крупнейших поставщиков облачных услуг и гипермасштабировщиков, напрямую поддерживают прием метрик через OpenTelemetry по протоколу OTLP. AWS обычно использует сборщик AWS Distro for OpenTelemetry (ADOT). AWS и Google Cloud не имеют широко доступного прямого приема журналов OTLP, в то время как прием журналов Azure через OTLP остается в значительной степени ограниченным.
Стратегия Google по упрощению конвейера телеметрии
Опять же, это часть продолжающегося развития в гонке за интеграцию и улучшение приема данных наблюдения среди гиперскейлеров, как написали Соломон и Чен из Google в своем блоге компании.
Недавний шаг Google Cloud Observability, пишут они, «является краеугольным камнем нашей стратегии по упрощению управления телеметрией и развитию открытой облачной среды. Мы понимаем, что в современных сложных облачных средах управление данными телеметрии в разрозненных системах, несовместимых форматах данных и огромных объемах информации может привести к пробелам в наблюдаемости и увеличению операционных накладных расходов».
«Мы стремимся оптимизировать ваш конвейер телеметрии, начиная с сосредоточения внимания на встроенном приеме OTLP для всех типов телеметрии, чтобы вы могли беспрепятственно отправлять свои данные в Google Cloud Observability. Это поможет обеспечить истинную нейтральность и совместимость поставщиков, устраняя необходимость в сложных преобразованиях или агентах конкретного поставщика».
ТЕНДЕНЦИОННЫЕ ИСТОРИИ YOUTUBE.COM/THENEWSTACK Технологии развиваются быстро, не пропустите ни одной серии. Подпишитесь на наш канал YouTube, чтобы смотреть все наши подкасты, интервью, демонстрации и многое другое. ПОДПИСАТЬСЯ Группа, созданная в Sketch. BC Gain — основатель и главный аналитик ReveCom Media. Его одержимость компьютерами началась, когда в начале 1980-х он взломал консоль Space Invaders, чтобы играть весь день за 25 центов в местном игровом зале. Затем он… Подробнее от Б. Кэмерона Гейна.
