Модуль 3.4: Основи спостережуваності
Складність:
[MEDIUM]- Концепції спостережуваностіЧас на виконання: 25-30 хвилин
Передумови: Модуль 3.3 (Хмарні нативні патерни)
Що ви зможете робити
Розділ «Що ви зможете робити»Після завершення цього модуля ви зможете:
- Пояснити три стовпи спостережуваності: логи, метрики та трейси
- Порівняти моніторинг (known-unknowns) зі спостережуваністю (unknown-unknowns)
- Визначити який сигнал спостережуваності використовувати для різних сценаріїв відлагодження
- Оцінити рівні зрілості спостережуваності та що кожен рівень дає операційним командам
Чому цей модуль важливий
Розділ «Чому цей модуль важливий»Не можна виправити те, чого не бачиш. Спостережуваність — це спосіб зрозуміти, що відбувається всередині ваших систем. Це особливо критично у розподілених системах, де налагодження складне. KCNA перевіряє ваше розуміння стовпів та практик спостережуваності.
Що таке спостережуваність?
Розділ «Що таке спостережуваність?»┌─────────────────────────────────────────────────────────────┐│ СПОСТЕРЕЖУВАНІСТЬ │├─────────────────────────────────────────────────────────────┤│ ││ Визначення: ││ ───────────────────────────────────────────────────────── ││ Здатність зрозуміти внутрішній стан системи ││ шляхом аналізу її зовнішніх виходів ││ ││ Моніторинг vs Спостережуваність: ││ ───────────────────────────────────────────────────────── ││ ││ МОНІТОРИНГ: ││ "Чи працює система?" ││ • Попередньо визначені метрики ││ • Відомі режими збоїв ││ • Дашборди та алерти ││ ││ СПОСТЕРЕЖУВАНІСТЬ: ││ "Чому система не працює?" ││ • Дослідження невідомих проблем ││ • Налагодження нових проблем ││ • Розуміння поведінки системи ││ ││ Моніторинг є підмножиною спостережуваності ││ │└─────────────────────────────────────────────────────────────┘Три стовпи
Розділ «Три стовпи»┌─────────────────────────────────────────────────────────────┐│ ТРИ СТОВПИ СПОСТЕРЕЖУВАНОСТІ │├─────────────────────────────────────────────────────────────┤│ ││ ┌─────────────┐ ┌─────────────┐ ┌─────────────┐ ││ │ МЕТРИКИ │ │ ЛОГИ │ │ ТРЕЙСИ │ ││ │ │ │ │ │ │ ││ │ Числа │ │ Події │ │ Запити │ ││ │ у часі │ │ текст │ │ між │ ││ │ │ │ │ │ сервісами │ ││ │ "Скільки?" │ │ "Що?" │ │ "Де?" │ ││ └─────────────┘ └─────────────┘ └─────────────┘ ││ ││ Разом вони відповідають: ││ • Що відбувається? (метрики) ││ • Що саме сталось? (логи) ││ • Як це відбувалось між сервісами? (трейси) ││ │└─────────────────────────────────────────────────────────────┘Метрики
Розділ «Метрики»Метрики — це числові вимірювання у часі:
┌─────────────────────────────────────────────────────────────┐│ МЕТРИКИ │├─────────────────────────────────────────────────────────────┤│ ││ Що вимірюють метрики: ││ ───────────────────────────────────────────────────────── ││ • Частота запитів (запитів/секунду) ││ • Частота помилок (помилок/секунду) ││ • Тривалість (час відповіді) ││ • Насиченість (CPU %, памʼять %) ││ ││ Приклад метрики: ││ ───────────────────────────────────────────────────────── ││ http_requests_total{method="GET", status="200"} 1234 ││ │ │ │ ││ │ │ │ ││ назва метрики мітки/теги значення ││ ││ Часовий ряд: ││ ───────────────────────────────────────────────────────── ││ Значення ││ │ ││ 100├ ┌──┐ ││ │ ┌──┐│ │ ┌──┐ ││ 50├──┘ └┘ └───┘ └──┐ ││ │ └── ││ └─────────────────────────→ Час ││ ││ Типи метрик: ││ • Counter: Лише зростає (запити, помилки) ││ • Gauge: Зростає та зменшується (температура, памʼять) ││ • Histogram: Розподіл значень (кошики затримок) ││ • Summary: Статистичний розподіл (перцентилі) ││ │└─────────────────────────────────────────────────────────────┘Метод RED
Розділ «Метод RED»Для сервісів відстежуйте:
| Метрика | Опис |
|---|---|
| Rate (Частота) | Запитів на секунду |
| Errors (Помилки) | Невдалих запитів на секунду |
| Duration (Тривалість) | Час на запит |
Метод USE
Розділ «Метод USE»Для ресурсів відстежуйте:
| Метрика | Опис |
|---|---|
| Utilization (Використання) | % часу коли ресурс зайнятий |
| Saturation (Насиченість) | Робота в черзі/очікуванні |
| Errors (Помилки) | Кількість помилок |
Логи
Розділ «Логи»Логи — це записи подій з мітками часу:
┌─────────────────────────────────────────────────────────────┐│ ЛОГИ │├─────────────────────────────────────────────────────────────┤│ ││ Що фіксують логи: ││ ───────────────────────────────────────────────────────── ││ • Події застосунку ││ • Помилки та стеки викликів ││ • Аудиторські сліди ││ • Інформація для налагодження ││ ││ Приклад логу: ││ ───────────────────────────────────────────────────────── ││ 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) ││ │└─────────────────────────────────────────────────────────────┘Трейси
Розділ «Трейси»Трейси відстежують запити у розподілених системах:
┌─────────────────────────────────────────────────────────────┐│ РОЗПОДІЛЕНЕ ТРАСУВАННЯ │├─────────────────────────────────────────────────────────────┤│ ││ Проблема: Запит проходить через кілька сервісів ││ ───────────────────────────────────────────────────────── ││ Користувач → API Gateway → Order Service → Payment → БД ││ ││ Де сповільнення? Де збій? ││ ││ Рішення: Трейси ││ ───────────────────────────────────────────────────────── ││ ││ Trace: Повна подорож запиту ││ Span: Одна операція в межах trace ││ ││ 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 передається через усі сервіси ││ Кожен сервіс додає свій span ││ │└─────────────────────────────────────────────────────────────┘Термінологія трейсів
Розділ «Термінологія трейсів»| Термін | Опис |
|---|---|
| Trace | Повна подорож запиту (усі spanʼи) |
| Span | Одна операція в межах trace |
| Trace ID | Унікальний ідентифікатор trace |
| Span ID | Унікальний ідентифікатор span |
| Parent Span | Операція, що викликає |
| Поширення контексту | Передача trace ID між сервісами |
Поєднання стовпів
Розділ «Поєднання стовпів»┌─────────────────────────────────────────────────────────────┐│ ПОЄДНАННі МЕТРИК, ЛОГІВ, ТРЕЙСІВ │├─────────────────────────────────────────────────────────────┤│ ││ Сценарій: Користувачі повідомляють про повільну оплату ││ ││ 1. МЕТРИКИ показують проблему ││ ───────────────────────────────────────────────────── ││ Дашборд: checkout_duration_p99 = 5s (зазвичай 1s) ││ "Оплата повільна, але чому?" ││ ││ 2. ТРЕЙСИ визначають де ││ ───────────────────────────────────────────────────── ││ Trace показує, що payment service займає 4s ││ "Payment — вузьке місце, але чому?" ││ ││ 3. ЛОГИ пояснюють чому ││ ───────────────────────────────────────────────────── ││ Лог: "Connection pool exhausted, waiting for ││ connection to external payment gateway" ││ "Ага! Пул зʼєднань потребує налаштування" ││ ││ Шлях дослідження: ││ Метрики (виявити) → Трейси (знайти) → Логи (діагноз) ││ │└─────────────────────────────────────────────────────────────┘Алертинг
Розділ «Алертинг»┌─────────────────────────────────────────────────────────────┐│ АЛЕРТИНГ │├─────────────────────────────────────────────────────────────┤│ ││ Перетворення метрик на сповіщення ││ ││ ┌─────────┐ ┌─────────────┐ ┌─────────────┐ ││ │ Метрики │ → │ Правила │ → │ Сповіщення │ ││ │ │ │ алертів │ │ Slack/Page │ ││ │ │ │ "Якщо X > Y"│ │ │ ││ └─────────┘ └─────────────┘ └─────────────┘ ││ ││ Практики алертингу: ││ ───────────────────────────────────────────────────────── ││ ││ • Алертуйте за симптомами, не причинами ││ Погано: "CPU > 90%" ││ Добре: "Час відповіді > 500ms" ││ ││ • Уникайте втоми від алертів ││ Забагато алертів = ігнорувати їх усі ││ ││ • Дієві алерти ││ Якщо не можете діяти — не алертуйте ││ ││ • Рівні серйозності ││ Critical: Розбудіть когось ЗАРАЗ ││ Warning: Перевірте завтра ││ Info: Лише для інформації ││ │└─────────────────────────────────────────────────────────────┘Чи знали ви?
Розділ «Чи знали ви?»-
Походження терміну спостережуваність — Походить з теорії управління, де система є “спостережуваною”, якщо внутрішні стани можна визначити з зовнішніх виходів.
-
OpenTelemetry уніфікує спостережуваність — Він надає єдиний стандарт для метрик, трейсів та логів, замінюючи специфічну для постачальників інструментацію.
-
Кардинальність має значення — Мітки з високою кардинальністю (як ID користувача) у метриках можуть вибухнути витратами на зберігання. Будьте обережні з тим, що маркуєте.
-
4 золоті сигнали — Книга Google SRE рекомендує: затримку, трафік, помилки та насиченість як ключові метрики для будь-якого сервісу.
Поширені помилки
Розділ «Поширені помилки»| Помилка | Чому це шкодить | Правильне розуміння |
|---|---|---|
| Використовувати лише один стовп | Неповна картина | Використовуйте всі три разом |
| Неструктуровані логи | Важко шукати | Використовуйте структуровані JSON логи |
| Забагато алертів | Втома від алертів | Алертуйте за симптомами, не причинами |
| Не передавати trace контекст | Розірвані трейси | Передавайте trace ID між сервісами |
Тест
Розділ «Тест»-
Які три стовпи спостережуваності?
Відповідь
Метрики (числові вимірювання у часі), Логи (записи подій з мітками часу) та Трейси (шляхи запитів у розподілених сервісах). Разом вони забезпечують повну видимість поведінки системи. -
Яка різниця між trace та span?
Відповідь
Trace — це повна подорож запиту через усі сервіси. Span — це одна операція в межах цього trace. Один trace містить кілька spanʼів, що утворюють дерево операцій. -
Що таке метод RED?
Відповідь
Методологія моніторингу сервісів: Rate (запитів/секунду), Errors (невдалих запитів/секунду), Duration (час на запит). Зосереджується на симптомах, видимих користувачам. -
Чому варто використовувати структуроване логування?
Відповідь
Структуровані логи (формат JSON) є машинно-зчитуваними, легко шукаються та мають послідовний формат. Неструктуровані текстові логи складніше запитувати та аналізувати у масштабі. -
Як метрики, логи та трейси працюють разом?
Відповідь
Метрики виявляють проблеми (дашборд показує високу затримку), трейси знаходять проблеми (який сервіс повільний), логи пояснюють проблеми (яка помилка сталась). Дослідження йде від метрик → трейсів → логів.
Підсумок
Розділ «Підсумок»Спостережуваність:
- Розуміння внутрішнього стану із зовнішніх виходів
- Виходить за межі моніторингу (відомі проблеми)
- Дає змогу досліджувати невідомі проблеми
Три стовпи:
- Метрики: Числові дані у часі
- Логи: Записи подій з контекстом
- Трейси: Шляхи запитів між сервісами
Методи:
- RED: Rate, Errors, Duration (сервіси)
- USE: Utilization, Saturation, Errors (ресурси)
- 4 золоті сигнали: Затримка, трафік, помилки, насиченість
Найкращі практики:
- Використовуйте всі три стовпи разом
- Структуроване логування
- Алертуйте за симптомами
- Поширюйте trace контекст
Наступний модуль
Розділ «Наступний модуль»Модуль 3.5: Інструменти спостережуваності - Prometheus, Grafana, Jaeger та інші інструменти спостережуваності в Kubernetes.