Плагины Fluentd: расширяем возможности
Плагины ввода
- in_forward — прослушивает TCP-сокет;
- in_http — принимает сообщения, передаваемые в POST-запросах;
- in_tail — считывает сообщения, записанные в последних строках текстовых файлов (работает так же, как команда tail -F);
- in_exec — с помощью этого плагина можно запускать стороннюю программу и получать её лог событий; поддерживаются форматы JSON, TSV и MessagePack;
- in_syslog — с помощью этого плагина можно принимать сообщения в формате syslog по протоколу UDP;
- in_scribe — позволяет получает сообщения в формате Scribe (Scribe — это тоже коллектор логов, разработанный Facebook).
Как происходит логирование?
Все программы Linux ведут лог путем отправки сообщений об ошибках или своем состоянии с помощью сокета syslog или просто записывая все сообщения в файл, который будет находиться в каталоге /var/log/.
Но важное значение имеет уровень подробности логирования. Вы можете настраивать подробность в каждой отдельной программе, или же с помощью syslog
Это поможет уменьшить использование дискового пространства, на хранение логов. Но тут нужно найти компромисс между количеством информации и использованием диска.
Например, ядро Linux определяет такие уровни логов, или как мы будем называть их ниже — приоритеты:
- KERN_EMERG — система неработоспособна;
- KERN_ALERT — нужно немедленно принять меры;
- KERN_CRIT — критическая ошибка;
- KERN_ERR — обычная ошибка;
- KERN_WARNING — предупреждение;
- KERN_NOTICE — замечание;
- KERN_INFO — информационное сообщение;
- KERN_DEBUG — сообщения отладки.
Подобные уровни лога поддерживаются в большинстве программ, которые ведут логи.
Клиент: пересылка логов с сохранением имени файла
Сохранять имена файлов мы будем в поле . В имена хочется включить каталоги, чтобы не наблюдать одноуровневую россыпь файлов: . Если лог читается не из файла, а из переданных в syslog сообщений от программы, то она может не согласиться записывать в TAG символ , потому что это не соответствует стандарту. Поэтому мы закодируем их двойными подчеркиваниями, а на лог-сервере распарсим обратно.
Создадим шаблон для передачи логов по сети. Мы хотим передавать сообщения с тегами длиннее 32 символов (у нас длинные названия логов), и передавать более точную, чем стандартную, метку времени с указанием временной зоны. Кроме того, к названию лог-файла будет добавлена локальная переменная , позже станет понятно, зачем. Локальные переменные в RainerScript начинаются с точки. Если переменная не определена, она раскроется в пустую строку.
Теперь создадим RuleSet, который будут использоваться для передачи логов по сети. Его можно будет присоединять к Input, читающим файлы, или вызывать как функцию. Да, rsyslog позволяет вызвать один RuleSet из другого. Для использования RELP надо сначала загрузить соответствующий модуль.
Теперь создадим Input, читающий лог-файл, и присоединим к нему этот RuleSet.
Стоит обратить внимание, что для каждого считываемого файла rsyslog создаёт state-файлы в своём рабочем каталоге (задаётся директивой ). Если rsyslog не может создавать там файлы, то весь лог-файл будет заново передаваться после перезапуска rsyslog
В случае, если какое-то приложение пишет в общий syslog с определённым тегом, и мы хотим как сохранять это в файл, так и пересылать по сети:
Последний нужен, чтобы прекратить обрабатывать эти сообщения, иначе они попадут в общий syslog. Кстати, если приложение умеет выбирать другой unix socket для syslog, кроме стандартного (nginx и haproxy так умеют), то можно с помощью модуля imuxsock сделать для этого сокета отдельный Input и прицепить к нему нужный RuleSet, не разбирая логи из общего потока по тегам.
Чтение лог-файлов, заданных через wildcard
Интерлюдия
Программист: Не могу найти на лог-сервере логи somevendor.log за начало прошлого месяца, посмотри плиз.
Девопс: Эээ… а мы разве пишем такие логи? Предупреждать же надо. Ну в любом случае всё старше недели логротейт потёр, если мы его не сохраняли — значит уже нету.
Программист: бурно возмущается
Если приложение пишет много разных логов, и иногда появляются новые, то обновлять конфиги каждый раз неудобно. Хочется это автоматизировать. Модуль imfile умеет считывать файлы, заданные вайлдкардом, и сохранять в мета-данных сообщения путь к файлу. Правда, путь сохраняется полный, а нам нужен только последний компонент, который оттуда придётся добыть. Кстати, тут нам и пригодится переменная
Вайлдкарды поддерживаются только в режиме работы imfile (это режим по-умолчанию). Начиная с верcии 8.25.0, вайлдкарды поддерживаются как в имени файла, так и пути: /var/log/.log.
Многострочные сообщения
Для работы с лог-файлами, содержащими многострочные сообщения, модуль imfile предлагает три варианта:
- — сообщения разделены пустой строкой
- — новые сообщения начинаются с начала строки, продолжение сообщения идёт с отступом. Часто так выглядят стектрейсы
- — определять начало нового сообщения по regexp (POSIX Extended)
Первые два варианта имеют проблемы в режиме работы , и при необходимости третий легко их заменяет с соответствующим regexp. Считывание многострочных логов имеет одну тонкость. Обычно признак нового сообщения находится в его начале, и мы не можем быть уверены, что программа закончила писать прошлое сообщение, пока не началось следующее. Из-за этого последнее сообщение может никогда не передаваться. Чтобы этого избежать, мы задаём , по истечении которого сообщение считается законченным и будет передано.
Выбор софта
Зачем вообще нужен syslog-сервер, когда есть elastic beats, logstash, systemd-journal-remote и ещё много новых блестящих технологий?
- Это стандарт для ведения логов в POSIX-совместимых системах.
Некоторый софт, например haproxy, использует только его. То есть совсем избавится от syslog вам всё равно не удастся - Его использует сетевое железо
- Сложнее в настройке, но богаче по возможностям, чем альтернативные решения.
Например, Elastic Filebeat до сих пор не умеет inotify. - Нетребователен к памяти. Возможно использование на embedded системах после небольшого тюнинга.
- Позволяет изменять сообщение перед сохранением/пересылкой.
Странная задача, но иногда требуется. Например, PCI DSS в разделе 3.4 требует маскировать или шифровать номера карт, если они сохраняются на диск. Тонкость в том, что если кто-то ввёл номер карты в строку поиска или в форму обратной связи, то как только вы сохранили запрос в лог, вы нарушаете стандарт.
Наблюдение: пользователи пытаются ввести номер карты в любое поле ввода на странице, и норовят сообщить его саппорту вместе с CVV.
Подготовка сервера
На сервере нужно, предварительно, выполнить следующие настройки.
Время
Для правильной фиксации времени логов, необходимо настроить его синхронизацию.
Сначала задаем правильный часовой пояс:
\cp /usr/share/zoneinfo/Europe/Moscow /etc/localtime
* в данном примере мы использовали московское время.
Затем устанавливаем и запускаем chrony.
а) на системе CentOS / Red Hat:
yum install chrony
systemctl enable chronyd
systemctl start chronyd
б) на системе Ubuntu / Debian:
apt-get install chrony
systemctl enable chrony
systemctl start chrony
Брандмауэр
Если используется брандмауэр, необходимо открыть порты TCP/UDP 514.
а) с помощью firewalld:
firewall-cmd —permanent —add-port=514/{tcp,udp}
firewall-cmd —reload
б) с помощью iptables:
iptables -A INPUT -p tcp —dport 514 -j ACCEPT
iptables -A INPUT -p udp —dport 514 -j ACCEPT
в) с помощью ufw:
ufw allow 514/tcp
ufw allow 514/udp
ufw reload
SELinux
Проверяем, работает ли в нашей системе SELinux:
getenforce
Если мы получаем в ответ:
Enforcing
… необходимо либо настроить SELinux:
semanage port -m -t syslogd_port_t -p tcp 514
semanage port -m -t syslogd_port_t -p udp 514
… либо отключить его командами:
setenforce 0
sed -i ‘s/^SELINUX=.*/SELINUX=disabled/g’ /etc/selinux/config
Установка и настройка syslog-ng
С установкой нет ничего сложного. Установить syslog-ng можно одной командой:
# yum install -y syslog-ng
Сразу переходим к настройке. Файл конфигурации располагается по адресу /etc/syslog-ng/syslog-ng.conf. Чтобы сервер начал принимать логи с удаленного устройства, его необходимо прописать в конфиг. Делается это просто. В самый конец конфигурационного файла добавляем информацию о новом устройстве:
destination d_xs-zabbix { file("/var/log/!remote/xs-zabbix.log"); }; filter f_xs-zabbix { netmask("10.1.3.29/255.255.255.255"); }; log { source(net); filter(f_xs-zabbix); destination(d_xs-zabbix); };
d_xs-zabbix | Название назначения для записи лога по адресу /var/log/!remote/xs-zabbix.log |
f_xs-zabbix | Название фильтра по адресу сервера источника. |
10.1.3.29 | Адрес сервера источника логов |
Соответственно для второго сервера нужно добавить еще 3 строки, например так:
destination d_xs-web { file("/var/log/!remote/xs-web.log"); }; filter f_xs-web { netmask("10.1.3.38/255.255.255.255"); }; log { source(net); filter(f_xs-web); destination(d_xs-web); };
И так далее. Добавляете столько серверов, сколько нужно. Не забудьте создать папку для логов. В моем примере это папка /var/log/!remote, сами файлы создавать не надо, служба автоматически их создаст, когда придет информация с удаленных серверов.
Запускаем syslog-ng и добавляем в автозагрузку:
# systemctl start syslog-ng # systemctl enable syslog-ng
Проверим, запустилась ли служба:
# netstat -tulnp | grep syslog udp 0 0 0.0.0.0:514 0.0.0.0:* 25960/syslog-ng
Все в порядке, слушает 514 udp порт. Не забудьте открыть этот порт в iptables, если у вас включен фаерволл. Сервер готов к приему логов.
Веб интерфейс для rsyslog
В качестве веб-интерфейса будем настраивать Loganalizer от adiscon. Установка веб интерфейса довольно проста. Заключается в скачивании архива, распаковке в каталог веб сервера и запуск графического мастера настройки. Итак, отсюда (http://loganalyzer.adiscon.com/downloads) качаем архив с файлами (Например: http://download.adiscon.com/loganalyzer/loganalyzer-3.5.6.tar.gz). Перед настройкой, конечно же должен быть установлен Web сервер и модуль php5 (aptitude install apache2 libapache2-mod-php5). А да, еще php5-gd для отображения отчетов.
~ # # Скачиваем архив: ~ # wget http://download.adiscon.com/loganalyzer/loganalyzer-3.5.6.tar.gz ~ # # распаковываем архив: ~ # tar xf loganalyzer-3.5.6.tar.gz
В текущем каталоге появится каталог loganalyzer-3.5.6, который содержит некоторую информацию, достойную прочтения:
~ # ls -l итого 12 drwxr-xr-x 3 root root 4096 Сен 20 22:51 . drwx------ 13 root root 4096 Сен 20 23:01 .. drwxrwxr-x 5 root root 4096 Сен 10 17:26 loganalyzer-3.5.6 ~ # ls -l loganalyzer-3.5.6/ итого 112 -rw-rw-r-- 1 root root 41186 Сен 10 17:26 ChangeLog drwxrwxr-x 2 root root 4096 Сен 20 23:01 contrib -rw-rw-r-- 1 root root 35497 Сен 10 17:26 COPYING drwxrwxr-x 2 root root 4096 Сен 10 17:34 doc -rw-rw-r-- 1 root root 8449 Сен 10 17:26 INSTALL drwxrwxr-x 14 root root 4096 Сен 10 17:34 src ~ # # из каталога src нам необходимо скопировать содержимое в /var/www/loganalyzer: ~ # mkdir /var/www/loganalyzer ~ # cp -r loganalyzer-3.5.6/src/* /var/www/loganalyzer ~ # # далее,необходимо создать пустой файл конфигурации, ~ # # который будет заполнен автоматически - установщиком ~ # touch /var/www/loganalyzer/config.php ~ # # зададим права на запись (после установки эти права можно убрать) ~ # chmod 666 /var/www/loganalyzer/config.php
Далее, пытаемся зайти на http://10.0.0.1/loganalyzer и видим чудо:
жмахаем here
Видим, для чего мы давали права 666, нажимаем Next
Здесь выбираем желаемые настройки. Отдельного внимания требует параметр Enable User Database. Если выбрать его, то будет создана отдельная база для хранения настроек Веб-интерфейса. Так же, будет доступна возможность создавать пользователей и группы. Жмем next.
Странно, но куда то пропало 6 шагов. (это потому что на прошлом шаге мы не выбрали хранение настроек в базе). На данном шаге выбираем источник сообщений (файл, sql) и указываем соответствующие параметры.
Это все. Ниже пару скриншотов того, что получилось:
Есть маленькое дополнение — веб сервер не имеет доступа к обычным файлам в каталоге /var/log/. Поэтому, журнал может не отображаться. Чтобы решить данную проблему, необходимо добавить пользователя www-data в группу adm:
~ # usermod -G adm www-data
Кроме Loganalyzer существует так же — Logzilla, обладающая тем же функционалом. Ее тоже стоит попробовать установить, если есть желание.
2 Logstash
Если вы являетесь поклонником или пользователем стека Elastic, стоит попробовать Logstash (стек ELK )
Как и другие инструменты ведения журнала в этом списке, у Logstash,полностью открытый исходный код, дает вам свободу развертывания и использования по своему усмотрению.
Но не вводите себя в заблуждение: Logstash – это иснтрумент, возможности которого намного превосходят любые скромные средства ведения журналов.
Он способен собирать огромные объемы данных с разных платформ, позволяет определять и выполнять собственные конвейеры данных, понимать неструктурированные дампы журналов и многое другое.
Конечно, единственным ограничением является то, что он работает только с набором продуктов Elastic, но если вы скоро начнете и хотите масштабироваться, Logstash – это то, что вам нужно!
Формат сообщений и legacy
Сообщения syslog при передаче по сети выглядят примерно так:
— Priority. Вычисляется как .Facility (категория) принимает значения от 0 до 23, им соответствуют различные категории системных служб: 0 — kernel, 2 — mail, 7 — news. Последние 8 — от local0 до local7 — определены для служб, не попадающих в предопределённые категории
.
Severity (важность) принимает значения от 0 (emergency, самая высокая) до 7 (debug, самая низкая). .
— время, обычно в формате «Feb 6 18:45:01»
Согласно RFC 3164, может записываться в формате времени ISO 8601: «2017-02-06T18:45:01.519832+03:00» с большей точностью и с учётом используемой временной зоны.
— имя хоста, сгенерировавшего сообщение
— содержит имя программы, сгенерировавшей сообщение. Не более 32 алфавитно-цифровых символов, хотя по факту многие реализации позволяют больше. Любой не-алфавитноцифровой символ заканчивает TAG и начинает MSG, обычно используется двоеточие. Иногда в квадратных скобках содержит номер сгенерировавшего сообщение процесса. Т. к. — не алфавитно-цифровые символы, то номер процесса вместе с ними должен считаться частью сообщения. Но обычно все реализации считают это частью тега, считая сообщением всё после символов «: «
— сообщение. Из-за неопределённости с тем, где же кончается тег и начинается сообщение, в начало может добавляться пробел. Не может содержать символов перевода строки: они являются разделителями фреймов, и начнут новое сообщение. Способы всё же переслать мгногострочное сообщение:экранирование. Получим на стороне приёмника текст с вместо переводов строки
использование octet-counted TCP Framing, как определено в RFC 5425 для TLS-enabled syslog. Нестандарт, только некоторые реализации.
Альтернатива протоколу syslog: RELP
Если сообщения пересылаются между хостами, использующими rsyslog, можно вместо plain TCP sysog использовать RELP — Reliable Event Logging Protocol. Был создан для rsyslog, сейчас поддерживается и некоторыми другими системами. В частности, его понимают Logstash и Graylog. Для транспорта использует TCP. Может опционально шифровать сообщения с помощью TLS. Надёжнее plain TCP syslog, не теряет сообщения при разрыве соединения. Решает проблему с многострочными сообщениями.
Клиент: пересылка логов с сохранением имени файла
Сохранять имена файлов мы будем в поле . В имена хочется включить каталоги, чтобы не наблюдать одноуровневую россыпь файлов: . Если лог читается не из файла, а из переданных в syslog сообщений от программы, то она может не согласиться записывать в TAG символ , потому что это не соответствует стандарту. Поэтому мы закодируем их двойными подчеркиваниями, а на лог-сервере распарсим обратно.
Создадим шаблон для передачи логов по сети. Мы хотим передавать сообщения с тегами длиннее 32 символов(у нас длинные названия логов), и передавать более точную, чем стандартную, метку времени с указанием временной зоны. Кроме того, к названию лог-файла будет добавлена локальная переменная , позже станет понятно, зачем. Локальные переменные в RainerScript начинаются с точки. Если переменная не определена, она раскроется в пустую строку.
Теперь создадим RuleSet, который будут использоваться для передачи логов по сети. Его можно будет присоединять к Input, читающим файлы, или вызывать как функцию. Да, rsyslog позволяет вызвать один RuleSet из другого. Для использования RELP надо сначала загрузить соответствующий модуль.
Теперь создадим Input, читающий лог-файл, и присоединим к нему этот RuleSet.
Стоит обратить внимание, что для каждого считываемого файла rsyslog создаёт state-файлы в своём рабочем каталоге(задаётся директивой ). Если rsyslog не может создавать там файлы, то весь лог-файл будет заново передаваться после перезапуска rsyslog
В случае, если какое-то приложение пишет в общий syslog с определённым тегом, и мы хотим как сохранять это в файл, так и пересылать по сети:
Последний нужен, чтобы прекратить обрабатывать эти сообщения, иначе они попадут в общий syslog. Кстати, если приложение умеет выбирать другой unix socket для syslog, кроме стандартного (nginx и haproxy так умеют), то можно с помощью модуля imuxsock сделать для этого сокета отдельный Input и прицепить к нему нужный RuleSet, не разбирая логи из общего потока по тегам.
Чтение лог-файлов, заданных через wildcard
Интерлюдия
Программист: Не могу найти на лог-сервере логи somevendor.log за начало прошлого месяца, посмотри плиз
Девопс: Эээ… а мы разве пишем такие логи? Предупреждать же надо. Ну в любом случае всё старше недели логротейт потёр, если мы его не сохраняли — значит уже нету.
Программист: бурно возмущается
Если приложение пишет много разных логов, и иногда появляются новые, то обновлять конфиги каждый раз неудобно. Хочется это автоматизировать. Модуль imfile умеет считывать файлы, заданные вайлдкардом, и сохранять в мета-данных сообщения путь к файлу. Правда, путь сохраняется полный, а нам нужен только последний компонент, который оттуда придётся добыть. Кстати, тут нам и пригодится переменная
Вайлдкарды поддерживаются только в режиме работы imfile (это режим по-умолчанию).
Многострочные сообщения
Для работы с лог-файлами, содержащими многострочные сообщения, модуль imfile предлагает три варианта:
- — сообщения разделены пустой строкой
- — новые сообщения начинаются с начала строки, продолжение сообщения идёт с отступом. Часто так выглядят стектрейсы
- — определять начало нового сообщения по regexp(POSIX Extended)
Первые два варианта имеют проблемы в режиме работы , и при необходимости третий легко их заменяет с соответствующим regexp. Считывание многострочных логов имеет одну тонкость. Обычно признак нового сообщения находится в его начале, и мы не можем быть уверены, что программа закончила писать прошлое сообщение, пока не началось следующее. Из-за этого последнее сообщение может никогда не передаваться. Чтобы этого избежать, мы задаём , по истечении которого сообщение считается законченным и будет передано.
Некоторые типсы и триксы для rsyslog
Иногда, когда rsyslog является сетевым сервисом для сбора удаленных логов, хранение сообщений по имени хоста неудобно или непроизводительно или может еще что-то. Чтобы отключить резолвинг ip адресов в хостнеймы, необходимо добавить параметр -x:
~ # cat /etc/default/rsyslog RSYSLOGD_OPTIONS="-c5 -x"
Для того чтобы разрешить в нетфильтре прохождение udp пакетов, необходимо использовать команду:
~ # iptables -A INPUT -p udp -s подсеть_источник --dport 514 -i интерфейс -j ACCEPT
Некоторые примеры правил с комментариями:
# если создаете селектор вот такого типа:
if $fromhost-ip startswith ‘10.0.1.’ then /что/то
# стоит обратить внимание на последнюю точку в адресе,
# иначе под правило подпадут адреса из подсети 10.0.111.0, 10.0.12.0 и другие
Для централизованного сервера сбора логов с сетевых устройств, можно на сетевых устройствах установить источник (facility) в какое-либо значение из local0-local7. Это позволит удобно сортировать сообщения, пример:
# cisco: net-device-cisco#conf t Enter configuration commands, one per line. End with CNTL/Z. <...> net-device-cisco(config)#logging facility local2 <...> # rsyslog-server local2.* /var/log/remote-cisco.log & ~
Таким образом, можно удобно фильтровать локальные сообщения от удаленных.
Вот некоторый конфиг, который позволяет отправлять почтовые уведомления о событиях (!!! почтовый сервер должен принимать сообщения без аутентификации):
$ModLoad ommail $ActionMailSMTPServer адрес_smtp $ActionMailSMTPPort 25 $ActionMailFrom адрес@отправителя $ActionMailTo адрес@получателя $template mail_subject,"On host %hostname%, Error-level by serverity" $template mail_body,"Facility.Serverity: %syslogfacility%.%syslogpriority% at %timegenerated% on host: %HOSTNAME%\r\n %msg%" $ActionMailSubject mail_subject # интервал времени (пауза между письмами) $ActionExecOnlyOnceEveryInterval 10 # фильтр отбора и действие if not ($msg contains 'что_то'\ or $msg contains 'еще_что_то'\ or $msg contains 'может_еще_что_то' )\ and ($syslogseverity-text =='err'\ or $syslogseverity-text =='crit'\ or $syslogseverity-text =='alert'\ or $syslogseverity-text =='emerg' )\ then :ommail:;mail_body
Траблешуттинг
Для диагностики работы syslog отлично помогает tcpdump, пример команды для мониторинга:
~ # tcpdump -vvv -nn -i интерфейс udp port 514
Ну и, конечно же сам /var/log/syslog.
Что еще почитать
https://www.suse.com/releasenotes/x86_64/SUSE-SLES/11-SP2/ — rsyslog внедряется в SuSe
http://www.debian.org/releases/lenny/i386/release-notes/ch-whats-new.en.html#system-changes — rsyslog внедряется в Debian
https://access.redhat.com/knowledge/docs/en-US/Red_Hat_Enterprise_Linux/5/html-single/5.2_Release_Notes/index.html#sect-Red_Hat_Enterprise_Linux-Release_Notes-Feature_Updates — rsyslog внедряется в RedHat
http://www.bog.pp.ru/work/syslog.html#linux — очень много русифицированных параметров и директив
http://www.rsyslog.com/doc — документация от разработчика
http://www.rsyslog.com/doc/rsyslog_conf_modules.html — модули rsyslog
http://tools.ietf.org/html/rfc3164 — RFC syslog
http://wiki.rsyslog.com/index.php/Configuration_Samples — примеры конфигураций
http://www.rsyslog.com/tag/more-complex-scenarios/ — многие примеры брал отсюда
http://www.rsyslog.com/doc/property_replacer.html — переменные в конфиге, такие как hostname $year …
Резюме
Статья получилась мега большая. В перспективе, наверно разделю ее на 2 более подробные… В целом, думаю, что прочитав материал — удастся получить достаточный объем базового понимания принципов работы rsyslog, чтобы реализовать своё более сложное и интересное решение. До новых статей!
Обработка сообщений
- Все сообщения приходят из Input (их может быть много) и попадают на обработку в привязанный к нему RuleSet. Если это явно не задано, то сообщения попадут в RuleSet по-умолчанию. Все директивы обработки сообщений, не вынесенные в отдельные RuleSet-блоки, относятся именно к нему. В частности, к нему относятся все директивы из традиционного формата конфигов:
- к Input привязан список парсеров для разбора сообщения. Если явно не задано, будет использоваться список парсеров для разбора традиционного формата syslog
- Парсер выделяет из сообщения свойства. Самые используемые:
- — сообщение
- — сообщение целиком до обработки парсером
- , — DNS имя и IP адрес хоста-отправителя
- , — facility в числовой и текстовой форме
- , — то же для severity
- — время из сообщения
- — поле TAG
- — поле TAG с отрезанным id процесса: ->
- весь список можно посмотреть тут
- RuleSet содержит список правил, правило состоит из фильтра и привязанных к нему одного или нескольких Actions
- Фильтры — логические выражения, с использованием свойств сообщения. Подробнее про фильтры
- Правила применяются последовательно к сообщению, попавшему в RuleSet, на первом сработавшем правиле сообщение не останавливается
- Чтобы остановить обработку сообщения, можно использовать специальное discard action: или в легаси-формате.
- Внутри Action часто используются шаблоны. Шаблоны позволяют генерировать данные для передачи в Action из свойств сообщения, например, формат сообщения для передачи по сети или имя файла для записи. Подробнее про шаблоны
- Как правило, Action использует модуль вывода(«om…») или модуль изменения сообщения(«mm…»). Вот некоторые из них:
- omfile — вывод в файл
- omfwd — пересылка по сети, через udp или tcp
- omrelp — пересылка по сети по протоколу RELP
- onmysql, ompgsql, omoracle — запись в базу
- omelasticsearch — запись в ElasticSearch
- omamqp1 — пересылка по протоколу AMQP 1.0
- весь список модулей вывода
→