Очень большие файлы журналов, что мне делать?

Example¶

The following example shows pulling structured imjournal messages and
saving them into /var/log/ceelog.

module(load="imjournal" PersistStateInterval="100"
       StateFile="/path/to/file") #load imjournal module
module(load="mmjsonparse") #load mmjsonparse module for structured logs

template(name="CEETemplate" type="string" string="%TIMESTAMP% %HOSTNAME% %syslogtag% @cee: %$!all-json%\n" ) #template for messages

action(type="mmjsonparse")
action(type="omfile" file="/var/log/ceelog" template="CEETemplate")

See also

Help with configuring/using :

• Mailing list — best route for general questions

• GitHub: rsyslog source project — detailed questions, reporting issues
  that are believed to be bugs with

• Stack Exchange (View, Ask)
  — experimental support from rsyslog community

See also

Contributing to :

• Source project: rsyslog project README.

• Documentation: rsyslog-doc project README

Настройка

Для приложение, ротация логов настраивается в отдельных файлах, расположенных по пути /etc/logrotate.d/ (во FreeBSD — /usr/local/etc/logrotate.d/).

К примеру, нам необходимо настроить ротацию лога для logstash-forwarder. Создаем файл со следующим содержимым:

vi /etc/logrotate.d/logstash

/var/log/logstash-forwarder/* {
    rotate 30
    size=10M
    missingok
    notifempty
    daily
    compress
    delaycompress
    maxage 30
    create 0644 root root
    postrotate
        /usr/bin/systemctl restart logstash-forwarder
    endscript
}

* где:

• rotate 30 — хранить последние 30 ротированных файлов. Остальные удалять.
• size=10M — пока размер лог-файла не превысит 10 мегабайт, он не будет ротироваться.
• missingok — если файла не существует, не выкидывать ошибку.
• notifempty — если файл пустой, не выполнять никаких действий.
• daily — делать ротацию каждый день.
• compress — сжимать ротированные файлы.
• delaycompress — сжимать только предыдущий журнал. Позволяет избежать ошибок, связанных с отсутствием доступа к используемому файлу.
• maxage 30 — хранить ротированные файлы за последние 30 дней. Остальные удалять.
• create 0644 root root — создать новый лог-файл после ротирования.
• postrotate … endscript — скрипт, который необходимо выполнить после чистки лога.

* /var/log/logstash-forwarder/* — путь к файлу, который нужно ротировать. * указывает, что нужно чистить все файлы, которые расположены в каталоге /var/log/logstash-forwarder.
* напомню, что во FreeBSD, путь будет /usr/local/etc/logrotate.d/logstash.

Другие примеры настройки читайте в инструкции Примеры настроек logrotate для различных программ. 

При настройке необходимо проверять работу сервиса после ротации лога. Некоторые службы могут перестать работать без лог-файла. В данном случае, необходимо создавать новый (create). Также, в некоторых случаях, сервис необходимо перезапускать, так как при создании нового файла меняется его дескриптор.

BSD-style Blocks¶

Note: rsyslog v7+ no longer supports BSD-style blocks
for technical reasons. So it is strongly recommended not to
use them.

Rsyslogd supports BSD-style blocks inside rsyslog.conf. Each block of
lines is separated from the previous block by a program or hostname
specification. A block will only log messages corresponding to the most
recent program and hostname specifications given. Thus, a block which
selects ‘ppp’ as the program, directly followed by a block that selects
messages from the hostname ‘dialhost’, then the second block will only
log messages from the ppp program on dialhost.

A program specification is a line beginning with ‘!prog’ and the
following blocks will be associated with calls to syslog from that
specific program. A program specification for ‘foo’ will also match any
message logged by the kernel with the prefix ‘foo: ’. Alternatively, a
program specification ‘-foo’ causes the following blocks to be applied
to messages from any program but the one specified. A hostname
specification of the form ‘+hostname’ and the following blocks will be
applied to messages received from the specified hostname. Alternatively,
a hostname specification ‘-hostname’ causes the following blocks to be
applied to messages from any host but the one specified. If the hostname
is given as ‘@’, the local hostname will be used. (NOT YET IMPLEMENTED)
A program or hostname specification may be reset by giving the program
or hostname as ‘*’.

Templates

Many vendors format their syslog messages differently. If the network equipment logs to a central rsyslog server the difference in logging will be easy to notice. After some time of log dumping it will be difficult to filter the syslog server messages for a certain

• Date
• Facility
• Severity
• Host
• Syslogtag
• ProcessID
• MessageType
• Message

To unify syslog messages to a certain or preferred format, Rsyslog uses templates which parse arriving messages and «rewrites» them to the desired format.

To maintain a simple and modular configuration, templates are stored within the /etc/rsyslog.d/ directory.
To include files stored within the rsyslog.d directory add following line to /etc/rsyslog.conf file:

 $IncludeConfig /etc/rsyslog.d/*.conf

Templates should be stored to the /etc/rsyslog.d/ directory.

ImportantFollowing templates are working very good, but are not perfect.

Here a simple template for a cisco IOS host which logs to rsyslogd:

FILE

$template mysql_cisco, "insert into SystemEvents (Message, Facility, FromHost, Priority, DeviceReportedTime, ReceivedAt, InfoUnitID, SysLogTag) values ('%msg:R,ERE,1,DFLT:%+: (.*)--end%', %syslogfacility%, '%fromhost%', %syslog
priority%, '%timereported:::date-mysql%', '%timegenerated:::date-mysql%', %iut%, '%msg:R,ERE,0,DFLT:%+:--end%')",SQL

Here a simple template for a ScreenOS host which logs to rsyslogd:

FILE

$template mysql_netscreen, "insert into SystemEvents (Message, Facility, FromHost, Priority, DeviceReportedTime, ReceivedAt, InfoUnitID, SysLogTag) values ('%msg:R,ERE,1,DFLT:+: (.*)--end%', %syslogfacility%, '%fromhost%', %s
yslogpriority%, '%timereported:::date-mysql%', '%timegenerated:::date-mysql%', %iut%, '%msg:R,ERE,0,DFLT:+:--end%')",SQL

Here a simple template for Linux host which logs to rsyslogd:

FILE

$template mysql_linux, "insert into SystemEvents (Message, Facility, FromHost, Priority, DeviceReportedTime, ReceivedAt, IntoUnitID, SysLogTag) values ('%msg%', %syslogfacility%, '%HOSTNAME%', %syslogpriority%, '%timereported:::
date-mysql%', '%timegenerated:::date-mysql%', %iut%, '%syslogtag:R,ERE,1,FIELD:(.+)(\{1,5}\]).*--end%')" ,SQL

Configure rsyslogd which predefined template to apply to which facility, add following template references to the end of the /etc/rsyslog.conf file:

All messages arriving at facility local4, are Cisco IOS messages:

 local4.* :ommysql:localhost,Syslog,rsyslog-user,MySecretPassword;mysql_cisco

All messages arriving at facility local5 , are ScreenOS messages:

 local5.* :ommysql:localhost,Syslog,rsyslog-user,MySecretPassword;mysql_netscreen

All messages arriving at syslog consider as Linux messages, and ignore local4 and local5 facilities which have their own templates.

 *.*;local4.none;local5.none :ommysql:localhost,Syslog,rsyslog-user,MySecretPassword;mysql_linux

The following is an example of how the /etc/rsyslog.conf file could look on a syslog server with working templates:

FILE

$ModLoad imudp
$UDPServerRun 514
$ModLoad ommysql.so
$IncludeConfig /etc/rsyslog.d/*.conf

*.info;mail.none;authpriv.none;cron.none	-/var/log/messages
authpriv.*					/var/log/secure
mail.*						-/var/log/maillog
cron.*						-/var/log/cron
*.emerg						*
uucp,news.crit					-/var/log/spooler
local7.*					/var/log/boot.log

local4.* :ommysql:localhost,Syslog,rsyslog-user,MySecretPassword;mysql_cisco
local5.* :ommysql:localhost,Syslog,rsyslog-user,MySecretPassword;mysql_netscreen
*.*;local4.none;local5.none :ommysql:localhost,Syslog,rsyslog-user,MySecretPassword;mysql_linux

Reload rsyslog server to apply new changes:

Selectors¶

Selectors are the traditional way of filtering syslog messages. They
have been kept in rsyslog with their original syntax, because it is
well-known, highly effective and also needed for compatibility with
stock syslogd configuration files. If you just need to filter based on
priority and facility, you should do this with selector lines. They are not second-class citizens in rsyslog and offer the simplest syntax
for this job. In versions of rsyslog prior to v7 there were significant
performance gains by using selector lines instead of the format. There is no longer any difference in performance between the two
formats.

The selector field itself again consists of two parts, a facility and a
priority, separated by a period (“.’’). Both parts are case insensitive
and can also be specified as decimal numbers, but don’t do that, you
have been warned. Both facilities and priorities are described in
syslog(3). The names mentioned below correspond to the similar
LOG_-values in /usr/include/syslog.h.

The priority is one of the following keywords, in ascending order:
debug, info, notice, warning, warn (same as warning), err, error (same
as err), crit, alert, emerg, panic (same as emerg). The keywords error,
warn and panic are deprecated and should not be used anymore. The
priority defines the severity of the message.

The behavior of the original BSD syslogd is that all messages of the
specified priority and higher are logged according to the given action.
Rsyslogd behaves the same, but has some extensions.

In addition to the above mentioned names the rsyslogd(8) understands
the following extensions: An asterisk (”*’’) stands for all facilities
or all priorities, depending on where it is used (before or after the
period). The keyword none stands for no priority of the given facility.
You can specify multiple facilities with the same priority pattern in
one statement using the comma (“,’’) operator. You may specify as much
facilities as you want. Remember that only the facility part from such a
statement is taken, a priority part would be skipped.

Multiple selectors may be specified for a single action using the
semicolon (“;’’) separator. Remember that each selector in the selector
field is capable to overwrite the preceding ones. Using this behavior
you can exclude some priorities from the pattern.

Некоторые типсы и триксы для 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, чтобы реализовать своё более сложное и интересное решение. До новых статей!

Настройка клиента

Устанавливаем и запускаем rsyslog по инструкции, . После приступаем к настройке клиента.

Все логи

Для начала можно настроить отправку всех логов на сервер. Создаем конфигурационный файл для rsyslog:

vi /etc/rsyslog.d/all.conf

Добавляем:

*.* @@192.168.0.15:514

* где 192.168.0.15 —  IP-адрес сервера логов. *.* — перенаправлять любой лог.

Перезапускаем rsyslog:

systemctl restart rsyslog

Для определенных категорий

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

vi /etc/rsyslog.d/kern.conf

Добавим строку:

kern.* @@192.168.0.15:514

Перезапускаем сервис логов:

systemctl restart rsyslog

Возможные категории для логов (facility):

№	Категория	Описание
kern	Сообщения, отправляемые ядром
1	user	Пользовательские программы
2	mail	Почта
3	daemon	Сервисы (демоны)
4	auth	Безопасность/вход в систему/аутентификация
5	syslog	Сообщения от syslog
6	lpr	Логи печати
7	news	Новостные группы (usenet)
8	uucp	Unix-to-Unix CoPy (копирование файлов между компьютерами)
9	cron	Планировщик заданий
10	authpriv	Безопасность/вход в систему/аутентификация — защищенный режим
11	ftp	Логи при передачи данных по FTP
12	ntp	Лог службы синхронизации времени (существует не везде)
13	security, log audit	Журнал аудита (существует не везде)
14	console, log alert	Сообщения, отправляемые в консоль (существует не везде)
15	solaris-cron, clock daemon	Cron в solaris (существует не везде)
16-23	local0 — local7	Зарезервированы для локального использования. Уровень серьезности определяется числом от 0 до 7.

Для определенного уровня

Если мы хотим передавать только сообщения об ошибках, добавляем строку в файл конфигурации rsyslog:

vi /etc/rsyslog.d/erors.conf

*.err @@192.168.0.15:514

Перезапускаем сервис логов:

systemctl restart rsyslog

Возможные уровни логов:

Возможные категории для логов (severity):

№
Уровень
Расшифровка
emerg
Система не работает (PANIC)
1
alert
Серьезная проблема, требующая внимания
2
crit
Критическая ошибка
3
err
Ошибка (ERROR)
4
warning
Предупреждение (WARN)
5
notice
Важное информационное сообщение
6
info
Информационное сообщение
7
debug
Отладочная информация

Аудит определенного лог-файла

Мы можем настроить слежение за изменением определенного лога и передавать их на сервер. Для этого нужно настроить и сервер, и клиента.

Настройка клиента

Создаем новый конфигурационный файл:

vi /etc/rsyslog.d/audit.conf

$ModLoad imfile
$InputFileName /var/log/audit/audit.log
$InputFileTag tag_audit_log:
$InputFileStateFile audit_log
$InputFileSeverity info
$InputFileFacility local6
$InputRunFileMonitor
*.*   @@192.168.0.15:514

* в данном примере мы будем отслеживать изменения лог-файла /var/log/audit/audit.log; нас интересуют события от уровня info и выше; все события будет отмечены категорией local6 и переданы на сервер 192.168.0.15.

Перезапускаем сервис на клиенте:

systemctl restart rsyslog

Настройка сервера (фильтрация сообщений)

На сервере нам нужно фильтровать все сообщения категории local6 (такую категорию мы выбрали, когда настроили клиента) и перенаправлять их в нужных нам файл. Открываем на редактирование конфигурационный файл rsyslog:

vi /etc/rsyslog.conf

Создаем новый шаблон для захвата логов:

$template HostAudit, «/var/log/rsyslog/%HOSTNAME%/audit.log»
local6.* ?HostAudit

* в данном примере мы создаем шаблон HostAudit; rsyslog будет принимать логи категории local6 и сохранять в файле /var/log/rsyslog/<имя компьютера, откуда пришел лог>/audit.log.

Перезапускаем сервер:

systemctl restart rsyslog

Лог определенного приложения

Некоторые приложения умеют отправлять лог напрямую на syslog. Например, nginx (начиная с версии 1.7.1). Для этого открываем конфигурационной файл (основной или конфиг виртуального домена):

vi /etc/nginx/nginx.conf

Добавляем или редактируем соответствующие настройки для логов:

…
access_log syslog:server=192.168.0.15:514 info;
error_log syslog:server=192.168.0.15:514 warn;
error_log  /var/log/nginx/error.log warn;
…

* в данном примере мы настроили хранение логов для nginx на сервере 192.168.0.15. Для ошибок также сохраняется локальный лог в файле /var/log/nginx/error.log.

Проверяем корректность конфигурационного файла nginx:

nginx -t

Перезапускаем сервис:

systemctl restart nginx

Централизованный сервер rsyslog в Debian

Давайте рассмотрим простой конфиг централизованного сервера rsyslog, который будет сортировать файлы логов по ip адресу источника сообщения. Редактировать файлы можно с помощью vim или другого текстового редактора. ip адрес сервера rsyslog примем за 10.0.0.1, на него необходимо натравить всех . Для корректной работы rsyslogd необходимо разрешить получение syslog сообщений из сети, подключив соответствующий модуль и задав правило, т.к. по умолчанию, UDP и TCP транспорт на сервере отключен (приведу только измененные\добавленные строки):

~ # cat /etc/rsyslog.conf 
<...>
#################
#### MODULES ####
#################
<...>
# раскомментируем параметры подключения модуля, позволяющего собирать информацию по UDP:
$ModLoad imudp
# раскомментируем номер порта для сервера - можно заменить на свой (не забудьте о клиентах)
$UDPServerRun 514

# раскомментируем параметры подключения модуля, позволяющего собирать информацию по TCP (по жаланию):
#$ModLoad imtcp 
# раскомментируем номер порта для сервера (по желанию - можно заменить на свой (не забудьте о клиентах)
#$InputTCPServerRun 514

###########################
#### GLOBAL DIRECTIVES ####
###########################
<...>
###############
#### RULES ####
###############
<...>
# удаленное журналирвание
# Зададим шаблон создания имен файлов (на основании IP адреса клиента) 
$template FILENAME,"/var/log/%fromhost-ip%/syslog.log"

# Укажем сохранять сообщения от любого источника (*) с любым приоритетом (*) в файл, заданный шаблоном
# Например, клиенты (10.0.0.2,10.0.0.3...) будут раскладываться в соответствующие каталоги /var/log/10.0.0.2/syslog.log 
*.*       ?FILENAME

# как вариант, возможно рассмотреть вот такой вид сортировки:
# шаблон, раскидывающий по имени хоста, году, месяц, дню
# $template RemoteHost,"/var/log/%HOSTNAME%/%$YEAR%/%$MONTH%/%$DAY%/syslog.log"
# правило, использующее шаблон
# *.*     ?RemoteHost

После задания указанных параметров, необходимо перезапустить\перечитать конфигурационный файл (service rsyslog restart). При этом, netstat нам должен показать, что сислог стал слушать соответствующий порт:

~ # netstat -nap | grep 514
udp 0 0 0.0.0.0:514 0.0.0.0:* 21017/rsyslogd

Конечно, мы можем не указывать параметры хранения, а лишь раскомментировать параметры $ModLoad imudp и $UDPServerRun 514, тогда rsyslogd будет размещать сообщения в стандартных выходных файлах (messages, syslog, etc), согласно правил по умолчанию. Необходимо учитывать, что указание только загрузки модуля (например $ModLoad imudp) недостаточно для приема сообщений по сети. Обязательно нужно указывать так же и соответствующий порт для прослушки (например, $UDPServerRun 514).

Настройка Rsyslog в Linux

Все настройки Rsyslog находятся в файле /etc/rsyslog.conf и других конфигурационных файлах из /etc/rsyslog.d/. Вы можете посмотреть существуют ли у вас эти файлы выполнив:

Основной конфигурационный файл — /etc/rsyslog.conf, в нем подключены все файлы из папки /etc/rsyslog.d/ с помощью директивы IncludeConfig в самом начале файла:

В этих файлах могут содержаться дополнительные настройки, например, аутентификация на Rsyslog сервере. В главном конфигурационном файле содержится очень много полезных настроек. Обычно он обеспечивает управление локальными логами по умолчанию, но для работы через сеть нужно добавить настройки. Сначала давайте рассмотрим что представляет из себя этот файл.

Синтаксис конфигурационного файла очень прост:

$ переменная значение

Все директивы начинаются со знака доллара, содержат имя переменной, а дальше связанное с ней значение. Так выглядит каждая строка конфигурационного файла. В его первой части размещены общие настройки программы и загрузка модулей. Во второй — ваши правила сортировки и фильтрации лог файлов.

# provides UDP syslog reception

#$ModLoad imudp
#$UDPServerRun 514

# provides TCP syslog reception

#$ModLoad imtcp
#$InputTCPServerRun 514

В этом участке загружаются все необходимые модули программы. Существуют четыре типа модулей:

• Модули ввода — можно рассматривать, как способ сбора информации из различных источников, начинаются с im.
• Модули вывода — позволяют отправлять сообщения в файлы или по сети, или в базу данных, имя начинается на om;
• Модули фильтрации — позволяют фильтровать сообщения по разным параметрам, начинаются с fm;
• Модули парсинга — предоставляют расширенные возможности для синтаксического анализа сообщения, начинаются с pm.

Сначала загружается модуль imuxsock, который позволяет сервису получать сообщения из сокетов, а второй imklog получает сообщения ядра. Следующим загружается модуль mark, который позволяет маркировать соединения, или же выводить сообщения о том, что syslog все еще работает. Например, вы можете попросить rsyslog выводить сообщения каждые 20 минут:

Дальше идут глобальные директивы:

В этой строке мы указываем, что нужно использовать стандартный формат хранения времени, в секундах с 1970 года.

Дальше следует набор прав разрешений для файлов журналов, которые будут созданы в вашей системе:

После создания этих файлов их права можно менять, на те, которые вам нужны.

Выше была более общая настройка syslog, ну а теперь самое интересное — правила сортировки логов. Вот набор правил по умолчанию:

Каждое правило имеет свой синтаксис, сначала идет источник и приоритет, затем действие. Если источник и приоритет совпадают, сообщение отправляется в указанный файл. Например, мы можем отправить больше сообщений в лог системы linux /var/messages:

В этой строке мы выбираем все сообщения уровня info, кроме mail,authpriv и cron. Шаблон mail.none будет означать, что не нужно логировать ни один уровень сообщений. Соответственно конструкция *.info — значит логировать сообщения от всех источников, но только с уровнем info, *.* — это вообще все сообщения, со всеми уровнями.

Источник и приоритет нечувствительны к регистру. Также заметьте, что приоритеты уровней error, warn и panic больше не используются, так как считаются устаревшими. В целом, в качестве источников вы можете использовать:

• auth;
• authpriv;
• cron;
• daemon;
• kern;
• lpr;
• mail;
• mark;
• news;
• security (эквивалентно auth);
• syslog;
• user;
• uucp;
• local0 … local7;

А в качестве приоритетов вы можете применить:

• emerg (раньше panic);
• alert;
• crit;
• error (раньше err);
• warn (раньше warning);
• notice;
• info;
• debug;

Как я уже говорил, звездочки на любом месте означают все варианты. Для фильтрации логов могут использоваться не только источник и приоритет, но и более сложные выражения на основе условий и сравнений.

Вы можете выполнять фильтрацию сообщений с помощью такого синтаксиса:

:поле, сравнение, «значение» путь_к_файлу

В качестве операции сравнения вы можете использовать такие варианты:

• contains — поле содержит указанное значение;
• isequal — поле должно быть идентичным значению;
• startswith — поле должно начинаться со значения;
• regex — сравнивает поле с регулярным выражением.

Например, отфильтруем сообщения только от определенной программы:

Кроме того, можно использовать более простой синтаксис, в виде выражения if. Вот основной синтаксис:

if $поле сравнение ‘значение’ then файл

Здесь используются те же самые компоненты, только выглядит немного проще. Например:

1: Установка S3cmd

Для отправки логов в хранилище будет использоваться инструмент S3cmd. Прежде чем установить его, нужно установить вспомогательные инструменты для работы с программами Python (S3cmd написан на Python).

Перейдите в каталог, в котором у вас есть право на запись, и загрузите архив .tar.gz S3cmd:

Примечание: Более актуальные версии S3cmd можно поискать на этой странице Github. Если вы найдете там новую версию, замените URL в команде ссылкой на новый пакет.

После завершения загрузки распакуйте архив:

Перейдите в полученный каталог и установите программу:

Протестируйте установку s3cmd, запросив версию инструмента:

Если вы видите аналогичный вывод, инструмент S3cmd успешно установлен. Затем настройте S3cmd для подключения к сервису хранения объектов.

Building from Source

Build Environment

In general, you need

• pkg-config
• libestr
• liblogging (stdlog component, for testbench)

It is best to build these from source.

Ubuntu

Add Adiscon repository:

Note: if you are a developer who wants to work with git master branch,
adding the Adiscon repository is probably not a good idea. It then
is better to also compile the supporting libraries from source, because
newer versions of rsyslog may need newer versions of the libraries than
there are in the repositories.
Libraries in question are at least: libestr, liblognorm, libfastjson.

Needed packages to build with omhiredis support:

Aditional packages for other modules:

For KSI, from the Adiscon PPA:

Debian

Note: For certain libraries version requirements might be higher,
in that case adding debian backports repositories might help.
For example installing with apt libfastjson-dev -t stretch-backports.

Aditional packages for other modules:

SUSE LINUX Enterprise Server 11

Available packages:

Missing packages:

How to Contribute

Contributions to rsyslog are very welcome. Fork and send us your Pull Requests.

For more information about contributing, see the
CONTRIBUTING file.

Note that it is easy to add output plugins using languages like Python or
Perl. So if you need to connect to a system which is not yet supported, you
can easily do so via an external plugin. For more information see the
README file in the external plugin directory.

Project Philosophy

We are an open source project in all aspects and very open to outside feedback
and contribution. We base our work on standards and try to solve all real-world
needs (of course, we occasionally fail tackling actually all needs ;)). While
the project is primarily sponsored by Adiscon, technical development is
independent from company goals and most decisions are solely based on mailing
list discussion results. There is an active community around rsyslog.

This method of open discussions is modelled after the IETF process, which is
probably the best-known and most successive collaborative standards body.

Project Funding

Rsyslog’s main sponsor Adiscon tries to fund rsyslog by selling custom
development and support contracts. Adiscon does NOT license rsyslog under a
commercial license (this is simply impossible for anyone due to rsyslog’s
license structure).

Any third party is obviously also free to offer custom development, support
and rsyslog consulting. We gladly merge results of such third-party work into
the main repository (assuming it matches the few essential things written
down in our contribution policy).