syslog-ng: принимаем сообщения syslog в сети

Для начала, поменяем rsyslog на syslog-ng, так как последним представляется более гибким и удобным (хотя на вкус, как и на цвет, все фломастеры разные).

$ sudo aptitude install syslog-ng

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

Сама идеология syslog-ng достаточно простая. Главный конфигурационный файл логически разбит на секции:

• опции запуска и работы демона (options);
• источники сообщений syslog (source)
• назначения для вывода журналов (destination);
• описание фильтров (filter);
• описание журналов (log).

С блоком options всё более-менее ясно, выглядит он примерно так:

options {
    long_hostnames(off);
    flush_lines(0);
    use_dns(no);
    use_fqdn(no);
    owner("root");
    group("adm");
    perm(0640);
    stats_freq(0);
    bad_hostname("^gconfd$");
    ts_format(rfc3164);
    create_dirs(yes);
    keep_hostname(yes);
};

В общем-то опции имеют вполне вменяемые названия и об их назначении можно легко догадаться. Скажем так, из опций которые я добавил к конфигурации по-умолчанию, идущей после установки пакета из репозитория, только три: ts_format, create_dirs и keep_hostname.

Двигаемся далее - source. Описание источника s_src оставляем как есть и добавляем слушатель к своему сетевому интерфейсу:

source s_net { udp(ip(172.16.0.1)); };

ip-адрес должен быть прописан на сетевом интерфейсе, s_net говорит о том,что слушать входящие сообщения необходимо на адресе 172.16.0.1 по порту udp/514.

Далее формируем фильтр для принимаемых syslog сообщений:

filter f_orion { netmask(10.254.103.38/32); };

Под действия этого фильтра попадают все сообщения пришедшие с ip-адреса 10.254.103.38. Маску сети можно задать как /30, /29 и т.д., таким образом можно расширить диапазон источников сообщений. Можно задать несколько сетей источников, например так:

filter f_orion { netmask(10.254.103.38/32) or netmask(172.16.0.0/27); };

Также можно отфильтровать некоторые нежелательные сообщения:

filter f_orion { netmask(10.254.103.38/32) and not match("%FAN-3-FAN_" value("MESSAGE")); };

Тут говорится о том, что все сообщения в которых будет встречено вхождение %FAN-3-FAN_ не будут включены в дальнейшую обработку (not).
Вместо netmask можно использовать host:

filter f_orion { host(10.254.103.38) and not match("%FAN-3-FAN_" value("MESSAGE")); };

но не каждому это подойдёт, например если источник из которого принимается syslog-сообщение не совпадает с устройством его генерирующим то в журнал, при использовании host, будет записан адрес устройства с которого принято сообщение, а не то устройство которое его сгенерировало. Это актуально при настройке syslog-сервера на пересылку сообщений на другой syslog-сервер. В случае когда источник syslog-сообщения и устройство на котором генерируется это сообщение совпадают то директивы netmask и host должны себя вести идентично.

Пришло время описать сам журнал, связав источник, фильтр и назначение в одно правило:

log { source(s_net); filter(f_orion); destination(d_orion); };

Отдельно хочется заметить, что в используемой сейчас нами версии Orion'а форвард syslog-сообщений работает несколько "криво", поэтом альтернативой был выбран не Forward, а Send, в котором и формируется более "вменяемое" сообщение, с нормально отрезолвленым названием узла сформировавшего исходное  сообщение, которое уже можно анализировать. Ну, а далее журналы по разным узлам разбираются примерно таким образом:

destination d_device_name { file("/var/log/noc-orion/orion.device_name.log"); };
filter f_device_name { netmask(10.254.103.38/32) and match("\\\[device_name\\\]" value("MESSAGE")) and not match("%FAN-3-FAN_" value("MESSAGE")); };
log { source(s_net); filter(f_device_name); destination(d_device_name); };