Контейнеры и поды

Мониторинг контейнеров Docker в Наблюдателе начинается, как только в стек поставлен агент: он находит все контейнеры своего compose-проекта или поды своего namespace в Kubernetes и раз в 30 секунд присылает их состояние. Настраивать ничего не нужно — список, статусы, CPU, память, диск, сеть, перезапуски и падения появляются сами.

В этой статье — как читать страницу стека, карточку и страницу контейнера, откуда берутся статусы и инциденты и как увидеть, на каком диске сервера лежат данные базы.

#Страница стека

Стек открывается из проекта или по адресу https://app.nablserver.ru/stacks/<id>. В шапке:

• название стека, метка «Compose» или «Kubernetes» и общий статус;
• описание, имя compose-файла или кластер и namespace;
• серверы, на которых работает стек (если указаны);
• строка-сводка: сколько HTTP-проверок и сколько из них недоступно, сколько контейнеров или подов и почему у стека такой статус;
• кнопки «HTTP-проверку» (добавить проверку сайта), «Агент» и «Настройки стека».

Если кнопка «Агент» красная, агента в стеке ещё нет; жёлтая — вышла новая версия, красная с точкой — версия несовместима, агента нужно обновить.

Ниже — вкладки. Набор зависит от того, что подключено:

#Статусы стека

Статус стека — худший из трёх сигналов: HTTP-проверки, состояние контейнеров и свежие инциденты. Причина видна в строке-сводке, например «проблемы у 1 из 6: перезапуск 1» или «HTTP: 1 из 2 недоступно».

Контейнеры, о которых агент не сообщал больше 5 минут, в статус не входят: обычно это удалённые или пересозданные контейнеры. Штатно завершённые контейнеры (код 0, Completed) тоже не считаются проблемой. Если замолчал сам агент, стек получит «Остановлен», а если HTTP-проверки при этом в норме — «Частично»: приложение живо, но Наблюдатель его не видит.

#Вкладка «Контейнеры»: мониторинг контейнеров Docker

Контейнеры сгруппированы по сервисам compose-файла. Над списком — поиск по имени контейнера или сервиса, фильтры по статусу и по типу («App», «Database», «Cache», «Broker», «Worker», «Frontend», «Analytics» — тип угадывается по имени и образу) и переключатель «Плитки» / «Таблица». Кнопка обновления в шапке стека перечитывает список, рядом — сколько контейнеров показано из всех.

В карточке контейнера:

• имя сервиса и имя контейнера, опубликованные порты;
• статус и сигналы: Docker HEALTHCHECK, число перезапусков, код последнего завершения;
• CPU — в ядрах: 1.50 CPU — полтора ядра. Docker считает загрузку относительно одного ядра, поэтому проценты больше 100 — норма, а ядра читать проще;
• RAM — сколько памяти занимает контейнер;
• Диск — тома Docker плюс слой файловой системы контейнера. Размер томов обновляется раз в ~3 минуты. У контейнеров баз данных отдельно показан логический размер базы — агент спрашивает его у СУБД;
• Сеть — входящий и исходящий трафик;
• когда агент прислал последний снимок.

#Статусы контейнера

Если контейнер упал, на карточке видна причина: «Контейнер убит OOM-killer (нехватка памяти)», 137 без OOM — «Процесс принудительно завершён (SIGKILL)», 139 — «Segmentation fault (SIGSEGV)», 127 — «Команда не найдена (CMD/ENTRYPOINT)», 143 — «Остановлен SIGTERM (docker stop)».

#Вкладка «Поды»: Kubernetes

Для стека в Kubernetes вместо контейнеров — поды. Их можно смотреть «По контроллерам» (Deployment, StatefulSet и другие) или «Таблицей», фильтровать по статусу и типу. У группы видно, сколько подов готово, сумму CPU и памяти, перезапуски и ноды.

Статусы пода: «Работает», «Не готов» (не проходит проверку готовности), «Ожидание», «Ошибка», «Завершён», «Циклит» (CrashLoopBackOff), «Неизвестно».

CPU и память подов видны, если в кластере установлен metrics-server. Под, которого нет в кластере больше часа (например, после выкатки), пропадает из списка, но его инциденты остаются в журнале. Как поставить агента — в статье про Kubernetes.

#Страница контейнера

Клик по карточке открывает страницу контейнера (или пода). В шапке — статус, Docker HEALTHCHECK с числом неудачных проверок подряд, сервис, время работы, нода, число перезапусков и причина последнего завершения. В меню «Действия контейнера» есть «Удалить контейнер» — это удаляет из Наблюдателя запись о контейнере и всю его историю метрик, сам контейнер на сервере не трогается.

Три вкладки: «Метрики», «Консоль» и «Инциденты».

#Метрики контейнера

Период выбирается вверху: «Сейчас», «1 ч», «6 ч», «24 ч», «7 д» или свои даты. «Сейчас» — живой поток от агента раз в секунду; кнопками «Стоп» и «Запустить» его можно заморозить и продолжить. История метрик хранится 30 дней и показывается средними по отрезкам.

• CPU — в ядрах, а также «Docker CPU» в процентах и «Доля хоста» — какая часть всех ядер сервера занята;
• Память — «Используется», «Лимит» и «Доступно»;
• Сетевой I/O — приём и передача;
• Диск — чтение и запись (blkio);
• Процессы (PIDs);
• блок «Состояние» — образ, состояние Docker, диск (тома и слой), размер базы, нода, первое и последнее появление.

Для подов Kubernetes живого потока нет: кластер отдаёт потребление срезами раз в ~15 секунд, графики строятся по ним.

#Тома: на каком диске сервера лежат данные

Блок «Тома» показывает, куда смонтирован каждый том контейнера: том Docker, папка хоста, а в Kubernetes — PVC или emptyDir. Если стек связан с сервером, где стоит агент сервера, рядом с томом видно, на каком сервере и разделе лежат данные, сколько места занято и сколько свободно. Раздел, заполненный на 80% и больше, подсвечивается жёлтым, от 90% — красным. Для PVC во внешнем хранилище (Ceph, NFS) так и написано: «внешнее хранилище — не диск сервера».

Так видна цепочка «база тормозит, потому что на сервере кончается диск». Нужен агент 0.12 и связь стека с сервером: обычно Наблюдатель находит её сам, а вручную она задаётся в «Настройках стека», раздел «Серверы». Подробнее — в статье про серверы.

#Инциденты контейнера: OOM, падения, unhealthy, перезапуски

Вкладка «Инциденты» — журнал всего, что случалось с контейнером. Сюда попадает всё, независимо от правил уведомлений:

Журнал фильтруется по периоду («Всё время», «24 ч», «7 д», «30 д») и по типу. Клик по инциденту открывает его страницу: графики CPU, памяти и перезапусков вокруг момента сбоя, живая консоль контейнера, события стека и соседние инциденты за ±30 минут, а если сбой связан с ошибкой приложения — ссылка на неё во вкладке «Ошибки».

Журнал — для разбора. Уведомление в Telegram, MAX или на почту приходит, только если включено правило: в новом проекте уже включены правила на OOM, падение с ненулевым кодом, непройденный HEALTHCHECK или проверку готовности, CrashLoopBackOff пода и больше трёх перезапусков. Пороги по CPU и памяти контейнера добавляются в правилах уведомлений.

#Выкатки

Когда сервис запускается в новой версии — с новым образом, а с агентом 0.13 и с новой конфигурацией (переменные окружения, ConfigMap, compose-файл), — в ленте стека появляется событие «Выкатка» со списком сервисов. В Kubernetes выкатка новыми подами тоже засчитывается, простой перезапуск — нет. Событие имеет уровень «Инфо» и по умолчанию в каналы не уходит; включить можно в фильтре канала.

Разбирая сбой, сначала посмотрите во вкладке «События», не было ли выкатки прямо перед ним. Подробнее — в статье про ленту событий.

#Если контейнеров не видно

• Вкладки «Контейнеры» нет или она пустая. Агент не установлен или не вышел на связь — кнопка «Агент» в шапке покажет установку. Проверка подключения описана в статьях про Docker Compose и Kubernetes.
• У контейнера «Нет свежих данных». Агент перестал о нём сообщать: контейнер удалён, пересоздан под новым именем или агент остановлен.
• Видны не все контейнеры. Агент в Docker Compose видит только свой compose-проект. Для другого проекта на том же сервере нужен свой стек.
• Нет CPU и памяти у подов. В кластере нет metrics-server.

Всё это можно спросить и у ИИ-ассистента: «почему перезапускается api в prod», «у каких контейнеров кончается память» — он видит те же контейнеры, инциденты и тома.

#Что дальше

• Логи контейнеров онлайн
• Мониторинг сервера: CPU, память, диски
• Правила уведомлений
• Лента событий и инциденты