🥇Моніторинг кластера Kubernetes: загальний огляд та знайомство з Prometheus

Розглянемо концепцію моніторингу Kubernetes, познайомимося з інструментом Prometheus, поговоримо про аллертинг.

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

Матеріал статті - вичавка з відкритої лекції школи «Слерм». Якщо хочете пройти повне навчання - записуйтесь на курс з Моніторинг та логування інфраструктури в Kubernetes.

Що моніторять у кластері Kubernetes

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

Перейдемо до моніторингу на рівні кластера.

Control Plane компоненти: API, Scheduler та інші. Як мінімум, треба відстежувати, щоб API серверів або etcd було більше 0. Etcd вміє віддавати багато метриків: по дисках, на яких він крутиться, здоров'ю свого кластера etcd та інші.

Docker з'явився давно і про його проблеми всім добре відомо: безліч контейнерів породжують зависання та інші проблеми. Тому сам Docker як систему теж варто контролювати, хоча б на доступність.

dns. Якщо в кластері відвалиться DNS, то за ним відвалиться і весь сервіс Discovery, перестануть працювати звернення від подів до подів. У моїй практиці таких проблем не було, проте це не означає, що за станом DNS не слід стежити. Затримки в запитах та деякі інші метрики можна відстежувати CoreDNS.

Ingress. Потрібно контролювати доступність інгресів (у тому числі Ingress Controller) як вхідних точок у проект.

Основні компоненти кластера розібрали - тепер опустимося нижче, на рівень абстракцій.

Здавалося б, додатки запускаються в подах, отже, їх потрібно контролювати, але насправді немає. Поди ефемерні: сьогодні працюють одному сервері, завтра іншому; сьогодні їх 10, завтра 2. Тому просто піди ніхто не моніторить. У межах мікросервісної архітектури важливіше контролювати доступність програми загалом. Зокрема, перевіряти доступність ендпоінтів сервісу: чи хоч щось працює? Якщо додаток доступний, те, що відбувається за ним, скільки зараз реплік - це питання другого порядку. Стежити за окремими інстансами немає потреби.

На останньому рівні потрібно контролювати роботу самої програми, знімати бізнес-метрики: кількість замовлень, поведінку користувачів та інше.

Прометей

Найкраща система для моніторингу кластера – це Прометей. Я не знаю жодного інструменту, який може зрівнятися з Prometheus за якістю та зручністю роботи. Він чудово підходить для гнучкої інфраструктури, тому коли кажуть «моніторинг Kubernetes», зазвичай мають на увазі саме Prometheus.

Є кілька варіантів, як почати працювати з Prometheus: за допомогою Helm можна поставити звичайний Prometheus або Prometheus Operator.

Звичайний Prometheus. З ним все добре, але потрібно налаштовувати ConfigMap - по суті, писати текстові файли конфігурації, як ми робили раніше, до мікросервісної архітектури.
Prometheus Operator трохи розлогіше, трохи складніше за внутрішньою логікою, але працювати з ним простіше: там є окремі об'єкти, абстракції додаються до кластера, тому їх набагато зручніше контролювати та налаштовувати.

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

Prometheus добре інтегрований з Kubernetes: може звертатися до API Server і взаємодіяти з ним.

Prometheus популярний, тому його підтримує велика кількість додатків та мов програмування. Підтримка потрібна, так як у Prometheus свій формат метрик, і для його передачі необхідна або бібліотека всередині програми, або готовий експортер. І таких експортерів чимало. Наприклад, є PostgreSQL Exporter: він бере дані з PostgreSQL і конвертує їх у формат Prometheus, щоб Prometheus міг з ними працювати.

Архітектура Prometheus

Сервер Prometheus - Це серверна частина, мозок Prometheus. Тут зберігаються та обробляються метрики.

Метрики зберігає time series database (TSDB). TSDB — це окрема база даних, а пакет мовою Go, який вшитий в Prometheus. Грубо кажучи, все знаходиться в одному бінарі.

Не зберігайте дані в TSDB довго
Інфраструктура Prometheus не підходить для тривалого зберігання метриків. За умовчанням термін зберігання становить 15 днів. Можна це обмеження перевищити, але треба мати на увазі: чим більше даних ви зберігатимете в TSDB і чим довше це робитимете, тим більше ресурсів вона споживатиме. Зберігати історичні дані в Prometheus вважається поганою практикою.
Якщо у вас величезний трафік, кількість метрик обчислюється сотнями тисяч на секунду, краще обмежити їх зберігання за обсягом диска чи терміном. Зазвичай в TSDB зберігають гарячі дані, метрики буквально за кілька годин. Для більш тривалого зберігання використовують зовнішні сховища в базах даних, які дійсно для цього підходять, наприклад InfluxDB, ClickHouse і так далі. Більше хороших відгуків я бачив ClickHouse.

Prometheus Server працює за моделлю тягнути: сам ходить за метриками в ті ендпоінти, які ми йому передали Сказали: «ходи в API Server», і він раз на n-е кількість секунд туди ходить і забирає метрики.

Для об'єктів із короткою тривалістю життя (job або cron job), які можуть з'являтися між періодами скрапінгу, є компонент Pushgateway. У нього пушать метрики від короткострокових об'єктів: job піднявся, виконав дію, відправив метрики в Pushgateway і завершився. Через деякий час Prometheus у своєму ритмі сходить і забере ці метрики з Pushgateway.

Для налаштування повідомлень у Prometheus є окремий компонент. Alertmanager. І правила аллертингу – alerting rules. Наприклад, потрібно створювати alert у випадку, якщо API серверів 0. Коли подія спрацьовує, alert передається до alert manager для подальшого відправлення. У alert manager досить гнучкі налаштування роутингу: одну групу алертів можна відправляти в телеграм-чат адмінів, іншу в чат розробників, третю в чат інфраструктурників. Оповіщення можуть надходити в Slack, Telegram, на email та інші канали.

Ну і насамкінець розповім про кілер-фічу Prometheus. Виявлення. При роботі з Prometheus не потрібно вказувати конкретні адреси об'єктів для моніторингу, достатньо вказати їх тип. Тобто не треба писати «ось IP-адреса, ось порт — монітор», натомість потрібно визначити, за якими принципами знаходити ці об'єкти (цілі - Цілі). Prometheus сам, залежно від того, які об'єкти зараз активні, підтягує до себе потрібні та додає на моніторинг.

Такий підхід добре лягає на структуру Kubernetes, де теж все плаває: сьогодні 10 серверів, завтра 3. Щоб щоразу не вказувати IP-адресу сервера, один раз написали, як його знаходити — і Discovering це робитиме.

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

https://prometheus.io/docs/prometheus/latest/querying/basics/

Простой запрос

    container_memory_usage_bytes

Математические операции

    container_memory_usage_bytes / 1024 / 1024

Встроенные функции

    sum(container_memory_usage_bytes) / 1024 / 1024

Уточнение запроса

    100 - avg by (instance) (rate(node_cpu_seconds_total{mode="idle"}[5m]) * 100)

Веб-інтерфейс Prometheus

Prometheus має свій, досить мінімалістичний веб-інтерфейс. Підходить хіба що для дебога чи демонстрації.

У рядку Expression можна написати запит мовою PromQL.

У вкладці Alerts містяться правила алертів — alerting rules, і вони мають три статуси:

inactive — якщо алерт не активний, тобто по ньому все добре, і він не спрацював;
pending — це якщо алерт спрацював, але відправка ще не пройшла. Затримку встановлюють, щоб компенсувати блимання мережі: якщо протягом хвилини заданий сервіс піднявся, то тривогу бити доки не треба;
firing – це третій статус, коли алерт загоряється та надсилає повідомлення.

У меню Status знайдете доступ до інформації про те, що являє собою Prometheus. Там є перехід до цілей (targets), про які ми говорили вище.

Більш детальний огляд інтерфейсу Prometheus дивіться у лекції Слерм з моніторингу кластера Kubernetes.

Інтеграція з Grafana

У веб-інтерфейсі Prometheus ви не знайдете красивих та зрозумілих графіків, з яких можна зробити висновок про стан кластера. Щоб їх будувати, Prometheus інтегрують із Grafana. Виходять такі дашборди.