Gregory's Server@sattellite хостятся на виртуалках, логируют в файлы, отвалилась БД, БД на том же разделе что логи (голосом тёзки: это было пиздец как смело) засрали логами весь диск, встали раком, дальше я не в теме, но надеюсь БД не закорраптили или бэкапы работали и свежи.
|
11 comments
  @sattellite я вот задумался, а как без выделенной системы сбора логов сделать систему логирования устойчивой к резкому аномальному возрастанию объёмов. Пока в голову идёт только система из многоуровневых кольцевых буферов по годам, месяцам, неделе, дням, часам, типа такого для бэкапа https://github.com/strizhechenko/backup_scheme @sattellite при лимитах на кольцо в 3-4х от нормальной нагрузки, я думаю, потеря части логов некритична в большинстве систем и любой рекавери в неё бы выродился. @strizhechenko интересное решение. Это замена родного logrotate для того, чтобы хранить логи на другом сервере? Можно и локально, конечно, использовать. @sattellite но есть нюанс, как триггерить переполнение лимита в моменте, а не по расписанию - клянусь Зевсом, я далек от мысли, что такой способ мне известен. @strizhechenko можно раз в минуту опрашивать кроном локально. То есть один скрипт кроном раз в минуту проверяет свободное место, если оно подходит к концу, то вызывает нужную ротацию, обязательно с блокировкой до конца выполнения. И раз в час/сутки/месяц по крону вызывать скрипт ротации. @sattellite не, ну в целом можно, всё равно за минуту весь раздел не забить тупо из-за физики :) @strizhechenko а чтобы прямо в моменте, то можно через inotify получать события и вызывать скрипт каждый раз, но это будет более сложно и ресурсоемко, чем периодами по крону @strizhechenko а ещё можно подсмотреть в atop как он мониторит свободное место на дисках. И использовать тот же способ или мониторить результат его работы по дискам. |
@sattellite ну и liveness/readyness проб, "guardian angel"-систем которые по крону чекают систему и фиксят что смогут, разумеется, нет.