Про /boot: ядра-то сносятся нормально, дело не в них.
dnf по дефолту держит три ядра (installonly_limit), и лишнее выкидывает только когда ставит новое. А ядро — это не только vmlinuz на 10 метров, к нему ещё initramfs 40–100 (в host-only и жирнее бывает) плюс kdump-образ такого же порядка, если kdump включён. Три ядра с kdump — уже под 700 метров, а /boot по дефолтной разметке 512М–1Г. Впритык изначально.
Плюс пик — ровно в середине транзакции: новое ядро распаковано, dracut initramfs собрал, а старое ещё лежит, оно уедет в конце. То есть в моменте там N+1 ядер, и оно падает именно тогда, а не «потом, когда почистится».
Плюс половина барахла в /boot вообще не принадлежит пакетам, поэтому repoquery его в упор не видит. Дёрни rpm -qf /boot/initramfs-*.img — на что-то скажет not owned by any package. initramfs же генерится скриптлетом уже после установки, в файлах пакета его нет. При штатном сносе ядра он подчищается, а если ядро выпиливали руками, транзакция когда-то отвалилась или машину клонировали — висит сиротой вечно. Плюс initramfs-0-rescue-*, который не удаляется никогда, и после смены machine-id их накапливается по несколько штук по 80 метров. du -sh /boot/* — и обычно сразу видно, что полраздела занято тем, чего в rpmdb нет.
А /var кончается по своей причине, к ядрам вообще отношения не имеет: dnf тянет всю транзакцию в /var/cache/dnf до начала установки, там же rpmdb и history.
Про расширение /var — оно не про логи. Это чтобы обновление не сдохло на середине транзакции с недописанным rpmdb, разгребать такое куда дороже, чем пара лишних гигов на LV. Если место скушала база или забытый debug — да, + память - это только отодвинет, но плейбук её и не должен лечить, его задача довести апдейт до конца и не оставить сервер в разобранном виде.
По zabbix'у согласен на все сто, триггеры нужны, и лучше предиктивные по тренду, а не голый порог. Но одно другое не заменяет: мониторинг не знает, сколько сожрёт конкретная транзакция, а плейбук не видит тренда между патчингами.
Про /boot: ядра-то сносятся нормально, дело не в них.
dnf по дефолту держит три ядра (installonly_limit), и лишнее выкидывает только когда ставит новое. А ядро — это не только vmlinuz на 10 метров, к нему ещё initramfs 40–100 (в host-only и жирнее бывает) плюс kdump-образ такого же порядка, если kdump включён. Три ядра с kdump — уже под 700 метров, а /boot по дефолтной разметке 512М–1Г. Впритык изначально.
Плюс пик — ровно в середине транзакции: новое ядро распаковано, dracut initramfs собрал, а старое ещё лежит, оно уедет в конце. То есть в моменте там N+1 ядер, и оно падает именно тогда, а не «потом, когда почистится».
Плюс половина барахла в /boot вообще не принадлежит пакетам, поэтому repoquery его в упор не видит. Дёрни
rpm -qf /boot/initramfs-*.img— на что-то скажет not owned by any package. initramfs же генерится скриптлетом уже после установки, в файлах пакета его нет. При штатном сносе ядра он подчищается, а если ядро выпиливали руками, транзакция когда-то отвалилась или машину клонировали — висит сиротой вечно. Плюс initramfs-0-rescue-*, который не удаляется никогда, и после смены machine-id их накапливается по несколько штук по 80 метров.du -sh /boot/*— и обычно сразу видно, что полраздела занято тем, чего в rpmdb нет.А /var кончается по своей причине, к ядрам вообще отношения не имеет: dnf тянет всю транзакцию в /var/cache/dnf до начала установки, там же rpmdb и history.
Про расширение /var — оно не про логи. Это чтобы обновление не сдохло на середине транзакции с недописанным rpmdb, разгребать такое куда дороже, чем пара лишних гигов на LV. Если место скушала база или забытый debug — да, + память - это только отодвинет, но плейбук её и не должен лечить, его задача довести апдейт до конца и не оставить сервер в разобранном виде.
По zabbix'у согласен на все сто, триггеры нужны, и лучше предиктивные по тренду, а не голый порог.
Но одно другое не заменяет: мониторинг не знает, сколько сожрёт конкретная транзакция, а плейбук не видит тренда между патчингами.