Чаще всего такое бывает из-зза совокупности неочевидных проблем в конфигурации логов, скриптов запуска логгируемуго софта и сиетемы ротации или бэкапа логов.
Например, описанная вами ситуация может быть порождена следующим стечением ошибок и обстоятельств.
Бывает, что на бэкенде в один и тот же лог-файл пишут несколько скриптов. Это уже конкуренный доступ к файлам и не есть хорошо. Такое случается, когда по образцу одной проги с логгированием потом делают другую, а конфигурация логгирования не предусматривает такую ситуацию. Вот когда два таких скрипта работают и логи в конфликтный файл пишутся не часто, могут случиться такие проблемы.
Ещё один из таких скриптов может запускаться под рутовыми правами, а другой после него под пользовательскими. Если запущщеный от рута скрипт вызвал ротацию лог-файла, то новый файл мог создаться уже с рутовыми правами по умолчанию, а это значит, что другой скрипт (или этот же, но запущеный от обычного пользователя) уже не сможет в него писать.
Как ситуация может исправиться сама собой? Да так же. Напрмер у вас запущен по крону скрипт бэкапа или той же самой ротации, который тоже работает от рута, но писался девопсами и учитывает историю с правами пересоздавая файл от имени нуного юзера или с нужными правами.
Я могу дого гадать на койейной гуще, но ставить какие-то мониторинги - это охота на ведьм.
Поищите все места, где присходит конфигурирование логов. Выясните какие процессы могут писать в этот файл и от чьего имени они запущены. Выясните какие крон-джобы запланированы и посмотрите по содержимому файлов и их метаданным когда именно случались проблемы.
Важно. чтобы в каждый отдельный лог-файл писал один и только один процесс. Он же занимался его ротацией (если, к примеру, вы логгируете стандартной питонячьей либой). Ещё хорошая идея не засталять софт писать логи в файлы, пусть пишет логи в stderr и/или stdout, а оттуда вы их на уровне системы перенаправите куда положено и отфильтруете как надо. если необходимо.
Итак. Перым делом смотрите какие процессы пишут файл, какие скрипты трогают эти файлы (бэкапы. ротация), посмотрите в crontab, посмотрите конфигурацию сотфа в плане логов и всё должно проясниться. Делать систему мониторинга за изменениями в файловой системе возможно, но это ректальная тонзиллэктомия получаетя какая-то...
UPD:
Почему-то не обратил внимания, что речь о логах mysql. Но всё по-прежнему: конфиг логгирования и ротации, распсиание и механизм ротации и бэкапа, поиск по конфигам фрагментов этого пути на предмет аномалий и повторов.
