Это бесплатный runbook к набору из 44 правил алертинга Prometheus с юнит-тестами, PrometheusRule для Kubernetes и примером Alertmanager. Сами правила — 790 ₽ в Telegram · все наборы · English version
Для каждого алерта из rules/*.yml ниже есть раздел с тем же именем. Ссылка runbook_url в алерте ведёт на заголовок раздела (имя алерта в нижнем регистре).
Формат раздела: что значит → частые причины → диагностика → как исправить → когда можно заглушить.
Общие правила:
rules/*.yml, а не игнорируйте его.Содержание: Linux-хосты · Docker · Kubernetes · Проверки сайтов
Что значит. Prometheus 3 минуты не может снять метрики с node-exporter (up == 0). Это не обязательно падение сервера: может не работать только exporter или сетевой путь до него.
Частые причины.
- сервер выключен, завис или перезагружается;
- сетевая проблема или правило файрвола между Prometheus и хостом (порт 9100);
- сервис node-exporter остановлен или упал;
- в scrape_configs указан неверный адрес.
Диагностика.
ping -c 3 <хост>
curl -sS -m 5 http://<хост>:9100/metrics | head
ssh <хост> 'systemctl status node_exporter --no-pager'
ssh <хост> 'journalctl -u node_exporter -n 50 --no-pager'
ssh <хост> 'uptime; dmesg -T | tail -n 30'
Название юнита зависит от способа установки (node_exporter, prometheus-node-exporter).
Как исправить. Если сервер недоступен — разбираться с хостингом/консолью гипервизора. Если жив только сам сервер, запустите exporter: systemctl restart node_exporter, проверьте файрвол (ss -ltnp | grep 9100).
Когда можно заглушить. На время плановых работ или вывода хоста из эксплуатации (лучше удалить цель из конфигурации Prometheus).
Что значит. На разделе осталось меньше 15% свободного места (учитывается место, доступное непривилегированным процессам). Реальных последствий ещё нет, но запас сокращается.
Частые причины. - рост логов без ротации; - накопление образов и слоёв Docker, дампов, бэкапов, кэшей пакетного менеджера; - рост базы данных; - удалённый файл, который держит открытым работающий процесс (место не освобождается).
Диагностика.
df -hT
du -xh --max-depth=1 / 2>/dev/null | sort -h | tail -n 15
du -xh --max-depth=1 /var 2>/dev/null | sort -h | tail -n 10
journalctl --disk-usage
docker system df # если на хосте есть Docker
lsof +L1 | head # удалённые, но открытые файлы
Как исправить. Настройте ротацию логов (logrotate, journalctl --vacuum-size=500M), удалите ненужное (apt clean / dnf clean all, docker image prune), перенесите данные на другой диск или расширьте том. Процессы с удалёнными открытыми файлами перезапустите.
Когда можно заглушить. Для разделов, которые заполняются штатно и очищаются самим приложением (например, кэш), — лучше исключить такой mountpoint в выражении правила. Временная заглушка допустима, если расширение диска уже запланировано.
Что значит. Свободно меньше 5% места на разделе. Запись данных в любой момент может начать падать с ошибками.
Частые причины. Те же, что у NodeDiskSpaceLow, но запас исчерпан: быстрый рост логов, зациклившееся приложение, пишущее в файл, переполнение базы.
Диагностика.
df -hT
du -xh --max-depth=2 / 2>/dev/null | sort -h | tail -n 20
ls -lhS /var/log | head
journalctl --disk-usage
docker system df
Как исправить. Быстро освободить место: усечь самый большой лог (: > /var/log/<файл>, а не rm, если файл открыт процессом), journalctl --vacuum-size=200M, docker system prune (внимательно читайте, что удалится), удалить старые бэкапы. Затем найдите источник роста и расширьте том.
Когда можно заглушить. Нельзя, пока место не освобождено. Исключение — раздел только для чтения или образ, не предполагающий свободного места (например, смонтированный iso/squashfs, если он не отфильтрован).
Что значит. По линейному тренду за последние 6 часов (predict_linear) место на разделе закончится в ближайшие 24 часа. Правило срабатывает только если свободно меньше 40%, чтобы не шуметь на больших пустых дисках.
Частые причины. - аномальный рост логов или БД; - запущенная выгрузка, бэкап или импорт данных; - утечка временных файлов.
Диагностика.
df -h <mountpoint>
du -xh --max-depth=2 <mountpoint> 2>/dev/null | sort -h | tail -n 20
find <mountpoint> -xdev -type f -mmin -60 -size +100M -exec ls -lh {} +
Сравните график node_filesystem_avail_bytes за последние 6–24 часа: рост равномерный или скачок.
Как исправить. Найти и остановить источник роста, добавить ротацию, расширить диск. Если запись одноразовая (импорт), оцените, хватит ли места до конца операции.
Когда можно заглушить. Если рост разовый и известен (миграция, импорт), а места заведомо хватит. Тогда поставьте заглушку на несколько часов, не на дни.
Что значит. Свободно менее 10% inodes на файловой системе. Когда они закончатся, создать новый файл будет нельзя, даже если место на диске есть (ошибка No space left on device при df -h с запасом).
Частые причины. Миллионы мелких файлов: сессии PHP, кэш, очередь почты, временные файлы, каталоги node_modules, старые ядра в /usr/src.
Диагностика.
df -i
for d in /var /tmp /home /usr; do echo "$d: $(find $d -xdev 2>/dev/null | wc -l)"; done
find /var -xdev -type d -size +1M 2>/dev/null | head # каталоги с огромным списком файлов
du -x --inodes --max-depth=2 /var 2>/dev/null | sort -n | tail -n 15
Ключ --inodes у du есть в GNU coreutils.
Как исправить. Удалите ненужные мелкие файлы в найденном каталоге (find <каталог> -type f -mtime +7 -delete, предварительно проверив список без -delete), настройте очистку кэша/сессий. Для ext4 число inodes задаётся при создании ФС — изменить его потом нельзя, только пересоздать ФС или перенести данные.
Когда можно заглушить. Для файловых систем с динамическим числом inodes (btrfs, xfs), если они дают ложные срабатывания, — исключите их из выражения.
Что значит. Доступно менее 10% оперативной памяти (по MemAvailable, то есть с учётом кэша, который ядро может отдать). Система ещё работает, но запас мал.
Частые причины. Утечка памяти в приложении, слишком много воркеров, рост кэша приложений (Redis, JVM), запуск тяжёлой задачи.
Диагностика.
free -h
ps aux --sort=-%mem | head -n 10
smem -tk 2>/dev/null | tail -n 15 # если установлен smem
docker stats --no-stream # если есть Docker
dmesg -T | grep -i -E 'oom|killed process' | tail
Как исправить. Найти процесс-потребитель, перезапустить при утечке, уменьшить число воркеров/размер кэша, добавить RAM. Для JVM проверьте -Xmx.
Когда можно заглушить. На серверах, где память намеренно занята под кэш (базы данных с большим shared_buffers и т.п.), но тогда лучше поднять порог в правиле под ваш профиль.
Что значит. Доступно менее 4% памяти: ядро скоро начнёт убивать процессы (OOM-killer), а система уйдёт в своп и тормоза.
Частые причины. Те же, что в NodeMemoryLow, но острее: резкая утечка, неожиданный всплеск нагрузки.
Диагностика.
free -h
ps aux --sort=-%mem | head -n 10
dmesg -T | grep -i -E 'out of memory|killed process' | tail
journalctl -k --since "1 hour ago" | grep -i oom
vmstat 1 5
Как исправить. Остановить или перезапустить главный потребитель, временно снять нагрузку, добавить память или swap как временную меру. Дальше — искать причину.
Когда можно заглушить. Нельзя, пока система не стабилизировалась.
Что значит. Используется более 80% swap (при условии, что swap настроен). Система вытесняет память на диск и работает медленно.
Частые причины. Нехватка RAM; один процесс с утечкой; слишком большой vm.swappiness в сочетании с давно неактивными страницами (в этом случае занятый swap может быть безвредным, но 80% — повод посмотреть).
Диагностика.
free -h
swapon --show
for f in /proc/*/status; do awk '/^Name|^VmSwap/{printf $2" "}END{print ""}' "$f"; done 2>/dev/null | sort -k2 -n -r | head
vmstat 1 5 # столбцы si/so — активный обмен
sysctl vm.swappiness
Как исправить. Освободить память (см. NodeMemoryLow). Если процессы лишь «пролежали» в swap без активного обмена (si/so около нуля), можно сбросить swap: swapoff -a && swapon -a — только когда RAM хватает на всё содержимое swap.
Когда можно заглушить. Если si/so нулевые и памяти достаточно, но swap заполнен давно-неактивными страницами.
Что значит. Средняя загрузка CPU по всем ядрам выше 90% в течение 15 минут.
Частые причины. Пик трафика, зациклившийся процесс, тяжёлый бэкап/сжатие/сборка, майнер после взлома, недостаток ядер под нагрузку.
Диагностика.
top -b -n 1 | head -n 15
ps aux --sort=-%cpu | head -n 10
pidstat 1 5 # пакет sysstat
docker stats --no-stream
Как исправить. Остановить виновника или ограничить (nice, cpulimit, лимиты cgroup/Docker), оптимизировать запросы, добавить ядер/узлов. Неизвестный процесс с высокой загрузкой проверьте на компрометацию.
Когда можно заглушить. Для хостов, предназначенных для пакетных расчётов, где 100% CPU — норма: исключите их или поднимите порог.
Что значит. Load average за 5 минут больше чем в 2 раза превышает число ядер в течение 15 минут. В load входят и процессы, ждущие CPU, и процессы в состоянии uninterruptible sleep (обычно ждут диск/NFS).
Частые причины. Перегрузка CPU, медленный диск или сеть (NFS), процессы в D-состоянии, слишком много параллельных задач.
Диагностика.
uptime
nproc
top -b -n 1 | head -n 15
ps -eo state,pid,cmd | awk '$1 ~ /D/' | head # процессы в D-состоянии
iostat -x 1 3
Как исправить. Если высокий %CPU — действуйте как в NodeCpuHigh; если много D-состояний — ищите проблему с диском/NFS, как в NodeIowaitHigh.
Когда можно заглушить. Если это известная пакетная нагрузка в нерабочее время.
Что значит. Процессор тратит более 30% времени на ожидание завершения дисковых операций. Диск (или сетевое хранилище) является узким местом.
Частые причины. Тяжёлые запросы к БД, бэкап/копирование, деградация диска или RAID, перегруженное облачное хранилище, активный swap, NFS недоступен.
Диагностика.
iostat -x 1 5 # пакет sysstat: смотрите %util и await
iotop -oPa # кто пишет/читает
vmstat 1 5 # столбцы wa, si, so
dmesg -T | grep -i -E 'i/o error|ata|nvme|blk_update' | tail
smartctl -H /dev/sda # пакет smartmontools
Как исправить. Остановить или ограничить виновника (ionice -c3), разнести нагрузку по дискам, оптимизировать запросы/индексы, заменить сбойный диск, увеличить IOPS у облачного тома.
Когда можно заглушить. На время запланированного бэкапа или перестроения RAID.
Что значит. На сетевом интерфейсе (кроме lo и veth*) более 1 ошибки приёма или передачи в секунду на протяжении 10 минут. Счётчик errs — это ошибки уровня драйвера/канала, а не обычные сбросы пакетов.
Частые причины. Плохой кабель или порт коммутатора, несовпадение duplex/скорости, проблемы с драйвером или виртуальной сетью на хостинге, перегруженный интерфейс.
Диагностика.
ip -s link show <интерфейс>
ethtool -S <интерфейс> | grep -i -E 'err|drop|crc|fifo'
ethtool <интерфейс> # скорость и duplex
dmesg -T | grep -i <интерфейс> | tail
Как исправить. Заменить кабель/порт, согласовать скорость/duplex, обновить драйвер или прошивку, обратиться к хостинг-провайдеру для виртуальных машин.
Когда можно заглушить. Для интерфейсов, не используемых в работе (например, служебные мосты): исключите их по метке device в выражении.
Что значит. Системные часы отличаются от эталонного времени более чем на 0.05 секунды (метрика ядра node_timex_offset_seconds) более 10 минут.
Частые причины. Не запущена служба синхронизации времени, недоступны NTP-серверы (блокировка UDP/123), виртуальная машина после паузы или миграции.
Диагностика.
timedatectl status
chronyc tracking && chronyc sources -v # если используется chrony
systemctl status chronyd systemd-timesyncd --no-pager
journalctl -u chronyd -u systemd-timesyncd -n 50 --no-pager
Как исправить. Запустить и включить службу синхронизации (systemctl enable --now chronyd или systemd-timesyncd), проверить доступность NTP-серверов, для принудительной подстройки — chronyc makestep.
Когда можно заглушить. На изолированных машинах без NTP, если точность времени не важна (лучше тогда отключить правило для этих хостов).
Что значит. Ядро сообщает, что часы не синхронизированы (node_timex_sync_status == 0) более 15 минут. Алерт может появиться и при небольшом смещении, пока ещё нет NodeClockSkew.
Частые причины. Те же, что и у NodeClockSkew; также — служба времени только что запущена и ещё не достигла синхронизации, либо вообще не установлена.
Диагностика.
timedatectl status # строка "System clock synchronized"
chronyc tracking
journalctl -u chronyd -u systemd-timesyncd --since "1 hour ago" --no-pager
Как исправить. Установить и включить NTP-клиент, открыть исходящий UDP 123 или указать доступные серверы в конфигурации (/etc/chrony.conf либо /etc/systemd/timesyncd.conf).
Когда можно заглушить. Для машин, намеренно работающих без синхронизации (лабораторные стенды).
Что значит. С момента последней загрузки хоста прошло менее 10 минут. Это информирующий алерт: он нужен, чтобы вы заметили неожиданные перезагрузки, которые иначе остаются незамеченными (хост снова виден, NodeDown не успевает сработать).
Частые причины. Плановое обновление ядра, аппаратный или гипервизорный сбой, kernel panic, OOM со сбросом, отключение питания, watchdog.
Диагностика.
uptime -s
last -x reboot shutdown | head
journalctl --list-boots | tail -n 5
journalctl -b -1 -n 100 --no-pager # конец предыдущей загрузки
systemctl --failed
Как исправить. Если перезагрузка плановая — ничего. Если нет — найдите причину в журнале предыдущей загрузки и убедитесь, что сервисы поднялись (systemctl --failed).
Когда можно заглушить. Во время запланированных обновлений с перезагрузкой.
Что значит. Метрики контейнеров с хоста не собираются: up == 0 для job cAdvisor в течение 3 минут. Пока алерт активен, остальные Docker-алерты на этом хосте не работают.
Частые причины. Контейнер cAdvisor остановлен, недоступен порт 8080, хост выключен, неверный адрес в scrape_configs.
Диагностика.
docker ps -a --filter name=cadvisor
docker logs --tail 50 cadvisor
curl -sS -m 5 http://<хост>:8080/metrics | head
ss -ltnp | grep 8080
Как исправить. Запустить контейнер (docker start cadvisor / docker compose up -d), проверить права монтирований (/, /var/run, /sys, /var/lib/docker), исправить адрес или файрвол.
Когда можно заглушить. На время обслуживания хоста или обновления cAdvisor.
Что значит. Контейнер присутствовал в метриках 5 минут назад, а сейчас cAdvisor его не видит. Алерт активен около 5 минут после исчезновения, затем гаснет сам, поэтому реагировать нужно быстро.
Частые причины. Контейнер остановлен (docker stop, exit), удалён при обновлении (docker compose up пересоздал его с новым ID), упал и не перезапустился (нет restart: always).
Диагностика.
docker ps -a --filter name=<имя>
docker inspect <имя> --format '{{.State.Status}} exit={{.State.ExitCode}} oom={{.State.OOMKilled}}'
docker logs --tail 100 <имя>
journalctl -u docker -n 50 --no-pager
Как исправить. Запустить контейнер (docker start <имя> или docker compose up -d), по логам понять причину остановки, при необходимости задать политику restart: unless-stopped.
Когда можно заглушить. При плановом удалении или переименовании контейнера. Для контейнеров, которые по замыслу живут короткое время (задачи), исключите их по метке name.
Что значит. За последние 15 минут контейнер запускался заново 3 раза и более (по изменению container_start_time_seconds). Процесс падает сразу после старта, а Docker его перезапускает.
Частые причины. Ошибка в конфигурации или переменных окружения, недоступная зависимость (БД, сеть), нехватка памяти (OOM), неверный образ или команда, отсутствующий файл или том.
Диагностика.
docker ps -a --filter name=<имя>
docker inspect <имя> --format '{{.State.ExitCode}} {{.State.OOMKilled}} {{.RestartCount}}'
docker logs --tail 200 <имя>
docker events --since 15m --filter container=<имя>
docker stats --no-stream <имя>
Как исправить. Исправить причину по последним строкам лога перед падением. Код выхода 137 обычно означает SIGKILL (в том числе OOM), 1 — ошибку приложения. Если причина в памяти — см. DockerContainerOomKilled.
Когда можно заглушить. При отладке на тестовом стенде. На production — нет.
Что значит. Контейнер упирается в заданный лимит CPU: более 25% периодов планировщика CFS были урезаны на протяжении 15 минут. Приложение замедляется, хотя на хосте CPU может быть свободен.
Частые причины. Слишком низкий --cpus / cpu_quota / deploy.resources.limits.cpus, рост нагрузки, многопоточное приложение, которому мало дробного лимита.
Диагностика.
docker stats --no-stream <имя>
docker inspect <имя> --format 'CPUs={{.HostConfig.NanoCpus}} quota={{.HostConfig.CpuQuota}} period={{.HostConfig.CpuPeriod}}'
docker top <имя>
NanoCpus в миллиардных долях ядра (1000000000 — это одно ядро), 0 означает отсутствие лимита.
Как исправить. Повысить лимит CPU, либо оптимизировать приложение, либо добавить реплик. Если лимит нужен «для порядка», подумайте о снятии ограничения и использовании cpu_shares.
Когда можно заглушить. Для фоновых контейнеров, которым троттлинг не мешает (задачи с низким приоритетом).
Что значит. Рабочий набор памяти контейнера (working_set) превышает 90% заданного лимита в течение 10 минут. Правило не срабатывает для контейнеров без лимита памяти.
Частые причины. Лимит выбран с недостаточным запасом, утечка памяти, рост нагрузки или кэша.
Диагностика.
docker stats --no-stream <имя>
docker inspect <имя> --format '{{.HostConfig.Memory}}'
docker exec <имя> sh -c 'cat /sys/fs/cgroup/memory.current /sys/fs/cgroup/memory.max 2>/dev/null'
docker logs --tail 100 <имя>
Файлы cgroup зависят от версии (v1/v2), поэтому команда может вернуть пусто.
Как исправить. Увеличить лимит, найти утечку (heap dump, профилирование), ограничить кэш приложения (maxmemory в Redis, -Xmx для JVM).
Когда можно заглушить. Если приложение намеренно использует всю выделенную память под кэш и вы это проверили.
Что значит. Ядро убило процесс контейнера из-за превышения лимита памяти: счётчик container_oom_events_total вырос за последние 10 минут.
Частые причины. Слишком малый лимит, утечка памяти, всплеск нагрузки, неверные настройки runtime (heap больше лимита контейнера).
Диагностика.
docker inspect <имя> --format 'OOMKilled={{.State.OOMKilled}} exit={{.State.ExitCode}} limit={{.HostConfig.Memory}}'
docker logs --tail 100 <имя>
dmesg -T | grep -i -E 'oom|killed process' | tail
docker stats --no-stream
Как исправить. Поднять лимит памяти, привести настройки приложения в соответствие с лимитом, исправить утечку. Следите за рестартами — DockerContainerRestartLoop.
Когда можно заглушить. Нельзя оставлять без внимания: OOM означает потерю процесса. Допустимо на тестовых стендах.
Команды ниже используют <ns> для namespace; добавляйте --context/-n под ваш кластер.
Что значит. Prometheus не может снять метрики с kube-state-metrics в течение 5 минут. Все алерты о Pod, Deployment, StatefulSet, DaemonSet, Job, HPA и узлах в этот период слепы.
Частые причины. Pod kube-state-metrics упал или переселяется, сетевая политика блокирует scrape, изменилось имя Service/ServiceMonitor, кончились ресурсы кластера.
Диагностика.
kubectl -n <ns> get pods -l app.kubernetes.io/name=kube-state-metrics
kubectl -n <ns> describe pod -l app.kubernetes.io/name=kube-state-metrics
kubectl -n <ns> logs -l app.kubernetes.io/name=kube-state-metrics --tail=100
kubectl -n <ns> get servicemonitor,endpoints | grep -i state-metrics
Как исправить. Устранить причину падения Pod (OOM, права RBAC, образ), вернуть ServiceMonitor/Service в рабочее состояние, при нехватке памяти поднять лимиты.
Когда можно заглушить. Во время обновления kube-prometheus-stack.
Что значит. Prometheus не получает метрики kubelet с узла 5 минут. Узел мог выйти из строя, либо kubelet остановился, либо нарушена сеть до порта 10250.
Частые причины. Узел выключен, kubelet упал, истёк сертификат kubelet, сетевая блокировка, узел удалён из кластера, но остался в targets.
Диагностика.
kubectl get nodes -o wide
kubectl describe node <узел>
ssh <узел> 'systemctl status kubelet --no-pager; journalctl -u kubelet -n 100 --no-pager'
Как исправить. Перезапустить kubelet (systemctl restart kubelet), восстановить узел, проверить сертификаты. Если узел удалён намеренно — уберите его из scrape-целей.
Когда можно заглушить. При выводе узла из кластера (drain).
Что значит. Контейнер 10 минут в состоянии CrashLoopBackOff: процесс стартует, падает, а Kubernetes перезапускает его с растущей паузой.
Частые причины. Ошибка приложения при старте, неверный конфиг/секрет, недоступная БД, нехватка памяти (OOMKilled), неверная команда, не пройденный liveness probe.
Диагностика.
kubectl -n <ns> get pod <pod>
kubectl -n <ns> describe pod <pod> # раздел Events и Last State
kubectl -n <ns> logs <pod> -c <контейнер> --previous
kubectl -n <ns> get events --sort-by=.lastTimestamp | tail -n 20
Ключ --previous показывает лог предыдущего (упавшего) запуска.
Как исправить. Исправить причину из лога: конфигурацию, секрет, зависимость. Если ломается liveness probe — увеличить initialDelaySeconds / failureThreshold. После исправления: kubectl -n <ns> rollout restart deployment/<имя>.
Когда можно заглушить. Для известного нерабочего Pod в тестовом namespace. Для production — нет.
Что значит. Pod 15 минут находится в фазе Pending или Unknown: Kubernetes не может запустить его на узле либо потерял связь с узлом.
Частые причины. Недостаточно ресурсов (CPU/память) на узлах, не удовлетворяются nodeSelector/affinity/taints, PVC не привязывается, узел недоступен, ресурсные квоты namespace.
Диагностика.
kubectl -n <ns> describe pod <pod> # раздел Events: FailedScheduling и причина
kubectl get nodes
kubectl top nodes
kubectl -n <ns> get pvc
kubectl -n <ns> describe resourcequota
Как исправить. Добавить ресурсы/узлы, ослабить ограничения планирования, исправить PVC/StorageClass, вернуть узел в работу. Для неудачно настроенных requests уменьшите их.
Когда можно заглушить. Если Pod намеренно ждёт (например, на узле с GPU, которого пока нет) и это известно.
Что значит. Контейнер не может получить образ из реестра (ErrImagePull / ImagePullBackOff) уже 10 минут.
Частые причины. Опечатка в имени или теге образа, образа нет в реестре, нет прав (не задан или протух imagePullSecret), реестр недоступен или лимиты на скачивание, нет сети на узле.
Диагностика.
kubectl -n <ns> describe pod <pod> # сообщение об ошибке в Events
kubectl -n <ns> get pod <pod> -o jsonpath='{.spec.containers[*].image}'
kubectl -n <ns> get secret # imagePullSecrets
ssh <узел> 'crictl pull <образ>'
Как исправить. Исправить имя/тег, пересоздать секрет доступа к реестру (kubectl create secret docker-registry ...) и указать его в imagePullSecrets, проверить доступность реестра с узла.
Когда можно заглушить. Нельзя, пока приложение не запущено.
Что значит. Контейнер был перезапущен, и причиной последнего завершения стал OOMKilled: процесс превысил лимит памяти (resources.limits.memory). Алерт активен, пока в течение 10 минут был рост счётчика перезапусков.
Частые причины. Слишком низкий лимит, утечка памяти, пиковая нагрузка, настройки runtime (JVM heap, Node.js) выше лимита контейнера.
Диагностика.
kubectl -n <ns> describe pod <pod> # Last State: Terminated, Reason: OOMKilled
kubectl -n <ns> top pod <pod> --containers
kubectl -n <ns> get pod <pod> -o jsonpath='{.spec.containers[*].resources}'
kubectl -n <ns> logs <pod> -c <контейнер> --previous
Как исправить. Увеличить лимит памяти, привести настройки приложения к лимиту, найти утечку. Сохраняйте разумную разницу между requests и limits.
Когда можно заглушить. Для тестовых и пакетных задач, где OOM ожидаем.
Что значит. Число доступных реплик Deployment отличается от желаемого 15 минут. Обычно доступных меньше; расхождение в большую сторону бывает при масштабировании.
Частые причины. Идёт неудачный rollout (новая версия не запускается), Pod не проходит readiness probe, нехватка ресурсов, удалён узел.
Диагностика.
kubectl -n <ns> get deploy <имя>
kubectl -n <ns> rollout status deployment/<имя>
kubectl -n <ns> describe deploy <имя>
kubectl -n <ns> get pods -l <метки-селектора> -o wide
kubectl -n <ns> describe pod <проблемный-pod>
Как исправить. Исправить причину нездоровых Pod (см. KubePodCrashLooping, KubePodNotReady). Если новая версия сломана — откатить: kubectl -n <ns> rollout undo deployment/<имя>.
Когда можно заглушить. При намеренном обнулении реплик (replicas: 0) на время обслуживания.
Что значит. Число готовых реплик StatefulSet отличается от желаемого 15 минут. StatefulSet поднимает Pod по порядку, поэтому одна проблемная реплика блокирует остальные.
Частые причины. Pod не готов (readiness probe), том не привязывается, нехватка ресурсов, недоступен узел, в кластере БД не набирается кворум.
Диагностика.
kubectl -n <ns> get statefulset <имя>
kubectl -n <ns> get pods -l <метки-селектора> -o wide
kubectl -n <ns> describe pod <имя>-<индекс>
kubectl -n <ns> get pvc
kubectl -n <ns> logs <имя>-<индекс> --previous
Как исправить. Устранить причину в проблемном Pod; проверить PVC и StorageClass; для БД — убедиться в состоянии репликации перед ручным удалением Pod. Без необходимости не удаляйте Pod StatefulSet с данными.
Когда можно заглушить. При запланированном масштабировании или обновлении по одной реплике.
Что значит. DaemonSet имеет меньше готовых Pod, чем должно быть (по одному на подходящий узел), в течение 15 минут.
Частые причины. Узел недоступен или NotReady, taint на узле без toleration, нехватка ресурсов на узле, Pod падает на конкретном узле (особенности ядра/ОС).
Диагностика.
kubectl -n <ns> get ds <имя>
kubectl -n <ns> get pods -l <метки-селектора> -o wide
kubectl -n <ns> describe ds <имя>
kubectl -n <ns> logs <pod-на-проблемном-узле> --previous
kubectl describe node <узел> | grep -i -A5 taints
Как исправить. Исправить причину на конкретных узлах: вернуть узел, добавить toleration, освободить ресурсы. Если узел выводится из кластера — удалите его через kubectl delete node.
Когда можно заглушить. Во время drain/обновления узлов.
Что значит. У Job есть Pod, завершившиеся с ошибкой (kube_job_status_failed > 0). Задача не выполнена или выполняется с повторами. Для CronJob метрика остаётся, пока существует объект Job (ограничено failedJobsHistoryLimit).
Частые причины. Ошибка в скрипте задачи, недоступная БД/API, нехватка прав, таймаут (activeDeadlineSeconds), нехватка ресурсов.
Диагностика.
kubectl -n <ns> get jobs
kubectl -n <ns> describe job <имя>
kubectl -n <ns> get pods -l job-name=<имя>
kubectl -n <ns> logs -l job-name=<имя> --tail=100
Как исправить. Исправить причину по логам, затем удалить неудавшийся Job (kubectl -n <ns> delete job <имя>), чтобы алерт погас, или дождаться следующего успешного запуска CronJob и очистки истории.
Когда можно заглушить. Если неудача известна, разобрана и повторный запуск не требуется (но тогда удалите Job).
Что значит. На томе PersistentVolumeClaim свободно менее 15%. Метрики берутся из kubelet и доступны не для всех типов томов.
Частые причины. Рост БД или логов, отсутствие ротации, накопившиеся дампы и временные файлы.
Диагностика.
kubectl -n <ns> get pvc <имя>
kubectl -n <ns> get pods -o wide | grep <pod-использующий-том>
kubectl -n <ns> exec <pod> -- df -h <путь-монтирования>
kubectl -n <ns> exec <pod> -- du -xh --max-depth=2 <путь-монтирования>
kubectl get storageclass
Как исправить. Очистить ненужное или расширить PVC (если StorageClass поддерживает allowVolumeExpansion: true): kubectl -n <ns> patch pvc <имя> -p '{"spec":{"resources":{"requests":{"storage":"<новый-размер>"}}}}'. Размер уменьшить нельзя.
Когда можно заглушить. Если рост разовый и расширение запланировано.
Что значит. На томе PVC свободно менее 5%. Приложение вот-вот не сможет писать данные.
Частые причины. Те же, что у KubePvcAlmostFull, но запас исчерпан.
Диагностика.
kubectl -n <ns> exec <pod> -- df -h <путь-монтирования>
kubectl -n <ns> exec <pod> -- du -xh --max-depth=2 <путь-монтирования>
kubectl -n <ns> get pvc <имя> -o yaml | grep -i -E 'storageClassName|storage:'
kubectl get storageclass <имя> -o jsonpath='{.allowVolumeExpansion}'
Как исправить. Срочно расширить PVC или освободить место. Для БД не удаляйте файлы данных вручную — используйте механизмы самой БД (очистка WAL/binlog, VACUUM и т.п.).
Когда можно заглушить. Нельзя, пока место не освобождено.
Что значит. Узел не сообщает состояние Ready в течение 5 минут. Kubernetes прекращает планировать на него Pod и через некоторое время начнёт эвакуацию.
Частые причины. Узел выключен или завис, kubelet остановлен, сеть между узлом и API-сервером, нехватка ресурсов на узле, ошибка container runtime.
Диагностика.
kubectl get nodes -o wide
kubectl describe node <узел> # Conditions и Events
kubectl get pods -A -o wide --field-selector spec.nodeName=<узел>
ssh <узел> 'systemctl status kubelet containerd --no-pager; journalctl -u kubelet -n 100 --no-pager'
ssh <узел> 'df -h; free -h; uptime'
Как исправить. Перезапустить kubelet/container runtime, освободить диск и память, перезагрузить или заменить узел. При необходимости выполните kubectl drain <узел> --ignore-daemonsets --delete-emptydir-data.
Когда можно заглушить. При плановых работах на узле.
Что значит. Узел сообщает одно из состояний нехватки ресурсов: MemoryPressure, DiskPressure или PIDPressure (имя в метке condition), 5 минут. Kubelet может начать вытеснять Pod.
Частые причины. Нехватка памяти (много Pod без лимитов), заполненный диск (образы, логи, emptyDir), слишком много процессов.
Диагностика.
kubectl describe node <узел> # Conditions
kubectl top node <узел>
ssh <узел> 'df -h /var/lib/kubelet /var/lib/containerd; free -h'
ssh <узел> 'crictl images | head; crictl ps | wc -l'
kubectl get pods -A --field-selector spec.nodeName=<узел> | grep -i evicted
Как исправить. Для DiskPressure — очистить образы и логи (crictl rmi --prune), расширить диск. Для MemoryPressure — выставить requests/limits, перераспределить Pod. Для PIDPressure — найти процесс, плодящий потоки.
Когда можно заглушить. Кратковременный пик при известной причине; при повторяющемся — нет.
Что значит. HPA работает на максимальном числе реплик (maxReplicas) 15 минут. Дальше автоматически масштабироваться некуда, хотя нагрузка может продолжать расти.
Частые причины. Реальный рост трафика, лимит maxReplicas слишком мал, неэффективное приложение, неудачно выбранная метрика масштабирования.
Диагностика.
kubectl -n <ns> get hpa <имя>
kubectl -n <ns> describe hpa <имя> # Metrics, Conditions, Events
kubectl -n <ns> top pods
kubectl top nodes
Как исправить. Если нагрузка легитимна — поднять maxReplicas (убедившись, что хватит ресурсов кластера) или оптимизировать приложение. Если метрика некорректна — настроить целевое значение.
Когда можно заглушить. Если работа на максимуме — штатный режим в часы пиковой нагрузки и вас это устраивает.
Что значит. Клиентские сертификаты, которыми обращаются к kube-apiserver, истекают менее чем через 7 дней (и не менее чем через 1 день). Метрика apiserver_client_certificate_expiration_seconds доступна не во всех дистрибутивах; правило работает, только если она есть. Значение — оценка по нижним 1% наблюдаемых сертификатов.
Частые причины. Сертификаты не продлевались автоматически (kubeadm не обновил их, истёк срок у kubeconfig-пользователей, сервисных аккаунтов или компонентов).
Диагностика.
kubeadm certs check-expiration # для кластеров kubeadm, на control plane
openssl x509 -noout -enddate -in /etc/kubernetes/pki/apiserver.crt
kubectl config view --raw -o jsonpath='{.users[*].user.client-certificate-data}' | base64 -d | openssl x509 -noout -enddate
Как исправить. Для kubeadm: kubeadm certs renew all на каждом control plane узле, затем перезапуск компонентов control plane. В управляемых кластерах (EKS/GKE/AKS и т.п.) сертификатами управляет провайдер — смотрите его документацию.
Когда можно заглушить. Если вы уже знаете об истечении и продление запланировано до критического срока.
Что значит. Клиентские сертификаты для обращения к kube-apiserver истекают менее чем через сутки (или уже истекли). После истечения компоненты и пользователи могут потерять доступ к кластеру.
Частые причины. Те же, что у KubeApiCertExpiresSoon: продление пропущено.
Диагностика.
kubeadm certs check-expiration
openssl x509 -noout -enddate -in /etc/kubernetes/pki/apiserver-kubelet-client.crt
ls -l /etc/kubernetes/pki /var/lib/kubelet/pki
Как исправить. Немедленно продлить сертификаты (kubeadm certs renew all и перезапуск компонентов control plane), обновить kubeconfig администраторов. Перед операцией сделайте резервную копию /etc/kubernetes.
Когда можно заглушить. Нельзя, пока не продлено.
Что значит. Prometheus не получает ответа от blackbox-exporter при проверке цели (up == 0) 3 минуты. Проверка сайта не выполняется, поэтому остальные алерты blackbox молчат.
Частые причины. Сервис blackbox-exporter остановлен, неверный адрес exporter в relabel_configs (параметр replacement), файрвол, ошибка в конфигурации модуля.
Диагностика.
systemctl status prometheus-blackbox-exporter --no-pager # либо ваше имя юнита
curl -sS -m 10 'http://<exporter>:9115/probe?module=http_2xx&target=https://example.com' | head -n 20
journalctl -u prometheus-blackbox-exporter -n 50 --no-pager
Для Docker/Kubernetes используйте docker logs / kubectl logs соответствующего Pod.
Как исправить. Запустить exporter, исправить адрес и порт (по умолчанию 9115) в конфигурации Prometheus, проверить синтаксис blackbox.yml.
Когда можно заглушить. На время обновления exporter.
Что значит. Проверка цели не проходит (probe_success == 0) 3 минуты подряд. Сайт или сервис недоступен либо отвечает не так, как ожидает модуль проверки.
Частые причины. Сервис упал, проблемы DNS, закрыт порт или файрвол, истёк/сломан TLS-сертификат, таймаут, неверный код ответа, не совпал ожидаемый текст ответа.
Диагностика.
curl -sS -v -m 10 -o /dev/null https://example.com
dig +short example.com
openssl s_client -connect example.com:443 -servername example.com </dev/null 2>/dev/null | openssl x509 -noout -dates
curl -sS -m 10 'http://<exporter>:9115/probe?module=http_2xx&target=https://example.com&debug=true'
Параметр debug=true у blackbox-exporter возвращает подробный журнал проверки.
Как исправить. По результату диагностики: поднять сервис, исправить DNS или сертификат, открыть порт. Если ложные срабатывания из-за таймаута — увеличьте timeout в модуле blackbox.
Когда можно заглушить. При плановых работах или миграции сайта.
Что значит. Среднее время проверки за 5 минут превышает 2 секунды в течение 10 минут, при этом проверка успешна. Сайт отвечает, но медленно.
Частые причины. Нагрузка на сервер или БД, медленные внешние API, сетевые проблемы или DNS, ошибки кэширования, большие страницы.
Диагностика.
curl -sS -o /dev/null -w 'dns=%{time_namelookup} connect=%{time_connect} tls=%{time_appconnect} ttfb=%{time_starttransfer} total=%{time_total}\n' https://example.com
Затем смотрите состояние самого сервера: NodeCpuHigh, NodeIowaitHigh, логи приложения и БД.
Как исправить. Исходя из того, какая фаза в curl медленная: DNS, соединение, TLS или ожидание ответа приложения. Оптимизировать запросы, добавить кэш, ресурсы.
Когда можно заглушить. Если порог 2 с слишком строг для данного сервиса — поднимите его в правиле. Заглушка допустима на время известной нагрузки.
Что значит. Итоговый HTTP-статус ответа (после редиректов) не в диапазоне 2xx в течение 5 минут. Нулевой статус (соединения не было) обрабатывается алертом BlackboxProbeFailed.
Частые причины. 5xx — ошибка приложения или прокси; 4xx — изменились маршруты, авторизация или проверяется неправильный URL; 3xx в конце цепочки — цикл редиректов или редирект на страницу вне 2xx.
Диагностика.
curl -sS -I -L -m 10 https://example.com
curl -sS -m 10 -o /dev/null -w '%{http_code} %{redirect_url}\n' https://example.com
Посмотрите логи веб-сервера и приложения за это время (journalctl -u nginx -n 100 --no-pager, docker logs --tail 100 <имя>).
Как исправить. Устранить ошибку приложения/конфигурации. Если сервис намеренно возвращает не 2xx (например, 401 для закрытой страницы), укажите допустимые коды в valid_status_codes модуля blackbox.
Когда можно заглушить. Если адрес намеренно отвечает не 2xx — лучше исправить модуль проверки, а не заглушать.
Что значит. До окончания сертификата осталось меньше 14 дней, но не меньше 3 (1 час подряд). Значение берётся из probe_ssl_earliest_cert_expiry — самый ранний срок во всей цепочке.
Частые причины. Не сработало автоматическое продление (ACME/certbot, cert-manager), изменился путь проверки домена, продление не настроено вовсе, отозван доступ к DNS API.
Диагностика.
echo | openssl s_client -connect example.com:443 -servername example.com 2>/dev/null | openssl x509 -noout -subject -issuer -dates
certbot certificates # если используется certbot
systemctl list-timers | grep -i certbot
journalctl -u certbot -n 50 --no-pager
kubectl get certificate -A # если используется cert-manager
Как исправить. Запустить продление вручную (certbot renew, повторный выпуск через cert-manager), затем перезагрузить веб-сервер (systemctl reload nginx), чтобы он подхватил новый файл. Исправьте причину, из-за которой автоматика не сработала.
Когда можно заглушить. Для сертификатов, которые вы намеренно не продлеваете (домен выводится из эксплуатации).
Что значит. До окончания сертификата осталось меньше 3 дней или он уже просрочен. Пользователи скоро увидят ошибку в браузере, а API-клиенты начнут отказываться от соединения.
Частые причины. Те же, что у BlackboxSslExpiresSoon, но продление не выполнено вовремя. Также веб-сервер мог не перечитать обновлённый сертификат.
Диагностика.
echo | openssl s_client -connect example.com:443 -servername example.com 2>/dev/null | openssl x509 -noout -enddate
ls -l /etc/letsencrypt/live/<домен>/ 2>/dev/null
nginx -t && systemctl status nginx --no-pager
Если файл на диске новый, а сервер отдаёт старый, сервер не перезагружали.
Как исправить. Немедленно продлить или выпустить сертификат вручную, перезагрузить веб-сервер/балансировщик, проверить результат командой openssl s_client.
Когда можно заглушить. Нельзя, пока сертификат не обновлён.