Перевод статьи «Sending Apache httpd Logs to Syslog» автора Rich Bowen.
Каждый раз, когда ваш сервер Apache получает запрос, он создает запись в одном или нескольких лог-файлах. Эти лог-файлы полезны для разных целей, от статистического анализа ваших посетителей до анализа атаки на ваш сервер.
Во многих случаях, наличие этих логов, записанных в локальной файловой системе, по крайней мере, неудобно. Два отдельных сценария пришли мне в голову, но, возможно, у вас есть другие.
С первым я, к сожалению, имел личный опыт. Когда взломщики атакуют сервер, они часто «убираются» за собой, так что вы не можете вычислить, как они проникли. Если они осторожны, это включает в себя удаление логов, так что вы не можете увидеть, какие техники они использовали. Это особенно важно, если они использовали сам веб-сервер в качестве способа проникновения, а некоторые скрипты-эксплойты просто удаляют лог-файлы для надежности. В этом случае, очень полезно иметь копию лог-файлов где-нибудь ещё.
Второй сценарий, возможно, менее вероятен, но он просто интересен. Когда у вас более одного сервера, — особенно если их у вас дюжины или сотни, — довольно трудно просматривать все ваши логи, так как их очень много. В этом случае, может быть полезно комбинировать их в одном месте.
В обоих случаях, посылать логи в центральный сервер syslog будет идеальным вариантом, в отличие от записи в локальной файловой системе.
Ведение лога в syslog
Так получилось, что мало людей знает о том, что Apache может вести лог ошибок в syslog с помощью одной директивы настройки:
ErrorLog syslog:local1
Это почти все, что надо сделать. Эта строка сообщает Apache посылать лог ошибок в syslog под названием local1. Конечно, вам также надо сказать вашему серверу syslog отправлять этот лог другому серверу, вашему серверу syslog, чтобы записывать его в лог-файл.
То, как именно вы можете это сделать, будет зависеть от реализации syslog. Как бы то ни было, обычный syslog в Linux использует файл под названием /etc/syslog.conf (или что-то похожее) для настройки отправки сообщений syslog.
Так как лог ошибок Apache использует стандартный для syslog вид, вы можете использовать обычные настройки syslog для разделения вывода данных syslog в различные файлы. Например, если вы хотите вести лог только для критических ошибок в отдельном файле, добавьте следующую строку в файл /etc/syslog.conf:
local1.crit /var/log/apache.crit
Это инициирует ведение лога записей уровня crit и выше в файл /var/log/apache.crit
Я обещал, что вы можете отправлять записи лога на другой сервер. Для этого пропишите такую строчку:
local1.* @192.168.200.12
Вам также надо настроить удаленный сервер syslog для принятия этих записей лога. Для большинства серверов syslog, это делается добавлением параметра -r к другим параметрам запуска сервера syslog. Тем не менее, это может быть по-другому в другой реализации, так что обратитесь к документации вашего syslog сервера.
Отправка логов доступа
К сожалению, только логи ошибок имеют такую встроенную возможность. Но крайне полезно также иметь логи доступа в наличии на удаленном сервере, по причинам, описанным выше.
Вот способ отправлять лог доступа в syslog. Однако, как и в любой другой подобной статье, я призываю вас прочитать документацию к Apache, так как эта возможность может быть встроена в будущем. На данный момент, вот что вам надо сделать. Весь процесс можно разделить на два шага.
Во-первых, создайте скрипт, который будет отправлять записи в syslog:
#!/usr/bin/perl
use Sys::Syslog qw( :DEFAULT setlogsock );
setlogsock('unix');
openlog('apache', 'cons', 'pid', 'local2');
while ($log = ) {
syslog('notice', $log);
}
closelog;
Этот скрипт, написанный на Perl, использует модуль Sys::Syslog для отправки данных серверу syslog. Убедитесь, что модуль Sys::Syslog установлен у вас, хотя, он должен быть стандартным для последних версий Perl.
Поместите куда-нибудь этот скрипт и сделайте его исполняемым. Для этого примера, я подразумеваю, что вы сохранили его, как /usr/local/apache/bin/apache_syslog.
Во-вторых, направьте ваш лог доступа на этот скрипт, используя pipe-синтаксис лог-файла:
CustomLog |/usr/local/apache/bin/apache_syslog combined
Скрипт apache_syslog будет запускаться при старте веб-сервера и обрабатывать записи лог-файла так, словно он получает их от сервера. Цикл while будет продолжаться, пока работает процесс Apache.
Как вы видите в скрипте, он отправляет эти записи в syslog под названием local2, так что настройте ваш syslog сервер с помощью следующей строки в /etc/syslog.conf:
local2.* @192.168.200.12
Ознакомьтесь с документацией модуля Sys::Syslog для получения более подробной информации о доступных опциях данного модуля.
С этой настройкой, в случае атаки на ваш сервер или фатальной ошибки, у вас по-прежнему будет удаленная копия ваших логов для того, чтобы понять, что произошло.
Примите во внимание и то, что если у вас есть несколько директив CustomLog, у вас могут и быть несколько лог-файлов. Поэтому, если вы хотите иметь локальный лог-файл вдобавок к удаленному, просто добавьте ещё одну директиву CustomLog, указывающую на локальный лог-файл:
CustomLog /usr/local/apache/logs/access_log combined
Предостережения
Конечно, существует пара предостережений при ведении лога в syslog.
Первое: если вы ведете лог с нескольких серверов в центральный сервер syslog, важным будет то, чтобы держать ваши часы синхронизированными с NTP. Если вы этого не сделаете, записи логов будут не будут поступать в правильном порядке, и это может вызвать трудности при обработке логов для получения статистической информации. В частности, некоторое программное обеспечение, производящее статистическую обработку, может неправильно сработать и прервать процесс своей работы.
Второе: я упомянул, что мой сервер syslog объединяет несколько записей лога в одну строку, в случае, если они одинаковые. Например, повторяющийся запрос к одному и тому же отсутствующему файлу, получит такое отображение:
Aug 31 20:18:05 192.168.200.10 last message repeated 19 times
Наконец, не лишним будет упомянуть о существовании сторонних модулей для ведения логов на нескольких серверах. Самым популярным из таких модулей является mod_log_spread, который может быть более подходящим решением для очень больших (если в наличии много серверов) инсталляций.
|
