Модуль 3.5: Інструменти спостережуваності

• Складність: [QUICK] — вибір інструментів і перша практика запуску
• Час на проходження: 40–55 хвилин
• Передумови: Модуль 3.4 (Основи спостережуваності), базові робочі навантаження Kubernetes та локальний кластер Kubernetes 1.35+ для необов’язкової практичної вправи
• Стиль команд: цей модуль використовує alias k=kubectl у прикладах для shell, щоб команди залишалися читабельними, але все одно запускали стандартний CLI Kubernetes

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

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

1. Діагностувати прогалини у спостережуваності, обираючи Prometheus, Grafana, Fluent Bit, Fluentd, Jaeger, Loki, Tempo або OpenTelemetry для конкретного симптому в кластері.
2. Порівняти підходи до збору метрик за моделями pull і push, зокрема визначити, коли доречний Prometheus Pushgateway.
3. Спроєктувати шлях збору телеметрії OpenTelemetry, який маршрутизує метрики, логи та трейси, не прив’язуючи код застосунку до одного бекенду.
4. Оцінити специфічні для Kubernetes сигнали від Metrics Server, kube-state-metrics та метрик застосунку під час налагодження поведінки кластера.

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

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

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

KCNA не вимагає, щоб ви як фахівець експлуатували кожен продукт спостережуваності. Він очікує, що ви розпізнаєте, який інструмент розв’язує яку проблему, чому Prometheus зазвичай витягує метрики замість того, щоб чекати, поки застосунки їх надішлють, чим Grafana відрізняється від сховищ даних, які вона візуалізує, чому Fluent Bit часто розгортають на кожній ноді та як OpenTelemetry зменшує постійну переробку інструментування між мовами й вендорами. Цей модуль перетворює перелік інструментів на операційну карту, щоб ви могли відповідати на екзаменаційні сценарії та робити обґрунтований вибір у реальному середовищі Kubernetes 1.35+.

Огляд стеку спостережуваності

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

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

┌─────────────────────────────────────────────────────────────┐
│              TYPICAL OBSERVABILITY STACK                    │
├─────────────────────────────────────────────────────────────┤
│                                                             │
│  ┌─────────────────────────────────────────────────────┐   │
│  │              VISUALIZATION                           │   │
│  │  ┌────────────────────────────────────────────────┐ │   │
│  │  │                 GRAFANA                         │ │   │
│  │  │  Dashboards for metrics, logs, traces          │ │   │
│  │  └────────────────────────────────────────────────┘ │   │
│  └─────────────────────────────────────────────────────┘   │
│                         │                                   │
│         ┌───────────────┼───────────────┐                  │
│         ▼               ▼               ▼                  │
│  ┌─────────────┐ ┌─────────────┐ ┌─────────────┐          │
│  │  METRICS    │ │   LOGS      │ │   TRACES    │          │
│  │             │ │             │ │             │          │
│  │ Prometheus  │ │ Loki        │ │ Jaeger      │          │
│  │ or          │ │ or          │ │ or          │          │
│  │ Mimir       │ │ Elasticsearch│ │ Tempo      │          │
│  └─────────────┘ └─────────────┘ └─────────────┘          │
│         ▲               ▲               ▲                  │
│         │               │               │                  │
│  ┌─────────────────────────────────────────────────────┐   │
│  │              COLLECTION                              │   │
│  │                                                      │   │
│  │  Metrics: Prometheus scrapes / OpenTelemetry       │   │
│  │  Logs: Fluentd / Fluent Bit / OpenTelemetry       │   │
│  │  Traces: OpenTelemetry / Jaeger agent             │   │
│  │                                                      │   │
│  └─────────────────────────────────────────────────────┘   │
│                         ▲                                   │
│                         │                                   │
│  ┌─────────────────────────────────────────────────────┐   │
│  │              APPLICATIONS                            │   │
│  │  [Pod] [Pod] [Pod] [Pod] [Pod] [Pod]              │   │
│  └─────────────────────────────────────────────────────┘   │
│                                                             │
└─────────────────────────────────────────────────────────────┘

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

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

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

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

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

Prometheus, метрики та оповіщення

Prometheus — це домінантна хмарна система метрик, бо вона зробила кілька принципових виборів, які пасують динамічній інфраструктурі. Замість того щоб вимагати від кожного застосунку знати, де живе сервер моніторингу, Prometheus виявляє цілі та зчитує їхні ендпоінти /metrics за розкладом. Ця pull-модель дає Prometheus незалежний погляд на живучість: якщо ціль зникає, зчитування зазнає невдачі, і система моніторингу може попередити про відсутність даних. Push-орієнтована система може випадково сховати мертву ціль, бо мертвий процес уже не присутній, щоб повідомити про свою смерть.

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

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

┌─────────────────────────────────────────────────────────────┐
│              PROMETHEUS                                     │
├─────────────────────────────────────────────────────────────┤
│                                                             │
│  CNCF Graduated project for metrics                       │
│                                                             │
│  Key characteristics:                                      │
│  ─────────────────────────────────────────────────────────  │
│  • Pull-based model (scrapes targets)                     │
│  • Time-series database                                    │
│  • PromQL query language                                  │
│  • AlertManager for alerting                              │
│                                                             │
│  How it works:                                             │
│  ─────────────────────────────────────────────────────────  │
│                                                             │
│  ┌─────────────────────────────────────────────────────┐   │
│  │                                                      │   │
│  │  ┌──────────┐                                       │   │
│  │  │Prometheus│ ──── scrape ────→ /metrics endpoint  │   │
│  │  │  Server  │                                       │   │
│  │  │          │ ←─── metrics ────  Target (Pod)      │   │
│  │  └──────────┘                                       │   │
│  │       │                                              │   │
│  │       ├──→ Store time series data                   │   │
│  │       ├──→ Evaluate alert rules                     │   │
│  │       └──→ Respond to PromQL queries               │   │
│  │                                                      │   │
│  └─────────────────────────────────────────────────────┘   │
│                                                             │
│  PromQL example:                                          │
│  ─────────────────────────────────────────────────────────  │
│  rate(http_requests_total[5m])                           │
│  "Requests per second over last 5 minutes"               │
│                                                             │
│  histogram_quantile(0.99, sum by (le) (rate(              │
│    request_duration_seconds_bucket[5m])))                │
│  "99th percentile latency"                               │
│                                                             │
└─────────────────────────────────────────────────────────────┘

Prometheus зберігає дані як часові ряди — це потужно, коли мітки обмежені, і небезпечно, коли мітки необмежені. Метрика на кшталт http_requests_total{status="500",method="POST",service="checkout"} залишається керованою, бо кожна мітка має невеликий набір значень. Метрика, яка містить ID користувача, ID сесії, ID замовлення чи сирий шлях URL, може створити новий ряд для кожної взаємодії клієнта. Це називають високою кардинальністю, і вона може вичерпати пам’ять задовго до того, як сам застосунок почне виглядати завантаженим.

Тип метрики важить так само, як її ім’я. Лічильники (counters) призначені для значень, які лише зростають, як-от загальна кількість запитів чи помилок, а функції PromQL на кшталт rate() перетворюють це постійно зростаюче число на тренд за секунду. Показники (gauges) призначені для значень, які можуть зростати й спадати, як-от глибина черги, поточна кількість з’єднань чи використання пам’яті. Гістограми групують спостереження у бакети, щоб команди могли оцінювати процентилі затримки, не зберігаючи кожен запит. Невірний вибір типу створює оманливі графіки навіть тоді, коли збір технічно працює.

Компонент	Призначення
Prometheus Server	Зчитує та зберігає метрики
AlertManager	Обробляє оповіщення, маршрутизацію, заглушення
Pushgateway	Для короткоживучих завдань (push метрик)
Exporters	Надають метрики від систем
Client libraries	Інструментують ваш код

Pushgateway — це виняток, який підтверджує правило pull-моделі. Він існує для пакетних завдань рівня сервісу, які виконуються коротко, успішно завершуються та зникають перш ніж Prometheus встигне надійно їх зчитати. Завдання перевірки резервної копії може надіслати свою фінальну метрику успіху до Pushgateway перед виходом, а Prometheus пізніше зчитує Pushgateway, як будь-яку іншу ціль. Це не загальний спосіб змусити довгоживучі сервіси надсилати метрики, бо тоді Prometheus втрачає простий сигнал «зчитування не вдалося», який повідомляє, що ціль вийшла з ладу.

Ключова фраза — пакетне завдання рівня сервісу, а не «будь-що короткоживуче». Якщо Job у Kubernetes представляє конкретну бізнес-активність на кшталт нічного узгодження, публікація фінальної метрики успіху чи тривалості може бути корисною. Якщо метрика представляє екземпляр машини, одноразовий Pod чи робочий процес, життєвий цикл якого вже видно в подіях Kubernetes, надсилання може створити застарілі ряди, які виглядають справними після того, як виробник зник. Розглядайте використання Pushgateway як проєктне рішення, що потребує семантики очищення, відповідальності та чітких міток.

Перед запуском будь-якого PromQL запитайте, яке рішення має підтримати цей запит. rate(http_requests_total[5m]) корисний, коли потрібна швидкість трафіку, тоді як histogram_quantile(0.99, sum by (le) (rate(request_duration_seconds_bucket[5m]))) корисний, коли найповільніший досвід користувачів важить більше за середній. Якщо оповіщення спрацьовує від одного миттєвого зразка, воно може коливатися під час звичайних сплесків. Якщо воно чекає надто довго, відповідальні дізнаються про біль клієнта вже після бізнесу. Мистецтво — обрати вікно, яке відповідає симптому та операційній дії.

Гіпотетичний сценарій: команда відстежує HTTP-запити, додаючи унікальний ID користувача як мітку Prometheus, що породжує зразки на кшталт http_requests_total{user_id="12345"}. Коли застосунок швидко зріс, Prometheus створив мільйони унікальних комбінацій міток, що означало мільйони часових рядів. Використання пам’яті зростало, поки Prometheus не впав, і збій моніторингу сховав збій застосунку. Виправленням був не більший дашборд, а кращий дизайн метрик, що використовував обмежені мітки на кшталт коду статусу, шаблону маршруту, методу та сервісу.

Метрики стають операційними лише тоді, коли вони з’єднані з оповіщеннями. Grafana вміє оповіщати, і багато команд це використовують, але екосистема Prometheus включає Alertmanager для групування, дедуплікації, заглушення та маршрутизації оповіщень. Ця різниця важить під час інциденту, бо десять оповіщень про одну збійну залежність мають стати одним дієвим викликом, а не десятьма незалежними перериваннями. Добре оповіщення зазначає вплив на клієнта, ймовірну відповідальність і перший запит, який треба виконати; погане оповіщення лише каже, що графік перетнув лінію.

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

Одне корисне ревізійне питання — чи називає оповіщення дію, якої воно очікує. «CheckoutErrorBudgetBurning» спрямовує відповідальних до впливу на клієнта та відповідальності за сервіс, тоді як «PodRestartsHigh» може потребувати, а може й не потребувати негайної дії залежно від поведінки робочого навантаження. Інфраструктурні оповіщення все ще потрібні, але їх слід прив’язувати до наслідку на кшталт втраченої ємності, погіршеної надмірності чи неминучої втрати даних. Prometheus і Alertmanager надають механізми; люди все одно мають закодувати, які симптоми заслуговують переривання.

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

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

Діаграма дашборда нижче зберігає ключову відмінність оригінального модуля. Grafana візуалізує та досліджує сигнали; вона не замінює Prometheus, Loki, Elasticsearch, Jaeger чи Tempo як системи зберігання. Це поширена пастка KCNA. Якщо питання запитує, який інструмент зберігає та робить запити до метрик часових рядів, відповідь — Prometheus. Якщо питання запитує, який інструмент надає дашборди по метриках, логах і трейсах, відповідь — Grafana. Якщо питання запитує, чому інженер може перейти від сплеску метрики до пов’язаних логів, не залишаючи браузер, відповідь — кореляція між джерелами.

┌─────────────────────────────────────────────────────────────┐
│              GRAFANA                                        │
├─────────────────────────────────────────────────────────────┤
│                                                             │
│  Visualization and dashboarding (not CNCF, but essential) │
│                                                             │
│  What Grafana does:                                        │
│  ─────────────────────────────────────────────────────────  │
│  • Create dashboards                                       │
│  • Query multiple data sources                            │
│  • Alerting (also has its own alerting)                   │
│  • Explore mode for ad-hoc queries                        │
│                                                             │
│  ┌─────────────────────────────────────────────────────┐   │
│  │  Dashboard: Application Overview                    │   │
│  │  ┌────────────────────────────────────────────────┐ │   │
│  │  │  Request Rate          Error Rate              │ │   │
│  │  │  ┌────────────┐        ┌────────────┐         │ │   │
│  │  │  │ ▂▃▅▇█▇▅▃▂ │        │ ▂▁▁▃▁▁▁▁▂ │         │ │   │
│  │  │  │  1.2k/s   │        │   0.5%    │         │ │   │
│  │  │  └────────────┘        └────────────┘         │ │   │
│  │  ├────────────────────────────────────────────────┤ │   │
│  │  │  Latency p99: 245ms   Active Pods: 5          │ │   │
│  │  └────────────────────────────────────────────────┘ │   │
│  └─────────────────────────────────────────────────────┘   │
│                                                             │
│  Data sources supported:                                  │
│  • Prometheus                                              │
│  • Loki (logs)                                            │
│  • Jaeger/Tempo (traces)                                  │
│  • Elasticsearch                                          │
│  • And many more...                                       │
│                                                             │
└─────────────────────────────────────────────────────────────┘

Логи відповідають на питання, які метрики навмисно стискають. Метрика може сказати, що сервіс оформлення замовлень повернув більше відповідей 500, але рядок логу може показати, що драйвер бази даних повідомив про «connection timeout» після зміни ліміту пулу. Kubernetes заохочує логування до stdout і stderr, бо середовище виконання контейнера може записувати ці потоки у файли на ноді, а агенти рівня ноди можуть збирати їх, не змінюючи кожен застосунок. Fluent Bit і Fluentd — поширені колектори на цьому рівні, причому Fluent Bit віддають перевагу, коли кожній ноді потрібен легкий агент.

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

┌─────────────────────────────────────────────────────────────┐
│              LOGGING TOOLS                                  │
├─────────────────────────────────────────────────────────────┤
│                                                             │
│  FLUENTD (CNCF Graduated)                                 │
│  ─────────────────────────────────────────────────────────  │
│  • Unified logging layer                                  │
│  • Collects from many sources                             │
│  • Routes to many destinations                            │
│  • Plugin ecosystem                                        │
│                                                             │
│  FLUENT BIT (CNCF Graduated, part of Fluentd)            │
│  ─────────────────────────────────────────────────────────  │
│  • Lightweight version of Fluentd                        │
│  • Lower resource usage                                   │
│  • Better for edge/resource-constrained                  │
│                                                             │
│  Typical flow:                                            │
│  ─────────────────────────────────────────────────────────  │
│  Container stdout → Fluent Bit → Elasticsearch/Loki     │
│                                                             │
│  LOKI (Grafana Labs)                                      │
│  ─────────────────────────────────────────────────────────  │
│  • Log aggregation system                                 │
│  • Designed to be cost-effective                         │
│  • Only indexes metadata (labels)                        │
│  • Pairs with Grafana                                     │
│                                                             │
│  ELK/EFK Stack:                                           │
│  ─────────────────────────────────────────────────────────  │
│  • Elasticsearch (storage)                               │
│  • Logstash/Fluentd (collection)                        │
│  • Kibana (visualization)                                │
│                                                             │
└─────────────────────────────────────────────────────────────┘

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

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

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

Трейсинг заповнює іншу прогалину: він супроводжує один запит крізь межі сервісів. У моноліті стек-трейс часто розповідає всю історію. У мікросервісах один запит на оформлення замовлення може пройти крізь інгрес-контролер, API-шлюз, сервіс кошика, сервіс платежів, сервіс протидії шахрайству та проксі бази даних, перш ніж користувач побачить результат. Трейс зберігає спільний trace ID і контекст span’ів через ці переходи, тож бекенд трейсингу може намалювати каскад, що показує, де накопичилася затримка або де виникла помилка.

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

┌─────────────────────────────────────────────────────────────┐
│              TRACING TOOLS                                  │
├─────────────────────────────────────────────────────────────┤
│                                                             │
│  JAEGER (CNCF Graduated)                                  │
│  ─────────────────────────────────────────────────────────  │
│  • End-to-end distributed tracing                         │
│  • Originally from Uber                                   │
│  • OpenTracing-compatible (historical); Jaeger v2 on OTel Collector │
│  • Service dependency analysis                            │
│                                                             │
│  Components (v1 legacy; v2 uses OTel Collector):           │
│  • Jaeger Client / OTel SDK (in your app)                │
│  • Jaeger Agent (per node — removed in Jaeger v2)        │
│  • Jaeger Collector                                       │
│  • Jaeger Query/UI                                        │
│                                                             │
│  TEMPO (Grafana Labs)                                     │
│  ─────────────────────────────────────────────────────────  │
│  • Cost-effective trace storage                          │
│  • Only stores trace IDs and spans                       │
│  • Integrates with Grafana                               │
│                                                             │
│  ZIPKIN                                                   │
│  ─────────────────────────────────────────────────────────  │
│  • One of the first distributed tracers                  │
│  • Originally from Twitter                               │
│  • Simple to set up                                      │
│                                                             │
└─────────────────────────────────────────────────────────────┘

Розгорнутий приклад: о 3:00 ночі оповіщення повідомляє HighErrorRate для сервісу платежів. У Grafana відповідальний підтверджує, що частота помилок різко зросла після розгортання, а потім фільтрує панелі Prometheus за простором імен і подом. Пов’язані логи Loki показують тайм-аути з’єднання від одного Pod’а платежів, а trace ID у лозі відкриває вигляд Jaeger, де span платежів проводить більшість часу в очікуванні на базу даних. Виправлення все ще може потребувати знання застосунку, але робочий процес спостережуваності перетворив розмитий виклик на конкретний шлях залежності.

Цей приклад також показує, чому «єдина панель скла» не має означати один недиференційований екран. Корисна частина — це спільний контекст: той самий часовий діапазон, простір імен, реліз, сервіс, под і trace ID можуть мандрувати між панелями та інструментами. Дашборд, що змішує непов’язані платформні графіки, бізнес-графіки та інфраструктурні графіки, може сповільнити відповідальних. Дашборд, що починається зі справності сервісу й веде назовні до сфокусованих логів і трейсів, дає відповідальним шлях замість стіни з графіків.

Зупиніться й передбачте: якщо ви розгорнете Fluent Bit як три репліки в Deployment на кластері з 20 нод, на яких нодах буде зібрано логи контейнерів? Відповідь — лише на тих нодах, куди потраплять ці три Pod’и, бо файли логів живуть у файловій системі кожної ноди. Саме тому агенти логів зазвичай працюють як DaemonSet’и. Патерн планування йде за розташуванням даних, а не за бажаною кількістю реплік.

OpenTelemetry як контракт інструментування

OpenTelemetry важить, бо вибір інструментів змінюється швидше, ніж мав би змінюватися код застосунку. До OpenTelemetry сервіс міг використовувати одну бібліотеку для метрик Prometheus, іншу для трейсів Jaeger та окрему конвенцію логування, що різнилася за мовою. Заміна бекенду могла вимагати торкання кожного сервісу, кожного середовища виконання та кожного конвеєра збірки. OpenTelemetry пропонує вендоронезалежні API, SDK, семантичні конвенції та Collector, тож команди можуть інструментувати код один раз і маршрутизувати телеметрію до бекенду, що пасує поточній платформі.

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

Конфігурацію Collector зазвичай описують як приймачі (receivers), процесори (processors), експортери (exporters) та конвеєри (pipelines). Приймачі беруть телеметрію від застосунків, агентів чи цілей зчитування. Процесори можуть пакетувати, фільтрувати, редагувати, додавати атрибути ресурсу чи семплувати телеметрію перш ніж вона залишить кластер. Експортери надсилають оброблені дані до одного чи кількох призначень. Конвеєри з’єднують ці частини для кожного типу сигналу, тож конвеєр метрик може поводитися інакше, ніж конвеєр трейсів, навіть коли обидва входять до того самого Collector.

┌─────────────────────────────────────────────────────────────┐
│              OPENTELEMETRY                                  │
├─────────────────────────────────────────────────────────────┤
│                                                             │
│  CNCF Graduated project - THE unified standard          │
│                                                             │
│  What it provides:                                         │
│  ─────────────────────────────────────────────────────────  │
│  • APIs for instrumenting code                            │
│  • SDKs for multiple languages                            │
│  • Collector for receiving/processing telemetry          │
│  • Unified protocol (OTLP)                               │
│                                                             │
│  ┌─────────────────────────────────────────────────────┐   │
│  │                                                      │   │
│  │  [App with OTel SDK] ──→ [OTel Collector] ──→      │   │
│  │                              │                      │   │
│  │                    ┌─────────┼─────────┐            │   │
│  │                    ▼         ▼         ▼            │   │
│  │              Prometheus   Jaeger    Loki            │   │
│  │              (metrics)   (traces)  (logs)          │   │
│  │                                                      │   │
│  └─────────────────────────────────────────────────────┘   │
│                                                             │
│  Why OpenTelemetry matters:                               │
│  ─────────────────────────────────────────────────────────  │
│  • Vendor neutral (switch backends easily)               │
│  • Single instrumentation for metrics+traces+logs        │
│  • Replaces OpenTracing and OpenCensus                  │
│  • Becoming the industry standard                        │
│                                                             │
└─────────────────────────────────────────────────────────────┘

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

Цей поділ відповідальності працює найкраще, коли платформа публікує невеликий контракт. Наприклад, кожен сервіс має задати ім’я сервісу, середовище, версію та простір імен; span’и HTTP мають використовувати стандартні семантичні атрибути; а логи мають містити кореляційне поле, яке за наявності може з’єднати їх із трейсами. Тоді платформа може будувати дашборди, політики зберігання та маршрути оповіщень навколо узгоджених метаданих. Без цього контракту OpenTelemetry все одно може збирати дані, але ці дані буде важко порівнювати між командами.

Уніфікований стандарт особливо цінний в організаціях зі змішаними мовами. Сервіс на Go, сервіс на Java та сервіс на Python можуть усі випромінювати span’и з узгодженими атрибутами на кшталт імені сервісу, методу HTTP, коду статусу та простору імен Kubernetes. Коли ці сервіси беруть участь в одному запиті, бекенд трейсингу може зшити span’и разом, бо контекст мандрує у стандартизованих заголовках. Перед запуском цього в реальному кластері запитайте, який результат ви б очікували, якщо один сервіс забуде поширити контекст трейса; трейс розколеться, і шлях залежності виглядатиме розірваним навіть тоді, коли мережа справна.

Для KCNA пам’ятайте, що OpenTelemetry — про інструментування та конвеєри телеметрії, а не просто ще один дашборд. Він доповнює Prometheus, Grafana, Jaeger, Loki, Tempo, Fluent Bit і Fluentd. У деяких розгортаннях він може збирати всі три типи сигналів; в інших він обробляє трейси та метрики, тоді як Fluent Bit досі обробляє файли логів рівня ноди. Сильна відповідь пояснює інтерфейс: застосунок чи агент випромінює телеметрію, Collector обробляє її, бекенд зберігає її, а інструменти візуалізації чи оповіщень допомагають людям діяти на її основі.

Історії міграцій — це місце, де цінність OpenTelemetry стає видимою. Компанія може почати з Jaeger, бо він знайомий, а пізніше обрати Tempo, бо він чисто інтегрується з її стеком на основі Grafana. Якби застосунки експортували напряму до специфічних для Jaeger клієнтів, ця міграція могла б вимагати посервісних змін коду й узгоджених релізів. Якщо застосунки використовують OpenTelemetry та експортують до Collector, міграцію можна провести поетапно: додавши другий експортер, перевіривши дані, перемкнувши дашборди й потім вивівши з експлуатації старе призначення.

Специфічні для Kubernetes сигнали спостережуваності

Kubernetes додає власний рівень сигналів, і відмінність між метриками ресурсів, станом об’єктів і поведінкою застосунку важлива для екзамену. Metrics Server постачає легкі метрики CPU та пам’яті, які використовують k top і Horizontal Pod Autoscaler. Це не історична база даних часових рядів, і це не заміна Prometheus. Він відповідає на негайні питання про ресурси на кшталт «скільки CPU цей Pod використовує зараз?», а не на питання на кшталт «якою була затримка p99 оформлення замовлення під час учорашнього релізу?».

kube-state-metrics експортує стан об’єктів Kubernetes як метрики Prometheus. Замість того щоб вимірювати CPU контейнера напряму, він повідомляє факти з API Kubernetes на кшталт бажаної кількості реплік, доступних реплік, фаз Pod’ів, умов нод і запитів на ресурси. Це цінно, бо багато збоїв є проблемами площини управління чи стану розгортання, а не сирими проблемами ресурсів. Deployment із бажаною кількістю реплік вісім і доступними репліками, що застрягли на трьох, розповідає іншу історію, ніж Deployment із вісьмома справними Pod’ами, що всі повертають помилки застосунку.

Ця відмінність запобігає поширеній помилці налагодження: трактуванню «Kubernetes справний» як того самого, що «сервіс справний». Kubernetes може планувати Pod’и, під’єднувати Сервіси та повідомляти готовність, поки застосунок повертає користувачам неправильну відповідь. І навпаки, застосунок може бути справним, але недостатньо забезпеченим ресурсами, бо планування, квота чи автомасштабування застрягли. Metrics Server, kube-state-metrics і метрики застосунку — це не конкурентні джерела істини. Це різні рівні однієї операційної картини.

┌─────────────────────────────────────────────────────────────┐
│              KUBERNETES OBSERVABILITY                       │
├─────────────────────────────────────────────────────────────┤
│                                                             │
│  Built-in Kubernetes metrics:                             │
│  ─────────────────────────────────────────────────────────  │
│                                                             │
│  METRICS SERVER                                           │
│  • Resource metrics (CPU, memory)                        │
│  • Used by kubectl top                                   │
│  • Used by HPA for autoscaling                          │
│                                                             │
│  KUBE-STATE-METRICS                                       │
│  • Kubernetes object state                               │
│  • Deployment replicas, Pod status, etc.                │
│  • Complements metrics server                            │
│                                                             │
│  Example queries:                                         │
│  ─────────────────────────────────────────────────────────  │
│                                                             │
│  # Pod resource usage                                     │
│  container_memory_usage_bytes{pod="my-app-xyz"}         │
│                                                             │
│  # Deployment availability                                │
│  kube_deployment_status_replicas_available               │
│  {deployment="frontend"}                                  │
│                                                             │
│  # Node conditions                                        │
│  kube_node_status_condition{condition="Ready"}           │
│                                                             │
└─────────────────────────────────────────────────────────────┘

Метрики застосунку доповнюють картину, вимірюючи поведінку, яку Kubernetes не може вивести. API-сервер може сказати вам, що Pod готовий (Ready), але він не може знати, чи відповідає ендпоінт оформлення замовлення цілі затримки 300 мс, якщо застосунок не надає цю метрику. Kubelet може повідомити про використання пам’яті, але він не може знати, що успішні спроби оплати впали після зміни функціонального прапора. Саме тому зрілі дашборди зазвичай поєднують справність кластера, стан робочого навантаження та індикатори рівня сервісу, замість того щоб трактувати готовність Kubernetes як сигнал справності бізнесу.

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

Ось компактний спосіб оцінити рівні під час налагодження. Якщо автомасштабування не вдається, спершу перевірте Metrics Server і події HPA, бо автомасштабувальник залежить від цього конвеєра. Якщо розгортання застрягло, огляньте kube-state-metrics або поля статусу Kubernetes, бо проблема може бути в плануванні, готовності, завантаженні образу чи доступності реплік. Якщо клієнти бачать помилки, поки Kubernetes виглядає справним, переключіться на метрики застосунку в Prometheus, логи та трейси, бо збій імовірно живе над рівнем оркестрації.

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

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

alias k=kubectl
k top pods -n monitoring
k get deploy -n monitoring
k describe hpa -n default

Налаштування alias вище — це лише ярлик shell, а не інший інструмент. Воно важить тут, бо сценарії KCNA часто використовують повне ім’я команди в тексті, тоді як практичні вправи KubeDojo використовують k, щоб повторювані команди залишалися читабельними. Коли ви бачите k get чи k top, читайте це як стандартний CLI Kubernetes проти кластера Kubernetes 1.35+. Якщо команда у вправі не вдається, питання усунення несправностей усе одно стосується стану Kubernetes, RBAC, просторів імен і встановлених компонентів, а не кастомної обгортки.

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

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

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

Патерн	Коли використовувати	Чому працює	Міркування щодо масштабування
Prometheus зчитує метрики застосунку та Kubernetes	Сервіси надають /metrics, існують exporter’и, або встановлено kube-state-metrics	Pull-збір дає незалежний сигнал відмови та пасує виявленню в Kubernetes	Тримайте мітки обмеженими та плануйте зберігання чи віддалене сховище до зростання кардинальності
Fluent Bit працює як DaemonSet	Логи stdout і stderr контейнерів живуть на кожній ноді	Один агент на ноду може читати локальні файли логів і слідувати за Pod’ами зі зміною планування	Задайте ліміти CPU й пам’яті, щоб логування не конкурувало з навантаженнями під час сплесків
OpenTelemetry Collector сидить між застосунками й бекендами	Командам потрібне вендоронезалежне інструментування чи узгодженість між мовами	Collector централізує пакетування, обробку, семплування та вибір експортерів	Розглядайте конфігурацію Collector як виробничий код і тестуйте зміни до розгортання
Grafana корелює кілька джерел даних	Відповідальним потрібні метрики, логи та трейси в одному шляху розслідування	Спільні фільтри й пов’язані панелі зменшують перемикання контексту під час інцидентів	Тримайте дашборди сфокусованими на рішеннях, а не на кожній метриці, яку стек може випромінити

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

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

Антипатерн	Що йде не так	Краща альтернатива
Трактування Metrics Server як заміни Prometheus	HPA і k top працюють, але немає історичної телеметрії застосунку	Використовуйте Metrics Server для метрик ресурсів, а Prometheus для моніторингу часових рядів
Маркування метрик ID користувачів чи ID запитів	Кардинальність часових рядів вибухає, а тиск на пам’ять Prometheus зростає	Використовуйте обмежені мітки на кшталт шаблону маршруту, коду статусу, методу та сервісу
Відправлення кожного поля логу до повнотекстового індексування за замовчуванням	Витрати на зберігання й індексування зростають швидше за цінність для налагодження	Індексуйте корисні мітки, обережно зберігайте структуровані поля та обирайте Loki чи Elasticsearch за потребами запитів
Розгортання колекторів без лімітів ресурсів	Сплеск телеметрії може заморити голодом Pod’и застосунку чи витіснити колектор	Задайте requests, limits, політики буферизації та очікування щодо зворотного тиску

Фреймворк прийняття рішень

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

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

Сценарій	Перший інструмент, до якого тягнутися	Наступний інструмент	Чому
HPA не масштабує завантажене навантаження	Metrics Server і події HPA	Метрики застосунку в Prometheus	HPA потребує метрик ресурсів чи кастомних метрик, а метрики застосунку пояснюють попит
Частота помилок зростає після релізу	Prometheus у Grafana	Логи Loki та трейси Jaeger чи Tempo	Метрики доводять тренд, логи й трейси локалізують збій
Job завершується до зчитування	Pushgateway	Правила оповіщень Prometheus	Короткоживучі завдання — валідний виняток для push, коли публікують фінальні метрики рівня сервісу
Командам із кількома мовами потрібні узгоджені трейси	OpenTelemetry SDK і Collector	Jaeger чи Tempo	Інструментування лишається стабільним, поки бекенди можуть змінюватися
Логи рівня ноди відсутні на деяких нодах	DaemonSet Fluent Bit	Планування й дозволи Kubernetes	Колектори мають працювати там, де існують файли логів
Дашборд зелений, але клієнти скаржаться	Метрики рівня сервісу в Prometheus	Трейси та логи	Справність Kubernetes не дорівнює бізнес-успіху

Для невеликого стартапу з кластером на п’ять нод стек у стилі PLG з Prometheus, Loki та Grafana може бути прагматичною відправною точкою, бо він тримає зберігання й операції відносно скромними. Elasticsearch лишається потужним, коли широкий повнотекстовий пошук — це жорстка вимога, але він часто вимагає більше пам’яті, планування шардів і операційного тюнінгу. Mimir і Tempo стають цікавими зі зростанням масштабу, коли командам потрібні горизонтально масштабовані Prometheus-сумісні метрики чи економне сховище трейсів. Правильний вибір — це найменший стек, що відповідає на поточні питання, залишаючи шлях міграції для майбутнього масштабу.

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

Коли ви порівнюєте інструменти на екзамені, шукайте контракт, яким володіє кожен інструмент. Prometheus володіє зчитуванням метрик, зберіганням, PromQL та оцінкою правил оповіщень. Grafana володіє візуалізацією та дослідженням між джерелами. Fluent Bit і Fluentd володіють збором і маршрутизацією логів. Jaeger і Tempo володіють зберіганням розподілених трейсів і робочими процесами запитів. OpenTelemetry володіє стандартами інструментування та конвеєрами Collector. Metrics Server і kube-state-metrics володіють видимістю ресурсів і стану об’єктів Kubernetes. Щойно ці контракти стають чіткими, більшість сценарних питань перетворюються на вправи на зіставлення з доданими операційними компромісами.

Який підхід ви б обрали тут і чому: команда має десять сервісів, жодного трейса та план перейти з Jaeger на Tempo наступного кварталу? Обґрунтована відповідь — інструментувати за допомогою OpenTelemetry та надсилати телеметрію через Collector, бо це уникає прив’язки коду застосунку до поточного бекенду трейсів. Вибір бекенду потім може змінюватися в конфігурації, тоді як семантичні конвенції та поширення контексту лишаються узгодженими між сервісами.

Чи знали ви?

• Prometheus отримав статус Graduated у CNCF у 2018 році після Kubernetes, що сигналізує, наскільки центральними стали метрики для хмарних операцій.
• OpenTelemetry було створено шляхом злиття OpenTracing та OpenCensus, щоб командам не доводилося мати конкурентні стандарти інструментування для схожих цілей телеметрії.
• Loki за дизайном індексує мітки, а не повний текст логів, що може знизити вартість зберігання й індексування, коли мітки обрано обережно.
• Metrics Server навмисно тримає вузьку роль: він обслуговує свіжі метрики ресурсів для автомасштабування та k top, а не довгостроковий аналіз спостережуваності.

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

Помилка	Чому трапляється	Як виправити
Надсилання всіх метрик сервісу напряму до Prometheus	Інженери припускають, що кожна система моніторингу отримує дані від застосунків	Дозвольте Prometheus зчитувати довгоживучі цілі та зарезервуйте Pushgateway для доречних короткоживучих завдань рівня сервісу
Використання Metrics Server як єдиного бекенду спостережуваності	k top працює, тож здається, що кластер охоплено метриками	Додайте Prometheus чи сумісну систему часових рядів для історії, метрик застосунку та правил оповіщень
Розгортання Fluent Bit як невеликого Deployment	Команди думають про колектори як про звичайні сервіси без стану	Запускайте колектори логів рівня ноди як DaemonSet, щоб логи контейнерів кожної ноди були досяжними
Створення дашбордів без відповідальності за оповіщення	Створення дашборда відчувається як завершення, навіть коли за ним ніхто не стежить	Визначте маршрути оповіщень, серйозність, runbook’и та заглушення для сигналів, що потребують дії
Додавання ID запитів чи ID користувачів як міток метрик	Розробники хочуть легкого занурення від метрик до окремих клієнтів	Розміщуйте ідентифікатори високої кардинальності в логах чи трейсах, а мітки Prometheus тримайте обмеженими
Трактування Grafana як бази даних метрик	Користувачі бачать графік у Grafana й припускають, що Grafana володіє даними	Навчіть розділяти візуалізацію, джерело даних, зберігання та збір
Встановлення OpenTelemetry без дизайну конвеєра	Команди приймають стандарт, але пропускають рішення про приймач, процесор, експортер і семплування	Проєктуйте конвеєри Collector явно й тестуйте маршрутизацію метрик, логів і трейсів до виробничого розгортання

Тест

Ваш сервіс оформлення замовлень показує різке зростання відповідей 500, але всі Pod'и готові (Ready), а CPU нод нормальний. Які інструменти ви б використали першими і які докази шукаєте?

Почніть із метрик Prometheus у Grafana, бо перше завдання — підтвердити тренд частоти помилок та ізолювати його за сервісом, маршрутом, статусом, простором імен і подом. Потім переключіться на логи через вивід Loki, Elasticsearch, Fluent Bit чи Fluentd, щоб знайти конкретні повідомлення про помилки навколо того самого часового вікна. Якщо сервіс є частиною ланцюга запитів, використайте трейси Jaeger чи Tempo, щоб побачити, де збійний запит сповільнився чи повернув помилку. Готовність Kubernetes і CPU — корисні сигнали, але вони не доводять, що запити бізнес-рівня є успішними.

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

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

Ваша організація має сервіси на Go, Java та Python, і платформна команда планує перенести трейси зі сховища Jaeger на Tempo пізніше. Який дизайн OpenTelemetry зменшує ризик переписування?

Інструментуйте кожен сервіс за допомогою API та SDK OpenTelemetry, потім надсилайте телеметрію до OpenTelemetry Collector, а не прив’язуйте код напряму до одного бекенду. Collector може маршрутизувати трейси до Jaeger сьогодні та Tempo пізніше, змінивши конфігурацію експортера. Він також може пакетувати, збагачувати, семплувати й узгоджено обробляти телеметрію для всіх мов. Цей дизайн тримає інструментування застосунку стабільним, поки платформа розвиває вибір сховища та візуалізації.

HPA не вдається масштабувати Deployment, тоді як Grafana досі показує зростання трафіку запитів застосунку. Які специфічні для Kubernetes сигнали ви маєте оцінити?

Спершу перевірте Metrics Server і статус HPA, бо HPA залежить від метрик ресурсів чи налаштованих кастомних метрик, щоб приймати рішення про масштабування. Використайте k describe hpa, щоб оглянути відсутні метрики, цільові значення та нещодавні події масштабування, потім перевірте k top pods, якщо метрики ресурсів мають бути доступні. kube-state-metrics також може показати стан бажаних і доступних реплік, коли розгортання чи проблема планування блокує ємність. Метрики застосунку в Prometheus пояснюють попит, але конвеєр автомасштабувальника пояснює, чому Kubernetes додав чи не додав реплік.

Команда розгортає Fluent Bit із трьома репліками на кластері з 20 нод і пізніше виявляє відсутні логи. Яка ймовірна помилка дизайну?

Ймовірна помилка — запуск колектора логів рівня ноди як Deployment замість DaemonSet. Файли логів контейнерів записуються на ноді, де працює кожен Pod, тож колектор має бути присутній на кожній ноді, яку слід спостерігати. Три репліки покривають лише три заплановані розташування, а Kubernetes може перемістити ці репліки під час обслуговування. DaemonSet робить намір планування таким, що відповідає розташуванню даних, запускаючи один Pod колектора на ноду.

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

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

Розробник хоче додати мітки `order_id` і `trace_id` до лічильника Prometheus, щоб знаходити окремі збої. Як ви маєте відповісти?

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

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

У цій вправі ви розгорнете стек Prometheus і Grafana в локальний кластер Kubernetes 1.35+, оглянете встановлені компоненти та зв’яжете вправу назад із рішеннями вибору інструментів із уроку. Команди використовують k після визначення alias k=kubectl, а потік зберігає мету оригінального модуля: побачити, як Prometheus, Grafana, Alertmanager і kube-state-metrics прибувають як один практичний стек моніторингу. Ви можете використати minikube чи kind, але приклади нижче припускають minikube для команд запуску й очищення.

• Крок 1: Запустіть локальний кластер, задайте alias і додайте Helm-репозиторій Prometheus.

  minikube start
  alias k=kubectl
  helm repo add prometheus-community https://prometheus-community.github.io/helm-charts
  helm repo update

  Нотатки до розв'язання

  Helm-репозиторій містить чарт kube-prometheus-stack, який використовується в цій вправі. Alias не змінює поведінку Kubernetes; він лише скорочує пізніші команди. Якщо minikube start не вдається, спершу полагодьте локальний кластер, бо Helm не може встановити в кластер, до якого немає доступу.

• Крок 2: Встановіть Kube-Prometheus Stack у виділений простір імен.

  helm install monitoring prometheus-community/kube-prometheus-stack --namespace monitoring --create-namespace

  Нотатки до розв'язання

  Цей чарт встановлює Prometheus, Grafana, Alertmanager, kube-state-metrics та допоміжні компоненти. Така широта корисна для навчання, бо ви можете оглянути кілька ролей спостережуваності одразу. У виробництві ви все одно переглянули б значення чарта, зберігання, маршрути оповіщень, облікові дані та запити на ресурси перш ніж вважати встановлення завершеним.

• Крок 3: Дочекайтеся, поки Pod’и моніторингу стануть готовими, та визначте їхні ролі.

  k get pods -n monitoring -w

  Нотатки до розв'язання

  Шукайте Pod’и, чиї імена містять Prometheus, Grafana, Alertmanager, operator і kube-state-metrics. Якщо Pod лишається в стані Pending, опишіть його (describe), щоб перевірити обмеження планування чи вимоги до сховища. Якщо Pod багаторазово перезапускається, огляньте логи й події перш ніж переходити до дашборда, бо рівень візуалізації залежить від базових сервісів.

• Крок 4: Зробіть port-forward до Grafana та відкрийте дашборд локально.

  k port-forward svc/monitoring-grafana 8080:80 -n monitoring

  Нотатки до розв'язання

  Відкрийте http://127.0.0.1:8080 у браузері. Типове ім’я користувача — admin, а типовий пароль для цього чарта зазвичай prom-operator, хоча значення за замовчуванням можуть змінюватися між релізами. Перейдіть до дашборда обчислювальних ресурсів Kubernetes і зв’яжіть побачене з уроком: Grafana — це рівень візуалізації, тоді як Prometheus і kube-state-metrics надають дані.

• Крок 5: Порівняйте метрики ресурсів, стан об’єктів і метрики, орієнтовані на застосунок.

  k top pods -n monitoring
  k get deploy -n monitoring
  k get svc -n monitoring

  Нотатки до розв'язання

  k top залежить від конвеєра метрик ресурсів, тоді як k get deploy показує стан об’єктів Kubernetes. Дашборди Grafana додають історичні вигляди Prometheus і панелі, похідні від kube-state-metrics. Мета вправи — не лише довести, що стек встановився; це практика розділення «використання ресурсів», «бажаного проти поточного стану» та «поведінки сервісу» під час читання даних спостережуваності.

• Крок 6: Очистіть локальний кластер, коли завершите.

  minikube delete

  Нотатки до розв'язання

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

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

• Ви можете пояснити, чому Prometheus встановлено як бекенд метрик, а Grafana як рівень візуалізації.
• Ви можете визначити, який встановлений компонент надає стан об’єктів Kubernetes для Prometheus.
• Ви можете розрізнити метрики ресурсів k top від історичних метрик Prometheus.
• Ви можете описати, чому Fluent Bit зазвичай працював би як DaemonSet, навіть якщо цей чарт зосереджено на метриках.
• Ви можете обрати, чи майбутній бекенд трейсингу має бути Jaeger чи Tempo, не змінюючи інструментування застосунку, коли використовується OpenTelemetry.

Джерела

• Огляд Prometheus
• Настанови щодо Prometheus Pushgateway
• Основи запитів Prometheus
• Документація Grafana
• Документація Grafana Loki
• Документація Fluentd
• Документація Fluent Bit
• Документація Jaeger
• Документація Grafana Tempo
• Документація OpenTelemetry
• Документація OpenTelemetry Collector
• Конвеєр метрик ресурсів Kubernetes
• Проєкт kube-state-metrics
• Helm-чарти спільноти Prometheus

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

Частину 3 завершено. Переходьте до Частини 4: Доставка застосунків, щоб з’єднати хмарну архітектуру з CI/CD, стратегіями розгортання та робочими процесами релізів, які допомагає захищати спостережуваність.