ServerAdmin.ru
28.4K subscribers
263 photos
33 videos
12 files
2.59K links
Авторская информация о системном администрировании.

Информация о рекламе: @srv_admin_reklama_bot
Автор: @zeroxzed

Второй канал: @srv_admin_live
Сайт: serveradmin.ru
Download Telegram
При настройке любой службы в Linux, которая пишет логи, надо обязательно следить за их ротацией. Типовая ситуация, когда логи забивают всё свободное место на диске, и сервак встаёт колом. Ротировать логи можно встроенной утилитой Linux - logrotate.

Для логов веб сайтов полезно включать ротацию не по заданному расписанию, а по размеру лог файла. Иногда случаются набеги ботов, которые могут раздуть логи до огромных размеров за несколько минут. Дождаться суточной ротации можно и не успеть. В этом случае полезно использовать следующий параметр logrotate:
size = 100M

Обычно люди ставят его и ожидают, что теперь логи будут автоматически ротироваться при достижении ими размера в 100 мегабайт. Ага, сейчас. Ничего подобного не произойдёт. По умолчанию logrotate запускается раз в сутки, поэтому он при всём желании не сможет следить за размером файла и ротировать его чаще, чем раз в сутки. Обычно за его запуск отвечает скрипт в директории /etc/cron.daily/logrotate.

Для того, чтобы logrotate мог проверять размер лог файла хотя бы раз в час, скрипт запуска надо перенести в директорию /etc/cron.hourly. А для более частой проверки, добавить его напрямую в cron с нужным интервалом запуска. Например, раз в 5 минут.

Допустим вы всё это сделали, но логи всё равно не будут ротироваться при достижении заданного размера. Понять, в чем же теперь проблема, не так просто. При запуске logrotate вы не увидите никаких ошибок. Он просто ничего не будет делать. Понять, в чём проблема, можно только при запуске в режиме отладки. Там вы увидите ошибку, если в этот день ротация уже была хотя бы раз.
destination /var/log/nginx/access.log.20220426.gz already exists, skipping rotation

Смысл тут в том, что logrotate сегодня уже произвел ротацию и создал архив лога с определенным именем и второй раз такой же файл он сделать не может. А маска имени файла при создании настроена в формате %Y%m%d. За эту маску отвечает параметр в /etc/logrotate.conf:
dateext

Самый простой вариант - это просто закомментировать этот параметр, тогда все архивы логов будут иметь следующую маску в файлах:
access.log.1.gz
access.log.2.gz
access.log.3.gz

Если же вам хочется сохранить исходный формат лога для всех файлов, а для тех, что ротируются по размеру, настроить другую маску имени, используйте дополнительный параметр:
dateformat -%Y-%m-%d_%H-%s

Формат имени архивного лога будет access.log.2022-04-26_15-1566819154.gz. Имена больше не будут дублироваться и logrotate сможет корректно запускать ротацию при достижении указанного размера файла.

Таким образом, чтобы настроить ротацию лог файла по достижении определенного размера, вам нужно:

1️⃣ Запускать через cron logrotate с достаточно высокой периодичностью, например раз в час или чаще.
2️⃣ Настроить маску файла для архива лога, чтобы она была уникальной в каждый момент запуска logrotate.

#logrotate #nginx #webserver
Одной из обязательных настроек, которую делаю на новом сервере, касается ротации текстовых логов. Несмотря на то, что их активно заменяют бинарные логи systemd, я предпочитаю возвращать текстовые логи syslog. Для этого на чистый сервер устанавливаю rsyslog:

# apt install rsyslog

Далее выполняю некоторые настройки, которые относятся к ротации логов с помощью logrotate. В первую очередь в фале /etc/logrotate.conf включаю параметр:

dateext

Он нужен, чтобы в имени файла была указана дата, когда лог-файл был ротирован. С этой настройкой связан один очень важный момент, если вы хотите ротировать логи чаще, чем раз в сутки. По умолчанию logrotate во время ротации лога с этой настройкой переименовывает текущий лог файл, назначая ему имя вида access.log.20241001.gz. То есть в имени файла будет указан текущий день. Второй раз в этот день ротация закончится ошибкой, так как logrotate скажет, что не могу переименовать лог, так как файл с таким именем уже существует. Для тех логов, что точно будут ротироваться чаще, чем раз в сутки, нужно обязательно добавить параметр:

dateformat -%Y-%m-%d_%H-%s

В таком случае каждое имя файла будет уникальным и проблем не возникнет.

Далее в обязательном порядке нужно настроить запуск logrotate чаще, чем раз в сутки. По умолчанию в Debian запуск logrotate настроен в /etc/cron.daily и запускается не чаще раза в сутки. Я обычно просто добавляю запуск в /etc/crontab каждые 5 минут:

*/5 * * * * root logrotate /etc/logrotate.conf

Эти настройки особенно актуальны для веб серверов, где очень быстро могут разрастись лог файлы.

Все возможные настройки файлов logrotate можно почитать в man. Там довольно подробно всё описано. Если не хочется читать man, можно воспользоваться простым конфигуратором:

🌐 https://scoin.github.io/logrotate-tool

Там наглядно перечислены настройки с описанием. Можно мышкой потыкать и посмотреть, как меняется конфигурационный файл. Вот пример моего файла ротации логов веб сервера:

/web/sites/*/logs/*.log {
  create 644 angie webuser
  size=50M
  dateext
  dateformat -%Y-%m-%d_%H-%s
  missingok
  rotate 30
  compress
  notifempty
  sharedscripts
  postrotate
if [ -f /run/angie.pid ]; then
kill -USR1 $(cat /run/angie.pid)
fi
  endscript
}

Маска /web/sites/*/logs/*.log захватывает все виртуальные хосты веб сервера, где логи располагаются в директориях:

◽️/web/sites/site01.ru/logs/
◽️/web/sites/site02.ru/logs/
и т.д.

Когда будете настраивать ротацию логов, проверяйте, чтобы у службы, для которой управляем логами, в итоге оказался доступ к этим логам. Я иногда ошибаюсь и потом приходится разбираться, почему после ротации логи нулевого размера. Это актуально, когда логи куда-то выносятся из /var/log и отдельно настраиваются права, например, для того, чтобы какие-то пользователи имели к ним доступ, к примеру, только на чтение.

#linux #logs #logrotate #webserver
Please open Telegram to view this post
VIEW IN TELEGRAM