Rivalry2

HTML Diff

0 added 0 removed

Original 2026-01-01

Modified 2026-02-19

1 Тема мониторинга объёмная, за одну статью её не разобрать. Цель этого текста - дать обзорное представление по инструментарию, концепциям и подходам.Материал статьи - выжимка из <a>открытой лекции школы "Слёрм"</a>. Если хотите пройти полное обучение - записывайтесь на курс по <a>Мониторингу и логированию инфраструктуры в Kubernetes</a>.

2 <h2>Что мониторят в кластере Kubernetes</h2>

3 Физические серверы Если кластер Kubernetes развёрнут на своих серверах, нужно следить за их здоровьем. С этой задачей справляется Zabbix; если вы с ним работаете, то не нужно отказываться, конфликтов не будет. За состоянием наших серверов следит именно Zabbix.

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

5 Control Plane компоненты: API, Scheduler и другие. Как минимум, надо отслеживать, чтобы API серверов или etcd было больше 0. Etcd умеет отдавать много метрик: по дискам, на которых он крутится, по здоровью своего кластера etcd и другие.

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

7 DNS. Если в кластере отвалится DNS, то за ним отвалится и весь сервис Discovery, перестанут работать обращения от подов к подам. В моей практике подобных проблем не было, однако это не значит, что за состоянием DNS не нужно следить. Задержки в запросах и некоторые другие метрики можно отслеживать на CoreDNS.

8 Ingress. Нужно контролировать доступность ингрессов (в том числе Ingress Controller) как входных точек в проект.

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

10 Казалось бы, приложения запускаются в подах, значит их нужно контролировать, но на самом деле нет. Поды эфемерны: сегодня работают на одном сервере, завтра на другом; сегодня их 10, завтра 2. Поэтому просто поды никто не мониторит. В рамках микросервисной архитектуры важнее контролировать доступность приложения в целом. В частности, проверять доступность эндпоинтов сервиса: работает ли хоть что-то? Если приложение доступно, то что происходит за ним, сколько сейчас реплик - это вопросы второго порядка. Следить за отдельными инстансами нет необходимости.

11 На последнем уровне нужно контролировать работу самого приложения, снимать бизнес-метрики: количество заказов, поведение пользователей и прочее.

12 <h2>Prometheus</h2>

13 Лучшая система для мониторинга кластера - это <a>Prometheus</a>. Я не знаю ни одного инструмента, который может сравниться с Prometheus по качеству и удобству работы. Он отлично подходит для гибкой инфраструктуры, поэтому когда говорят "мониторинг Kubernetes", обычно имеют в виду именно Prometheus.Есть пара вариантов, как начать работать с Prometheus: с помощью Helm можно поставить обычный Prometheus или Prometheus Operator.

14 <ol><li>Обычный Prometheus. С ним всё хорошо, но нужно настраивать ConfigMap - по сути, писать текстовые конфигурационные файлы, как мы делали раньше, до микросервисной архитектуры.</li>

15 <li>Prometheus Operator чуть развесистее, чуть сложнее по внутренней логике, но работать с ним проще: там есть отдельные объекты, абстракции добавляются в кластер, поэтому их гораздо удобнее контролировать и настраивать.</li>

16 </ol>Чтобы разобраться с продуктом, я рекомендую сначала поставить обычный Prometheus. Придётся всё настраивать через конфиг, но это пойдёт на пользу: разберётесь, что к чему относится и как настраивается. В Prometheus Operator вы сразу поднимаетесь на абстракцию выше, хотя при желании покопаться в глубинах тоже будет можно.Prometheus хорошо интегрирован с Kubernetes: может обращаться к API Server и взаимодействовать с ним.

17 Prometheus популярен, поэтому его поддерживает большое количество приложений и языков программирования. Поддержка нужна, так как у Prometheus свой формат метрик, и для его передачи необходима либо библиотека внутри приложения, либо готовый экспортёр. И таких экспортёров довольно много. Например, есть PostgreSQL Exporter: он берёт данные из PostgreSQL и конвертирует их в формат Prometheus, чтобы Prometheus мог с ними работать.

18 <h2>Архитектура Prometheus</h2>

19 Prometheus Server - это серверная часть, мозг Prometheus. Здесь хранятся и обрабатываются метрики.Метрики хранит time series database (TSDB). TSDB - это не отдельная база данных, а пакет на языке Go, который вшит в Prometheus. Грубо говоря, всё находится в одном бинаре.

20 Не храните данные в TSDB долго

21 Инфраструктура Prometheus не подходит для длительного хранения метрик. По умолчанию срок хранения составляет 15 дней. Можно это ограничение превысить, но надо иметь в виду: чем больше данных вы будете хранить в TSDB и чем дольше будете это делать, тем больше ресурсов она будет потреблять. Хранить исторические данные в Prometheus считается плохой практикой.

22 Если у вас огромный трафик, количество метрик исчисляется сотнями тысяч в секунду, то лучше ограничить их хранение по объёму диска или по сроку. Обычно в TSDB хранят "горячие данные", метрики буквально за несколько часов. Для более долгого хранения используют внешние хранилища в тех базах данных, которые действительно для этого подходят, например InfluxDB, ClickHouse и так далее. Больше хороших отзывов я видел про ClickHouse.

23 Prometheus Server работает по модели pull: сам ходит за метриками в те эндпоинты, которые мы ему передали. Сказали: "ходи в API Server", и он раз в n-ое количество секунд туда ходит и забирает метрики.

24 Для объектов с короткой продолжительностью жизни (job или cron job), которые могут появляться между периодами скрапинга, есть компонент Pushgateway. В него пушатся метрики от краткосрочных объектов: job поднялся, выполнил действие, отправил метрики в Pushgateway и завершился. Через некоторое время Prometheus в своём ритме сходит и заберёт эти метрики из Pushgateway.

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

26 Ну и напоследок расскажу про киллер-фичу Prometheus - Discovering. При работе с Prometheus не нужно указывать конкретные адреса объектов для мониторинга, достаточно задать их тип. То есть не надо писать "вот IP-адрес, вот порт - мониторь", вместо этого нужно определить, по каким принципам находить эти объекты (targets - цели). Prometheus сам, в зависимости от того, какие объекты сейчас активны, подтягивает к себе нужные и добавляет на мониторинг.

27 Такой подход хорошо ложится на структуру Kubernetes, где тоже всё плавает: сегодня 10 серверов, завтра 3. Чтобы каждый раз не указывать IP-адрес сервера, один раз написали, как его находить - и Discovering будет это делать.

28 Язык Prometheus называется PromQL. С помощью этого языка можно доставать значения конкретных метрик и потом их преобразовывать, строить по ним аналитические выкладки.

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

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

31 container_memory_usage_bytes

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

33 container_memory_usage_bytes / 1024 / 1024

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

35 sum(container_memory_usage_bytes) / 1024 / 1024

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

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

38 <h2>Веб-интерфейс Prometheus</h2>

39 У Prometheus есть свой, довольно минималистичный веб-интерфейс. Подходит разве что для дебага или демонстрации.В строке Expression можно писать запрос на языке PromQL.

40 Во вкладке Alerts содержатся правила алертов - alerting rules, и у них есть три статуса:

41 <ol><li>inactive - если в данный момент алерт не активный, то есть по нему всё хорошо, и он не сработал;</li>

42 <li>pending - это в случае, если алерт сработал, но отправка ещё не прошла. Задержку устанавливают, чтобы компенсировать мигания сети: если в течение минуты заданный сервис поднялся, то тревогу бить пока не надо;</li>

43 <li>firing - это третий статус, когда алёрт загорается и отправляет сообщения.</li>

44 </ol>В меню Status найдёте доступ к информации о том, что из себя представляет Prometheus. Там же есть переход к целям (targets), о которых мы говорили выше.Более подробный обзор интерфейса Prometheus смотрите <a>в лекции Слёрм по мониторингу кластера Kubernetes</a>.<h2>Интеграция с Grafana</h2>

45 В веб-интерфейсе Prometheus вы не найдёте красивых и понятных графиков, из которых можно сделать вывод о состоянии кластера. Чтобы их строить, Prometheus интегрируют с Grafana. Получаются вот такие дашборды.Настроить интеграцию Prometheus и Grafana совсем несложно, инструкции найдёте в документации: <a>GRAFANA SUPPORT FOR PROMETHEUS</a>, ну а я на этом закончу.В следующих статьях мы продолжим тему мониторинга: поговорим про сбор и анализ логов с помощью Grafana Loki и альтернативных инструментов.

46 <h2>Может быть интересно:</h2>

47 <ul><li><a>Интенсив по Python для инженеров и разработчиков</a></li>

48 <li><a>Курс по GoLang для инженеров</a></li>

49 </ul>