Модуль 1.4: Спостережуваність Istio

Складність: `[СЕРЕДНЯ]`

Час на проходження: 50-70 хвилин

Передумови

Перш ніж починати цей модуль, ви маєте завершити попередні модулі ICA, тому що спостережуваність стає корисною лише тоді, коли в сітці вже є трафік, політики та маршрутизація, які варто пояснювати.

Модуль 1: Встановлення та архітектура — istiod, sidecar-проксі Envoy, ін’єкція та керування площиною даних
Модуль 2: Керування трафіком — VirtualService, DestinationRule, Gateway, повторні спроби та розподіл трафіку
Модуль 3: Безпека та усунення несправностей — mTLS, AuthorizationPolicy, istioctl analyze та налагодження проксі
Базова операційна впевненість у роботі з Kubernetes: Деплойменти, Сервіси, простори імен, мітки та kubectl logs
Базове розуміння метрик, логів, трейсів та запитів до часових рядів у стилі Prometheus

Цей модуль передбачає Kubernetes 1.35+ та сучасне встановлення Istio з використанням Telemetry API. Старіші матеріали про Istio можуть згадувати Mixer (вилучений в епоху 1.5), глобальні прапорці трейсингу або складне налаштування EnvoyFilter для базової телеметрії. Сприймайте ці патерни як історичні, якщо тільки застарілий кластер не змушує вас їх підтримувати.

Результати навчання

Після завершення цього модуля ви зможете:

Спроєктувати конфігурацію спостережуваності Istio, яка обирає правильну область дії Telemetry для вимог рівня всієї сітки, рівня простору імен та рівня робочого навантаження.
Налагоджувати поведінку сервісів, поєднуючи стандартні метрики Istio, журнали доступу Envoy, дані графа Kiali та розподілені трейси, замість того щоб покладатися на один сигнал.
Оцінювати запити PromQL для частоти запитів, частоти помилок та затримки, щоб дашборди вимірювали саме ту поведінку, яка реально потрібна команді для роботи.
Налаштовувати трейсинг та журналювання доступу з практичними рішеннями щодо семплування, фільтрації та поширення заголовків, які дозволяють уникнути зашумленої або оманливої телеметрії.
Порівнювати Grafana, Kiali, Jaeger, статистику Envoy та необроблені логи, щоб обрати найшвидший інструмент для виробничого інциденту або сценарію ICA.

Чому цей модуль важливий

Команда платіжної платформи розгортає новий сервіс оформлення замовлень у п’ятницю по обіді. Розгортання виглядає справним, Поди готові, а Сервіс Kubernetes має ендпоінти. За десять хвилин служба підтримки повідомляє, що деякі замовлення завершуються, деякі завершуються за тайм-аутом, а деякі дають збій лише тоді, коли трафік проходить через канарковий маршрут.

Команді не потрібна ще одна команда, яка скаже, що Поди працюють. Їм потрібно знати, який шлях сервісу дає збій, чи ізольовані збої однією версією робочого навантаження, чи змінилися mTLS або політика маршрутизації, і чи є повільним переходом оформлення замовлення, склад, авторизація платежу чи зовнішній API боротьби з шахрайством.

Спостережуваність Istio корисна, тому що sidecar-проксі Envoy перебувають на шляху запиту. Вони бачать кількість запитів, коди відповідей, затримку, розміри в байтах, стан mTLS, рішення щодо маршрутизації та ідентифікатори трейсів навіть тоді, коли команди застосунків не ідеально інструментували кожен сервіс. Це не усуває потреби в телеметрії застосунку, але дає платформним інженерам спільну базову лінію для багатьох мов та команд.

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

Іспит ICA розглядає спостережуваність як окремий домен, тому що вона пов’язує між собою інші домени. Керування трафіком створює маршрути, які потрібно перевіряти. Політики безпеки створюють рішення про авторизацію, які потрібно пояснювати. Усунення несправностей починається із симптомів, але стає надійним лише тоді, коли ви можете перетворити ці симптоми на докази.

Досвідчений оператор не запитує першим: «Який дашборд мені відкрити?». Він запитує: «Який доказ підтвердить або спростує мою поточну теорію?». Якщо теорія полягає в тому, що маршрут спрямовує трафік до неправильної підмножини, Kiali та мітки призначення можуть швидко дати відповідь. Якщо теорія полягає в тому, що бекенд-перехід є повільним, гістограми затримки Prometheus та трейси кращі. Якщо теорія полягає в тому, що значення мають лише заборонені або невдалі виклики, відфільтровані журнали доступу дають найконкретніший запис.

Тому цей модуль розглядає спостережуваність як операційний метод, а не як екскурсію по дашбордах. Ви навчитеся визначати область дії ресурсів Telemetry, читати мітки, які роблять метрики Istio корисними, розуміти, як трейсинг залежить від поширення заголовків, і як журнали доступу розкривають факти запиту, які спостерігає проксі. Що важливіше, ви відпрацюєте перехід між сигналами, не втрачаючи з поля зору початкове запитання, тому що найшвидше дослідження зазвичай таке, що дедалі більше звужує докази, а не збирає кожен можливий графік.

Ментальна модель

Уявіть собі спостережуваність Istio як чотири узгоджені сигнали, а не один дашборд. Метрики відповідають на запитання «скільки та як часто». Логи відповідають на запитання «що сталося з цим запитом на цьому проксі». Трейси відповідають на запитання «де цей запит витратив час між переходами». Подання топології відповідають на запитання «які сервіси справді спілкуються прямо зараз».

1. Побудуйте ментальну модель спостережуваності

Спостережуваність Istio починається з простого механізму: кожне робоче навантаження з ін’єкцією має проксі Envoy, і трафік, що проходить через Envoy, можна вимірювати послідовно. Застосунок усе ще має значення, особливо для бізнес-подій та поширення трейсів, але сітка дає вам спільний рівень мережевої телеметрії та телеметрії запитів.

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

┌────────────────────────────────────────────────────────────────────────────┐
│                         Istio Observability Flow                           │
├────────────────────────────────────────────────────────────────────────────┤
│                                                                            │
│  Client                                                                    │
│    │                                                                       │
│    ▼                                                                       │
│  ┌────────────────┐        ┌────────────────┐        ┌────────────────┐    │
│  │ Envoy sidecar  │───────▶│ Envoy sidecar  │───────▶│ Envoy sidecar  │    │
│  │ source proxy   │        │ destination    │        │ next service   │    │
│  └───────┬────────┘        └───────┬────────┘        └───────┬────────┘    │
│          │                         │                         │             │
│          │ metrics                 │ metrics                 │ metrics     │
│          │ access logs             │ access logs             │ access logs │
│          │ trace spans             │ trace spans             │ trace spans │
│          ▼                         ▼                         ▼             │
│  ┌────────────────┐        ┌────────────────┐        ┌────────────────┐    │
│  │ Prometheus     │        │ Log backend    │        │ Jaeger/Zipkin  │    │
│  │ RED metrics    │        │ request facts  │        │ request path   │    │
│  └────────────────┘        └────────────────┘        └────────────────┘    │
│          │                                                   │             │
│          ▼                                                   ▼             │
│  ┌────────────────┐                                 ┌────────────────┐     │
│  │ Grafana        │                                 │ Kiali          │     │
│  │ dashboards     │                                 │ topology       │     │
│  └────────────────┘                                 └────────────────┘     │
│                                                                            │
└────────────────────────────────────────────────────────────────────────────┘

Діаграма показує, чому Istio може забезпечити базову лінію без змін у коді. Проксі видають телеметрію, тому що вони вже обробляють трафік. Це відрізняється від інструментації застосунку, де кожен сервіс має явно записувати бізнес-метрики або створювати спани за допомогою SDK.

Базова лінія не означає повноту. Envoy може повідомити, що checkout викликав payments і отримав 503, але він не може знати, що невдала спроба платежу була поновленням преміумпідписки, якщо застосунок не запише цей доменний факт. Envoy може почати або продовжити спани трейсів, але застосунок має пересилати заголовки трейсів, коли робить вихідні виклики. Цей розподіл відповідальності тримає платформу чесною: сітка дає кожній команді однакові транспортні докази, тоді як інструментація застосунку пояснює бізнес-зміст за цими доказами.

Зупиніться й передбачте: Якщо запит іде від frontend до checkout, а потім до payments, але checkout не пересилає заголовки трейсів до payments, що покаже Jaeger?

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

Чотири сигнали спостережуваності підтримують різні операційні запитання.

Сигнал	Найкраще запитання	Джерело в Istio	Поширений інструмент
Метрики	«Чи стає цей сервіс повільнішим або частіше дає збій?»	Стандартні метрики Envoy	Prometheus та Grafana
Журнали доступу	«Що цей проксі записав для конкретного класу запитів?»	Провайдер журналу доступу Envoy	`kubectl logs` або бекенд логів
Трейси	«Який перехід був повільним для цього шляху запиту?»	Спани Envoy плюс поширені заголовки	Jaeger або Zipkin
Топологія	«Хто з ким спілкується прямо зараз?»	Метрики та аналіз конфігурації Istio	Kiali

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

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

Та сама дисципліна застосовується, коли дашборд уже вказує на ймовірну причину. Якщо панель показує помилки від reviews-v2, не піддавайтеся спокусі негайно відредагувати маршрут. Спершу запитайте, чи використовує запит потрібний репортер, чи зосереджені помилки в одному коді відповіді, чи підтверджує Kiali, що трафік досягає цього робочого навантаження, і чи показують логи прапорці Envoy, які змінили б вашу інтерпретацію. Ці додаткові перевірки перетворюють правдоподібну теорію на обґрунтоване операційне рішення.

┌──────────────────────────────────────────────────────────────────┐
│                     Choosing the First Signal                     │
├───────────────────────────────┬──────────────────────────────────┤
│ Symptom                       │ Start with                       │
├───────────────────────────────┼──────────────────────────────────┤
│ Users report intermittent 5xx │ Prometheus error-rate query       │
│ One request path is slow      │ Trace for the slow path           │
│ Canary route seems wrong      │ Kiali graph plus route labels     │
│ Security policy denies calls  │ Access logs plus mTLS labels      │
│ Dashboard shows odd totals    │ Metric labels and reporter choice │
└───────────────────────────────┴──────────────────────────────────┘

Не запам’ятовуйте таблицю як тривіальний факт. Використовуйте її як звичку сортування. Інструмент не є метою; мета — обрати докази, які можуть змінити вашу наступну дію.

Активна перевірка: Команда каже: «Kiali показує червоне ребро, отже Prometheus, мабуть, зламаний». Яке пояснення ймовірніше?

Kiali часто візуалізує дані Prometheus та конфігурацію Istio разом. Червоне ребро зазвичай означає, що базові метрики запитів показують помилки або погіршення стану, а не те, що Prometheus зламаний. Ви оглянули б відповідні часові ряди istio_requests_total та робоче навантаження призначення, перш ніж звинувачувати інструмент.

2. Налаштуйте Telemetry за областю дії

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

API потужний, тому що він має область дії. Ресурс Telemetry рівня всієї сітки дає безпечне типове значення. Ресурс рівня простору імен може підняти семплування для критично важливої для бізнесу області. Ресурс рівня робочого навантаження може увімкнути інтенсивне налагодження для одного сервісу, не затоплюючи весь кластер логами та спанами.

┌──────────────────────────────────────────────────────────────────────────┐
│                       Telemetry Scope Precedence                         │
├──────────────────────────────────────────────────────────────────────────┤
│                                                                          │
│  Mesh-wide default                                                       │
│  namespace: istio-system                                                 │
│  selector: none                                                          │
│        │                                                                 │
│        ▼                                                                 │
│  Namespace override                                                      │
│  namespace: target application namespace                                 │
│  selector: none                                                          │
│        │                                                                 │
│        ▼                                                                 │
│  Workload override                                                       │
│  namespace: target application namespace                                 │
│  selector: matchLabels for selected Pods                                 │
│                                                                          │
│  More specific configuration wins when settings overlap.                 │
│                                                                          │
└──────────────────────────────────────────────────────────────────────────┘

Область дії	Де живе ресурс	Селектор	Використовуйте, коли
Уся сітка	`istio-system`	Немає	Вам потрібне типове значення для кожного робочого навантаження з ін’єкцією
Простір імен	Простір імен застосунку	Немає	Одній команді чи середовищу потрібна інша поведінка телеметрії
Робоче навантаження	Простір імен застосунку	`spec.selector.matchLabels`	Одному Деплойменту потрібна тимчасова чи особлива обробка

Ось типове значення для всієї сітки, яке вмикає метрики Prometheus, надсилає трейси до налаштованого провайдера, сумісного із Zipkin, та вмикає журналювання доступу Envoy. У реальній платформі ви можете обрати відфільтроване журналювання замість журналювання кожного запиту, але побачити спершу невідфільтровану форму робить пізніший фільтр легшим для розуміння.

apiVersion: telemetry.istio.io/v1
kind: Telemetry
metadata:
  name: mesh-observability-defaults
  namespace: istio-system
spec:
  metrics:
    - providers:
        - name: prometheus
  tracing:
    - providers:
        - name: zipkin
      randomSamplingPercentage: 1.0
  accessLogging:
    - providers:
        - name: envoy

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

apiVersion: telemetry.istio.io/v1
kind: Telemetry
metadata:
  name: payments-debug-tracing
  namespace: payments
spec:
  tracing:
    - providers:
        - name: zipkin
      randomSamplingPercentage: 25.0

Перевизначення на рівні робочого навантаження має бути точнішим. Наступний ресурс обирає лише Поди з міткою app: checkout у просторі імен payments і записує журнали доступу тільки для невдалих запитів. Це той тип цілеспрямованої зміни, який допомагає під час інциденту, не створюючи проблеми зі сховищем для кожного сервісу.

apiVersion: telemetry.istio.io/v1
kind: Telemetry
metadata:
  name: checkout-error-logs
  namespace: payments
spec:
  selector:
    matchLabels:
      app: checkout
  accessLogging:
    - providers:
        - name: envoy
      filter:
        expression: "response.code >= 400"

Зупиніться й передбачте: Якщо Telemetry рівня сітки встановлює семплування трейсів на 1.0, Telemetry простору імен у payments встановлює його на 25.0, а Telemetry робочого навантаження для checkout встановлює його на 100.0, яке семплування має використовувати checkout?

checkout має використовувати налаштування рівня робочого навантаження, тому що це найбільш специфічна область дії, що відповідає. Інші робочі навантаження в payments мають використовувати налаштування рівня простору імен, а робочі навантаження поза payments — типове значення рівня сітки.

Поширене джерело прихованої плутанини — розміщення простору імен. Ресурс рівня сітки належить до istio-system без селектора. Ресурс рівня простору імен належить до простору імен застосунку без селектора. Ресурс робочого навантаження також належить до простору імен застосунку, а його селектор має відповідати міткам Подів робочого навантаження, а не міткам Сервісу Kubernetes, якщо тільки ці мітки справді не присутні на Подах.

Ви можете оглянути мітки перед написанням селектора робочого навантаження. Це дозволяє уникнути ситуації, коли YAML застосовується успішно, але не відповідає нічому корисному.

kubectl get pods -n payments --show-labels

kubectl get deploy checkout -n payments -o jsonpath='{.spec.template.metadata.labels}'

На різниці між мітками Сервісу та мітками шаблону Пода варто зупинитися, тому що вона спричиняє багато тихих збоїв. Сервіси Kubernetes обирають Поди, але Telemetry з областю дії робочого навантаження в Istio обирає мітки робочого навантаження на самих Подах. Якщо ви скопіюєте мітки з об’єкта Сервісу, не перевіривши шаблон Деплойменту, ви можете створити дійсний ресурс Telemetry, який ніколи не впливає на той проксі, який ви мали намір дослідити. Завжди перевіряйте цільові мітки, перш ніж вважати перевизначення робочого навантаження активним доказом.

Telemetry API також може додавати чи видаляти теги метрик. Будьте обережними з кастомними мітками, тому що мітки з високою кардинальністю можуть перевантажити Prometheus. Мітка на кшталт destination_service очікувана, бо кількість сервісів обмежена. Мітка на кшталт user_id небезпечна, тому що вона може створити окремий часовий ряд для кожного користувача.

apiVersion: telemetry.istio.io/v1
kind: Telemetry
metadata:
  name: add-environment-tag
  namespace: istio-system
spec:
  metrics:
    - providers:
        - name: prometheus
      overrides:
        - match:
            metric: ALL_METRICS
            mode: CLIENT_AND_SERVER
          tagOverrides:
            environment:
              operation: UPSERT
              value: '"production"'

Вибір тега	Ризик кардинальності	Операційна цінність	Рекомендація
`environment`	Низький	Добре для розділення prod, staging та dev	Зазвичай безпечно
`team`	Низький до середнього	Корисно для дашбордів володіння	Безпечно за умови контролю
`request_path`	Середній до високого	Корисно лише коли шляхи нормалізовано	Уникайте необроблених шляхів з ідентифікаторами
`user_id`	Дуже високий	Спокусливо, але небезпечно	Не використовуйте як мітку метрики
`trace_id`	Дуже високий	Краще в логах та трейсах	Не використовуйте як мітку метрики

Активна перевірка: Вас просять додати customer_id як мітку Prometheus, щоб бізнес-команда могла налагодити один акаунт. Що ви порадите натомість?

Не додавайте customer_id до метрик сітки, тому що це створює часові ряди з високою кардинальністю і може зашкодити продуктивності Prometheus. Розмістіть ідентифікатори запитів у логах або трейсах, а потім співвіднесіть конкретне дослідження клієнта через ID трейсу, ID запиту або подію рівня застосунку.

Досвідчене вміння тут — не знати кожне поле Telemetry напам’ять. Це узгодження області дії та кардинальності конфігурації з операційною проблемою. Широкі типові значення мають бути дешевими та стабільними. Дорога телеметрія має бути тимчасовою, цілеспрямованою та легкою для видалення.

Думайте про область дії Telemetry так само, як про радіус ураження (blast radius) для зміни маршрутизації. Налаштування рівня сітки має бути достатньо безпечним, щоб про нього можна було забути в напружений день, тому що воно впливає на кожне робоче навантаження з ін’єкцією. Налаштування рівня простору імен має узгоджуватися з межею команди, середовища чи дослідження. Налаштування рівня робочого навантаження має бути достатньо точним, щоб інший оператор міг видалити його після інциденту, не замислюючись, чи не несло воно таємно якусь поведінку платформи.

3. Використовуйте метрики Istio для RED-дашбордів

Стандартні метрики Istio дозволяють будувати RED-дашборди: rate (частота), errors (помилки) та duration (тривалість). Цих трьох сигналів достатньо, щоб відповісти на перше операційне запитання для більшості сервісів HTTP та gRPC: скільки трафіку надходить, скільки дає збій і як довго тривають успішні чи невдалі запити.

Головний лічильник обсягу запитів та помилок — це istio_requests_total. Головна гістограма затримки — istio_request_duration_milliseconds. Гістограми розмірів запитів та відповідей допомагають, коли на продуктивність впливає зростання корисного навантаження або поведінка стиснення.

Метрика	Тип	Основне запитання
`istio_requests_total`	Лічильник	Скільки запитів сталося, згрупованих за мітками на кшталт сервісу та коду відповіді?
`istio_request_duration_milliseconds`	Гістограма	Який розподіл затримки спостерігав Envoy для запитів?
`istio_request_bytes`	Гістограма	Якого розміру були тіла запитів?
`istio_response_bytes`	Гістограма	Якого розміру були тіла відповідей?
`istio_tcp_sent_bytes_total`	Лічильник	Скільки даних TCP було надіслано для не-HTTP-трафіку?
`istio_tcp_received_bytes_total`	Лічильник	Скільки даних TCP було отримано для не-HTTP-трафіку?
`istio_tcp_connections_opened_total`	Лічильник	Скільки TCP-з’єднань було відкрито?
`istio_tcp_connections_closed_total`	Лічильник	Скільки TCP-з’єднань було закрито?

Метрики Istio містять мітки, які описують репортера, джерело, призначення, код відповіді, протокол та політику безпеки. Ці мітки роблять метрики корисними, але вони також створюють можливості для неправильних запитів. Той самий запит може спостерігатися з боку джерела та з боку призначення, тому вам потрібно навмисно обирати репортера.

istio_requests_total{
  reporter="destination",
  source_workload="productpage-v1",
  source_workload_namespace="default",
  destination_workload="reviews-v2",
  destination_workload_namespace="default",
  destination_service="reviews.default.svc.cluster.local",
  request_protocol="http",
  response_code="200",
  response_flags="-",
  connection_security_policy="mutual_tls"
}

Мітка	Чому вона має значення	Часта помилка
`reporter`	Розрізняє спостереження з боку джерела та призначення	Змішування репортерів та подвійний підрахунок трафіку
`destination_service`	Групує трафік за ідентичністю сервісу Kubernetes	Запит до робочого навантаження, коли потрібні SLO рівня сервісу
`destination_workload`	Ідентифікує Деплоймент, що обслуговує запити, або версію робочого навантаження	Пропуск поганої канарки, бо підсумки сервісу виглядають нормальними
`response_code`	Розділяє успіх, клієнтські та серверні помилки	Сприйняття всіх відповідей не-200 як серверних збоїв
`response_flags`	Показує умови рівня Envoy, як-от скидання чи тайм-аути	Ігнорування збоїв проксі, коли логи застосунку виглядають чистими
`connection_security_policy`	Показує, чи захищав mTLS з’єднання	Припущення про стан політики без перевірки спостереженого трафіку

Зупиніться й передбачте: Дашборд сервісу використовує reporter="source" для однієї панелі та reporter="destination" для іншої. Чому підсумки запитів можуть не збігатися?

Проксі джерела та проксі призначення спостерігають трафік з різних позицій. Повторні спроби, відсутні sidecar-проксі, наскрізний (passthrough) трафік або прогалини в телеметрії можуть зробити дві перспективи різними. Для дашбордів надійності сервісу reporter="destination" зазвичай є чистішим серверним поглядом.

Робочий приклад робить патерн запиту конкретним. Припустимо, підтримка повідомляє, що сервіс reviews дає збій після канаркового релізу. Спочатку вам потрібна частота запитів рівня сервісу, потім частка серверних помилок, а потім затримка для сервісу призначення.

sum(rate(istio_requests_total{
  reporter="destination",
  destination_service="reviews.default.svc.cluster.local"
}[5m]))

Цей запит відповідає лише на запитання про обсяг. Його не слід використовувати як запит частоти помилок, бо він включає всі коди відповідей. Наступний запит ділить трафік серверних помилок на весь трафік для того самого сервісу та того самого репортера.

sum(rate(istio_requests_total{
  reporter="destination",
  destination_service="reviews.default.svc.cluster.local",
  response_code=~"5.*"
}[5m]))
/
sum(rate(istio_requests_total{
  reporter="destination",
  destination_service="reviews.default.svc.cluster.local"
}[5m]))

Тепер уявіть, що частота помилок прийнятна, але користувачі все одно скаржаться на повільність. Гістограми затримки потребують іншої форми, тому що необроблена метрика має ряди за відрами (buckets). histogram_quantile оцінює перцентиль за частотами по відрах.

histogram_quantile(0.99,
  sum(rate(istio_request_duration_milliseconds_bucket{
    reporter="destination",
    destination_service="reviews.default.svc.cluster.local"
  }[5m])) by (le)
)

Крок досвідченого перегляду — перевірка, чи відповідає запит операційному запитанню. Запит затримки P99 за сервісом корисний для досвіду користувача, але він може приховати одну погану версію робочого навантаження. Якщо задіяна канарка, додайте destination_workload або destination_version, якщо ця мітка існує у вашій телеметрії.

histogram_quantile(0.95,
  sum(rate(istio_request_duration_milliseconds_bucket{
    reporter="destination",
    destination_service="reviews.default.svc.cluster.local"
  }[5m])) by (le, destination_workload)
)

Активна перевірка: Канарка отримує лише десять відсотків трафіку, і P95 рівня сервісу виглядає нормальним. Яка зміна запиту допоможе вам з’ясувати, чи повільна канарка?

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

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

scrape_configs:
  - job_name: envoy-stats
    metrics_path: /stats/prometheus
    kubernetes_sd_configs:
      - role: pod
    relabel_configs:
      - source_labels: [__meta_kubernetes_pod_container_name]
        action: keep
        regex: istio-proxy
      - source_labels: [__address__]
        action: replace
        regex: ([^:]+)(?::\d+)?
        replacement: $1:15020
        target_label: __address__

Ви можете перевірити, що sidecar-проксі видає метрики, не чекаючи на Prometheus. Ця перевірка корисна, коли дашборд порожній і вам потрібно відокремити «Envoy не видає» від «Prometheus не скрейпить».

kubectl exec deploy/productpage-v1 -c istio-proxy -- \
  curl -s 127.0.0.1:15020/stats/prometheus | grep '^istio_requests_total' | head -5

Порожній результат не завжди означає, що телеметрія зламана. Робоче навантаження могло ще не отримати трафіку, проксі може бути не вставлено, або команда може націлюватися на неправильний контейнер. Згенеруйте трафік, підтвердьте, що контейнер istio-proxy існує, та перевірте мітки робочого навантаження перед зміною конфігурації Telemetry.

Симптом	Імовірна причина	Перша перевірка
Немає `istio_requests_total` від sidecar	Через проксі ще не проходив трафік	Згенеруйте трафік і повторіть звернення до ендпоінту статистики
Метрики від sidecar, але немає даних у Prometheus	Завдання скрейпу або виявлення цілі неправильне	Перевірте цілі Prometheus для Подів `istio-proxy`
Підсумки сервісу виглядають подвоєними	Запит змішав репортерів джерела та призначення	Явно фільтруйте за одним `reporter`
Проблема канарки прихована в агрегаті	Запит згрупований лише за сервісом	Групуйте за міткою робочого навантаження або версії
Несподівана мітка відкритого тексту	Трафік оминає mTLS або політика дозвільна	Перевірте `connection_security_policy` та PeerAuthentication

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

Коли ви переглядаєте вираз PromQL, читайте його зсередини назовні. Селектор має називати сервіс, репортера та клас відповіді, що відповідають запитанню. Вікно діапазону має бути достатньо довгим, щоб згладити нормальне дрижання, але достатньо коротким, щоб показати недавню зміну. Агрегація має зберігати мітки, які мають значення, як-от версія робочого навантаження під час канарки, і відкидати мітки, які лише додають шуму. Ця звичка ловить багато помилок дашборду, перш ніж вони стануть інцидентним фольклором.

4. Трейсуйте запити крізь межі сервісів

Розподілений трейсинг з’єднує спани в шлях запиту. В Istio Envoy може створювати спани для переходів, які спостерігає проксі, але застосунок має поширювати заголовки трейсів, коли робить вихідні запити. Ця відмінність — одна з найважливіших концепцій спостережуваності в сітці.

Трейс — це вся подорож запиту. Спан — це одна виміряна за часом одиниця роботи всередині цієї подорожі. Якщо frontend викликає checkout, а checkout викликає payments, справний трейс має показувати пов’язані спани, які поділяють контекст трейсу. Якщо checkout втрачає заголовки, payments усе одно може створити спан, але він з’явиться як окремий трейс.

┌────────────────────────────────────────────────────────────────────────────┐
│                          Trace Context Propagation                         │
├────────────────────────────────────────────────────────────────────────────┤
│                                                                            │
│  Good path                                                                 │
│  frontend ──headers──▶ checkout ──same trace headers──▶ payments           │
│      │                    │                              │                 │
│      ▼                    ▼                              ▼                 │
│  span A               span B                         span C                │
│      └────────────────────┴──────────────────────────────┘                 │
│                  one connected trace                                       │
│                                                                            │
│  Broken path                                                               │
│  frontend ──headers──▶ checkout ──headers dropped──▶ payments              │
│      │                    │                              │                 │
│      ▼                    ▼                              ▼                 │
│  span A               span B                         span X                │
│      └────────────────────┘                         separate trace         │
│                                                                            │
└────────────────────────────────────────────────────────────────────────────┘

Поширені заголовки включають родину B3 та родину W3C Trace Context. Вам не потрібно запам’ятовувати кожен заголовок для щоденної роботи, але вам потрібно розпізнавати, що застосунки мають пересилати вхідний контекст до вихідних запитів.

x-request-id
x-b3-traceid
x-b3-spanid
x-b3-parentspanid
x-b3-sampled
x-b3-flags
b3
traceparent
tracestate

Зупиніться й передбачте: Сервіс на Java використовує HTTP-клієнт, який створює свіжий вихідний запит і не копіює жодних вхідних заголовків. Трейсинг Istio увімкнено на 100.0 відсотків для цього робочого навантаження. Чи приєднається бекенд-виклик до трейсу фронтенду?

Ні. Повне семплування збільшує, як часто записуються трейси, але не лагодить відсутнього поширення. Застосунок або його бібліотека трейсингу все одно мають копіювати чи вставляти контекст трейсу у вихідні запити.

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

Частота семплування	Практичне використання	Ризик
`0.1`	Шляхи продакшену з дуже високим обсягом	Рідкісні помилки можуть не семплуватися
`1.0`	Стандартне типове значення продакшену	Зазвичай збалансоване для широкої видимості
`10.0`	Staging або коротке дослідження в продакшені	Більше сховища та навантаження на бекенд
`25.0`	Зосереджене налагодження простору імен	Має бути обмежене в часі
`100.0`	Одне робоче навантаження під час активного дослідження	Небезпечне як довгострокове типове значення

Налаштуйте трейсинг через Telemetry після того, як провайдер трейсингу з’явиться в конфігурації сітки. Назва провайдера в Telemetry має відповідати провайдеру розширення, налаштованому для сітки.

apiVersion: install.istio.io/v1alpha1
kind: IstioOperator
# In-cluster IstioOperator controller removed in 1.24; still works with istioctl install -f; Helm recommended
spec:
  meshConfig:
    extensionProviders:
      - name: zipkin
        zipkin:
          service: zipkin.istio-system.svc.cluster.local
          port: 9411
      - name: jaeger
        zipkin:
          service: jaeger-collector.istio-system.svc.cluster.local
          port: 9411

apiVersion: telemetry.istio.io/v1
kind: Telemetry
metadata:
  name: tracing-default
  namespace: istio-system
spec:
  tracing:
    - providers:
        - name: zipkin
      randomSamplingPercentage: 1.0
      customTags:
        cluster:
          literal:
            value: "primary"
        request_id:
          header:
            name: x-request-id
            defaultValue: "missing"

Jaeger може приймати спани у форматі Zipkin через сумісний ендпоінт колектора, тому багато прикладів використовують форму провайдера zipkin, навіть коли бекендом є Jaeger. Важлива операційна перевірка — не назва бренду в YAML; це те, чи збігаються сервіс колектора, порт, протокол та назва провайдера Telemetry.

Активна перевірка: Команда каже: «Jaeger порожній, отже трейсинг Istio вимкнено». Які перевірки вам слід зробити, перш ніж прийняти цей висновок?

Підтвердьте, що ресурс Telemetry посилається на наявного провайдера, підтвердьте, що сервіс колектора досяжний, згенеруйте семпльований трафік та перевірте, що застосунки поширюють заголовки крізь межі сервісів. Також перевірте, чи не настільки низьке семплування, що ваш маленький тест не створив збереженого трейсу.

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

Корисний перегляд трейсу ставить конкретні запитання. Який спан споживає найбільшу частину загального часу? Чи видно повторні спроби? Чи перетнув запит очікувані сервіси? Чи змінився код відповіді на певному переході? Чи є відсутні спани, які натякають на збій поширення заголовків?

Симптом трейсу	Імовірне значення	Наступна дія
Один бекенд-спан домінує в затримці	Низхідний сервіс або залежність повільні	Перевірте метрики сервісу та логи застосунку для цього бекенду
Трейс зупиняється на середньому сервісі	Заголовки не було поширено або трафік вийшов із сітки	Огляньте HTTP-клієнт застосунку та ін’єкцію sidecar
Багато коротких спанів повторних спроб	Повторні спроби маскують нестабільність висхідного сервісу	Перевірте політику повторних спроб `VirtualService` та метрики помилок
Кореневий спан відсутній	Вхідний трафік може оминати очікуваний проксі	Перевірте Gateway, ін’єкцію та шлях запиту
Спани не мають корисних тегів	Кастомні теги Telemetry або інструментація застосунку бідні	Додайте безпечні теги з обмеженою кардинальністю

Звичка досвідченого інженера — співвідносити трейси з іншими доказами. Трейс доводить, що сталося з одним семпльованим запитом. Метрики доводять, чи поширений патерн. Журнали доступу можуть перевірити точні коди відповідей та прапорці. Kiali може показати, чи відповідає шлях трейсу реальній топології сервісів.

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

5. Фільтруйте та читайте журнали доступу Envoy

Журнали доступу — це найконкретніший сигнал сітки. Вони записують факти рівня запиту від Envoy, включно з методом, шляхом, кодом відповіді, прапорцями відповіді, висхідним сервісом, тривалістю та інформацією про з’єднання. Вони також є найлегшим сигналом для перевиробництва.

Типовим операційним запитанням для журналів доступу має бути: «Який клас запитів мені потрібно захопити?». Журналювання кожного успішного запиту для кожного сервісу може бути прийнятним у крихітній лабораторії, але воно створює проблеми з вартістю, зберіганням та приватністю в реальних системах. Telemetry Istio дозволяє вмикати журналювання широко або фільтрувати його вузько.

apiVersion: telemetry.istio.io/v1
kind: Telemetry
metadata:
  name: access-log-default
  namespace: istio-system
spec:
  accessLogging:
    - providers:
        - name: envoy

Орієнтований на продакшен ресурс зазвичай відфільтрований. Цей приклад захоплює клієнтські помилки, серверні помилки та не-mTLS-трафік для одного простору імен. Він дає операторам докази для дослідження збоїв та політик, не записуючи кожен звичайний запит.

apiVersion: telemetry.istio.io/v1
kind: Telemetry
metadata:
  name: suspicious-request-logs
  namespace: default
spec:
  accessLogging:
    - providers:
        - name: envoy
      filter:
        expression: "response.code >= 400 || connection.mtls == false"

Вираз фільтра	Захоплює	Випадок використання
`response.code >= 400`	Клієнтські та серверні помилки	Загальне дослідження збоїв
`response.code >= 500`	Лише серверні помилки	Сортування надійності бекенду
`request.duration > duration("1s")`	Повільні запити понад одну секунду	Дослідження затримки
`connection.mtls == false`	Відкритий текст або не-mTLS-трафік	Перевірка безпеки
`response.code == 403`	Відмови авторизації	Налагодження політик
`response.flags != 0`	Аномалії рівня Envoy (ненульовий бітовий вектор прапорців)	Сортування тайм-аутів або скидань проксі

Зупиніться й передбачте: Ви вмикаєте фільтр журналу доступу для response.code >= 500, а потім тестуєте відсутню сторінку, яка повертає 404. Чи має цей запит з’явитися в журналах доступу sidecar?

Він не має з’явитися, тому що фільтр захоплює лише серверні помилки. Якщо вам потрібні і відсутні маршрути, і бекенд-збої, використовуйте response.code >= 400 натомість.

Ви можете читати журнали доступу безпосередньо з контейнера istio-proxy. Пряма перевірка логів корисна під час лабораторної роботи або коли централізований бекенд логів затримується, але робочі процеси продакшену зазвичай пересилають ці логи до бекенду з можливістю пошуку.

kubectl logs deploy/productpage-v1 -c istio-proxy --tail=20

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

[2026-04-26T10:30:45.123Z] "GET /reviews/0 HTTP/1.1" 200 - via_upstream
  "-" 0 295 24 23 "-" "curl/8.0" "abc-123" "reviews:9080"
  outbound|9080||reviews.default.svc.cluster.local 10.244.1.5:39012
  10.244.2.8:9080 10.244.1.5:33456 - default

Поле	Що оглядати	Чому воно має значення
Код відповіді	`200`, `404`, `503`, `403`	Розділяє успіх, промахи маршрутів, бекенд-збої та відмови політик
Прапорці відповіді	`-`, скидання, тайм-аут, індикатори збою висхідного сервісу	Показує, чи Envoy згенерував або спостеріг аномальну умову
Тривалість	Час запиту в мілісекундах	Допомагає пов’язати логи із симптомами затримки
Висхідний кластер	`outbound	port
ID запиту	Значення `x-request-id`	Співвідносить логи з трейсами та логами застосунку
Authority та шлях	Хост і шлях маршруту	Допомагає налагоджувати зіставлення Gateway та VirtualService

Активна перевірка: Користувач повідомляє про 503, але логи контейнера застосунку не показують жодного запиту. Яка підказка в журналі доступу свідчить, що Envoy дав збій ще до того, як запит досяг застосунку?

Шукайте непорожні прапорці відповіді та індикатори збою з’єднання з висхідним сервісом у журналі доступу sidecar. Якщо Envoy не зміг під’єднатися до висхідного ендпоінту або дав тайм-аут до того, як застосунок обробив запит, логи застосунку можуть бути порожніми.

Формат журналу доступу можна налаштувати через налаштування сітки та провайдерів. Кодування JSON легше парсити системам логів, тоді як текст легше швидко прочитати людині в терміналі. Правильний вибір залежить від низхідного конвеєра логів, а не від особистих уподобань.

apiVersion: install.istio.io/v1alpha1
kind: IstioOperator
# meshConfig.accessLogFile is the legacy global toggle; Telemetry accessLogging is preferred for new installs
spec:
  meshConfig:
    accessLogFile: /dev/stdout
    accessLogEncoding: JSON

Будьте обережними з конфіденційними даними. Проксі можуть спостерігати заголовки та шляхи, а вони можуть містити токени, ідентифікатори акаунтів або персональні дані, якщо застосунки використовують небезпечні патерни URL. Журналювання лише класів помилок не видаляє конфіденційний вміст автоматично, тому команди продакшену мають переглядати формати, терміни зберігання та правила редагування.

Логи — це скальпель, коли відфільтровані, і потоп, коли увімкнені без наміру. Під час інцидентів віддавайте перевагу фільтру рівня робочого навантаження, який захоплює підозрілу умову. Після інциденту видаліть або знизьте область журналювання, щоб тимчасова конфігурація налагодження не стала постійною вартістю платформи.

Аспект приватності має таке саме значення, як аспект сховища. Навіть якщо ваш формат журналу доступу не включає тіл запитів, URL та заголовки можуть нести конфіденційні ідентифікатори, коли застосунки розміщують номери акаунтів, підказки сесій або токени в небезпечних місцях. Оператори сітки мають ставитися до журналювання доступу як до виробничого потоку даних із правилами зберігання та перегляду, а не як до нешкідливої зручності в терміналі. Такий підхід тримає спостережуваність корисною, не перетворюючи її на випадковий шлях розкриття даних.

6. Працюйте з Kiali, Grafana та Jaeger разом

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

Інструмент	Сильна сторона	Слабка сторона	Найкраще перше використання
Kiali	Граф сервісів, бейджі mTLS, валідація конфігурації Istio	Залежить від метрик і може трохи запізнюватися	Перевірити, хто з ким спілкується, і чи виглядає конфігурація підозрілою
Grafana	Дашборди часових рядів та панелі SLO	Вимагає добрих запитів та міток	Підтвердити тренди частоти, помилок та затримки
Jaeger	Шлях окремого запиту та час спанів	Семплування означає, що він може не показати кожен запит	Проаналізувати один повільний або невдалий шлях запиту
Статистика Envoy	Необроблений ендпоінт метрик проксі	На рівні пода та низькорівневий	Відокремити проблеми видачі проксі від проблем скрейпінгу
Журнали доступу	Конкретні записи запитів	Можуть бути зашумленими та дорогими	Оглянути відфільтровані збої або відмови політик

Kiali особливо корисний після змін у керуванні трафіком. Якщо VirtualService має розподіляти трафік між reviews-v1 та reviews-v2, Kiali може показати, чи трафік справді досягає обох робочих навантажень. Цей вигляд графа робить помилки маршрутів видимими швидше, ніж читання YAML рядок за рядком.

kubectl get svc -n istio-system kiali

kubectl port-forward svc/kiali -n istio-system 20001:20001

istioctl dashboard kiali

Grafana краща, коли запитання стосується часу. Якщо інцидент почався після розгортання, дашборд може показати, чи зросла частота помилок у час розгортання, чи зросла затримка лише для одного призначення, і чи проблема все ще триває. Дашборди слід проєктувати навколо запитань, а не навколо кожної доступної метрики.

kubectl port-forward svc/grafana -n istio-system 3000:3000

istioctl dashboard grafana

Кастомна панель Grafana може використовувати той самий PromQL, який ви запускали б безпосередньо в Prometheus. Ця панель групує частоту запитів за кодом відповіді для обраного сервісу, що допомагає відокремити нормальний трафік від клієнтських та серверних помилок.

{
  "targets": [
    {
      "expr": "sum(rate(istio_requests_total{reporter=\"destination\", destination_service=~\"$service\"}[5m])) by (response_code)",
      "legendFormat": "{{response_code}}"
    }
  ],
  "title": "Request Rate by Response Code",
  "type": "timeseries"
}

Jaeger найкорисніший після того, як у вас є репрезентативний запит. Трейс може показати, що фронтенд був швидким, checkout витратив більшість часу в очікуванні payments, а payments зробив повільний виклик до зовнішньої залежності. Це конкретніше, ніж сказати «сайт повільний».

kubectl port-forward svc/jaeger-query -n istio-system 16686:16686

Зупиніться й передбачте: Дашборд Grafana показує зростання P99 для checkout, але Kiali показує всі вузли зеленими. Який інструмент вам слід використати наступним і чому?

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

Kiali також може валідувати конфігурацію Istio. Він може позначити VirtualService, який посилається на відсутній Gateway, підмножину DestinationRule, яка не відповідає міткам робочого навантаження, або трафік, що тече до несподіваного призначення. Ця валідація орієнтована на час виконання і доповнює istioctl analyze.

istioctl analyze -n default

kubectl get virtualservice,destinationrule,telemetry -A

Активна перевірка: VirtualService стверджує, що надсилає десять відсотків трафіку до reviews-v2, але Kiali показує, що трафік отримує лише reviews-v1. Що вам слід порівняти?

Порівняйте призначення маршрутів VirtualService, мітки підмножини DestinationRule та фактичні мітки Подів на reviews-v2. Назва підмножини може бути правильною, тоді як селектор міток за нею не відповідає жодному Поду.

Ефективний робочий процес інциденту поєднує інструменти в продуманому порядку. Почніть із Grafana або Prometheus, щоб довести симптом та його обсяг. Використайте Kiali, щоб перевірити топологію та поведінку маршруту. Використайте Jaeger, щоб оглянути один репрезентативний шлях. Використайте журнали доступу, щоб підтвердити точні результати запитів, спостережені проксі. Використайте istioctl та команди Kubernetes, щоб оглянути конфігурацію, яка пояснює докази.

┌────────────────────────────────────────────────────────────────────────────┐
│                         Practical Debugging Loop                           │
├────────────────────────────────────────────────────────────────────────────┤
│                                                                            │
│  Symptom                                                                   │
│    │                                                                       │
│    ▼                                                                       │
│  Prometheus/Grafana: quantify rate, errors, duration                       │
│    │                                                                       │
│    ▼                                                                       │
│  Kiali: confirm topology, route split, mTLS, config warnings               │
│    │                                                                       │
│    ▼                                                                       │
│  Jaeger: inspect one slow or failed request path                           │
│    │                                                                       │
│    ▼                                                                       │
│  Access logs: verify exact proxy-observed request outcome                  │
│    │                                                                       │
│    ▼                                                                       │
│  Kubernetes and Istio config: change the smallest thing that explains data │
│                                                                            │
└────────────────────────────────────────────────────────────────────────────┘

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

Цикл навмисно оборотний. Якщо Jaeger натякає, що бекенд повільний, але Prometheus не показує широкого зростання затримки, ви можете вирішити, що трейс не репрезентативний, і повернутися до метрик з іншим групуванням. Якщо Kiali показує несподіване ребро, ви можете повернутися до журналів доступу, щоб підтвердити, чи це реальний трафік користувачів, синтетичні зонди чи неправильно маршрутизований виклик. Хороші оператори переходять між інструментами, тому що цього вимагають докази, а не тому, що фіксований чеклист каже, що наступний дашборд є обов’язковим.

Чи знали ви?

Istio може видавати метрики запитів без змін у коді застосунку, тому що sidecar-проксі Envoy спостерігають трафік на шляху запиту та експортують стандартні метрики для поведінки HTTP, gRPC та TCP.
Семплування трейсів та поширення трейсів розв’язують різні проблеми, тому що семплування вирішує, які запити зберігаються, а поширення вирішує, чи приєднаються низхідні спани до того самого трейсу.
Kiali часто розкриває помилки конфігурації через поведінку під час виконання, тому що він поєднує ресурси Istio, дані графа сервісів, стан трафіку та індикатори безпеки, замість того щоб показувати лише статичний YAML.
Фільтри журналу доступу — це елемент керування спостережуваністю, а не лише контроль вартості, тому що фільтрація змушує команди визначати, які результати запитів достатньо важливі, щоб зберігати їх під час звичайної роботи.

Типові помилки

Помилка	Чому вона трапляється	Як її виправити
Встановлення семплування трейсів `100.0` для всієї сітки в продакшені	Сховище трейсів та навантаження на колектор можуть різко зрости в кожному сервісі	Використовуйте низькі типові значення сітки та підіймайте семплування лише для цільових просторів імен чи робочих навантажень
Забування поширити заголовки трейсів у коді застосунку	Jaeger показує роз’єднані фрагменти трейсів, навіть хоча Envoy створює спани	Пересилайте заголовки контексту трейсу B3 або W3C через кожен вихідний запит
Запит метрик Istio без фільтрації `reporter`	Дашборди можуть подвоювати підрахунок або змішувати перспективи джерела та призначення	Обирайте `reporter="destination"` для серверних поглядів надійності, якщо тільки вам не потрібна перспектива джерела
Додавання ідентифікаторів користувачів чи запитів як тегів метрик	Prometheus створює величезну кількість часових рядів і стає дорогим чи нестабільним	Розміщуйте ідентифікатори з високою кардинальністю в логах чи трейсах замість міток метрик
Застосування Telemetry робочого навантаження з мітками, що відповідають лише Сервісу	Ресурс застосовується, але не впливає на жоден Под	Огляньте мітки шаблону Пода та зіставте `spec.selector.matchLabels` із цими мітками
Журналювання кожного запиту назавжди в завантаженій сітці	Обсяг логів перевантажує сховище і ускладнює пошук записів про збої	Використовуйте відфільтровані журнали доступу та обмежуйте в часі детальне журналювання під час досліджень
Сприйняття Kiali, Grafana та Jaeger як взаємозамінних	Команди стрибають між інструментами, не довівши й не звузивши теорію	Використовуйте метрики для обсягу, топологію для потоку, трейси для шляхів та логи для точних записів запитів
Припущення, що порожній дашборд означає, що Istio зламано	Скрейпінг Prometheus, генерація трафіку, ін’єкція чи мітки запиту можуть бути неправильними	Перевірте статистику sidecar безпосередньо перед зміною конфігурації телеметрії сітки

Тест

Питання 1

Ваша команда розгортає checkout-v2 як канарку за наявним сервісом checkout. Дашборд Grafana рівня сервісу показує нормальну середню затримку, але кілька користувачів повідомляють про повільне оформлення замовлень. Яку зміну запиту ви зробили б першою і чому?

Показати відповідь

Розкладіть запит затримки за робочим навантаженням або версією замість агрегування цілого сервісу. Канарка може отримувати малу частку трафіку, тому середні значення рівня сервісу та навіть перцентилі можуть приховати її поведінку. Запитайте istio_request_duration_milliseconds_bucket з reporter="destination" та згрупуйте за міткою на кшталт destination_workload чи версією, якщо доступна.

Питання 2

Ресурс Telemetry рівня простору імен встановлює трейсинг на 25.0 відсотків для payments, а ресурс Telemetry рівня робочого навантаження встановлює трейсинг на 100.0 відсотків для Подів з міткою app: fraud-checker. Під час інциденту трейси для fraud-checker усе ще розріджені. Що вам слід перевірити, перш ніж знову змінювати значення семплування?

Показати відповідь

Перевірте, що селектор робочого навантаження відповідає фактичним міткам Подів, що ресурс Telemetry перебуває в тому самому просторі імен, що й робоче навантаження, що назва провайдера існує в конфігурації сітки, і що достатньо трафіку досягає робочого навантаження. Якщо трейси роз’єднані, а не розріджені, також перевірте, що застосунки поширюють заголовки трейсів.

Питання 3

Розробник повідомляє, що Jaeger показує один трейс від frontend до checkout та окремий трейс від payments до inventory для тієї самої дії користувача. Трейсинг Istio увімкнено, і частота семплування висока. Яка найімовірніша причина і яке виправлення ви запросили б?

Показати відповідь

Найімовірніша причина — відсутнє поширення контексту трейсу в одному з переходів застосунку, зазвичай між checkout та payments. Envoy може створювати спани, але застосунок або бібліотека трейсингу мають пересилати заголовки трейсів B3 чи W3C у вихідних запитах. Виправлення — оновити HTTP-клієнт сервісу чи middleware трейсингу, щоб поширювати вхідні заголовки трейсів.

Питання 4

Виробничий сервіс отримує тисячі запитів за секунду. Служба безпеки просить докази не-mTLS-трафіку, але платформна команда не хоче журналювати кожен запит. Як ви налаштували б журналювання доступу для цього дослідження?

Показати відповідь

Використайте цільовий ресурс Telemetry з фільтром журналу доступу на кшталт connection.mtls == false, за бажанням поєднаний з умовами коду відповіді. За можливості обмежте його відповідним простором імен чи робочим навантаженням, а не всією сіткою. Це захоплює запити, релевантні для безпеки, не перетворюючи кожен успішний mTLS-запит на запис у лозі.

Питання 5

Панель дашборду для reviews.default.svc.cluster.local показує вдвічі більшу частоту запитів, ніж очікувано від навантажувального тесту. Запит підсумовує istio_requests_total, але не фільтрує за reporter. Що не так із запитом і як ви його виправили б?

Показати відповідь

Запит, імовірно, змішує ряди репортерів джерела та призначення, що може подвоїти підрахунок або інакше спотворити результат. Явно фільтруйте за однією перспективою, зазвичай reporter="destination" для серверної частоти запитів. Потім зберігайте той самий вибір репортера в усіх пов’язаних панелях частоти, помилок та затримки.

Питання 6

Після застосування VirtualService, який має маршрутизувати частину трафіку до reviews-v2, Kiali все ще показує, що весь трафік іде до reviews-v1. Поди справні. Які зв’язки конфігурації вам слід оглянути?

Показати відповідь

Огляньте призначення маршрутів VirtualService, підмножини DestinationRule та фактичні мітки Подів для reviews-v2. Маршрут може посилатися на назву підмножини, яка існує в YAML, але чиї мітки не відповідають жодному Поду. Також підтвердьте, що трафік входить через хост та gateway, з якими насправді зіставляється VirtualService.

Питання 7

Команда каже, що їхній дашборд Prometheus порожній після ввімкнення Telemetry. Ви можете виконати exec у контейнер istio-proxy і побачити istio_requests_total за адресою 127.0.0.1:15020/stats/prometheus. Що це доводить і де вам слід досліджувати далі?

Показати відповідь

Це доводить, що Envoy видає метрику з sidecar, тому наступне дослідження має зосередитися на скрейпінгу Prometheus, виявленні цілі, перейменуванні міток (relabeling) чи мітках запиту дашборду. Перевірте цілі Prometheus для Подів istio-proxy та підтвердьте, що шлях скрейпу й перезапис адреси вказують на порт 15020.

Практична вправа: Налаштування та налагодження спостережуваності Istio

Мета

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

Ця вправа використовує зразок Bookinfo, тому що він має кілька сервісів і достатній потік запитів, щоб зробити метрики, топологію та трейси осмисленими. Команди передбачають локальний кластер Kubernetes з Istio, встановленим за допомогою профілю, який включає або дозволяє аддони спостережуваності. Якщо ваше середовище використовує зовнішні Prometheus, Grafana чи трейсинг, адаптуйте лише команди доступу до аддонів.

Налаштування

Запустіть команди налаштування з оболонки з доступом до вашого кластера. Команди використовують повну назву бінарника kubectl, тому вони працюють як при копіюванні в неінтерактивний скрипт, так і в інтерактивному терміналі.

istioctl install --set profile=demo -y

kubectl label namespace default istio-injection=enabled --overwrite

kubectl apply -f https://raw.githubusercontent.com/istio/istio/release-1.27/samples/bookinfo/platform/kube/bookinfo.yaml

kubectl apply -f https://raw.githubusercontent.com/istio/istio/release-1.27/samples/addons/prometheus.yaml
kubectl apply -f https://raw.githubusercontent.com/istio/istio/release-1.27/samples/addons/grafana.yaml
kubectl apply -f https://raw.githubusercontent.com/istio/istio/release-1.27/samples/addons/kiali.yaml
kubectl apply -f https://raw.githubusercontent.com/istio/istio/release-1.27/samples/addons/jaeger.yaml

kubectl wait --for=condition=ready pod -l app=productpage --timeout=180s

kubectl wait --for=condition=ready pod -l app=reviews --timeout=180s

kubectl wait --for=condition=ready pod -l app=ratings --timeout=180s

Згенеруйте базовий трафік перед тим, як оглядати метрики. Без трафіку багато метрик запитів будуть відсутні або нецікаві.

for i in $(seq 1 30); do
  kubectl exec deploy/ratings-v1 -- curl -s productpage:9080/productpage > /dev/null
done

Завдання 1: Застосувати типові значення Telemetry для всієї сітки

Застосуйте ресурс Telemetry рівня сітки, який вмикає метрики Prometheus, налаштовує трейсинг із помірною лабораторною частотою семплування та вмикає журналювання доступу. У продакшені ви зазвичай використовували б нижчий трейсинг та більш вибіркове журналювання, але лабораторія починається наочно, щоб ви могли перевірити шлях сигналу.

kubectl apply -f - <<'EOF'
apiVersion: telemetry.istio.io/v1
kind: Telemetry
metadata:
  name: mesh-observability-defaults
  namespace: istio-system
spec:
  metrics:
    - providers:
        - name: prometheus
  tracing:
    - providers:
        - name: zipkin
      randomSamplingPercentage: 5.0
  accessLogging:
    - providers:
        - name: envoy
EOF

Перевірте, що ресурс існує.

kubectl get telemetry -n istio-system mesh-observability-defaults -o yaml

Завдання 2: Створити перевизначення налагодження для простору імен

Створіть перевизначення трейсингу рівня простору імен для простору імен default. Це симулює тимчасове дослідження, де команді застосунку потрібно більше трейсів для Bookinfo без зміни типового значення для всієї сітки.

kubectl apply -f - <<'EOF'
apiVersion: telemetry.istio.io/v1
kind: Telemetry
metadata:
  name: default-debug-tracing
  namespace: default
spec:
  tracing:
    - providers:
        - name: zipkin
      randomSamplingPercentage: 25.0
EOF

Перевірте, що обидва ресурси Telemetry існують у своїх очікуваних областях дії.

kubectl get telemetry -A

Завдання 3: Відфільтрувати журнали доступу Productpage

Застосуйте ресурс Telemetry рівня робочого навантаження, який журналює лише помилки для productpage. Перш ніж застосовувати його, огляньте мітки Пода, щоб підтвердити, що селектор відповідає робочому навантаженню.

kubectl get pods -l app=productpage --show-labels

kubectl apply -f - <<'EOF'
apiVersion: telemetry.istio.io/v1
kind: Telemetry
metadata:
  name: productpage-error-logs
  namespace: default
spec:
  selector:
    matchLabels:
      app: productpage
  accessLogging:
    - providers:
        - name: envoy
      filter:
        expression: "response.code >= 400"
EOF

Згенеруйте один успішний запит та один запит до відсутньої сторінки. Запит до відсутньої сторінки має з більшою ймовірністю з’явитися під фільтром лише помилок.

kubectl exec deploy/ratings-v1 -- curl -s -o /dev/null -w '%{http_code}\n' productpage:9080/productpage

kubectl exec deploy/ratings-v1 -- curl -s -o /dev/null -w '%{http_code}\n' productpage:9080/does-not-exist

Огляньте логи sidecar productpage.

kubectl logs deploy/productpage-v1 -c istio-proxy --tail=20

Завдання 4: Перевірити необроблені метрики Envoy

Перевірте ендпоінт статистики sidecar безпосередньо. Це каже вам, чи видає Envoy метрики, перш ніж ви налагоджуватимете Prometheus чи Grafana.

kubectl exec deploy/productpage-v1 -c istio-proxy -- \
  curl -s 127.0.0.1:15020/stats/prometheus | grep '^istio_requests_total' | head -10

Якщо команда нічого не повертає, згенеруйте більше трафіку та повторіть.

for i in $(seq 1 20); do
  kubectl exec deploy/ratings-v1 -- curl -s productpage:9080/productpage > /dev/null
done

kubectl exec deploy/productpage-v1 -c istio-proxy -- \
  curl -s 127.0.0.1:15020/stats/prometheus | grep '^istio_requests_total' | head -10

Завдання 5: Відпрацювати міркування на PromQL

Якщо Prometheus встановлено у вашому просторі імен системи Istio, зробіть port-forward і запустіть запити в інтерфейсі. Використовуйте 127.0.0.1 в адресі браузера.

kubectl port-forward svc/prometheus -n istio-system 9090:9090

Відкрийте http://127.0.0.1:9090 та запустіть запит частоти запитів для сервісу productpage із Bookinfo.

sum(rate(istio_requests_total{
  reporter="destination",
  destination_service="productpage.default.svc.cluster.local"
}[5m]))

Запустіть запит частоти помилок. Якщо ваш згенерований трафік не дав помилок через ту саму ідентичність сервісу, скоригуйте сервіс призначення або згенеруйте більше невдалих запитів.

sum(rate(istio_requests_total{
  reporter="destination",
  destination_service="productpage.default.svc.cluster.local",
  response_code=~"5.*"
}[5m]))
/
sum(rate(istio_requests_total{
  reporter="destination",
  destination_service="productpage.default.svc.cluster.local"
}[5m]))

Запустіть запит затримки. Потім змініть групування, щоб включити destination_workload, та порівняйте, що може розкрити запит.

histogram_quantile(0.95,
  sum(rate(istio_request_duration_milliseconds_bucket{
    reporter="destination",
    destination_service="productpage.default.svc.cluster.local"
  }[5m])) by (le)
)

Завдання 6: Оглянути топологію та трейси

Відкрийте Kiali, якщо аддон присутній. Використайте його, щоб перевірити, що сервіси Bookinfo з’єднані, і трафік тече між productpage, details, reviews та ratings.

istioctl dashboard kiali

Якщо присутній бекенд трейсингу, відкрийте його та пошукайте недавні трейси Bookinfo. Згенеруйте додатковий трафік, якщо трейси не з’являються, потім перевірте, чи з’єднані спани між сервісами.

for i in $(seq 1 40); do
  kubectl exec deploy/ratings-v1 -- curl -s productpage:9080/productpage > /dev/null
done

istioctl dashboard jaeger

Переглядаючи трейс, визначте найповільніший спан, код відповіді та чи включає шлях запиту всі очікувані сервіси. Якщо трейс розпадається на фрагменти, пов’яжіть це спостереження з поширенням заголовків, а не припускайте, що бекенд лежить.

Завдання 7: Діагностувати спроєктований збій

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

Згенеруйте невдалий запит.

kubectl exec deploy/ratings-v1 -- curl -s -o /dev/null -w '%{http_code}\n' productpage:9080/does-not-exist

Використайте журнали доступу, щоб підтвердити, чи записав проксі невдалий запит.

kubectl logs deploy/productpage-v1 -c istio-proxy --tail=30

Використайте Prometheus чи необроблені метрики Envoy, щоб вирішити, чи вплинув збій на один запит чи на ширший патерн. Використайте Kiali, щоб підтвердити, що граф сервісів усе ще показує очікуваний потік трафіку. Якщо трейсинг доступний, пошукайте семпльований запит та вирішіть, чи додає він корисної інформації понад лог.

Критерії успіху

Ресурс Telemetry рівня сітки існує в istio-system та налаштовує метрики, трейсинг і журналювання доступу.
Ресурс Telemetry рівня простору імен існує в default та перевизначає трейсинг без зміни типового значення для всієї сітки.
Ресурс Telemetry рівня робочого навантаження обирає Поди productpage та фільтрує журнали доступу до відповідей з помилками.
Ви можете пояснити, чому Telemetry робочого навантаження є більш специфічним, ніж Telemetry простору імен та сітки.
Ви можете отримати istio_requests_total безпосередньо з ендпоінту статистики Envoy на порту 15020.
Ви можете написати або оцінити запит частоти запитів на PromQL із використанням reporter="destination".
Ви можете написати або оцінити запит частоти помилок, який ділить запити серверних помилок на загальну кількість запитів для того самого сервісу.
Ви можете пояснити, чому роз’єднані трейси зазвичай вказують на відсутнє поширення заголовків, а не на відсутні спани Envoy.
Ви можете обрати між Kiali, Grafana, Jaeger та журналами доступу для конкретного запитання усунення несправностей.

Прибирання

Видаліть ресурси Telemetry та зразок Bookinfo, коли завершите. Прибирання навмисно називає кожен ресурс явно, щоб ви не видалили непов’язану конфігурацію спостережуваності.

kubectl delete telemetry mesh-observability-defaults -n istio-system

kubectl delete telemetry default-debug-tracing -n default

kubectl delete telemetry productpage-error-logs -n default

kubectl delete -f https://raw.githubusercontent.com/istio/istio/release-1.27/samples/bookinfo/platform/kube/bookinfo.yaml

kubectl delete -f https://raw.githubusercontent.com/istio/istio/release-1.27/samples/addons/prometheus.yaml
kubectl delete -f https://raw.githubusercontent.com/istio/istio/release-1.27/samples/addons/grafana.yaml
kubectl delete -f https://raw.githubusercontent.com/istio/istio/release-1.27/samples/addons/kiali.yaml
kubectl delete -f https://raw.githubusercontent.com/istio/istio/release-1.27/samples/addons/jaeger.yaml

Якщо ви встановили Istio лише для цієї лабораторії і жоден інший модуль його не потребує, ви можете видалити його окремо.

istioctl uninstall --purge -y

kubectl delete namespace istio-system

Джерела

Додаткове читання

Istio Telemetry Reference — Канонічний довідник з областей дії Telemetry, перевизначень, трейсингу, метрик та конфігурації журналювання доступу.
Istio Standard Metrics — Визначає назви метрик, мітки та семантику, що використовуються в усьому модулі для настанов із PromQL та дашбордів.
Distributed Tracing Overview — Найкраще джерело про вимоги до поширення трейсів, налаштування провайдера та межу між спанами, згенерованими проксі, та поведінкою застосунку.
Visualizing Your Mesh with Kiali — Показує, як Kiali використовує телеметрію Istio для графів і як він вписується в робочі процеси спостережуваності.

Наступний модуль

Ви завершили модуль спостережуваності ICA та основну послідовність ICA. Використайте наступний крок огляду, щоб об’єднати встановлення, керування трафіком, безпеку, усунення несправностей та спостережуваність в одну операційну модель.

Далі: Огляд напрямку ICA

Для глибшої практики поверніться до цих модулів і поставте те саме операційне запитання в кожному з них: «Який доказ підтвердить, що ця конфігурація поводиться так, як задумано?»

Модуль 1: Встановлення та архітектура — перевірте ін’єкцію, готовність проксі та стан площини управління.
Модуль 2: Керування трафіком — перевірте збіги маршрутів, підмножини, повторні спроби, тайм-аути та розподіл трафіку.
Модуль 3: Безпека та усунення несправностей — перевірте стан mTLS, рішення про авторизацію та конфігурацію проксі.
Цей модуль — перевірте метрики, логи, трейси, топологію та запити дашбордів.

Модуль 1.4: Спостережуваність Istio

Складність: [СЕРЕДНЯ]

Час на проходження: 50-70 хвилин

Передумови

Результати навчання

Чому цей модуль важливий

1. Побудуйте ментальну модель спостережуваності

2. Налаштуйте Telemetry за областю дії

3. Використовуйте метрики Istio для RED-дашбордів

4. Трейсуйте запити крізь межі сервісів

5. Фільтруйте та читайте журнали доступу Envoy

6. Працюйте з Kiali, Grafana та Jaeger разом

Чи знали ви?

Типові помилки

Тест

Питання 1

Питання 2

Питання 3

Питання 4

Питання 5

Питання 6

Питання 7

Практична вправа: Налаштування та налагодження спостережуваності Istio

Мета

Налаштування

Завдання 1: Застосувати типові значення Telemetry для всієї сітки

Завдання 2: Створити перевизначення налагодження для простору імен

Завдання 3: Відфільтрувати журнали доступу Productpage

Завдання 4: Перевірити необроблені метрики Envoy

Завдання 5: Відпрацювати міркування на PromQL

Завдання 6: Оглянути топологію та трейси

Завдання 7: Діагностувати спроєктований збій

Критерії успіху

Прибирання

Джерела

Додаткове читання

Наступний модуль

Підсумковий чеклист спостережуваності ICA

Складність: `[СЕРЕДНЯ]`