Какие могут быть причины такого ступенчатого роста access-логов nginx?

Question

[Михаил Матюнин]

Заметили очень странное изменение размера файла access-логов nginx. Ниже будет скриншот из Zabbix, по которому видно, что файл логов nginx растёт ступенчато (на графике показано свободное место в /var, но там только логи nginx, к тому же проверяли изменение размера логов и в консоли). Видно, что замер "ступенек" на графике равномерно и пропорционально возрастает.

Самое странное, что в районе 22:00 файл логов стал весить 8Гб, а потом сразу 4Гб, при этом мы никаких действий не осуществляли и никаких "особых демонов ротации логов" на хосте нет.

Несколько уточнений:

• Трафик равномерный, никаких скачков в течение для не было.
  
• Логи в конфиге nginx настроены по дефолту:
  

access_log /var/log/nginx/access.log main;

Может есть какие-то особенности записи логов в nginx, о которых мы не догадались по доке?

Comments

[Алексей Романенко]

Отфильтруйте все логи по времени и посмотрите в каких произошло что-то аномальное

[Михаил Матюнин]

Проверяли это первым делом, но никаких аномалий не нашли.

Answer 1

[Михаил Матюнин]

В общем ответ оказался для нас слегка неожиданным, и суть заключалась в специфике работы XFS. Оказалось, что на диске по мере роста файла преаллоцируется пространство, что и объясняет скачкообразный рост показателей в команде du, не коррелирующий с динамикой трафика. Ниже ссылки для интересующихся, а также скрин графика из Zabbix, на котором мы решили отдельно мониторить файл логов (выводы du и stat). И как мы видим - du растёт ступенчато, а stat по динамике соответствует трафику:

git.kernel.org/cgit/linux/kernel/git/torvalds/linu...
serverfault.com/questions/406069/why-are-my-xfs-fi...

Answer 2

[Эргил Осин]

А кто вам сказал, что никаких ротаций?
Вы уверены, что у вас не отработал logrotate?

Comments

[Михаил Матюнин]

Logrotate.d настроен в daily, к тому же ротация не объясняет скачкообразный рост лога (опять же повторюсь - трафик ровный, буферизации записи в лог нет), также на ротацию не похоже изменение 4гб->8гб->4гб в течение пары минут.

Answer 3

[Павел Селиванов]

nginx сам логи чистить не умеет и правильно делает. Это отрабатывает что-нибудь вроде logrotate.
UPD:
Это точно не сам nginx, он логи только пишет. Я бы для начала сделал grep -r /etc -e nginx | grep -v ^/etc/nginx.
Если не удалось ничего найти таким образом - можно подключить тяжёлую артиллерию: поставить auditd, прописать в rules что-нибудь вроде

auditctl -a exit,always -F path =/var/log/nginx -F perm = aw

И смотреть в логах auditd всё, что работало с этой папкой. Только надо учитывать, этих логов будет очень много, на каждый syscall.

Comments

[Михаил Матюнин]

Поначалу сам на него подумал, но не похоже. См. мой ответ выше про logrotate.d

[Михаил Матюнин]

Про auditd надо подумать, спасибо за совет!

Answer 4

[kresska]

Во-первых, vfs.file.size на access.log
Во-вторых, cat /etc/logrotate.d/nginx
+ можно lsof`ом посмотреть /var/log и увидеть кто и что туда пишет
в один момент времени лог на 4гб скакнуть не мог, как часто вы свободное место в /var/log проверяете?
Кстати, в конце крафика, ступенькообразность заканчивается, изменили время забора метрики?

Answer 5

[Андрей Буров]

не поверю что в /var нет ничего кроме логов nginx...

Comments

[Михаил Матюнин]

Ну есть конечно логи крона, dmesg и прочее по мелочи, но это не имеет отношение к проблеме, ими можно пренебречь, так как я специально указал, что мы проверяли размер файла логов nginx из консоли, и это именно он занимает 99.9% места в /var.