Телеметрія у розподілених системах — які можливості вона надає? Розбираємо демо з OpenTelemetry

Неможливо достеменно знати, що відбувається всередині віддаленої чи розподіленої системи, навіть якщо вони запущені на локальному ПК. Саме телеметрія надає всю інформацію про перебіг внутрішніх процесів. Ці дані можуть бути у вигляді логів, метрик або Distributed Trace.

У блозі розповім окремо про кожен із цих форматів, а також розглянемо, чим корисний протокол OpenTelemetry та як ви можете гнучко налаштувати телеметрію.

Телеметрія — для чого потрібна?

• Показує поточний та попередній стан системи. Це може знадобитися у багатьох ситуаціях. Наприклад, так можна дізнатися, що вночі навантаження системи сягало 70%, а тому, можливо, треба додати новий інстанс. Також в метриках можна побачити, коли виникали помилки, та які саме трейси та екшени всередині трейсів падали.

• Демонструє, як юзери користуються системою. Завдяки телеметрії можна побачити, які User Actrions популярні, які кнопки найчастіше натискають користувачі тощо. Ця інформація допоможе розробникам, наприклад, додавати кеш до екшенів. А бізнесу ці дані важливі для розуміння реального використання системи людьми.
• Підсвічує, де і як зменшити витрати на роботу системи. Припустимо, за телеметрією видно, як із чотирьох інстансів реально працює лише один — і той на 20%. В такому випадку можна відмовитися від двох зайвих (базовий мінімум — два інстанси). Це дозволяє відповідно до обставин варіювати потужність системи та витрати на її підтримку.
• Оптимізує CI/CD-пайплайни. Ці процеси також можна логувати та аналізувати. Наприклад, якщо один зі степів білду або деплою займає багато часу, то з телеметрією можна побачити, що саме займає так багато часу та коли ці проблеми почалися. Потім ви зможете розробити певні кроки для усунення проблем.
• Інше. Нестандартних кейсів може бути неймовірно багато. Ви збираєте дані, а як їх обробляти й де використовувати — то вже інша справа. Все залежить від особливостей системи та проєкту. Десь треба логувати все-все, а десь вистачить трейсів на центральних сервісах.

Велика IT-система та навіть деякі види бізнесу не зможуть існувати без телеметрії. Тому цей процес треба підтримувати та впроваджувати в проєкти, якщо його немає.

Типи даних у телеметрії

Логи

Найпростіший тип даних у телеметрії. Логи бувають двох типів:

• Автоматичні — генеруються за допомогою фреймворку чи сервісу (App Service в Azure). За допомогою цих даних можна логувати, наприклад, який реквест прийшов та вийшов, що було всередині реквесту. З автоматичними логами не потрібно нічого робити для збору даних, що зручно для рутинних задач.
• Мануальні — треба запускати власноруч. Не так просто, як з автоматичними, але виправдано у логуванні важливих частин системи. Це зазвичай навантажені або націлені на бізнес-задачі процеси. Скажімо, в education-системі буде значною проблемою загубити тести студентів за певний період.

Зазвичай логувати всі дані непотрібно. Оцініть систему, знайдіть (якщо досі цього не зробили) найбільш вразливі та цінні частини системи. Скоріш за все, там треба додати логів. Іноді вам треба буде використовувати логорієнтоване програмування. У моїй практиці був проєкт десктопного застосунку на WPW, який погано працював із потоками. Єдиний шанс побачити, що відбувалося — логувати кожен крок.

Метрики

Більш складні дані у порівнянні з логами. Можуть бути цінними і для команди розробки, і для бізнесу. Метрики також виділяють автоматичні та мануальні:

• Автоматичні — метрики, які надає система. Наприклад, у Windows можна побачити показники навантаження на CPU, кількості реквестів тощо. Такий же принцип на вкладці Monitoring при розгортанні віртуальної машини на AWS чи Azure. Там можна знайти кількість даних, які надходять до системи або виходять із неї.
• Мануальні — можете додавати їх самі. Наприклад, коли треба бачити актуальну кількість підписок на сервіс. Це можна реалізувати через логи, але їх потрібно порахувати. З метриками все виглядає наочно і зрозуміло безпосередньо для клієнта.

Distributed Trace

Ці дані необхідні для роботи з розподіленими системами, що знаходяться не на одному інстансі. Тобто ми не знаємо, котрий інстанс та якого сервісу обробляє той чи інший реквест у певний проміжок часу. Все залежить від побудови системи. Тут можливі такі варіанти:

На першій схемі ліворуч клієнт надсилає реквест до BFF, а той — окремо до трьох сервісів. У центрі показана ситуація, коли реквест надходить до першого сервісу, який відправляє його до другого, а той вже до третього. Схема праворуч зображує, як сервіс надсилає реквести до Message Broker. Далі він розподіляє їх між другим і третім сервісами.

Думаю, ви стикалися з подібними системами, і прикладів можна навести безліч. Ці схеми дуже відрізняються від монолітів. У системах з одним інстансом нам відомий стек викликів від контролера до бази даних. Тому можна відносно легко знайти, де і що відбулося протягом певного API call. Скоріш за все цю інформацію надає фреймворк.

Та у розподілених системах неможливо побачити весь флоу. Кожен сервіс має окрему систему логування. Під час надсилання реквесту на BFF ми бачимо, що сталося всередині, але не знаємо, що відбувалося в сервісах 1, 2 та 3. Саме для такої ситуації придумали Distributed Trace. Ось приклад роботи:

Розберемо детально. Тут User Action йде на API Gateway, потім — на сервіс А, далі — на сервіс В. У результаті створюється виклик до бази даних. При їх надсиланні до системи на виході отримаємо подібну до наведеної схему.

Тут добре видно тривалість кожного процесу: від User Action до Database. Наприклад, бачимо, що виклики йшли один за одним. Час між викликом API Gateway та Service A прийшовся скоріше на сетап HTTP-з’єднання. Час між викликом Service B та Database знадобився на сетап до бази даних та обробку цих даних. Тож можна оцінити, де і скільки часу витрачено на кожну операцію. Це можливо завдяки механізму Correlation ID.

У чому суть? Зазвичай у монолітних застосунках при логуванні система прив’язує логи та екшени до process ID або thread ID. Тут механізм той самий, але ми його штучно додаємо до реквестів. Погляньмо на приклад:

При старті у Web Application екшену Order Service він бачить доданий Correlation ID. Так сервіс розуміє, що він є частиною ланцюжка, і передає «маркер» далі наступним сервісам. Вони зі свого боку розуміють себе як частину великого процесу. В результаті кожен елемент логуватиме дані так, щоб система бачила все, що відбувається протягом багатоетапного екшену.

Передача Correlation ID може відбуватися по-різному. Наприклад, у HTTP ці дані частіше за все передаються як один із параметрів хедерів. У сервісах Message Broker зазвичай записується всередині меседжу. Хоча, мабуть, у кожній платформі є SDK чи бібліотеки, що допоможуть реалізувати цей функціонал.

Як працює OpenTelemetry

Часто формат телеметрії старої системи не підтримується в новій. Це призводить до багатьох проблем під час переходу з однієї системи на іншу. Наприклад, так було з AppInsight і CloudWatch. Дані не групуються, а отже щось працює не так.

OpenTelemetry дозволить обійти такі проблеми. Це протокол передачі даних у вигляді об’єднаних бібліотек OpenCensus та OpenTracing. Першу створювали розробники Google для збору метрик і трейсів, другу — фахівці Uber лише для трейсів. В якийсь момент компанії зрозуміли, що працюють фактично над однією задачею. Тому вирішили об’єднати зусилля і створити універсальний формат відображення даних.

Завдяки протоколу OTLP логи, метрики та трейси надсилаються в єдиному форматі. Згідно з репозиторієм OpenTelemetry, сьогодні відомі IT-гіганти контриб’ютять цей проєкт. Він має попит у продуктах, які збирають та відображають дані (наприклад, Datadog та New Relic). Також він є помічним у системах, яким потрібна телеметрія (Facebook, Atlassian, Netflix та інші).

Основні компоненти протоколу OTLP

• Cross-language specification — набір інтерфейсів, які потрібно реалізувати для відправки логів, метрик і трейсів до системи відображення телеметрії.
• SDK — заімплементовані частини у вигляді автоматичних трейсів, метрик і логів. По суті це бібліотеки підключеного фреймворку. Завдяки їм можна побачити необхідну інформацію без написання жодного рядка коду.

Існує багато SDK для популярних мов програмування. Проте всі вони мають різні можливості. Зверність увагу на таблицю. Трейсінг має стабільні версії усюди, крім PHP та JS SDK. А от з метриками та логами досі не дуже добре у багатьох мовах. Десь є лише альфа-версії, десь експериментальні, подекуди взагалі не реалізовано імплементацію протоколу. З власного досвіду скажу, що на сервісах на .NET все працює нормально. Тут і просте підключення, і надійність логування.

• Collector — головна частина OpenTelemetry. Це софт, який передається з OpenTelemetry у вигляді exe-, pkg- або docker-файлу.

Колектор складається з чотирьох компонентів:

1. Receivers — це джерела даних колектору. Технічно логи, метрики та трейси відправляються у ресівери. Тобто вони діють як точка доступу. Ресівери можуть приймати OTLP з Jaeger або Prometheus.
2. Processors — їх можна запустити для кожного типу даних. Вони фільтруватимуть дані, додаватимуть атрибути та кастомізуватимуть процес під конкретні задачі системи чи проєкту.
3. Exporters — кінцева ціль для відправки телеметрії. Звідси вони потрапляють до OTLP, Jaeger чи Prometheus.
4. Extensions — ці інструменти розширюють колектор. Як приклад: health_check. З його допомогою можна надсилати реквест на ендпоінт і зрозуміти, чи працює колектор. Екстеншени показують багато чого: скільки ресіверсів та експортерів у системі, як вони працюють тощо.

На цій схемі маємо два типи даних — метрики та логи (позначені різними кольорами). Логи йдуть через свій процесор до Jaeger. Метрики прямують через інший процесор, мають свій фільтр і відправляються до двох джерел даних: OTLP і Prometheus. Це надає гнучкі можливості аналізу даних. Адже різний софт має різні способи демонстрації телеметрії.

Цікавий момент: дані можна приймати з OpenTelemetry і надсилати їх туди ж. Тобто в певних випадках однакові дані ви можете надсилати в один і той самий колектор.

Деплоймент OTLP

Існує багато способів, як побудувати систему збору телеметрії. Одна з найпростіших схем зображена на ілюстрації нижче. Тут є один .NET-сервіс, який надсилає OpenTelemetry відразу до New Relic:

За необхідності схему можна доповнити агентом. Він може виступати як хост-сервіс чи бекграунд-процес всередині сервісу, збирати дані та надсилати їх до New Relic:

Йдемо далі — додаємо у схему ще один застосунок (наприклад, на Node JS). Він надсилатиме дані напряму до колектора. А перший робитиме це через власного агента за допомогою OTLP. Колектор надсилатиме дані вже до двох систем. Наприклад, метрики йтимуть до New Relic, а логи — до Datadog:

Сюди ще можна додати Prometheus як джерело даних. Наприклад, коли в команді з’явилася людина, яка полюбляє цей інструмент і хоче використовувати його. Тут дані все одно збиратимуться в New Relic та Datadog:

Систему телеметрії можна ускладнювати нескінченно, адаптуючи її під свій проєкт. Ось ще один приклад:

Тут є декілька колекторів, кожен з яких збирає дані по-своєму. Агент у .NET-застосунку відправляє дані до New Relic і до колектора. При цьому один колектор може відправляти інформацію до іншого, тому що OTLP надсилається до іншого джерела даних. Воно може робити з ними що завгодно. В результаті перший колектор фільтрує потрібні дані та передає наступному. Останній — розподіляє логи, метрики та трейси між New Relic, Datadog та Azure Monitor. Завдяки цьому механізму аналізувати телеметрію можна так, як зручно саме вам.

Розбираємо можливості OpenTelemetry

Передусім — це гнучкість. Розглянемо дану властивість на практиці. Для цього тестування я зробив проєкт за наведеною схемою:

Все починається з Angular-застосунку, який відправляє HTTP-реквести до Python-застосунку. Той зі свого боку надсилає реквести до застосунків на .NET та Node JS. Вони працюють за своїми сценаріями. Застосунок на .NET відправляє до Azure Service Bus реквести та хендлить їх у Report Service.

Потім надсилає метрики про те, скільки реквестів він обробив. Додатково .NET відправляє реквести до MS SQL. Реквести Node JS йдуть до Azure Blob Queue та Google. Тобто система емулює якусь роботу. В усіх застосунках використовуються автоматичні системи відправки трейсів до колектору.

Почнемо з розбору docker-compose файлу.

Тут зібрано сетап декількох сервісів BFF. Серед закоменчених — Jaeger, який допомагає дивитися трейси.

Передбачено ще один софт для перегляду трейсів — це Zipkin.

Також є MS SQL та власне колектор. В останньому вказано config-файл і багато портів, на які можна щось відправляти.

Сonfig-файл містить набір головних топіків: recievers, exporters, processors, extensions. Завершує все service. Він виступає як конструктор усього цього.

Ресівер один. Це otlp, тобто саме Open Telemetry Protocol. Хоча можна підключати й інші ресівери (наприклад, Prometheus). Ресівер можна конфігурувати. Припустимо, сетапити allowed_origins, як у моєму прикладі.

Наступний елемент — експортери. З ними можна відправляти метрики до Prometheus.

Далі йдуть екстеншенси. В цьому випадку це health_check. Він є ендпойнтом, який перевірятиме активність колектору.

Насамкінець маємо сервіс з pipelines, traces, metrics. З ними зрозуміло, який тип даних звідки береться, чим він обробляється, куди надсилається. В цьому прикладі трейси з ресіверу відправляються для логування на два бекенди, а для метрик використовується Prometheus.

Розберемо, як це працює в реальності. Фронтенд надсилає реквести до бекенду, а бекенд використовує BFF для відправки реквестів. Створюємо кол і бачимо результати. Серед них, наприклад, є деякі реквести зі статусом 500.

Щоб розібратися, що пішло не так, дивимося трейси через Zipkin.

Детальний опис проблемного реквесту показує: фронтенд викликав BFF, а той відправив два реквести. Вони синхронні, тобто відправляються один за одним. За трейсами можна дізнатися, куди спрямований цей реквест, на який URL, який HTTP-метод використовувався. І все це згенеровано на основі автоматичних даних. Також можна додавати мануальні трейси — вони зроблять інфографіку більш інформативною.

Крім того, тут бачимо, що BFF викликав BILLINGSERVICE. У ньому працюють middleware, надсилається реквест до Azure та є http.post, який відправлявся до Azure. В результаті отримано статус CREATED. Далі система сетапила і відправляла реквест до Google.

Також є POSTALSERVICE, в якому впав один реквест. Подивимося на нього уважніше і побачимо опис помилки: ServiceBusSender has already been closed… Тому наступного разу треба бути обережним з ServiceBusSender. Також тут можна побачити відправку декількох запитів на MS SQL.

Врешті ми отримали доволі змістовну інфографіку про всі процеси в системі. Однак хочу вас застерегти: не завжди все так прозоро. У нашому випадку два трейси, як то кажуть, out of context. З ними нічого не зрозуміло: де вони виконуються, що з ними відбувається, деталей мінімум… Таке іноді трапляється, і до цього треба бути готовими. Як варіант, додавати мануальні трейси:

Погляньмо, як у Prometheus відправляються метрики. На ілюстрації видно, що надсилання додаткових реквестів пройшло успішно. Був один, а стало п’ять. Тобто метрики працюють справно:

У схемі .NET-застосунок відправляє реквести до Azure Service Bus, далі їх обробляє Report Service. Проте в Zipkin не було Report Service. Але ж метрики показують, що він працює! Тому пам’ятайте: досі не все й не усюди в OTLP працює так, як треба. Я знаю бібліотеки, які до меседжброкерів додають трейси за замовчуванням, і їх можна побачити у стеку. Хоча це досі вважається експериментальним функціоналом.

А ще згадаймо про health_check. Він покаже, чи взагалі працює наш колектор.

Тепер відправимо дані ще я до Jaeger (додамо новий ресурс трейсів). Після його старту треба заново надіслати реквести, адже він не отримує попередні дані. Отримаємо такий лист сервісів:

Маємо приблизно такі ж трейси, як у Zipkin (зокрема, зі статусом 500):

Мені подобається вкладка System Architecture, де знаходиться граф системи. Він показує, що все починається з реквесту до BFF, який перенаправляється до BillingService та PostalService. Це приклад того, як різні інструменти відображають дані у власний унікальний спосіб.

Останнє, що розберемо в цій статті — це order. У ньому можна знайти реквест та згенерований traceid. Якщо вкажете його в системі, то дізнаєтесь, що сталося в реквесті, та зможете детально дослідити HTTP call. Таким чином фронтенд дізнається, що він є першим, хто отримав User Action. У цей же спосіб фронтенд розуміє, що треба створити трейс, який передаватиметься по ланцюжку і надсилатиме дані колектору. А колектор збиратиме їх і передаватиме до Jaeger, Zipkin та Prometheus.

Тож переваги використання OpenTelemetry Protocol очевидні. Це гнучка система для збору, обробки та відправки телеметрії. Особливо зручно у поєднанні з Docker, який я використовував при створенні цього демо.

Проте завжди пам’ятайте про обмеження OTLP. У випадку з трейсами все досить добре. А от доцільність використання цього протоколу для метрик і логів залежить від готовності бібліотек та SDK конкретної системи.