Расширенная поддержка Dynatrace для экспортеров метрик OpenTelemetry, поступающих от облачных рабочих нагрузок, упрощает их анализ. Решение также выявляет контекстные взаимосвязи между блоками, сервисами, узлами и кластерами Kubernetes.

После конференции Kubecon в Валенсии в начале 2022 года, многие организации приняли OpenTelemetry Protocol (OTLP) как универсальный протокол для сигналов наблюдаемости, включая метрики, трассировку и логи. Однако, его реализация проходит не без вызовов.

Почему компаниям трудно реализовать потенциал OpenTelemetry?
Многим организациям трудно внедрить фреймворк OpenTelemetry по ряду причин. Рассмотрим несколько примеров:
● Анализ сигналов OpenTelemetry часто происходит изолированно. Без контекста и взаимосвязей между данными и базовой топологией приходится тратить много времени, чтобы вручную присвоить данным метки или создать перекрестные ссылки между информационными панелями несовместимых инструментов. ● Улучшение мониторинговых данных часто требует изменений в коде. Инженеры, ответственные за надежность сайта, побуждают разработчиков добавить в исходный код больше атрибутов ресурсов, конечных точек и токенов. Таким образом, много сил тратится на координацию между командами. ● Трудно выбрать, где и как собирать данные. Kubernetes-командам нужны простые и последовательные, независимые от вендора, архитектуры для анализа сигналов наблюдаемости. Это приводит к появлению кастомных решений, которые приходится собирать как конструктор каждый раз, когда добавляется или удаляется определенный компонент.
Из этих примеров очевидны две проблемы. Во-первых, командам нужно простое решение для настройки стандартных экспортеров, агентов и коллекторов. Во-вторых, чтобы реализовать сбор сигналов OpenTelemetry, нужны гарантии, что внедрение фреймворка окупится — организация получит аналитическую информацию, которая поможет улучшить эффективность бизнеса.
Эти проблемы может решить Dynatrace. Платформа начала поддерживать OTLP с начала 2023 года, поскольку это упрощает сбор и анализ метрик телеметрии с рабочей нагрузки облака. Решение определяет контекстные взаимосвязи между блоками, сервисами, узлами и кластерами Kubernetes.
Далее рассмотрим, как поддержка протокола OTLP в Dynatrace упрощает процессы, обеспечивает понимание контекста и предоставляет доступ к инсайтам Davis® AI.
Поддержка протокола OTLP в Dynatrace
Большинство современных языков программирования, таких как C++, Go, Java, JavaScript и Python (смотрите полный список), поддерживают OpenTelemetry SDK. Поэтому, можно использовать оператор OpenTelemetry для автоматического измерения или добавлять метрики и ресурсы с помощью библиотек с открытым кодом для каждого языка.
Начиная с 1.254 версии Dynatrace, организации могут использовать стандартные OTLP-экспортеры, чтобы отправлять трассировку и метрики в свою среду Dynatrace. Сочетание этих сигналов с Dynatrace Operator позволяет автоматически определять контекст, например, информацию о блоке, пространстве имен, узле или кластере. Такие измерения автоматически добавляются к метрикам и трассировке OpenTelemetry, что расширяет возможности Davis AI для анализа и выявления первопричин проблем.
Снимок с экрана ниже показывает информационную панель Dynatrace, где по определенным метрикам OpenTelemetry измеряется выполнение заказов. Также на панели есть метрики SLO, которые поступают с рабочей нагрузки Kubernetes. То есть она показывает отклонение в — 1.31.3% от цели с одной стороны и контекст этого отклонения — с другой.
Используем этот пример, как отправную точку для разведывательного анализа с учетом контекста с помощью Dynatrace Davis.

Проведение разведывательного анализа с применением соответствующих сигналов в контексте

Dynatrace обеспечивает высокий уровень разведывательного анализа как для OneAgent, так и для других источников данных. На иллюстрации ниже показано, как метрики OpenTelemetry для счетчиков выполнения заказов отправляются из рабочей нагрузки Python в Kubernetes через конечные точки OTLP. 

Мы можем проанализировать отклонения от целевого SLO и улучшить результат с помощью инсайтов Davis по готовому обзору рабочей нагрузки Kubernetes. Обзор содержит анализ ресурсов, список сервисов, блоки, ивенты и логи. Дополнительно, в конце страницы с обзором, метрики выполнения заказов автоматически связываются с рабочей нагрузкой с помощью топологической модели Dynatrace Smartscape®. 
Davis может коррелировать все сигналы на странице рабочей нагрузки Kubernetes вместе с метриками OpenTelemetry. Следующий снимок экрана показывает, что Davis сопоставил значительное замедление CPU с уменьшением выполнения заказов, которое привело к отклонению от цели SLO. 

Страница с обзором также предоставляет дальнейший анализ логов и событий. Dynatrace обнаружил, что произошло изменение в спецификации развертывания в то же время как CPU резко замедлился, а показатель выполнения заказов уменьшился.

Еще один кусочек пазла — инструмент для просмотра логов. Он показывает сообщения о сбоях в проведении платежей, которое получает из рабочей нагрузки Kubernetes, вместе со ссылками на распределенные трассировки. Их можно рассмотреть подробнее, нажав View trace. 

Dynatrace автоматически объединяет трассировку и логи. Сбой в проведении оплаты был зафиксирован в 04:22:26 утра. Трассировка начинается с рабочей нагрузки фронтенда. Она показывает ошибку HTTP 500, задержки во времени и 750-кратное увеличение времени ответа по сравнению с нормальным промежутком. Показатели текущего и нормального времени ответа показаны рядом, для сравнения: 

Таким образом, разведывательный анализ начался с отклонения от цели SLO. Davis установил связь между замедлением рабочей нагрузки Kubernetes CPU и выполнением заказов. А вызвано это было событием развертывания. Dynatrace определил, что проблема в конкретном методе, который функционировал нормально до события.

Завершить анализ удалось быстро и без осложнений. Это благодаря уникальной способности Dynatrace предоставлять сигналы наблюдаемости в контексте и соотносить их с открытыми источниками данных, такими как метрики и трассировки OpenTelemetry.