Модуль 3.4: Основи спостережуваності

Складність: [СЕРЕДНЯ] — концепції спостережуваності для Kubernetes 1.35 і новіших версій. Час на проходження: 45–55 хвилин. Передумови: Модуль 3.3, хмарні патерни, а також базова впевненість у читанні Pod’ів, Сервісів і логів застосунків у кластері Kubernetes.

Що ви зможете зробити

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

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

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

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

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

Цей модуль навчає спостережуваності як експлуатаційної дисципліни, а не як категорії продуктів. Ви порівняєте моніторинг зі спостережуваністю, дізнаєтеся, як метрики, логи та трейси відповідають на різні питання, і потренуєтеся обирати правильний сигнал під час інциденту в Kubernetes. Мета — не запам’ятати назви інструментів для іспиту KCNA. Мета — навчитися міркувати як оператор, який вміє перетворити заплутані симптоми на обґрунтовану наступну дію.

Що означає спостережуваність на практиці

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

┌─────────────────────────────────────────────────────────────┐
│               СПОСТЕРЕЖУВАНІСТЬ                             │
├─────────────────────────────────────────────────────────────┤
│                                                             │
│  Визначення:                                               │
│  ─────────────────────────────────────────────────────────  │
│  Здатність зрозуміти внутрішній стан системи,             │
│  досліджуючи її зовнішні виходи                           │
│                                                             │
│  Моніторинг проти спостережуваності:                      │
│  ─────────────────────────────────────────────────────────  │
│                                                             │
│  МОНІТОРИНГ:                                               │
│  "Чи працює система?"                                     │
│  • Заздалегідь визначені метрики                          │
│  • Відомі режими відмов                                   │
│  • Дашборди та оповіщення                                 │
│                                                             │
│  СПОСТЕРЕЖУВАНІСТЬ:                                        │
│  "Чому система не працює?"                                │
│  • Досліджувати невідомі проблеми                         │
│  • Налагоджувати нові несправності                        │
│  • Розуміти поведінку системи                             │
│                                                             │
│  Моніторинг є підмножиною спостережуваності               │
│                                                             │
└─────────────────────────────────────────────────────────────┘

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

Розрізнення відомого невідомого та невідомого невідомого корисне тому, що змінює спосіб, у який ви ставите питання. Відоме невідоме — це щось на кшталт «чи перевищить насичення CPU наш поріг оповіщення сьогодні вночі?», бо ризик зрозумілий, а вимірювання заздалегідь визначене. Невідоме невідоме — це щось на кшталт «чому лише покупці-новачки, які користуються одним способом оплати, бачать повільне оформлення замовлення після нешкідливого розгортання?», бо форма проблеми проявляється під час розслідування. Хороша спостережуваність дає змогу поставити це друге питання, не випускаючи нового коду для налагодження під час інциденту.

У Kubernetes платформа надає корисну сировину, але не повну систему спостережуваності. Kubelet може надавати дані про ресурси контейнерів, Pod’и можуть записувати логи в stdout та stderr, а сервісні сітки чи інструментовані бібліотеки можуть поширювати контекст трейсу, проте ці сигнали все одно потребують збору, зберігання, індексування, кореляції та політик утримання. Кластер може бути технічно спостережуваним у дрібних частинах, залишаючись при цьому експлуатаційно непрозорим для тих, хто чергує.

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

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

Три стовпи як взаємодоповнювальні докази

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

┌─────────────────────────────────────────────────────────────┐
│              ТРИ СТОВПИ СПОСТЕРЕЖУВАНОСТІ                   │
├─────────────────────────────────────────────────────────────┤
│                                                             │
│  ┌─────────────┐  ┌─────────────┐  ┌─────────────┐         │
│  │   МЕТРИКИ   │  │    ЛОГИ     │  │   ТРЕЙСИ    │         │
│  │             │  │             │  │             │         │
│  │  Числа      │  │  Події      │  │  Запити     │         │
│  │  у часі     │  │  текст      │  │  через      │         │
│  │             │  │             │  │  сервіси    │         │
│  │ "Скільки?"  │  │  "Що?"      │  │  "Де?"      │         │
│  └─────────────┘  └─────────────┘  └─────────────┘         │
│                                                             │
│  Разом вони відповідають на:                              │
│  • Що відбувається? (метрики)                             │
│  • Що саме сталося? (логи)                                │
│  • Як це сталося в усіх сервісах? (трейси)                │
│                                                             │
└─────────────────────────────────────────────────────────────┘

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

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

┌─────────────────────────────────────────────────────────────┐
│              МЕТРИКИ                                        │
├─────────────────────────────────────────────────────────────┤
│                                                             │
│  Що вимірюють метрики:                                     │
│  ─────────────────────────────────────────────────────────  │
│  • Частота запитів (запитів/секунду)                      │
│  • Частота помилок (помилок/секунду)                      │
│  • Тривалість (час відповіді)                             │
│  • Насичення (CPU %, пам'ять %)                          │
│                                                             │
│  Приклад метрики:                                         │
│  ─────────────────────────────────────────────────────────  │
│  http_requests_total{method="GET", status="200"} 1234    │
│        │               │                          │       │
│        │               │                          │       │
│    назва метрики    мітки/теги                 значення   │
│                                                             │
│  Часовий ряд:                                             │
│  ─────────────────────────────────────────────────────────  │
│  Значення                                                  │
│    │                                                       │
│ 100├      ┌──┐                                            │
│    │  ┌──┐│  │   ┌──┐                                    │
│  50├──┘  └┘  └───┘  └──┐                                 │
│    │                     └──                              │
│    └─────────────────────────→ Час                       │
│                                                             │
│  Типи метрик:                                            │
│  • Counter: лише зростає (запити, помилки)               │
│  • Gauge: зростає і спадає (температура, пам'ять)        │
│  • Histogram: розподіл значень (кошики затримки)         │
│  • Summary: статистичний розподіл (перцентилі)           │
│                                                             │
└─────────────────────────────────────────────────────────────┘

Метод RED — це орієнтований на сервіс спосіб обирати метрики. Rate (частота) повідомляє, скільки трафіку отримує сервіс, errors (помилки) повідомляють, яка частка цього трафіку зазнає невдачі, а duration (тривалість) повідомляє, скільки часу займають успішні чи невдалі запити. RED потужний тому, що прямо відображається на досвід користувача: сервіс, який є повільним, відмовляє чи отримує незвичний трафік, заслуговує на увагу, навіть якщо кожна Нода досі має вільний CPU.

Метод RED

Для сервісів відстежуйте:

Метрика	Опис
Rate (частота)	Запитів за секунду
Errors (помилки)	Невдалих запитів за секунду
Duration (тривалість)	Час на запит

Метод USE доповнює RED, зосереджуючись на ресурсах, а не на шляхах запитів. Utilization (утилізація) запитує, наскільки зайнятий ресурс, saturation (насичення) запитує, чи чекає робота, а errors (помилки) запитують, чи повідомляє сам ресурс про відмову. У Kubernetes USE може застосовуватися до CPU, пам’яті, дисків, мережевих інтерфейсів, черг, пулів з’єднань і будь-якої спільної залежності, яка може стати вузьким місцем. Нода з високою утилізацією не є автоматично інцидентом, але насичена черга плюс зростання тривалості запитів — це серйозний натяк.

Метод USE

Для ресурсів відстежуйте:

Метрика	Опис
Utilization (утилізація)	% часу, коли ресурс зайнятий
Saturation (насичення)	Робота в черзі/очікуванні
Errors (помилки)	Кількість помилок

Метрики Kubernetes зазвичай надходять із кількох рівнів. Конвеєр метрик ресурсів може показати недавнє використання CPU та пам’яті для Pod’ів і Нод, метрики у стилі kube-state можуть описувати стан об’єктів, як-от бажану кількість реплік чи готовність Pod’а, а метрики застосунку мають розкривати поведінку сервісу, як-от частоту запитів, помилки, тривалість, глибину черги та відмови залежностей. Сприймайте ці рівні як взаємодоповнювальні: метрики платформи пояснюють тиск планування та виконання, тоді як метрики застосунку пояснюють, чи страждають користувачі.

У налаштуванні Prometheus Operator об’єкти ServiceMonitor чи PodMonitor (кастомні ресурси) можуть спростити збір, але назви та мітки метрик усе одно належать команді сервісу. Хороші мітки Kubernetes, як-от namespace, service, version, route, method і status, допомагають сегментувати інциденти; необмежені мітки, як-от ідентифікатор користувача, сирий URL, ідентифікатор сесії та ідентифікатор запиту, належать у логах чи трейсах, а не у сховищі часових рядів.

Логи — це записи подій із позначкою часу, і вони несуть деталі, які метрики навмисно опускають. Корисний рядок логу повідомляє, який сервіс його видав, коли це сталося, яку операцію було спробувано, до якого запиту чи трейсу він належав і які безпечні ідентифікатори допомагають пов’язати його з іншими доказами. Різниця між «оплата зазнала невдачі» та структурованою подією з полями service, level, trace_id, order_id і санітизованим кодом помилки — це різниця між пошуком голки в копиці сіна та запитом до запису.

┌─────────────────────────────────────────────────────────────┐
│              ЛОГИ                                           │
├─────────────────────────────────────────────────────────────┤
│                                                             │
│  Що фіксують логи:                                         │
│  ─────────────────────────────────────────────────────────  │
│  • Події застосунку                                        │
│  • Помилки та стек-трейси                                  │
│  • Журнали аудиту                                          │
│  • Налагоджувальна інформація                              │
│                                                             │
│  Приклад логу:                                             │
│  ─────────────────────────────────────────────────────────  │
│  2024-01-15T10:23:45.123Z INFO [order-service]            │
│    orderId=12345 customerId=67890 action=created          │
│    "Order created successfully"                           │
│                                                             │
│  Рівні логування:                                         │
│  ─────────────────────────────────────────────────────────  │
│  DEBUG → INFO → WARN → ERROR → FATAL                      │
│  (докладно)             (критично)                       │
│                                                             │
│  Структуроване логування (рекомендовано):                 │
│  ─────────────────────────────────────────────────────────  │
│  {                                                        │
│    "timestamp": "2024-01-15T10:23:45.123Z",              │
│    "level": "INFO",                                       │
│    "service": "order-service",                           │
│    "orderId": "12345",                                   │
│    "message": "Order created successfully"               │
│  }                                                        │
│                                                             │
│  Переваги структурованих логів:                           │
│  • Легко шукати                                           │
│  • Машинно розбірливі                                     │
│  • Узгоджений формат                                      │
│                                                             │
│  У Kubernetes:                                            │
│  ─────────────────────────────────────────────────────────  │
│  Контейнери пишуть у stdout/stderr                        │
│  Колектори логів (Fluentd, Fluent Bit) збирають логи     │
│  Надсилають у сховище (Elasticsearch, Loki)              │
│                                                             │
└─────────────────────────────────────────────────────────────┘

Kubernetes формує практики логування специфічним чином. Контейнери зазвичай мають писати логи застосунку в stdout та stderr, після чого колектор на рівні Ноди чи sidecar може перемістити ці логи до бекенду, як-от Loki, Elasticsearch або іншої системи. Такий підхід відокремлює код застосунку від доставлення логів, але це також означає, що команди мають стандартизувати поля, перш ніж логи покинуть Pod. Якщо кожен сервіс вигадує різні назви для ідентифікаторів запитів, логи стає важко корелювати саме в той момент, коли ясність важить найбільше.

Звичний патерн збору в Kubernetes — це колектор на рівні Ноди, що працює як DaemonSet, бо він може читати файли логів контейнерів для кожного Pod’а на цій Ноді та збагачувати записи метаданими namespace, Pod’а, контейнера та міток. Sidecar-колектор усе одно може бути корисним, коли застосунок пише застарілий файловий формат, який треба перетворити поруч із робочим навантаженням, але він додає контейнери до кожної репліки та прив’язує доставлення логів до життєвого циклу Pod’а. Для міркувань рівня KCNA запам’ятайте типовий підхід: писати у stdout/stderr, збирати на Ноді, збагачувати метаданими Kubernetes і залишати sidecar’и для особливих випадків.

Трейси простежують запити через розподілені системи, представляючи всю подорож як трейс, а кожну операцію — як спан (span). Коли запит входить в API-шлюз, викликає сервіс замовлень, досягає сервісу оплати, а потім запитує базу даних, трейс може показати, який перехід (hop) спожив час і яка батьківська операція його спричинила. Трейсинг найкорисніший, коли поширення контексту працює через кожну межу, включно з HTTP, gRPC, системами обміну повідомленнями, фоновими завданнями та проксі сервісної сітки.

┌─────────────────────────────────────────────────────────────┐
│              РОЗПОДІЛЕНИЙ ТРЕЙСИНГ                          │
├─────────────────────────────────────────────────────────────┤
│                                                             │
│  Проблема: запит проходить через кілька сервісів          │
│  ─────────────────────────────────────────────────────────  │
│  User → API Gateway → Order Service → Payment → Database │
│                                                             │
│  Де він уповільнився? Де зазнав невдачі?                  │
│                                                             │
│  Рішення: трейси                                          │
│  ─────────────────────────────────────────────────────────  │
│                                                             │
│  Trace: повна подорож запиту                             │
│  Span: одна операція в межах трейсу                      │
│                                                             │
│  Trace ID: abc-123                                        │
│  ┌─────────────────────────────────────────────────────┐   │
│  │                                                      │   │
│  │ ├── API Gateway (span 1)                           │   │
│  │ │   └── 50ms                                       │   │
│  │ │                                                   │   │
│  │ ├── Order Service (span 2)                         │   │
│  │ │   └── 120ms                                      │   │
│  │ │   │                                              │   │
│  │ │   ├── Payment Service (span 3)                  │   │
│  │ │   │   └── 200ms  ← Повільно!                    │   │
│  │ │   │                                              │   │
│  │ │   └── Database (span 4)                         │   │
│  │ │       └── 30ms                                   │   │
│  │ │                                                   │   │
│  │ └── Всього: 400ms                                  │   │
│  │                                                      │   │
│  └─────────────────────────────────────────────────────┘   │
│                                                             │
│  Trace ID поширюється через усі сервіси                   │
│  Кожен сервіс додає свій спан                             │
│                                                             │
└─────────────────────────────────────────────────────────────┘

Термінологія трейсингу проста, але експлуатаційні наслідки важливі. Ідентифікатор трейсу (trace ID) має давати змогу знайти повну подорож запиту, тоді як ідентифікатори спанів і зв’язки з батьківським спаном зберігають форму роботи. Поширення контексту — це акт передавання цих ідентифікаторів далі, щоб наступний сервіс міг прикріпити свою роботу до того самого трейсу. Коли поширення ламається, система може й далі збирати спани, але запит постає як роз’єднані фрагменти.

У Kubernetes трейсинг зазвичай поєднує інструментування застосунку з колектором чи бекендом. Бібліотеки OpenTelemetry можуть створювати спани всередині застосунку, сервісна сітка може додавати спани мережевого рівня, а OpenTelemetry Collector може працювати як шлюзовий Deployment, sidecar чи агент на рівні Ноди залежно від масштабу та потреб у контролі. Важливий вибір дизайну — не сама форма колектора; це те, чи переживає контекст трейсу виклики між Pod’ами, переходи через черги, повторні спроби та фонових виконавців, щоб логи й трейси могли описувати один запит, а не роз’єднані фрагменти.

Термінологія трейсингу

Термін	Опис
Trace (трейс)	Повна подорож запиту (всі спани)
Span (спан)	Одна операція в межах трейсу
Trace ID	Унікальний ідентифікатор трейсу
Span ID	Унікальний ідентифікатор спана
Parent Span (батьківський спан)	Операція, що викликає
Поширення контексту	Передавання trace ID між сервісами

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

З’єднання сигналів під час інциденту

Найкращі розслідування інцидентів рухаються від широких симптомів до конкретних причин, не вдаючи, що один сигнал може відповісти на кожне питання. Метрики виявляють і окреслюють проблему, трейси локалізують повільний чи відмовний сегмент шляху запиту, а логи пояснюють локальну причину відмови. Ця послідовність не є законом, бо іноді першим натяком стає оповіщення на основі логів чи екземпляр (exemplar) трейсу, але це надійний типовий підхід, коли інцидент починається із симптому, видимого користувачеві.

┌─────────────────────────────────────────────────────────────┐
│           З'ЄДНАННЯ МЕТРИК, ЛОГІВ, ТРЕЙСІВ                  │
├─────────────────────────────────────────────────────────────┤
│                                                             │
│  Сценарій: користувачі повідомляють про повільне          │
│            оформлення замовлення                           │
│                                                             │
│  1. МЕТРИКИ показують проблему                            │
│     ─────────────────────────────────────────────────────  │
│     Дашборд: checkout_duration_p99 = 5s (зазвичай 1s)    │
│     "Оформлення повільне, але чому?"                      │
│                                                             │
│  2. ТРЕЙСИ визначають де                                  │
│     ─────────────────────────────────────────────────────  │
│     Трейс показує, що сервіс оплати займає 4s            │
│     "Оплата — це вузьке місце, але чому?"                │
│                                                             │
│  3. ЛОГИ пояснюють чому                                   │
│     ─────────────────────────────────────────────────────  │
│     Лог: "Connection pool exhausted, waiting for         │
│           connection to external payment gateway"        │
│     "Ага! Пул з'єднань потребує налаштування"            │
│                                                             │
│  Подорож:                                                  │
│  Метрики (виявити) → Трейси (локалізувати) → Логи        │
│  (діагностувати)                                          │
│                                                             │
└─────────────────────────────────────────────────────────────┘

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

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

У Kubernetes дисциплінований тріаж часто починається із симптомів рівня сервісу, а потім переходить до доказів рівня Pod’а та Ноди. Ви можете порівняти частоту помилок за маршрутом і версією розгортання, дослідити повільний трейс на предмет того спана сервісу, який домінує в затримці, а потім скористатися k logs чи бекендом логів, щоб дослідити події поруч із тим самим ідентифікатором трейсу. Звичка до командного рядка досі важлива, тож представте скорочення один раз у вашій оболонці за допомогою alias k=kubectl, а потім послідовно використовуйте k у вправах і ранбуках.

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

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

Є друга навичка впорядкування, яку початківці часто пропускають: використовуйте сигнал, що відповідає питанню. «Скільки користувачів зачеплено?» — це зазвичай питання метрик. «Який сервіс поглинув затримку?» — це зазвичай питання трейсу. «Який виняток, відмова чи тайм-аут стався всередині цього сервісу?» — це зазвичай питання логу. Коли команди змішують ці питання, вони марнують час, прохаючи логи оцінити вплив на весь парк або прохаючи дашборди пояснити один стек-трейс.

Оповіщення, інструментування та реалії Kubernetes

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

┌─────────────────────────────────────────────────────────────┐
│              ОПОВІЩЕННЯ                                     │
├─────────────────────────────────────────────────────────────┤
│                                                             │
│  Перетворіть метрики на сповіщення                        │
│                                                             │
│  ┌─────────┐    ┌─────────────┐    ┌─────────────┐        │
│  │ Метрики │ →  │ Правила     │ →  │ Сповіщення  │        │
│  │         │    │ "Якщо X > Y"│    │ Slack/Page  │        │
│  └─────────┘    └─────────────┘    └─────────────┘        │
│                                                             │
│  Хороші практики оповіщення:                              │
│  ─────────────────────────────────────────────────────────  │
│                                                             │
│  • Оповіщайте про симптоми, а не причини                  │
│    Погано: "CPU > 90%"                                   │
│    Добре:  "Час відповіді > 500ms"                       │
│                                                             │
│  • Уникайте втоми від оповіщень                           │
│    Забагато оповіщень = ігнорують усі                     │
│                                                             │
│  • Дієві оповіщення                                       │
│    Якщо не можете діяти — не оповіщайте                   │
│                                                             │
│  • Рівні серйозності                                      │
│    Critical: викликати когось ЗАРАЗ                       │
│    Warning: перевірити завтра                            │
│    Info: лише до відома                                  │
│                                                             │
└─────────────────────────────────────────────────────────────┘

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

Інструментування — це робота з того, щоб змусити програмне забезпечення видавати корисні сигнали ще до інциденту. Для робочих навантажень Kubernetes це може охоплювати метрики застосунку на ендпоінті скрейпінгу, структуровані логи з узгодженими полями, трейсинг OpenTelemetry, події Kubernetes та мітки робочих навантажень, які ідентифікують сервіс, namespace, версію та середовище. Інструментування не завершено, коли дані існують. Воно завершено, коли дані можна об’єднати між інструментами достатньо швидко, щоб скерувати рішення.

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

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

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

Який підхід ви обрали б тут і чому: додати мітку user_id до лічильника запитів високого обсягу чи додати той самий ідентифікатор користувача як структуроване поле логу та атрибут трейсу з контролем терміну зберігання? Мітка метрики робить широкі запити дорогими й нестабільними, тоді як поле логу чи трейсу зберігає цільову цінність для налагодження, не множачи кожен часовий ряд на чисельність користувачів. Цей компроміс є центральним для дизайну спостережуваності.

Один практичний робочий процес Kubernetes — поєднувати сигнали платформи з сигналами застосунку. Платформа може показати, чи перезапускалися Pod’и, чи розгорнувся Deployment, чи з’явилося тротлінг CPU, чи зазнала Нода тиску. Застосунок може показати частоту запитів, помилки залежностей, відмови бізнес-операцій і спани трейсів. Інциденти стають яснішими, коли анотації розгортань, мітки Pod’ів і версії застосунку з’являються на тій самій часовій шкалі, що й зміни затримки та помилок.

Іспит KCNA очікує словникового запасу, але реальна експлуатація очікує суджень. Метрики без міток не можуть сегментувати вплив; метрики з необачними мітками можуть покласти бекенд моніторингу. Логи без структури дешеві в записі, але дорогі в пошуку; логи з конфіденційними даними створюють ризик безпеки. Трейси без семплування можуть бути недоступними за ціною при високому трафіку; трейси з поганим семплуванням можуть пропустити той єдиний запит, що пояснює інцидент. Хороші команди роблять ці компроміси свідомо.

Робочий приклад: сервіс кошика, який повільний лише іноді

Уявіть сервіс кошика, який зазвичай відповідає за 180 мілісекунд, але тепер має тривалість p99 понад три секунди для частини запитів. Першою помилкою було б запитувати в кожного інженера теорію, перш ніж домовитися про симптом. Кращий перший крок — підтвердити метрику, визначити, чи зросли помилки разом із затримкою, і сегментувати дані за безпечними вимірами, як-от маршрут, код статусу, namespace та версія застосунку. Це перетворює «кошик повільний» на експлуатаційно корисне твердження.

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

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

Тепер порівняйте цей ланцюжок доказів зі слабшим. Якби команда мала лише дашборди CPU, вона могла б помітити, що Pod’и інвентаризації використовують більше CPU, ніж зазвичай, і перезапустити їх, хоча CPU є наслідком повторних спроб, а не кореневою причиною. Якби команда мала лише сирі текстові логи, вона могла б шукати «timeout» по всіх сервісах і потонути в непов’язаних повідомленнях. Якби команда мала лише трейси без кореляції з логами, вона могла б знати, де було витрачено час, але не — чому залежність відмовила в роботі.

Той самий приклад також показує, чому важливі метадані власності сервісу. Коли спан інвентаризації з’являється в трейсі, черговий інженер має знати, яка команда ним володіє, який ранбук застосовується, який дашборд показує його метрики RED і які недавні розгортання його змінили. Без цих метаданих спостережуваність усе одно видає дані, але координація стає повільною. Високоякісна спостережуваність скорочує і технічний пошук, і людську передачу.

Семплування, термін зберігання та вартість — це проєктні рішення

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

Семплування найлегше зрозуміти на трейсах. Зберігання кожного трейсу для кожного запиту може бути корисним у малій лабораторії, але завантажений виробничий сервіс може генерувати набагато більше трейсів, ніж команда може зберегти чи дослідити. Семплування на основі заголовка (head-based) вирішує, чи зберегти трейс, на початку запиту, що просто, але може пропустити рідкісні відмови. Семплування на основі хвоста (tail-based) вирішує після того, як побачило результат запиту, що може зберегти повільні чи невдалі трейси, але потребує більшої місткості колектора та буферизації.

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

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

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

Що додає Kubernetes і чого не додає

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

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

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

Інша звичка — відрізняти готовність від справжньої якості сервісу. Проба готовності (readiness probe) повідомляє Kubernetes, чи має Pod отримувати трафік, але вона може не покривати кожну залежність чи бізнес-шлях. Сервіс може пройти перевірку готовності, тоді як один важливий маршрут відмовляє. Спостережуваність закриває цей розрив, вимірюючи реальні результати запитів, спани залежностей та помилки рівня застосунку. Готовність захищає маршрутизацію; спостережуваність захищає міркування.

Рівні зрілості спостережуваності

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

Рівень	Доступні сигнали	Що це уможливлює	Типовий розрив
1. Базовий моніторинг	Перевірки доступності, CPU, пам’ять, сирі логи контейнерів	Виявляти повні збої та очевидний тиск на ресурси	Часткові відмови та подорожі користувачів лишаються невидимими
2. Видимість сервісу	Метрики RED, структуровані логи, події Kubernetes, контекст розгортання	Окреслювати вплив за сервісом, маршрутом, версією та namespace	Міжсервісна причинність досі повільна
3. Корельована спостережуваність	Поширення трейсів, ідентифікатори трейсів у логах, обмежені мітки, метадані власності	Простежити один запит через сервіси та передати потрібній команді	Семплування, термін зберігання та чутливість даних потребують урядування
4. Система, що навчається	Симптомні оповіщення, бюджети помилок, виправлення інструментування після інцидентів, огляди вартості	Перетворювати повторювані невідомі невідомі на відстежувані відомі невідомі	Інструментарій може дрейфувати, якщо власники його не підтримують

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

Від реагування на інциденти до навчання

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

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

Для тих, хто вивчає KCNA, цей цикл навчання важливий, бо словниковий запас іспиту може звучати статично. Метрики, логи, трейси, RED, USE та золоті сигнали — це не картки, що плавають в ізоляції. Це інструменти у системі зворотного зв’язку, де виробничий досвід покращує наступний дизайн. Команда, яка ставиться до спостережуваності як до безперервного вдосконалення, поступово перетворюватиме невідомі невідомі на відомі невідомі, а потім кодуватиме найважливіші відомі невідомі як надійний моніторинг.

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

Огляд спостережуваності перед виробництвом

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

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

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

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

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

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

Є ще одна звичка, що відрізняє корисну спостережуваність від дорогої телеметрії: запишіть питання, перш ніж додавати сигнал. Якщо питання звучить «чи зачеплені клієнти», сигнал має вимірювати поведінку, видиму клієнтові. Якщо питання звучить «яка залежність повільна», сигнал має зберігати шлях запиту та хронометраж. Якщо питання звучить «чому ця операція зазнала невдачі», сигнал має нести безпечний локальний контекст. Ця дисципліна не дає командам збирати дані, бо вони доступні, і підштовхує їх збирати дані, бо вони змінюють рішення.

Патерни та антипатерни

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

Патерн	Коли його використовувати	Чому він працює	Міркування щодо масштабування
Симптомне оповіщення	Виклик людей для виробничих інцидентів	Воно прив’язує переривання до впливу на клієнта, а не до внутрішнього шуму	Тримайте метрики причин на дашбордах і посилайтеся на них з ранбуків оповіщень
Корельовані сигнали	Розслідування розподілених запитів	Спільні ідентифікатори трейсів і мітки сервісів з’єднують метрики, логи та трейси	Стандартизуйте назви полів між мовами та командами
Обмежені мітки метрик	Проєктування метрик у стилі Prometheus	Мітки низької кардинальності тримають сховище передбачуваним, а запити швидкими	Перемістіть факти високої кардинальності в логи, трейси чи екземпляри
Часові шкали з урахуванням розгортань	Налагодження після релізів	Анотації версій і розгортань розкривають, чи слідують симптоми за зміною	Автоматизуйте анотації з CI/CD, а не покладайтеся на пам’ять

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

Антипатерн	Що йде не так	Краща альтернатива
Театр дашбордів	Команди підтримують багато панелей, але не можуть відповісти на питання інциденту	Починайте з питань ранбука та будуйте лише ті погляди, що підтримують рішення
Виклик лише за причинами	Оповіщення CPU чи пам’яті будять людей, навіть коли користувачам добре	Викликайте за затримкою, помилками, доступністю чи спаленням бюджету помилок
Зламаний контекст трейсу	Шляхи запитів постають як роз’єднані спани	Забезпечуйте заголовки поширення та тестуйте інструментування на інтеграційних шляхах
Логування сирих корисних навантажень	Конфіденційні дані та шумні записи потрапляють у бекенд логів	Логуйте поля зі списку дозволених, санітизуйте значення та застосовуйте термін зберігання за класом даних

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

Помилка	Чому вона шкодить	Правильне розуміння
Використання лише одного стовпа	Неповна картина	Використовуйте всі три разом
Неструктуровані логи	Важко шукати	Використовуйте структуровані логи JSON
Забагато оповіщень	Втома від оповіщень	Оповіщайте про симптоми, а не причини
Непоширення контексту трейсу	Зламані трейси	Передавайте ідентифікатори трейсів між сервісами
Метрики високої кардинальності	Підриває вартість сховища	Використовуйте мітки з обмеженими значеннями
Оповіщення про внутрішні причини	Зайві пробудження	Оповіщайте про симптоми, видимі користувачеві
Логування конфіденційних даних	Порушення безпеки	Санітизуйте та маскуйте PII
Нескінченне зберігання метрик	Споживає дороге сховище	Знижуйте дискретизацію старіших метрик

Рамка ухвалення рішень

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

Питання рішення	Почніть з	Підтвердьте за допомогою	Уникайте
Чи зачеплені користувачі прямо зараз?	Метрики RED та перевірки доступності	Спалення бюджету помилок, розбивка за регіоном чи маршрутом	Починати з CPU та припускати вплив
Де запит уповільнюється?	Розподілений трейс для репрезентативного повільного запиту	Метрики сервісу для підозрюваного спана	Читати кожен лог сервісу по порядку
Чому цей сервіс відмовив локально?	Структуровані логи, відфільтровані за ідентифікатором трейсу та часом	Насичення ресурсів, помилки залежностей, події розгортання	Грепати неструктуровані логи по всіх Pod’ах
Чи має це когось будити?	Серйозність симптому та тривалість	Дієвість ранбука та вплив на бізнес	Викликати за кожним порогом метрики причини
Чи можемо ми дозволити собі цей сигнал?	Огляд кардинальності та терміну зберігання	Політика семплування, контроль доступу, оцінки сховища	Сприймати всі дані спостережуваності як безкоштовні

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

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

Чи знали ви?

Термін має коріння в теорії управління. Спостережуваність спочатку описувала, чи можна визначити внутрішній стан системи з її зовнішніх виходів, — концепція, що стала наново практичною для програмного забезпечення, коли розподілені системи унеможливили пряму інспекцію.
OpenTelemetry став проєктом CNCF у 2019 році (випустився, graduated, у 2026 році). Він об’єднав попередні зусилля OpenTracing та OpenCensus, щоб команди могли інструментувати метрики, логи та трейси, не прив’язуючи кожен застосунок до одного постачальника від самого початку.
Кардинальність може домінувати у вартості швидше за трафік. Одна мітка метрики з мільйонами можливих значень може створити мільйони часових рядів, навіть якщо застосунок видає лише одну назву лічильника.
Золоті сигнали SRE — це чотири погляди, орієнтовані на користувача. Затримка, трафік, помилки та насичення дають командам компактний спосіб моніторити сервіси, не вдаючи, що кожна внутрішня метрика заслуговує на виклик.

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

Помилка	Чому вона стається	Як її виправити
Сприйняття моніторингу та спостережуваності як синонімів	Дашборди відчуваються як доказ того, що система спостережувана	Тримайте дашборди для відомих невідомих, а для невідомих невідомих додавайте логи, трейси та поля кореляції
Оповіщення про CPU перед впливом на користувача	Метрики причин легко збирати та легко порогувати	Викликайте за симптомами, як-от затримка, помилки та доступність, потім посилайтеся на погляди CPU для діагностики
Додавання ідентифікаторів користувачів як міток метрик	Команди хочуть налагодження для кожного користувача з кожного інструмента	Тримайте мітки метрик обмеженими та розміщуйте ідентифікатори користувачів у санітизованих логах чи трейсах з контролем доступу
Залишення ідентифікаторів трейсів поза логами	Логування й трейсинг реалізуються різними бібліотеками чи командами	Стандартизуйте поля, щоб кожен лог помилки можна було об’єднати з трейсом і версією сервісу
Збір неструктурованого тексту логів	Розробники оптимізують для швидкого локального друку, а не для пошуку по всьому парку	Видавайте структуровані логи з узгодженими ключами, рівнями, позначками часу, назвами сервісів і безпечними ідентифікаторами
Забування контексту розгортання Kubernetes	Команда досліджує симптоми часу виконання, не перевіряючи недавніх змін	Додавайте анотації розгортань і мітки версій до метрик, логів, трейсів і часових шкал інцидентів
Зберігання конфіденційних даних у системах спостережуваності	Налагоджувальне логування фіксує корисні навантаження, заголовки чи секрети під час розробки	Використовуйте поля зі списку дозволених, редагування, обмеження терміну зберігання та обмежений доступ для бекендів спостережуваності

Тест

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

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

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

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

Розробник хоче додати `user_id` до `http_requests_total`, щоб підтримка могла досліджувати окремих клієнтів. Як би ви оцінили компроміси кардинальності та безпеки?

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

Ваш сервіс Kubernetes має метрики RED, але оповіщення досі будять команду через стрибки CPU, що не зачіпають користувачів. Як би ви спроєктували кращу практику оповіщення?

Тримайте CPU як діагностичну метрику, але припиніть використовувати її як основну умову виклику, якщо вона прямо не передбачає шкоди користувачам для цього сервісу. Краще оповіщення починається із симптомів, як-от висока частота помилок, висока тривалість запиту, невдалі перевірки доступності чи швидке спалення бюджету помилок протягом осмисленої тривалості. Оповіщення має посилатися на дашборди та кроки ранбука, що включають CPU, насичення, перезапуски Pod’ів і недавні розгортання для діагностики. Цей дизайн зменшує втому від оповіщень, бо людей переривають через проблеми, що потребують дії, а не через кожне внутрішнє коливання.

Трейс показує спан API-шлюзу та спан сервісу замовлень, але очікуваний спан сервісу оплати відсутній, хоча логи оплати існують. У чому ймовірна проблема і як команда має її виправити?

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

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

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

Огляд безпеки знаходить номери платіжних карток у централізованих логах, але розробники покладаються на логи для налагодження виробничих інцидентів. Що має змінитися?

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

Практична вправа: тріаж спостережуваності

У цій вправі ви — черговий інженер хмарної платформи електронної комерції, що працює на Kubernetes 1.35 чи новішої версії. Користувачі повідомляють, що кошик для покупок іноді не завантажується, і ваше завдання — перейти від симптому до ймовірної кореневої причини без здогадок. Якщо у вас є реальний кластер, визначте alias k=kubectl у вашій оболонці, перш ніж почати; якщо ви читаєте офлайн, сприймайте кожне завдання як вправу з проєктування ранбука та записуйте докази, які ви очікували б зібрати.

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

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

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

alias k=kubectl
k create namespace obs-lab
k -n obs-lab create deployment cart --image=nginx:1.25 --replicas=2
k -n obs-lab expose deployment cart --port=80 --target-port=80
k -n obs-lab label deploy,rs,pod,svc -l app=cart app.kubernetes.io/name=cart app.kubernetes.io/version=1.25 --overwrite
k -n obs-lab rollout restart deployment/cart
k -n obs-lab get deploy,rs,pods,svc -l app.kubernetes.io/name=cart
k -n obs-lab describe deployment cart
k -n obs-lab logs deploy/cart --tail=20
k -n obs-lab get events --sort-by=.lastTimestamp | tail -20
k -n obs-lab top pods

Якщо k top pods зазнає невдачі, зверніть увагу, що API метрик або metrics-server недоступні у вашій лабораторії, і продовжуйте з іншими доказами. Це спостереження саме по собі корисне: кластер без метрик ресурсів усе одно може показати стан об’єктів і логи, але він не може підтримати тріаж ресурсів у стилі USE лише за допомогою kubectl.

Завдання

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

Орієнтири для розв’язання

Один можливий шлях тріажу

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

Одне можливе твердження про кореневу причину

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

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

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

Джерела

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

Модуль 3.5: Інструменти спостережуваності — Prometheus, Grafana, Jaeger, OpenTelemetry та практичні вибори інструментів за сигналами спостережуваності, які ви вивчили тут.