Как в Apache под Windows настроить автоматическую ротацию и очистку логов

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

С помощью этого плагина мы сможем в Apache в 2.4 под Windows настроить автоматическую чистку логов со временем.

Файл данного плагина не входит в стандартный набор Apache, но команда apachelounge компилирует его для Windows. Перейдите на сайт https://www.apachelounge.com/download/, найдите и скачайте файл mod_log_rotate:

Распакуйте архив и поместите файл mod_log_rotate.so в папку modules, если вы устанавливали по этой инструкции, то это папка C:\Server\bin\Apache24\modules\.

Для включения этого модуля, добавьте в ваш конфигурационный файл httpd.conf (C:\Server\bin\Apache24\conf\httpd.conf) строки:

Чтобы изменения вступали в силу, не забывайте при каждом изменении конфигурационного файла httpd.conf перезапускать веб-сервер!

Интервал ротации логов по умолчанию установлен на 86400 секунд (это один день). С помощью директивы

можно установить другой интервал ротации в секундах. Самый короткий интервал, который может быть установлен, равен 60 секундам.

Обычно интервал ротации журнала основан на UTC. Например, интервал 86400 (один день) приведёт к ротации журналов в UTC 00:00.

С помощью следующей директивы вы можете сделать так, чтобы ротация журналов происходила по местному времени:

У директивы RotateInterval может быть альтернативная опция:

Она указывает смещение времени ротации журналов веб сервера. Например:

приведёт к тому, что логи будут ротироваться в 23:00 UTC.

Теперь в качестве имени для настраиваемого лога можно указать дату в формате strftime(). К примеру вы можете сделать что-то вроде такого:

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

Внимание

После включения mod_log_rotate, этот модуль отвечает за весь вывода журнала веб сервера, даже если впоследствии используется RotateLogs Off.

Это означает, что директива BufferedLogs, которая реализуется mod_log_config, будет игнорироваться.

Поскольку BufferedLogs не документирована и помечена как экспериментальная функция, это не должно быть проблемой в производственных средах.

Альтернатива для rotatelogs

Использование модуля mod_log_rotate является альтернативой для поставляемой с Apache программы rotatelogs. Если вы не хотите устанавливать дополнительный модуль, то используйте rotatelogs (документация). Если вам нужна инструкция по rotatelogs, то пишите в комментариях!

Связанные статьи:

• Удалённый просмотр и поиск по логам Apache в Windows (модуль mod_view) (100%)
• Почему в логах ошибок Apache не сохраняются записи об ошибке 404 (83.4%)
• Apache log (логи): как настроить и анализировать журналы веб-сервера (77.5%)
• Как ограничить пропускную способность Apache на Windows для IP и отдельных файлов (75.1%)
• Модуль Apache mod_alias (75.1%)
• Как установить ownCloud сервер в Windows (RANDOM — 50%)

Comments

Спасибо. mod_log_rotate затрагивает как и access.log так и error.log?

Нет, с логом ошибок этот модуль не работает. Если интересно почему: ошибки могут быть такими, что аварийно завершится процесс сервера, по этой причине, например, ошибки не буферизируются (выводятся сразу). По этой причине в Linux различают «стандартный вывод» и «стандартный вывод ошибок» — оба выводятся в консоль, но второй также не буферизируется. То есть ошибки выводятся сразу как только возникли, не надеясь, что процесс Apache, а уж тем более какой-то модуль, переживут эту ошибку.

Тем не менее с использованием внешней программы можно управлять и журналом ошибок (если Apache вылетит, внешняя программа всё равно обработает полученную информацию). В частности это умеет упомянутая в инструкции программа rotatelogs (в Windows это rotatelogs.exe).

Я подготовлю инструкцию по rotatelogs и покажу как можно ротировать логи ошибок.

Спасибо буду крайне признателен за Вашу инструкцию по rotatelogs

Admin’s Notes

воскресенье, 17 апреля 2016 г.

Подключаем (включаем) ротацию log файлов на Apache x64 2.4.20 под Windows Server 2008

Тут опишу два способа ротации логов.

СПОСОБ РАЗ

2) Копируем из архива файл mod_log_rotate.so в каталог с модулями Apache (обычно это подкаталог modules)

3) В файл httpd.conf добавляем строку LoadModule log_rotate_module modules/mod_log_rotate.so

4) В файл httpd.conf добавляем строку RotateLogs On

5) В файл httpd.conf добавляем строку RotateLogsLocalTime On

6) По желанию добавляем в файл httpd.conf добавляем строку RotateInterval указываем значение в секундах через которое будут создаваться новые файлы логов. По умолчанию используется значение 86400 то есть один день. Если эту строчку не указать, то будет использовано значение по умолчанию. Минимальное значение 60 секунд.

7) В файле httpd.conf изменяем строку создания файла логов доступа. Например на такую: «E:/iLogs/access %Y.%m.%d %B %H-%M-%S.log» combinedio

То же самое проделываете для всех ваших логов доступа (access.log) на виртуальных хостингах. Иначе к их названию просто прилепиться случайное число.

8) Перезапускаем Apache

P.S. mod_log_rotate 1.00a for Apache 2.4 Win64 VC14 работает только для логов доступа. Для логов ошибок он не работает.

СПОСОБ ДВА

При помощи утилиты – rotatelogs.

Rotatelogs — небольшая утилита в составе APACHE, позволяющая осуществлять ротацию логов по времени и по размеру.

rotatelogs [ -l ] [ -f ] logfile rotationtime|filesizeM [ offset ]

-l — Использовать локальное время

-f — Открыть новый файл немедленно, не дожидаясь добавления в него записи

logfile — путь и базовое название лога. Допускается использование модификаторов имени файла (ниже)

rotationtime — время ротации в секундах

filesizeM — максимальный размер лога в мегабайтах

offset — смещение во времени в минтах

Примеры для APACHE под WINDOWS

Внимание. надо указывать либо полный путь к утилите rotatelogs либо отностительный, а так же файлу логов.

CustomLog «|C:/bin/rotatelogs.exe C:/var/logs/logfile 86400″ common

CustomLog «|bin/rotatelogs.exe -l C:/var/logs/logfile.%Y.%m.%d 86400″ common

CustomLog «|C:/bin/rotatelogs.exe C:/var/logs/logfile 5M» common

ErrorLog «|C:/bin/rotatelogs.exe C:/var/logs/errorlog.%Y-%m-%d-%H_%M_%S 5M»

Модификаторы названия файла

%A full weekday name (localized)

%a 3-character weekday name (localized)

%B full month name (localized)

%b 3-character month name (localized)

%c date and time (localized)

%d 2-digit day of month

%H 2-digit hour (24 hour clock)

%I 2-digit hour (12 hour clock)

%j 3-digit day of year

%M 2-digit minute

%p am/pm of 12 hour clock (localized)

%S 2-digit second

%U 2-digit week of year (Sunday first day of week)

%W 2-digit week of year (Monday first day of week)

%w 1-digit weekday (Sunday first day of week)

%X time (localized)

%x date (localized)

%Z time zone name

Вторым способом можно ротировать и логи ошибок. Но он не позволить использовать пробелы между модификаторами.

Можно одновременно использовать оба метода. Например первый для логов доступа, а второй для лога ошибок.

Либо же только второй для обоих логов.

Возможно в будущем, первым способом можно будет ротировать и логи ошибок.

Ротация файлов по размеру в logrotate

Написать заметку по настройке ротации логов в logrotate меня побудило то, что постоянно забываю все сделать правильно. Запишу все нюансы, заодно с остальными поделюсь информацией. Речь пойдет о ротации лог файлов по достижении ими определенного размера.

Это будет короткая заметка про конкретную настройку. Подробно описывать работу logrotate не буду, так как в интернете и так полно материала на эту тему.

Для примера буду описывать ротацию логов nginx. После установки nginx, вы получите следующий конфиг для ротации логов — /etc/logrotate.d/nginx.

Все не указанные явно параметры будут браться из дефолтного конфига /etc/logrotate.conf.

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

И ждете, что по достижении размера файла access.log в десять мегабайт, будет произведена ротация. На самом деле не будет. По-умолчанию, logrotate запускается раз в сутки, поэтому он при всем желании не сможет следить за размером файла и ротировать его чаще, чем раз в сутки.

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

Допустим вы все это сделали, но логи все равно не будут ротироваться при достижении заданного размера. Понять, в чем же теперь проблема, не так просто. При запуске logrotate вы не увидите никаких ошибок. Он просто ничего не будет делать. Понять, в чем проблема, можно только при запуске в режиме отладки. Там вы увидите ошибку, если в этот день ротация уже была хотя бы раз.

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

Самый простой вариант — это просто закомментировать этот параметр, тогда все архивы логов будут иметь следующую маску в файлах:

И так далее. Если же вам хочется сохранить исходный формат лога для всех файлов, а для тех, что ротируются по размеру, настроить другую маску имени, используйте дополнительный параметр:

Формат имени архивного лога будет access.log.2019-08-26_15-1566819154.gz. Имена больше не будут дублироваться и logrotate сможет корректно запускать ротацию при достижении указанного размера файла. Обращаю внимание, что формат тут отличается от привычной конструкции в date, к которой обычно все привыкли. Сделать формат %Y-%m-%d_%H-%M не получится. Logrotate не поймет маску с минутами %M. Так что для уникальности имени в пределах одного часа надо использовать %s.

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

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

Вот пример для ротации конфигов nginx или apache по достижении размера лог файла в 10 мегабайт.

Не забудьте создать директорию /var/log/nginx/old для хранения старых логов. На этом у меня все по ротации логов в logrotate с учетом размера файла.

Вертим логи как хотим ― анализ журналов в системах Windows

Пора поговорить про удобную работу с логами, тем более что в Windows есть масса неочевидных инструментов для этого. Например, Log Parser, который порой просто незаменим.

В статье не будет про серьезные вещи вроде Splunk и ELK (Elasticsearch + Logstash + Kibana). Сфокусируемся на простом и бесплатном.

Журналы и командная строка

До появления PowerShell можно было использовать такие утилиты cmd как find и findstr. Они вполне подходят для простой автоматизации. Например, когда мне понадобилось отлавливать ошибки в обмене 1С 7.7 я использовал в скриптах обмена простую команду:

Она позволяла получить в файле fail.txt все ошибки обмена. Но если было нужно что-то большее, вроде получения информации о предшествующей ошибке, то приходилось создавать монструозные скрипты с циклами for или использовать сторонние утилиты. По счастью, с появлением PowerShell эти проблемы ушли в прошлое.

Основным инструментом для работы с текстовыми журналами является командлет Get-Content, предназначенный для отображения содержимого текстового файла. Например, для вывода журнала сервиса WSUS в консоль можно использовать команду:

Для вывода последних строк журнала существует параметр Tail, который в паре с параметром Wait позволит смотреть за журналом в режиме онлайн. Посмотрим, как идет обновление системы командой:

Смотрим за ходом обновления Windows.

Если же нам нужно отловить в журналах определенные события, то поможет командлет Select-String, который позволяет отобразить только строки, подходящие под маску поиска. Посмотрим на последние блокировки Windows Firewall:

Смотрим, кто пытается пролезть на наш дедик.

При необходимости посмотреть в журнале строки перед и после нужной, можно использовать параметр Context. Например, для вывода трех строк после и трех строк перед ошибкой можно использовать команду:

Оба полезных командлета можно объединить. Например, для вывода строк с 45 по 75 из netlogon.log поможет команда:

Журналы системы ведутся в формате .evtx, и для работы с ними существуют отдельные командлеты. Для работы с классическими журналами («Приложение», «Система», и т.д.) используется Get-Eventlog. Этот командлет удобен, но не позволяет работать с остальными журналами приложений и служб. Для работы с любыми журналами, включая классические, существует более универсальный вариант ― Get-WinEvent. Остановимся на нем подробнее.

Для получения списка доступных системных журналов можно выполнить следующую команду:

Вывод доступных журналов и информации о них.

Для просмотра какого-то конкретного журнала нужно лишь добавить его имя. Для примера получим последние 20 записей из журнала System командой:

Последние записи в журнале System.

Для получения определенных событий удобнее всего использовать хэш-таблицы. Подробнее о работе с хэш-таблицами в PowerShell можно прочитать в материале Technet about_Hash_Tables.

Для примера получим все события из журнала System с кодом события 1 и 6013.

В случае если надо получить события определенного типа ― предупреждения или ошибки, ― нужно использовать фильтр по важности (Level). Возможны следующие значения:

• 0 ― всегда записывать;
• 1 ― критический;
• 2 ― ошибка;
• 3 ― предупреждение;
• 4 ― информация;
• 5 ― подробный (Verbose).

Собрать хэш-таблицу с несколькими значениями важности одной командой так просто не получится. Если мы хотим получить ошибки и предупреждения из системного журнала, можно воспользоваться дополнительной фильтрацией при помощи Where-Object:

Ошибки и предупреждения журнала System.

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

Подробнее почитать про работу обоих командлетов для работы с системными журналами можно в документации PowerShell:

PowerShell ― механизм удобный и гибкий, но требует знания синтаксиса и для сложных условий и обработки большого количества файлов потребует написания полноценных скриптов. Но есть вариант обойтись всего-лишь SQL-запросами при помощи замечательного Log Parser.

Работаем с журналами посредством запросов SQL

Утилита Log Parser появилась на свет в начале «нулевых» и с тех пор успела обзавестись официальной графической оболочкой. Тем не менее актуальности своей она не потеряла и до сих пор остается для меня одним из самых любимых инструментов для анализа логов. Загрузить утилиту можно в Центре Загрузок Microsoft, графический интерфейс к ней ― в галерее Technet. О графическом интерфейсе чуть позже, начнем с самой утилиты.

О возможностях Log Parser уже рассказывалось в материале «LogParser — привычный взгляд на непривычные вещи», поэтому я начну с конкретных примеров.

Для начала разберемся с текстовыми файлами ― например, получим список подключений по RDP, заблокированных нашим фаерволом. Для получения такой информации вполне подойдет следующий SQL-запрос:

Посмотрим на результат:

Смотрим журнал Windows Firewall.

Разумеется, с полученной таблицей можно делать все что угодно ― сортировать, группировать. Насколько хватит фантазии и знания SQL.

Log Parser также прекрасно работает с множеством других источников. Например, посмотрим откуда пользователи подключались к нашему серверу по RDP.

Работать будем с журналом TerminalServices-LocalSessionManager\Operational.

Не со всеми журналами Log Parser работает просто так ― к некоторым он не может получить доступ. В нашем случае просто скопируем журнал из %SystemRoot%\System32\Winevt\Logs\Microsoft-Windows-TerminalServices-LocalSessionManager%4Operational.evtx в %temp%\test.evtx.

Данные будем получать таким запросом:

Смотрим, кто и когда подключался к нашему серверу терминалов.

Особенно удобно использовать Log Parser для работы с большим количеством файлов журналов ― например, в IIS или Exchange. Благодаря возможностям SQL можно получать самую разную аналитическую информацию, вплоть до статистики версий IOS и Android, которые подключаются к вашему серверу.

В качестве примера посмотрим статистику количества писем по дням таким запросом:

Если в системе установлены Office Web Components, загрузить которые можно в Центре загрузки Microsoft, то на выходе можно получить красивую диаграмму.

Выполняем запрос и открываем получившуюся картинку…

Любуемся результатом.

Следует отметить, что после установки Log Parser в системе регистрируется COM-компонент MSUtil.LogQuery. Он позволяет делать запросы к движку утилиты не только через вызов LogParser.exe, но и при помощи любого другого привычного языка. В качестве примера приведу простой скрипт PowerShell, который выведет 20 наиболее объемных файлов на диске С.

Ознакомиться с документацией о работе компонента можно в материале Log Parser COM API Overview на портале SystemManager.ru.

Благодаря этой возможности для облегчения работы существует несколько утилит, представляющих из себя графическую оболочку для Log Parser. Платные рассматривать не буду, а вот бесплатную Log Parser Studio покажу.

Интерфейс Log Parser Studio.

Основной особенностью здесь является библиотека, которая позволяет держать все запросы в одном месте, без россыпи по папкам. Также сходу представлено множество готовых примеров, которые помогут разобраться с запросами.

Вторая особенность ― возможность экспорта запроса в скрипт PowerShell.

В качестве примера посмотрим, как будет работать выборка ящиков, отправляющих больше всего писем:

Выборка наиболее активных ящиков.

При этом можно выбрать куда больше типов журналов. Например, в «чистом» Log Parser существуют ограничения по типам входных данных, и отдельного типа для Exchange нет ― нужно самостоятельно вводить описания полей и пропуск заголовков. В Log Parser Studio нужные форматы уже готовы к использованию.

Помимо Log Parser, с логами можно работать и при помощи возможностей MS Excel, которые упоминались в материале «Excel вместо PowerShell». Но максимального удобства можно достичь, подготавливая первичный материал при помощи Log Parser с последующей обработкой его через Power Query в Excel.

Приходилось ли вам использовать какие-либо инструменты для перелопачивания логов? Поделитесь в комментариях.