Розширена підтримка 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.