Как решать проблему нехватки места на диске при регулярных уведомлениях

Что проверяют

Умеете ли вы найти причину, а не чистить диск руками после каждого алерта. Если уведомление приходит регулярно, значит, что-то растёт без ограничения, и интервьюер ждёт, что вы это найдёте и закроете. Следом часто спрашивают: df показывает полный диск, а du столько не находит, почему.

Как отвечать

Порядок разбора на сервере:

• что кончилось: df -h для места и df -i для inode. Миллионы мелких файлов сессий или кэша исчерпывают inode при свободных гигабайтах;
• кто занял: du -xh --max-depth=1 / | sort -h или ncdu, спускаясь в самый большой каталог;
• удалённые, но открытые файлы: lsof +L1. Процесс держит дескриптор, и место не освобождается, пока его не перезапустить или не обрезать файл;
• journald: journalctl --disk-usage, лимит через SystemMaxUse= в journald.conf;
• Docker: docker system df, затем docker image prune и docker builder prune. Драйвер логов json-file по умолчанию не ротируется, лимит задаётся max-size и max-file в daemon.json, либо берите драйвер local.

Дальше закрываете причину: logrotate с подходящей схемой (copytruncate для процессов, которые не умеют переоткрывать файл, иначе postrotate с сигналом), сроки хранения бэкапов и артефактов сборки, лимиты ephemeral-storage для подов, вынос старых данных в объектное хранилище.

Меняется и мониторинг. Статичный порог в 90% либо будит зря, либо срабатывает поздно. Лучше прогноз в Prometheus: predict_linear(node_filesystem_avail_bytes[6h], 24*3600) < 0 предупредит, что место кончится в ближайшие сутки, при любом текущем проценте.

Где спотыкаются

Удаляют растущий лог через rm, пока приложение в него пишет. Место не вернулось, файла не видно, а du и df расходятся.

Предлагают сразу увеличить диск. Это даёт время, но если причина в неротируемых логах, через месяц алерт вернётся.

Забывают про inode: процесс получает No space left on device, а df -h показывает свободные гигабайты, и человек ищет проблему не там.