RSyslog – удобный способ сбора и обработки системных логов

На днях, по работе пришлось в форсированном порядке изучить методы сбора и анализа логов. Как основа – системный демон syslogd, но стандартный «вариант» имеет ряд ограничений. Основная задача, поставленная передо мною – централизованный сбор и удобное представление логов с множества серверов и других устройств. Сама идея сбора логов с серверов в одном месте не нова и является общепринятым решением в корпоративной среде.

Что нам дает сбор логов в одном месте (назовем это место лог-сервером). Можно выделить несколько положительных моментов, имеющих для каждого случая разную значимость. Но есть несомненные плюсы :

• Отпадает необходимость ежедневно мониторить логи на каждом сервере (особенно актуально, когда серверов целая «ферма»).  Все находится в одной контрольной точке.
• Логгирование идет и на локальную машину и на лог-сервер. В случае полного разрушения системы хранения данных сервера или в случае взлома, с последющей чисткой логов машины, мы не теряем драгоценную информацию, т.к. у нас есть копия на лог-сервере.

Уже этих двух факторов достаточно для аргументации введения системы централизованного сбора логов. Почему стоит использовать RSyslog а не другие варианты? Потому что RSyslog – оптимальное решение, функционально превосходящее свои аналоги и легко осваиваемое новичками. Немного предыстории вопроса….

Задача отправки логов на удаленный сервер и задача сбора логов (функция лог-сервера) легко реализуема возможностями старого и надежного syslogd демона. Запуск с ключом -r заставляет службу прослушивать 514 порт UDP протокола и принимать сообщения от других машин (клиентов). Отправка же логов на удаленный сервер осуществляется, в простейшем случае, одной строкой в конфиге /etc/syslog.conf и перезапуском демона логгирования. Конфигруация syslog позволяет отфильтровать сообщения по facility (что то вроде входного источника) и по serverity (уровень важности, всего 8 уовней). Конфигурирование стандартного syslog очень прозрачно и понятно, а главное давно переведено на множество языков. Я например ознакомился с конфигурированием syslog  на OpenNET.

Однако собрав все логи в кучу, становится очень трудно разбирать эти «завалы». Конечно можно настроить фильтры в клиентских машинах и слать не все сообщения, но все равно объем лог файлов становится неудобен для анализа. И вот тут все начинают искать выход. Я несколько дней рыл ресурсы сети и нашел два «живых» решения, которые продолжают развиватсья – syslog-ng (нью дженерейшен) и RSyslog. Оба решения – замена стандартного демона syslog и совместимы с его конфигурационными файлами. Остальные решения которые я нашел обычно либо слабее функционально либо давно не развиваются  (а чаще всего оба фактора сразу). Сказать что лучше: syslog-ng или RSyslog я не могу, да и не каджый поверит на слово. Однако беглый анализ функционала и схемы лицензирования, а так же ситуации с распространением склонил меня в сторону RSyslog. Одно из сравнений функциональных возможностей обеих систем можно найти тут – RSyslog vs Syslog-ng, сравнение хоть и расположено на сайте RSyslog, но претендует на объективность и дает некоторое представление о прелдагаемых возможностях.

Rsyslog позицианирует себя как  расширеный модуль syslogd для систем Linux и Unix, обладающий продвинутой многопоточностью и акцентированный на безопасности и надежности. Rsyslog предлагает широкий круг возможностей, с которым можно ознакомится перейдя по ссылке – RSyslog features.

Вот краткий функциональный перечень RSyslog:

• буферизация на жестком диске;
• удаленную передача логов на другой сервер (используя TCP, SSL, TLS и RELP);
• запись лого сразу в базу данных, а не только в файл (MySQL, Posrgres SQL, Oracle и множество других, через подключаемые расширения);
• нотификация используя email (smtp);
• полностью конфигурируемый и изменяемый формат сообщений (включая высокоточные временные метки);
• расширенные возможности фильтровки сообщений, дополняющие типичные facility.serverity (основанные на регулярных выражениях);
• возможность сжатия сообещий «на лету»;
• возможность чтения логфайлов с преобразованием к формату syslog;
• возможность легкого перехода с syslogd, благодаря совместимости конфигурацинных файлов;

В дополнение ко всему этому следует указать на доступный по GPL функциональный веб-интерфейс phpLogCon, который используется для визуализации, сортировки и анализа всех данных в режиме онлайн. Веб интерфейс phpLogCon позволяет визуализировать данные не только из базы данных (в которую пишет Rsyslog или Syslog-ng), но и данные из логфайлов. Пример интерфейса можно найти на специальном демо-сайте.

Еще одним значимым фактом, в пользу Rsyslog, является включение его в стандартную поставку  дистрибутива Fedora 8 (на замену syslogd), а так же включение в поставку грядущего Debian Lenny. Этих два факта выводят RSyslog на новый уровень.

PS

В заключение хочу сказать что проект бурно развивается и постоянно расширяет фурнкционал и повышает надежность. Единственный отрицательный момент – отсутствие нормальной документации (как следствие бурного развития),  и полное отсутствие информации на родном Русском языке. Но с этим я намерен бороться… заодно и свой уровень английского подниму…

PSPS

Rainer Gerhards

Rainer Gerhards – человек, которому мы можем сказать спасибо за Rsyslog и phpLogCon в том виде, который есть сейчас. Все таки немцы делают замечательные машины и хорошо программируют :)