Метрики для моніторингу кластерів Kubernetes
Kubernetes — це система, де ресурси живуть недовго. Через це класичний моніторинг «по серверу» не працює. Спостереження ведеться на рівні системи.
При моніторингу дивляться на:
- Інфраструктуру
- Компоненти кластера (Control Plane)
- Поди та контейнери
- Застосунки всередині контейнерів
- Бізнес-процеси
Нумо дізнаватись детальніше!
Інфраструктурний рівень
Інфраструктурний рівень — це основа кластера. Тут живуть вузли, на яких працюють поди, і саме від їхніх ресурсів залежить стабільність усіх сервісів.
Що відстежуємо і чому це важливо?
CPU Usage
Якщо процесор завантажений понад норму, поди можуть зависати або працювати повільно. Важливо помітити це раніше, ніж користувачі відчують затримки.
Memory Usage
Брак пам’яті призводить до того, що поди вмирають з помилкою OOMKilled. Навіть невелика нестача може спричинити ланцюгові проблеми.
Disk I/O
Вузькі місця у введенні/виведенні даних сповільнюють роботу контейнерів і можуть уповільнити бази даних або логування.
Network I/O
Затримки у мережі впливають на взаємодію між подами та зовнішніми сервісами. Навіть стабільні сервіси можуть поводитися «повільно», якщо трафік не проходить нормально.
Інструменти
- kubectl top node дає швидкий огляд використання CPU та пам’яті на вузлах.
- Node Exporter + Prometheus дозволяють збирати детальніші метрики, бачити історію та тренди навантаження.
На що звертати увагу?
- Постійне високі значення CPU або пам’яті сигналізують про перевантаження.
- Раптові піки disk або network I/O можуть вказувати на проблеми з подами або зовнішніми залежностями.
- Своєчасне виявлення цих сигналів допомагає уникнути падінь подів і збоїв у роботі сервісів.
Control Plane (рівень кластера)
Це мозок Kubernetes. Він приймає рішення про розгортання подів, балансування навантаження, стан кластера. Якщо тут щось ламається, весь кластер починає «кульгати».
Основні компоненти
- API Server — приймає запити користувачів та сервісів. Якщо він зависає або обробляє запити повільно, команди kubectl або автоматичні процеси сповільнюються.
- Scheduler — вирішує, на який вузол запускати под. Затримки тут можуть призвести до того, що нові поди зависають у статусі Pending.
Controller Manager — стежить за станом подів, ReplicaSets, Deployment. Помилки тут можуть зупиняти автозаміщення впалих подів. - ETCD — ключове сховище конфігурацій і стану кластера. Проблеми з диском чи латентність записів можуть зруйнувати синхронізацію всього кластера.
Що відстежуємо і чому?
apiserver_request_duration_seconds
Показує, як швидко API Server обробляє запити. Висока latency — сигнал проблем із ресурсами або перевантаженням.
scheduler_e2e_scheduling_duration_seconds
Час, потрібний Scheduler для розподілу подів. Збільшення значень означає, що нові поди «застрягають».
etcd_disk_backend_commit_duration_seconds
Затримки записів у ETCD можуть спричинити неконсистентність стану кластера.
На що звертати увагу?
- Якщо API Server часто повертає 500 або 503, це прямий сигнал проблем.
- Повільне планування подів може бути наслідком вузьких місць у ресурсах або проблем з Scheduler.
- ETCD з високою latency або помилками запису — критична ситуація, яку потрібно вирішувати відразу.
Інструменти
- Prometheus + kube-state-metrics для збору метрик компонентів.
- Grafana для візуалізації та швидкого виявлення проблемних компонентів.
Поди та контейнери
Поди — це місця, де живуть твої сервіси. Контейнери в них споживають CPU, пам’ять, мережу. Якщо щось піде не так, це першим сигналізує про проблеми.
Що відстежуємо?
CPU і Memory Usage
Надмірне споживання може призвести до OOMKilled або уповільнення подів.
Рестарти подів
Часті рестарти сигналізують про помилки в контейнері або проблеми з ресурсами.
Статуси подів
- Pending — Kubernetes не може знайти вузол із потрібними ресурсами.
- Running — под активний, але варто перевірити readiness-probes і логи, щоб упевнитися, що сервіс справді працює.
- CrashLoopBackOff — контейнер падає під час запуску, система намагається його відновити.
- OOMKilled — контейнер завершився через перевитрату пам’яті.
Як відрізнити короткочасну проблему від системної?
Щоб зрозуміти, чи проблема випадкова, чи вже системна, подивись на масштаб і повторюваність. Один под, що впав один раз, — це, скоріш за все, просто тимчасова помилка, яка не потребує втручання.
Але якщо одночасно рестартує багато подів або вони зависають у статусі Pending — це вже сигнал про глибшу проблему: брак ресурсів, конфлікт у конфігурації чи збій у кластері.
У такому випадку варто копати глибше — перевірити вузли, планувальник і налаштування ресурсів.
Інструменти
- kubectl describe pod <ім’я> — швидко побачити статус, рестарти, причини падіння.
- Prometheus метрики для подів (container_cpu_usage_seconds_total, container_memory_usage_bytes) — для трекінгу ресурсів у часі.
Чому це важливо?
Стеження за подами та контейнерами дає ранні сигнали, що щось йде не так. Це допомагає запобігти масштабним збоям, перш ніж вони торкнуться користувачів або бізнес-процесів.
Застосунки всередині контейнерів
На цьому рівні стежимо не за тим, скільки CPU чи пам’яті споживає под, а за тим, як сам сервіс поводиться для користувача:
- Latency (час відповіді) — наскільки швидко сервіс обробляє запити.
- Error rate (кількість помилок) — відсоток невдалих запитів.
- Throughput (пропускна здатність) — скільки запитів обробляється за одиницю часу.
Навіщо це потрібно?
CPU і пам’ять покажуть, що сервіс робочий, але не скажуть, що він почав відповідати повільно або повністю завис. Кастомні метрики допомагають поєднати технічний стан із бізнес-показниками.
Користувацькі та бізнес-метрики
Kubernetes сам по собі нічого не знає про твої бізнес-процеси, тому важливо додавати власні метрики, які показують, як сервіс працює для юзерів:
- Активні користувачі
- Кількість замовлень або транзакцій
- Повідомлення або події
Навіщо це потрібно?
Такі метрики потрібні, щоб поєднати технічний моніторинг із реальною поведінкою користувачів. Вони показують, як технічні збої впливають на бізнес — наприклад, коли через помилку в сервісі падає кількість замовлень чи активних користувачів.
Такі дані дозволяють вчасно помічати проблеми, важливі не лише для інфраструктури, а й для продукту.
Крім того, бізнес-метрики стають основою для визначення SLI, SLO і SLA. Тобто вимірюваних показників і цілей, що описують якість сервісу з погляду юзера.
Що використовувати для моніторингу Kubernetes?
Prometheus + Grafana
База будь-якого моніторингу.
Prometheus збирає метрики з усіх компонентів кластера, а Grafana візуалізує їх на зручних дашбордах. Разом вони показують стан системи в реальному часі та історію змін.
Alertmanager
Працює поруч із Prometheus. Відправляє сповіщення у Slack, Telegram чи на пошту, коли метрики виходять за межі норми. Може групувати подібні події, щоб не засипати команду спамом.
Kube State Metrics, Node Exporter і cAdvisor
Збирають додаткові дані про стан об’єктів Kubernetes, вузлів і контейнерів.
- Node Exporter стежить за CPU, пам’яттю, диском.
- cAdvisor — за контейнерами.
- Kube State Metrics — за статусами подів, деплойментів, сервісів.
Loki та Tempo
Працюють у парі з Grafana для логів і трасування запитів. Завдяки цьому можна зв’язати метрики, логи та трейсинг в одну картину й швидше знаходити причини проблем.
Zabbix
Централізований моніторинг для інфраструктури та Kubernetes в тому ж числі. Збирає метрики з вузлів, мережі та сервісів, відстежує стан подів через Kubernetes API та дозволяє налаштовувати тригери та алерти.
Поради для моніторингу Kubernetes
- Збирай лише потрібні метрики
Не тягни все підряд — це перевантажує та ускладнює аналіз. Обери ключові показники: CPU, пам’ять, кількість подів, час відповіді сервісів, кількість помилок. - Встанови чіткі пороги сповіщень
Попередження мають бути релевантними. Якщо команда отримує сотню алертів за день, то не реагує вже ні на один. Краще мати кілька, але найкритичніших. - Пов’язуй технічні й бізнесові метрики
Проблема з API може виглядати незначною — поки не побачиш, що кількість замовлень впала на 20%. Моніторинг має показувати не лише що пішло не так, а і як це впливає на користувача. - Використовуй єдину точку спостереження
Об’єднай метрики, логи та трейсинг в одному інтерфейсі (наприклад, через Grafana). Коли вся інформація під рукою, аналізувати інциденти у рази простіше. - Переглядай дашборди регулярно
Моніторинг — це не раз налаштувати й забути. Кластери ростуть, архітектура змінюється, з’являються нові сервіси. Перевіряй, чи метрики досі релевантні.
Післяслово
Все, тепер ти можеш відчувати кластер «на дотик». Коли розумієш, що означає кожна метрика, ти перестаєш гасити пожежі й починаєш керувати стабільністю свідомо.
А підтягнути скіли завжди можна в ITEDU. Тобі буде цікаво: