Как спроектировать политику ротации и хранения логов на узлах, чтобы избежать переполнения диска, не теряя важные данные для расследования инцидентов?

Короткий ответ

Нужно комбинировать ограничение размера/количества файлов логов на узле (ротация по размеру и количеству, не только по времени), гарантированную и своевременную выгрузку в централизованное хранилище до удаления локальных файлов, и мониторинг заполнения диска как отдельную метрику с алертом задолго до критического порога.

Как это работает подробнее

локальная ротация логов (через logrotate, встроенные механизмы container runtime или настройки kubelet) ограничивает объём, который может занять лог на диске узла, принудительно удаляя или сжимая старые файлы при превышении лимита. Если централизованный агент сбора логов не успевает вычитать файл до его ротации/удаления, часть данных теряется безвозвратно — поэтому важно, чтобы скорость вычитки агентом была выше скорости записи приложением, а лимиты ротации давали разумный запас по времени.

Пример кода

example.txtКопировать

# kubelet: лимиты на контейнер + количество файлов
containerLogMaxSize: "50Mi"
containerLogMaxFiles: 5
# --- promql ---
# Алерт на приближение к заполнению диска узла
node_filesystem_avail_bytes{mountpoint="/var/log"} / node_filesystem_size_bytes{mountpoint="/var/log"} < 0.2

Что использовать на практике

• Практика. для критичных сервисов полезно мониторить саму лаг-метрику агента логирования (разницу между моментом записи строки и моментом её попадания в центральное хранилище) и настраивать алерт при её росте, а не только мониторить свободное место на диске. Также стоит учитывать, что некоторые инциденты (например, "диск заполнился из-за логов") сами являются observability-инцидентом, который нужно уметь детектировать через node_filesystem_avail_bytes.
• Практика. При срабатывании такого алерта (менее 20% свободного места) у команды остаётся запас времени на реакцию (увеличить лимиты, найти источник избыточного логирования), прежде чем диск заполнится полностью и узел начнёт испытывать проблемы с записью, что подтверждается стабильным трендом снижения node_filesystem_avail_bytes на графике.

Подводные камни

• Частые ошибки. настраивать ротацию только по времени (например, "раз в день"), не ограничивая по размеру — при резком всплеске логирования (например, цикл ошибок, печатающий stack trace тысячи раз в секунду) диск заполняется за минуты, а не за сутки; не мониторить свободное место на диске узлов как отдельную метрику с заранее заданным порогом предупреждения (например, 80%), обнаруживая проблему только при полном заполнении, когда уже невозможно даже записать новый лог.