Розподілений трейсинг, ЧаПи

Istio інтегрується з системами розподіленого трейсингу, використовуючи Envoy-based трейсинг. Завдяки інтеграції трейсингу на основі Envoy, застосунки відповідають за перенаправлення заголовків трейсів для наступних вихідних запитів.

Додаткову інформацію можна знайти в огляді Розподіленого трейсингу та у документації Envoy щодо трейсів.

Istio дозволяє звітувати про трейс-відрізки (span) для комунікацій між робочими навантаженнями всередині мережі. Проте, щоб різні трейс-відрізки (span) могли бути зшиті разом для повного огляду потоку трафіку, застосунки повинні пропагувати контекст трейсингу між вхідними та вихідними запитами.

Зокрема, Istio покладається на застосунки для пересилання ідентифікатора запиту, згенерованого Envoy, і стандартних заголовків. Ці заголовки включають

• x-request-id

• traceparent

• tracestate

  Користувачі Zipkin повинні переконатися, що вони [поширюють заголовки трейсів B3] (https://github.com/openzipkin/b3-propagation).

• x-b3-traceid

• x-b3-spanid

• x-b3-parentspanid

• x-b3-sampled

• x-b3-flags

• b3

Розповсюдження заголовків можна виконати за допомогою клієнтських бібліотек, таких як OpenTelemetry. Це також можна зробити вручну, як задокументовано у Задачі розподіленого трасування.

Для інтеграцій трейсингу на основі Envoy, Envoy (sidecar проксі) надсилає інформацію про трейсинг безпосередньо до бекендів трейсингу від імені застосунків, що проходять через проксі.

Envoy:

• генерує ID запитів та заголовки трейсингу (наприклад, X-B3-TraceId) для запитів, коли вони проходять через проксі
• генерує трейс-відрізки (span) для кожного запиту на основі метаданих запиту та відповіді (наприклад, час відповіді)
• надсилає згенеровані трейс-відрізки (span) до бекендів трейсингу
• передає заголовки трейсингу до застосунку, який проходить через проксі

Istio підтримує OpenTelemetry та сумісні бекенди включаючи Jaeger. Серед інших платформ також підтримуються Zipkin та Apache SkyWalking.

Шлюз Istio або додатковий проксі-сервер (Envoy) генерує початкові заголовки, якщо вони не вказані в запиті.

Хоча sidecar Istio обробляє як вхідні, так і вихідні запити для асоційованого екземпляра застосунку, він не має явного способу корелювати вихідні запити з вхідним запитом, який їх спричинив. Єдиний спосіб досягти такої кореляції — це якщо застосунок передає відповідну інформацію (наприклад, заголовки) з вхідного запиту до вихідних запитів. Передача заголовків може бути здійснена через клієнтські бібліотеки або вручну. Подальше обговорення представлено в Що потрібно для розподіленого трейсингу з Istio?.

Швидкість вибірки для трейсингу встановлена в 1% в конфігураційному профілі default. Це означає, що лише 1 зі 100 трейсів, захоплених Istio, буде надіслано до бекенда для трейсингу. Швидкість вибірки в профілі demo все ще встановлена на 100%. Дивіться цей розділ секцію для отримання додаткової інформації про те, як налаштувати швидкість вибірки.

Якщо ви все ще не бачите дані трейсингу, будь ласка, переконайтесь, що ваші порти відповідають конвенціям іменування портів в Istio і що відповідний порт контейнера відкритий (наприклад, через специфікацію podʼа), щоб дозволити захоплення трафіку sidecar проксі (Envoy).

Якщо ви бачите дані трейсингу тільки для egress-проксі, але не для ingress-проксі, це також може бути повʼязано з конвенціями іменування портів.

Istio через Envoy зараз підтримує стратегію вибірки на основі відсотків для генерації трейсів. Будь ласка, ознайомтеся з цією секцією для отримання інформації про те, як налаштувати цей рівень вибірки.

Зараз Istio не підтримує протоколи pub/sub та event bus. Будь-яке використання цих технологій є використанням навмання і може призвести до збоїв в будь-який момент.