UMGUM.COM (лучше) 

ISC-DHCPd + Syslog ( Простейшая настройка журналирования DHCP-сервера в Linux. )

20 сентября 2017  (обновлено 8 декабря 2017)

OS: Linux Debian 6/7/8/9.
Application: ISC-DHCPd, Syslog и Logrotate.

Задача: наладить сбор сообщений о событиях обслуживания сервером клиентских DHCP-запросов в отдельном журнальном файле.

Используемый в Linux и BSD сервер автоматизации выдачи сетевых настроек "ISC DHCPd" (далее DHCPd) старенький и местами странно отсталый. Американский "Internet Systems Consortium" выпустил его первую стабильную версию в конце 1997 года, прошли десятилетия, в 2017 году мы уже пользуемся четвёртой версий, а средств управления без перезапуска этим сервисом нет, как отсутствует и поддержка возможности направить сообщения о событиях в произвольный файл. За двадцать лет важнейший и привычный всем функционал так и не добавили - но альтернативы нет, и мы продолжаем жить с тем, что неудобно, но работает.

По умолчанию весь поток сообщений о взаимодействии с клиентами DHCPd отправляет в подсистему журналирования "syslog" несущей операционной системы. Казалось бы, пусть себе шлёт их, куда захочет. В общем, пусть бы оно и так, но для сети в пару десятков тысяч пользователей поток сообщений льётся так обильно, что полностью забивает собой всё остальное - можно считать, что об остальных системных событиях вы уже не узнаете.


Определение параметров журналирования в DHCPd.

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

# vi /etc/dhcp/dhcpd.conf

....
# Use this to send dhcp log messages to a different log file (you also
# have to hack syslog.conf to complete the redirection).
log-facility local7;
....

Не обязательно использовать метку "local7", но она фигурирует в примере от разработчиков, и не конфликтует с метками других распространённых сервисов - так что проще оставить "по умолчанию".

Как я упоминал выше, применение параметров без полного перезапуска DHCPd не поддерживается, так что особо важно предварительно проверить, не допущено ли ошибок в конфигурации такового:

# /usr/sbin/dhcpd -f -t -q
# /etc/init.d/isc-dhcp-server restart

На данный момент три приложения системы журналирования в Linux актуальны и используются: "Syslog", "RSyslog" и "Syslog-NG" - рассмотрим способы обработки сообщений DHCPd в каждой из них.

Сбор событий DHCPd в отдельном файле посредством "Syslog".

Старая и простая подсистема, в которой всё с интересующей нас меткой просто отправляется в файл, после чего обработка пакета данных завершается:

# vi /etc/syslog.conf

....
loca7.*  /var/log/dhcpd.log
....

# /etc/init.d/syslog reload

Сбор событий DHCPd в отдельном файле посредством "RSyslog".

В этой, пришедшем на замену "Syslog"-у, подсистеме журналирования, по умолчанию обработка пакета данных продолжается даже после совпадения с критерием фильтрации - явно останавливаем процесс операндом "& ~":

# vi /etc/rsyslog.d/dhcpd.conf

local7.* /var/log/dhcpd.log
& ~

# /etc/init.d/rsyslog reload

Сбор событий DHCPd в отдельном файле посредством "Syslog-NG".

В наиболее современном "Syslog-NG" управление потоками гибче, но существенно сложнее - приходится не только вылавливать нужное, но и отсекать это же там, где оно помешает:

# vi /etc/syslog-ng/syslog-ng.conf

....
# Указываем целевой файл журнала
destination d_dhcpd { file("/var/log/dhcpd.log"); };

# Описываем критерии фильтрации (можно по "метке", но эффективнее по наименованию испускающего событие приложению)
// filter f_dhcpd { facility(local7); };
filter f_dhcpd { program('^dhcpd$'); };

# Добавляем в некоторые имеющиеся фильтры указания исключать из них уже захваченное фильтром "f_dhcpd":
filter f_debug { .... and not filter(f_dhcpd); };
filter f_error { .... and not filter(f_dhcpd); };
filter f_messages { .... and not filter(f_dhcpd); };
filter f_syslog { .... and not filter(f_dhcpd); };

# Формируем цепочку обработчиков, которая обслуживает поток сообщений DHCPd
log { source(s_src); filter(f_dhcpd); destination(d_dhcpd); };
....

# /etc/init.d/syslog-ng reload

Настройка ротации файлов журнала.

Конечно же, если поддержка вывода журнала событий в DHCPd отсутствует, то усечения и ротация такового тоже не предусмотрена. Исправим это:

# vi /etc/logrotate.d/dhcpd

/var/log/dhcpd.log {
  weekly
  rotate 7
  size 100M
  missingok
  notifempty
  compress
  delaycompress
  copytruncate
  su root root
}

Проверяем корректность настройки ротации:

# logrotate -d /etc/logrotate.d/dhcpd

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


Заметки и комментарии к публикации:


Оставьте свой комментарий ( выразите мнение относительно публикации, поделитесь дополнительными сведениями или укажите на ошибку )