Модуль 1.4: Основи Observability

Складність: [MEDIUM] — Критична навичка для експлуатації систем

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

Пререквізити: Базове розуміння розподілених систем

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

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

Пояснити три стовпи Observability (метрики, логи, трасування) та на які питання відповідає кожен із них
Розрізняти моніторинг («чи система зламана?») та Observability («чому вона зламана?»)
Описати, як Prometheus, Grafana та Loki працюють разом у типовому стеку Kubernetes
Спроектувати базові SLI/SLO для вебзастосунку та пояснити, чому вони важливіші за % доступності (uptime)

Чому це важливо

«Чи працює система?» — здається простим питанням. У розподілених системах, таких як Kubernetes, це не так. Застосунки охоплюють кілька Pod, вузлів та сервісів. Observability дає вам можливість зрозуміти, що відбувається всередині вашої системи, на основі її зовнішніх виводів. Без цього ви дієте наосліп.

Що таке Observability?

Observability — це здатність розуміти внутрішній стан системи шляхом аналізу її виводів.

┌─────────────────────────────────────────────────────────────┐
│              MONITORING vs OBSERVABILITY                    │
├─────────────────────────────────────────────────────────────┤
│                                                             │
│  MONITORING (Традиційний)                                   │
│  "Чи працює? Чи не гальмує?"                                │
│  - Заздалегідь визначені панелі (dashboards)                │
│  - Відомі сценарії збоїв                                    │
│  - Реактивний підхід: сповіщення при порушенні порогу       │
│                                                             │
│  OBSERVABILITY (Сучасний)                                   │
│  "Чому гальмує? Що змінилося?"                              │
│  - Дослідження довільних питань                             │
│  - Виявлення невідомих сценаріїв збоїв                      │
│  - Проактивний підхід: розуміння до того, як станеться збій │
│                                                             │
│  Ключова ідея: Monitoring каже ВАМ, ЩО не так               │
│               Observability пояснює ЧОМУ                    │
│                                                             │
└─────────────────────────────────────────────────────────────┘

Зупиніться та подумайте: Якщо новий мікросервіс розгорнуто, і він миттєво падає через непередбачений витік пам’яті, що буде кориснішим для діагностики першопричини: традиційний моніторинг чи сучасна Observability?

Три стовпи

┌─────────────────────────────────────────────────────────────┐
│              THREE PILLARS OF OBSERVABILITY                 │
├─────────────────────────────────────────────────────────────┤
│                                                             │
│  ┌─────────────┐  ┌─────────────┐  ┌─────────────┐        │
│  │   METRICS   │  │    LOGS     │  │   TRACES    │        │
│  │             │  │             │  │             │        │
│  │  Числа у    │  │  Події з    │  │  Запити між │        │
│  │  часі       │  │  текстом    │  │  сервісами  │        │
│  │             │  │             │  │             │        │
│  └──────┬──────┘  └──────┬──────┘  └──────┬──────┘        │
│         │                │                │                │
│         ▼                ▼                ▼                │
│  "CPU на 90%"    "Помилка: DB    "Запит тривав           │
│  "Ріст помилок    з'єднання       300ms: 150ms у          │
│   5xx"            втрачено"       сервісі A, 150ms        │
│                                   у сервісі B"            │
│                                                             │
│  КОЛИ вживати:   КОЛИ вживати:   КОЛИ вживати:           │
│  - Дашборди     - Відлагодження - Продуктивність        │
│  - Alerting      - Аудит         - Залежності            │
│  - Тренди        - Безпека       - Вузькі місця          │
│                                                             │
└─────────────────────────────────────────────────────────────┘

Метрики

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

Типи метрик

Counter (завжди зростає):
  - http_requests_total
  - errors_total
  - bytes_sent_total

Gauge (може зростати або зменшуватися):
  - temperature_celsius
  - memory_usage_bytes
  - active_connections

Histogram (розподіл):
  - request_duration_seconds
  - Показує затримки: p50, p90, p99

Prometheus (Стандарт)

# Prometheus збирає метрики, опитуючи (scraping) ендпоінти
# Ваш застосунок відкриває метрики за адресою /metrics

# Приклад виводу ендпоінту метрик:
# HELP http_requests_total Total HTTP requests
# TYPE http_requests_total counter
http_requests_total{method="GET",path="/api",status="200"} 1234
http_requests_total{method="POST",path="/api",status="500"} 12

# HELP request_duration_seconds Request latency
# TYPE request_duration_seconds histogram
request_duration_seconds_bucket{le="0.1"} 800
request_duration_seconds_bucket{le="0.5"} 1100
request_duration_seconds_bucket{le="1.0"} 1200

PromQL (Мова запитів)

# Кількість запитів на секунду за останні 5 хвилин
rate(http_requests_total[5m])

# Коефіцієнт помилок
sum(rate(http_requests_total{status=~"5.."}[5m]))
/
sum(rate(http_requests_total[5m]))

# 99-й перцентиль затримки
histogram_quantile(0.99, rate(request_duration_seconds_bucket[5m]))

Логи

Логи — це записи дискретних подій із міткою часу.

Структуровані vs Неструктуровані

НЕСТРУКТУРОВАНІ (важко парсити):
2024-01-15 10:23:45 ERROR Failed to connect to database: connection refused

СТРУКТУРОВАНІ (JSON, легко запитувати):
{
  "timestamp": "2024-01-15T10:23:45Z",
  "level": "error",
  "message": "Failed to connect to database",
  "error": "connection refused",
  "service": "api",
  "pod": "api-7d8f9-abc12",
  "trace_id": "abc123def456"
}

Рівні логування

Рівень	Коли використовувати
DEBUG	Детальна інформація для відлагодження (вимкнено в prod)
INFO	Нормальна робота, важливі етапи
WARN	Щось неочікуване, але придатне для відновлення
ERROR	Щось пішло не так, потребує уваги
FATAL	Застосунок не може продовжувати роботу

Логування в Kubernetes

# Перегляд логів
kubectl logs pod-name
kubectl logs pod-name -c container-name  # Для мульти-контейнерних Pod
kubectl logs pod-name --previous         # Логи після попереднього падіння
kubectl logs -f pod-name                 # Слідкувати (tail)
kubectl logs -l app=nginx                # За лейблом

У продакшн-середовищах логи надсилаються до централізованої системи. Популярні стеки:

ELK (Elasticsearch, Logstash, Kibana): Традиційний важковаговик для пошуку та аналізу тексту.
EFK (Elasticsearch, Fluentd, Kibana): Популярний Kubernetes-native варіант, де Logstash замінено на Fluentd.
Loki + Grafana: Рішення від Grafana, яке індексує лише метадані (лейбли), що робить його значно дешевшим і нативно інтегрованим із Prometheus.

Трасування (Traces)

Траси відстежують шлях запиту через кілька сервісів.

┌─────────────────────────────────────────────────────────────┐
│              DISTRIBUTED TRACE                              │
├─────────────────────────────────────────────────────────────┤
│                                                             │
│  User Request (trace_id: abc123)                           │
│  Загальний час: 500ms                                       │
│                                                             │
│  ├─ Frontend (100ms)                                       │
│  │   └─ Render page                                        │
│  │                                                          │
│  ├─ API Gateway (50ms)                                     │
│  │   └─ Auth check                                         │
│  │                                                          │
│  ├─ User Service (150ms)                                   │
│  │   ├─ Get user data (50ms)                              │
│  │   └─ Database query (100ms)  ← Повільно!                │
│  │                                                          │
│  └─ Order Service (200ms)                                  │
│      ├─ Fetch orders (50ms)                               │
│      └─ Cache lookup (150ms)   ← Також повільно!           │
│                                                             │
│  Траси відповідають на питання: "Чому цей запит повільний?" │
│  Відповідь: DB query в User Service + Cache в Orders       │
│                                                             │
└─────────────────────────────────────────────────────────────┘

Ключові концепції

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

Інструменти трасування

Jaeger: Проєкт CNCF, дуже популярний у середовищах Kubernetes.
Zipkin: Зріла система трасування, створена у Twitter.
OpenTelemetry: Сучасний стандарт для інструментарію коду та збору всіх телеметричних даних вендор-нейтральним способом.

Стек Observability

┌─────────────────────────────────────────────────────────────┐
│              TYPICAL KUBERNETES OBSERVABILITY STACK         │
├─────────────────────────────────────────────────────────────┤
│                                                             │
│  ЗБІР ДАНИХ                                                 │
│  ┌─────────────────────────────────────────────────────┐   │
│  │  Prometheus     Fluentd/      OpenTelemetry         │   │
│  │  (метрики)      Fluent Bit    (логи/траси)          │   │
│  └─────────────────────────────────────────────────────┘   │
│                          │                                  │
│                          ▼                                  │
│  ЗБЕРЕЖЕННЯ                                                 │
│  ┌─────────────────────────────────────────────────────┐   │
│  │  Prometheus    Elasticsearch   Jaeger/              │   │
│  │  (часові ряди) або Loki         Tempo                │   │
│  │                (логи)          (траси)              │   │
│  └─────────────────────────────────────────────────────┘   │
│                          │                                  │
│                          ▼                                  │
│  ВІЗУАЛІЗАЦІЯ                                               │
│  ┌─────────────────────────────────────────────────────┐   │
│  │                   GRAFANA                            │   │
│  │  - Дашборди для всіх трьох стовпів                  │   │
│  │  - Єдине вікно моніторингу                          │   │
│  │  - Alerting                                         │   │
│  └─────────────────────────────────────────────────────┘   │
│                                                             │
└─────────────────────────────────────────────────────────────┘

Зупиніться та подумайте: Якщо Prometheus зберігає метрики, Loki — логи, а Tempo — траси, який компонент дозволяє інженеру легко перейти від сплеску затримки на графіку безпосередньо до логів саме цих повільних запитів?

Індикатори та цілі рівня сервісу (SLIs/SLOs)

«% доступності» часто вводить в оману. Якщо ваше API технічно «працює», але відповідь триває 30 секунд, користувачі від нього відмовляться. Site Reliability Engineering (SRE) використовує SLI та SLO, щоб зосередитися на досвіді користувача.

SLI (Service Level Indicator): Прямий вимірюваний факт про поведінку сервісу. Приклад: Частка запитів HTTP GET, що повернули 200 OK протягом 100 мс.
SLO (Service Level Objective): Ваша ціль для SLI. Приклад: 99.9% запитів за останні 30 днів мають відповідати критеріям SLI.
SLA (Service Level Agreement): Бізнес-контракт, що визначає фінансові штрафи у разі невиконання SLO. Інженери зосереджені насамперед на SLI та SLO.

Kubernetes-Native метрики

# Спочатку встановіть metrics-server (кластери kind не включають його за замовчуванням)
kubectl apply -f https://github.com/kubernetes-sigs/metrics-server/releases/latest/download/components.yaml
# Для kind/local кластерів виправте його для роботи без перевірки TLS:
kubectl patch deployment metrics-server -n kube-system --type=json \
  -p '[{"op":"add","path":"/spec/template/spec/containers/0/args/-","value":"--kubelet-insecure-tls"}]'
# Зачекайте ~60 секунд для початку збору метрик, потім:
kubectl top nodes
kubectl top pods

# Використання ресурсів
NAME          CPU(cores)   MEMORY(bytes)
node-1        250m         1024Mi
node-2        100m         512Mi

Ключові метрики Kubernetes

Метрика	Що вона каже
`container_cpu_usage_seconds_total`	Споживання CPU
`container_memory_usage_bytes`	Споживання пам’яті
`kube_pod_status_phase`	Стан життєвого циклу Pod
`kube_deployment_status_replicas_available`	Кількість здорових реплік
`apiserver_request_duration_seconds`	Затримка API server

Alerting

# Правило Prometheus AlertManager
groups:
  - name: kubernetes
    rules:
      - alert: PodCrashLooping
        expr: rate(kube_pod_container_status_restarts_total[15m]) > 0
        for: 5m
        labels:
          severity: warning
        annotations:
          summary: "Pod {{ $labels.pod }} перебуває у циклі перезавантаження"

      - alert: HighErrorRate
        expr: |
          sum(rate(http_requests_total{status=~"5.."}[5m]))
          /
          sum(rate(http_requests_total[5m])) > 0.05
        for: 5m
        labels:
          severity: critical
        annotations:
          summary: "Рівень помилок вище 5%"

Кращі практики сповіщень

Хороші сповіщення:
✓ Дієві (хтось може це виправити)
✓ Термінові (потребують негайної уваги)
✓ Не зашумлені (мало хибних спрацювань)
✓ Базуються на порушеннях SLO

Погані сповіщення:
✗ "CPU на 80%" (і що? Це впливає на користувачів?)
✗ Кожен перезапуск Pod (в K8s це іноді очікувано)
✗ Втома від алертов = ігнорування сповіщень

Золоті сигнали

Книга SRE від Google визначає чотири золоті сигнали:

┌─────────────────────────────────────────────────────────────┐
│              ЧОТИРИ ЗОЛОТІ СИГНАЛИ                          │
├─────────────────────────────────────────────────────────────┤
│                                                             │
│  1. LATENCY (Затримка)                                      │
│     Час обслуговування запиту                               │
│     "Як довго тривають запити?"                             │
│                                                             │
│  2. TRAFFIC (Трафік)                                        │
│     Попит на вашу систему                                   │
│     "Скільки запитів на секунду?"                           │
│                                                             │
│  3. ERRORS (Помилки)                                        │
│     Частота невдалих запитів                                │
│     "Який відсоток запитів падає?"                          │
│                                                             │
│  4. SATURATION (Насиченість)                                │
│     Наскільки сервіс "заповнений"                           │
│     "Наскільки ми близькі до межі ресурсів?"                │
│                                                             │
│  Якщо ви добре відстежуєте ці чотири речі, ви помітите     │
│  більшість проблем до того, як їх відчують користувачі.     │
│                                                             │
└─────────────────────────────────────────────────────────────┘

Реальна історія: Тихе затемнення

Уявіть сервіс оплати інтернет-магазину в Чорну п’ятницю. Раптово завантаження CPU бази даних підскочило до 100%. Традиційна система моніторингу спрацювала на «High CPU». Черговий інженер у паніці перезавантажив базу даних, але CPU миттєво підскочив знову. Тим часом тисячі клієнтів не могли завершити покупки.

З сучасною Observability:

Спочатку спрацьовує SLO alert: «Рівень успішних оплат впав нижче 99%».
Інженер відкриває Grafana dashboard і бачить, що золотий сигнал Traffic у нормі, але Latency злетіла.
Вони переглядають Trace (Jaeger) для повільного запиту оплати. Він показує, що PaymentService чекає 30 секунд відповіді від стороннього платіжного шлюзу.
Сплеск CPU бази даних був лише симптомом — потоки накопичувалися в черзі, чекаючи на шлюз, і блокували ресурси. Інженер швидко перемикає feature flag на резервний шлюз. Система миттєво відновлюється.

Observability не просто вказала на те, що сервер зайнятий; вона надала контекст, щоб відповісти ЧОМУ система не працювала.

Компроміси в Observability

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

Вартість vs Деталізація: Метрики високої роздільної здатності (збір щосекунди) дають неймовірну деталізацію, але експоненціально збільшують витрати на зберігання. Зменшення частоти старих метрик (downsampling) є важливим для довгострокового зберігання.
Логи vs Метрики: Логування кожного HTTP-запиту лише для підрахунку трафіку є обчислювально дорогим і витрачає величезну кількість дискового простору. Замість цього використовуйте метрики Prometheus для дешевого підрахунку подій, а логи залиште для важливих або вибіркових діагностичних даних.
100% трасування vs Семплювання: Трасування кожного запиту в архітектурі з високим навантаженням створює велике навантаження на мережу та сховище. Більшість зрілих систем впроваджують «head sampling» (трасування випадкових 1% запитів) або «tail sampling» (трасування лише тих запитів, що завершилися помилкою або великою затримкою).

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

Помилка	Чому це шкодить	Рішення
Неструктуровані логи	Неможливо ефективно запитувати або агрегувати; вимагає крихкого парсингу через regex.	Впроваджуйте структуроване логування в JSON у всіх застосунках.
Відсутність кореляції трас	Неможливо простежити шлях запиту через розподілені сервіси для пошуку першопричини.	Передавайте та логуйте Trace ID через усі межі сервісів.
Забагато сповіщень	Викликає «втому від алертов»; інженери перевантажуються і починають ігнорувати критичні попередження.	Налаштовуйте сповіщення суворо на симптоми, що бачать користувачі, та порушення SLO.
Перевантажені дашборди	Викликає інформаційний параліч під час інцидентів, коли швидкість діагностики критична.	Будуйте цілеспрямовані дашборди, зосереджені на Золотих сигналах.
Відсутність політики зберігання	Дані Observability ростуть експоненціально, що веде до витрат та повільних запитів.	Визначайте суворі TTL (Time to Live) та зменшуйте частоту старих даних.
Використання логів для метрик	Висока вартість обробки для підрахунку подій або швидкості через парсинг тексту.	Використовуйте лічильники (counters) та гістограми Prometheus замість парсингу логів.
Відсутність стандартних лейблів	Неможливо фільтрувати дані за середовищем, регіоном або версією застосунку.	Застосовуйте послідовні лейбли (наприклад, `env=prod`, `version=v1.2`) до всіх даних.

Чи знали ви?

Інженери Netflix можуть простежити шлях одного запиту через сотні мікросервісів. Їхня величезна інфраструктура Observability обробляє мільярди подій на секунду, щоб відтворення відео ніколи не зупинялося.
Термін «Observability» походить із теорії керування 1960-х років. Інженер Рудольф Е. Калман визначив систему як «спостережувану», якщо її внутрішній стан можна точно вивести, просто дивлячись на її зовнішні виводи.
Втома від сповіщень — реальна та небезпечна. Дослідження показують, що коли інженерні команди отримують забагато хибних або недієвих сповіщень, вони починають ігнорувати до 90% із них, ризикуючи пропустити катастрофічні збої.
Prometheus став другим проєктом, що завершив інкубацію (graduated) в Cloud Native Computing Foundation (CNCF), одразу після самого Kubernetes. Це підкреслює, наскільки фундаментальним є збір метрик для cloud-native архітектур.

Контрольні запитання

Сценарій: Ви розслідуєте раптовий сплеск помилок 500 Internal Server Error у вашому вебзастосунку. Ви знаєте точний час, але вам потрібно побачити конкретні stack traces, щоб зрозуміти помилку в коді. Який стовп Observability найбільш доречний тут?

Відповідь
Логи. Хоча метрики підказали вам, що рівень помилок зріс (симптом), саме логи містять детальні текстові записи подій із мітками часу. Перегляд логів за цей конкретний час покаже stack trace та точний контекст того, чому застосунок впав.
Сценарій: Користувач повідомляє, що натискання кнопки «Оформити замовлення» у вашій архітектурі з 15 мікросервісів займає понад 10 секунд. Проте дашборди окремих сервісів показують низьке завантаження CPU всюди. Яку концепцію Observability слід використати для пошуку вузького місця?

Відповідь
Розподілене трасування (Distributed Traces). Траси створені для відстеження одного запиту користувача, коли він проходить через кілька сервісів. Переглянувши трасу для повільного замовлення, ви зможете побачити, скільки мілісекунд було витрачено на кожен спан сервісу, і швидко зрозуміти, чи затримка спричинена повільним запитом до БД, API-викликом чи мережею.
Сценарій: Ваш менеджер хоче забезпечити максимальну доступність і пропонує створити критичне сповіщення кожного разу, коли завантаження CPU вузла бази даних перевищує 80%. Виходячи з принципів SLO, що ви порадите менеджеру?

Відповідь
Ви повинні порадити не робити цього, оскільки високий рівень CPU — це причина, а не симптом. Згідно з принципами SLO та Золотими сигналами, сповіщення мають базуватися на впливі на користувача, наприклад, на зростанні Latency або рівні помилок. База даних із 80% CPU може працювати ідеально ефективно без впливу на користувачів, тому таке сповіщення буде лише шумом, що викликає втому від алертов.
Сценарій: Ваш кластер Kubernetes генерує терабайт логів щодня, що призводить до величезних витрат. Ви виявляєте, що розробники записують логи для кожного HTTP-запиту лише для того, щоб підрахувати кількість звернень до ендпоінту. Яку архітектурну зміну ви б рекомендували?

Відповідь
Вам слід рекомендувати перейти від логів до метрик для підрахунку запитів. Створення та зберігання текстових логів для кожної події дуже неефективне. Замість цього розробники мають інкрементувати метрику-лічильник Prometheus (наприклад, `http_requests_total`). Метрики займають мінімум місця, оскільки вони агрегують числа з часом, а не зберігають окремі текстові записи.
Сценарій: Під час розбору інциденту команда зрозуміла, що черговому знадобилося 45 хвилин на діагностику, бо довелося вручну порівнювати мітки часу між дашбордом метрик та окремим терміналом із логами. Як сучасний стек Observability вирішує це?

Відповідь
Сучасний стек використовує єдиний рівень візуалізації, як-от Grafana, у поєднанні з кореляцією трас. Якщо розробники додають Trace ID у свої структуровані логи, Grafana дозволяє інженеру натиснути на сплеск на графіку метрик і миттєво перейти до логів та трас саме для цього часового вікна та запиту. Це усуває потребу в ручному порівнянні часу.
Сценарій: Ваша команда використовує SLI «відповіді HTTP 200 доставлені менш ніж за 200 мс» із ціллю SLO 99.9%. За останній місяць ви досягли лише 98%. Власник продукту наполягає на релізі великої нової фічі наступного тижня. Що має зробити команда?

Відповідь
Команда має зупинити розробку нових фіч і повністю зосередитися на виправленні надійності та продуктивності. Коли SLO порушено, це означає, що «бюджет на помилки» (error budget) вичерпано, і система занадто ненадійна для користувачів. Нові фічі несуть ризики, які можуть погіршити стан. Об’єктивність SLO допомагає вирішити суперечку між бізнесом та інженерією.
Сценарій: Молодший розробник пропонує логувати події безпеки так: [WARN] User bob@company.com failed login from IP 192.168.1.5. Чому цей підхід проблемний для масштабування і яка є альтернатива?

Відповідь
Це неструктуроване логування. Якщо аналітику потрібно підрахувати всі невдалі спроби входу з певного IP, йому доведеться писати складні та крихкі регулярні вирази. Альтернатива — структуроване логування (зазвичай JSON), де email та IP зберігаються як окремі поля: `{"level":"warn", "event":"failed_login", "user":"bob@company.com", "ip":"192.168.1.5"}`. Це дозволяє миттєво та надійно виконувати запити.

Практична вправа

Завдання: Дослідіть основи Observability в Kubernetes.

# 1. Розгорніть тестовий застосунок
kubectl create deployment web --image=nginx:1.25 --replicas=3
kubectl expose deployment web --port=80

# 2. Перегляньте логи
kubectl logs -l app=web --all-containers
kubectl logs -l app=web -f  # Слідкувати за логами

# 3. Перевірте використання ресурсів
# Спочатку встановіть metrics-server (якщо ще не зроблено):
kubectl apply -f https://github.com/kubernetes-sigs/metrics-server/releases/latest/download/components.yaml
kubectl patch deployment metrics-server -n kube-system --type=json \
  -p '[{"op":"add","path":"/spec/template/spec/containers/0/args/-","value":"--kubelet-insecure-tls"}]'
# Зачекайте ~60 секунд, потім:
kubectl top pods
kubectl top nodes

# 4. Зімітуйте проблему
# Масштабуйте до 0 (зламайте сервіс)
kubectl scale deployment web --replicas=0

# Перевірте події (події Kubernetes)
kubectl get events --sort-by='.lastTimestamp'

# 5. Перевірте статус Pod (базові метрики)
kubectl get pods -o wide
kubectl describe pod -l app=web

# 6. Згенеруйте логи
kubectl scale deployment web --replicas=1
kubectl exec -it $(kubectl get pod -l app=web -o name | head -1) -- \
  curl -s localhost > /dev/null

# Перегляньте логи доступу nginx
kubectl logs -l app=web | tail

# 7. Дослідіть за допомогою JSONPath (запити схожі на метрики)
kubectl get pods -o jsonpath='{range .items[*]}{.metadata.name}{"\t"}{.status.phase}{"\n"}{end}'

# 8. Очищення
kubectl delete deployment web
kubectl delete service web

Критерії успіху: Розуміння логів, подій та базового моніторингу ресурсів.

Підсумок

Observability — це про розуміння вашої системи:

Три стовпи:

Метрики: Числа у часі (Prometheus)
Логи: Записи подій (ELK, Loki)
Траси: Шлях запиту (Jaeger)

Золоті сигнали (що моніторити):

Latency (Затримка)
Traffic (Трафік)
Errors (Помилки)
Saturation (Насиченість)

Специфіка Kubernetes:

kubectl logs для логів Pod
kubectl top для метрик ресурсів
Events для активності кластера
Prometheus для комплексних метрик

Ключова ідея: Observability — це не просто моніторинг. Це здатність ставити будь-які запитання про вашу систему та отримувати відповіді.

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

Module 1.5: Platform Engineering Concepts — Побудова внутрішніх платформ для розробників.