Linux: syslog сервер «под ключ». пошаговая настройка
Содержание:
- Подготовка сервера
- Настройка клиента
- Установка и настройка MySQL
- История
- Segmentation Faults¶
- Централизованный сервер rsyslog в Debian
- rsyslog в картинках
- Запуск демона syslogd
- Веб интерфейс для rsyslog
- Debug Log¶
- Настройка Cisco для Syslog
- Настройка syslog для iptables
- How To Setup¶
- Some Sample Data¶
- Configuration Problems¶
Подготовка сервера
На сервере нужно, предварительно, выполнить следующие настройки.
Время
Для правильной фиксации времени логов, необходимо настроить его синхронизацию.
Сначала задаем правильный часовой пояс:
\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
Настройка клиента
Устанавливаем и запускаем 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 | Почта | |
| 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
Установка и настройка MySQL
— Устанавливаем Percona Server по инструкции разработчика:
— Перезагружаем сервер:
sudo reboot
— Настраиваем Percona Server:
sudo cp /etc/mysql/my.cnf /etc/mysql/my.cnf_old sudo cp /etc/mysql/percona-server.conf.d/mysqld.cnf /etc/mysql/my.cnf sudo nano /etc/mysql/my.cnf
— Содержание /etc/mysql/my.cnf для сервера с 6Gb ОЗУ:
user = mysql pid-file = /var/run/mysqld/mysqld.pid socket = /var/run/mysqld/mysqld.sock # PATHS basedir = /usr datadir = /var/lib/mysql tmpdir = /dev/shm lc-messages-dir = /usr/share/mysql explicit_defaults_for_timestamp local-infile = 0 # NETWORK bind-address = 127.0.0.1 port = 3306 connect_timeout = 60 wait_timeout = 28800 max_connections = 2048 max_allowed_packet = 64M max_connect_errors = 1000 # LOGS log_error = /var/log/mysql/error.log slow_query_log_file = /var/log/mysql/slow.log slow_query_log = 1 long_query_time = 20 # Recommended in standard MySQL setup sql_mode=NO_ENGINE_SUBSTITUTION,STRICT_ALL_TABLES # Disabling symbolic-links is recommended to prevent assorted security risks symbolic-links=0 # limits tmp_table_size = 256M max_heap_table_size = 128M # innodb innodb_data_home_dir = /var/lib/mysql innodb_file_per_table = 1 innodb_status_file = 1 innodb_buffer_pool_size = 4G innodb_buffer_pool_instances = 8 innodb_flush_method = O_DIRECT innodb_io_capacity = 800 innodb_flush_log_at_trx_commit = 0 innodb_support_xa = ON innodb_log_file_size = 128M innodb_log_buffer_size = 64M # other stuff sync_binlog = 0 event_scheduler = 1 query_cache_type = 0 query_cache_size = 0
— Применяем настройки:
sudo service mysql restart
История
Syslog был разработан в 1980 году Эриком Оллманом (Eric Allman) как часть проекта Sendmail, и использовался первоначально только для Sendmail. Зарекомендовав себя как стабильное и удобное решение, Syslog был использован и в других приложениях, став стандартом ведения журналов в системах UNIX и GNU/Linux. Позднее появились реализации и под другие операционные системы.
Март 2009 года ознаменовался выходом целой группы RFC, предложивших достаточно серьёзные усовершенствования протокола Syslog.
В октябре 2009 года увидела свет ещё одна группа RFC, связывающая управление объектами с протоколом Syslog.
Segmentation Faults¶
Rsyslog has a very rapid development process, complex capabilities and
now gradually gets more and more exposure. While we are happy about
this, it also has some bad effects: some deployment scenarios have
probably never been tested and it may be impossible to test them for the
development team because of resources needed. So while we try to avoid
this, you may see a serious problem during deployments in demanding,
non-standard, environments (hopefully not with a stable version, but
chances are good you’ll run into troubles with the development
versions).
In order to aid the debugging process, it is useful to have debug symbols
on the system. If you build rsyslog yourself, make sure that the
option is included in CFLAGS. If you use packages, the debug symbols come
in their own package. It is highly recommended to install that package
as it provides tremendous extra benefit. To do so, do:
yum install rsyslog-debuginfo
Obviously, this is for RPM-based systems, but it’s essentially the same
with other packaging systems, just use the native commands. Note that
the package may be named slightly different, but it should always be
fairly easy to locate.
Active support from the user base is very important to help us track
down those things. Most often, serious problems are the result of some
memory misaddressing. During development, we routinely use valgrind, a
very well and capable memory debugger. This helps us to create pretty
clean code. But valgrind can not detect everything, most importantly not
code paths that are never executed. So of most use for us is
information about aborts and abort locations.
Unfortunately, faults rooted in addressing errors typically show up only
later, so the actual abort location is in an unrelated spot. To help
track down the original spot, libc later than 5.4.23 offers
support
for finding, and possible temporary relief from it, by means of the
MALLOC_CHECK_ environment variable. Setting it to 2 is a useful
troubleshooting aid for us. It will make the program abort as soon as
the check routines detect anything suspicious (unfortunately, this may
still not be the root cause, but hopefully closer to it). Setting it to
0 may even make some problems disappear (but it will NOT fix them!).
With functionality comes cost, and so exporting MALLOC_CHECK_ without
need comes at a performance penalty. However, we strongly recommend
adding this instrumentation to your test environment should you see any
serious problems. Chances are good it will help us interpret a dump
better, and thus be able to quicker craft a fix.
In order to get useful information, we need some backtrace of the abort.
First, you need to make sure that a core file is created. Under Fedora,
for example, that means you need to have an “ulimit -c unlimited” in
place.
Now let’s assume you got a core file (e.g. in /core.1234). So what to do
next? Sending a core file to us is most often pointless — we need to
have the exact same system configuration in order to interpret it
correctly. Obviously, chances are extremely slim for this to be. So we
would appreciate if you could extract the most important information.
This is done as follows:
$ gdb /path/to/rsyslogd $ core /core.1234 $ info thread $ thread apply all bt full $ q # quits gdb
The same method can be applied to a running rsyslog process that suffers
from a lock condition. E.g. if you experience that rsyslog is no longer
forwarding log messages, but this cannot be reproduced in our lab. Using
gdb to review the state of the active threads may be an option to see
which thread is causing the problem (e.g. by locking itself or being in a
wait state).
Again, basically the same steps can be applied. But, instead of using a
core file, we will require the currently used PID. So make sure to acquire
the PID before executing gdb.
$ gdb /path/to/rsyslogd $ attach PID # numerical value $ info thread $ thread apply all bt full $ q # quits gdb
Then please send all information that gdb spit out to the development
team. It is best to first ask on the forum or mailing list on how to do
that. The developers will keep in contact with you and, I fear, will
probably ask for other things as well 😉
Note that we strive for highest reliability of the engine even in
unusual deployment scenarios. Unfortunately, this is hard to achieve,
especially with limited resources. So we are depending on cooperation
from users. This is your chance to make a big contribution to the
project without the need to program or do anything else except get a
problem solved.
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
Централизованный сервер 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 в картинках
После всего прочтенного хотелось бы все это лицезреть в понятном виде. Попробую ка я все это обрисовать.
В данной схеме я постарался отобразить схему движения сообщения «сквозь» логику работы демона rsyslogd. Давайте попробуем разобраться в последовательности. Итак, сообщение пришло в систему с помощью одного из модулей ввода (сеть, файл, /dev/log …) — оранжевая сноска. Далее, сообщения выстраиваются в главную очередь (если не хватает системных ресурсов ). Очереди rsyslogd это отдельная тема), но для типового понимания этой информации достаточно. Далее, сообщения поступают в обработчик, который использует модули парсинга — фиолетовая сноска. После данного этапа, мессаджи сверяются с фильтрами (читай — с селекторами источник.приоритет), заданными в правилах. Если сообщение подпадает под селектор, то перед применением действия к сообщению применяется соответствующий шаблон (если шаблон для действия не указан, то применяется шаблон по умолчанию, либо тот, который задан в глобальных параметрах). Ну и применяется соответствующее действие. На основании действия, сообщение может быть направлено в соответствующее место, если это место требует применения модуля (например, ommysql, ompgsql), то используются соответствующий модуль вывода.
Вот, собственно и вся схема.
Запуск демона syslogd
Запуск демона протоколирования запускаются на этапе инициализации системы посредством скрипта /etc/rc.d/init.d/syslog, однако для того, чтобы задать параметры запуска, нет необходимости корректировать этот скрипт — начиная с версии 7.2, опции запуска считываются из отдельного конфигурационного файла /etc/sysconfig/syslog (/etc/default/syslog в debian).
Вот некоторые возможные параметры запуска демона syslogd:
- -a /folder/socket — указание дополнительного слушающего сокета (не забудьте предварительно создать сокет)
- -d — отладочный режим. При этом демон не переходит в фоновый режим и выдает все сообщения на текущий терминал;
- -f имя-конфигурационного-файла. Задает имя альтернативного конфигурационного файла, который будет использоваться вместо заданного по умолчанию /etc/syslog.conf;
- -l список-хостов — задание списка хостов, имена которых не должны записываться с указанием полного доменного имени (FQDN — Full Qwalified Domain Name);
- -m минут — запущенный без этой опции sysklogd через каждые 20 минут записывает в протокол сообщения категории mark (временные отметки). С помощью опции -m можно либо изменить интервал между отметками, либо вовсе отменить выдачу таких сообщений;
- -p socket — задание альтернативного сокета UNIX (вместо прослушиваемого по умолчанию /dev/log);
- -r — разрешение принимать сообщения от удаленных хостов;
- -x — запрет определения имени хоста по его адресу для предотвращения зависания при работе на одном хосте с сервером DNS.
- -v — показать версию и закончить работу
После запуска демона syslogd создается файл статуса /var/lock/subsys/syslog нулевой длины, и файл с идентификационным номером процесса /var/run/syslogd.pid.
С помощью командыkill -SIGNAL `cat /var/run/syslogd.pid`
можно послать демону syslogd один из следующих сигналов: SIGHUP — перезапуск демона; SIGTERM — завершение работы; SIGUSR1 — включить/выключить режим отладки.
Вообще-то в системе запускаются два демона протоколирования — syslogd и klogd. Оба демона входят в состав пакета sysklogd.
Демон klogd отвечает за журналирование событий, происходящих в ядре системы. Необходимость в отдельном демоне klogd объясняется тем, что ядро не может использовать стандартную функцию syslog. Дело в том, что стандартные библиотеки С (включая ту библиотеку, в которой находится функция syslog) предназначены для использования только обычными приложениями. Поскольку ядро тоже нуждается в функциях журналирования, в него включены свои библиотеки, недоступные приложениям. Поэтому ядро использует свой собственный механизм генерации сообщений.
Демон klogd предназначен для организации обработки этих сообщений. В принципе он может производить такую обработку полностью самостоятельно и независимо от syslogd, например, записывая эти сообщения в файл, но в большинстве случаев используется принятая по умолчанию настройка klogd, при которой все сообщения от ядра пересылаются тому же демону syslogd.
Веб интерфейс для 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, обладающая тем же функционалом. Ее тоже стоит попробовать установить, если есть желание.
Debug Log¶
If you ask for help, there are chances that we need to ask for an
rsyslog debug log. The debug log is a detailed report of what rsyslog
does during processing. As such, it may even be useful for your very own
troubleshooting. People have seen things inside their debug log that
enabled them to find problems they did not see before. So having a look
at the debug log, even before asking for help, may be useful.
Note that the debug log contains most of those things we consider
useful. This is a lot of information, but may still be too few. So it
sometimes may happen that you will be asked to run a specific version
which has additional debug output. Also, we revise from time to time
what is worth putting into the standard debug log. As such, log content
may change from version to version. We do not guarantee any specific
debug log contents, so do not rely on that. The amount of debug logging
can also be controlled via some environment options. Please see
debugging support for further details.
In general, it is advisable to run rsyslogd in the foreground to obtain
the log. To do so, make sure you know which options are usually used
when you start rsyslogd as a background daemon. Let’s assume “-c5” is
the only option used. Then, do the following:
- make sure rsyslogd as a daemon is stopped (verify with ps -ef|grep
rsyslogd) - make sure you have a console session with root permissions
-
run rsyslogd interactively:
where “your options” is what you usually use. /sbin/rsyslogd is the
full path to the rsyslogd binary (location different depending on
distro). In our case, the command would be - press ctrl-C when you have sufficient data (e.g. a device logged a
record)
NOTE: rsyslogd will NOT stop automatically — you need to ctrl-c out
of it! - Once you have done all that, you can review logfile. It contains the
debug output. - When you are done, make sure you re-enable (and start) the background
daemon!
If you need to submit the logfile, you may want to check if it contains
any passwords or other sensitive data. If it does, you can change it to
some consistent meaningless value. Do not delete the lines, as
this renders the debug log unusable (and makes Rainer quite angry for
wasted time, aka significantly reduces the chance he will remain
motivated to look at your problem ;)). For the same reason, make sure
whatever you change is change consistently. Really!
Настройка Cisco для Syslog
as53xx231#conf t Enter configuration commands, one per line. End with CNTL/Z. as53xx231(config)#logging trap ? <0-7> Logging severity level alerts Immediate action needed (severity=1) critical Critical conditions (severity=2) debugging Debugging messages (severity=7) emergencies System is unusable (severity=0) errors Error conditions (severity=3) informational Informational messages (severity=6) notifications Normal but significant conditions (severity=5) warnings Warning conditions (severity=4) as53xx231(config)#logging trap debugging as53xx231(config)#logging facility local2 as53xx231(config)#logging 10.26.95.254 as53xx231(config)#exit
- logging trap debugging — (Использование syslog server logging level) задаем уровень подробности логов.
- local2 — (Facility parameter for Использование syslog messages). Предварительно нужно проверить на FreeBSD свободен ли local2, если занят, то можно использовать любой с local1 по local7.
- 10.26.95.254 — сервер, на котором настроен Использование syslog для принятия сообщений от cisco.
Настройка syslog для iptables
По умолчанию Правила iptables логи записывает в журналы /var/log/messages, /var/log/syslog, и /var/log/kern.log. Настроим протоколирование iptables в отдельный файл iptables.log. Уровень протоколирования выбран –log-level INFO
Алгоритм изменений syslog:
- указываем сообщения ядра уровня INFO записывать в дополнительный файл: kern.info /var/log/iptables.log
- вывод в файлы syslog, kern.log блокируем: kern.!=info
# touch /var/log/iptables.log
# nano /etc/rsyslog.d/50-default.conf
kern.info /var/log/iptables.log
auth,authpriv.* /var/log/auth.log
*.*;auth,authpriv.none;\
kern.!=info -/var/log/syslog
#cron.* /var/log/cron.log
daemon.* -/var/log/daemon.log
kern.*;kern.!=info -/var/log/kern.log
...
*.=info;*.=notice;*.=warn;\
auth,authpriv.none;\
cron,daemon.none;\
mail,news.none;kern.!=info -/var/log/messages
...
# service rsyslog restart
Вариант №2. Настройка syslog. Тестировалась на ОС: CentOS 6.6 Final
Для удобства введем общий префикс IPT: для правил iptables. По этому префиксу демон syslog будет определять что эта искомая строка и запишет согласно правилу в нужный нам файл iptables.log.
$IPT -A FORWARD -m limit --limit 3/m --limit-burst 5 -j LOG --log-level INFO --log-prefix "IPT: " $IPT -A INPUT -m limit --limit 3/m --limit-burst 5 -j LOG --log-level INFO --log-prefix "IPT: IN_ETH0: "
Создадим правила в /etc/rsyslog.d/iptables.conf
- iptables.conf
-
:msg, contains, "IPT: " -varlogiptables.log & ~
Где параметр
& ~ говорит о том что дальнейшую обработку записи производить не надо, следовательно она не попадет в другие файлы логов
«IPT: » — log-prefix — критерий с которого начинается запись лога, чтобы rsyslog смог ее отловить и перенаправить в нужный файл. Его можно сделать разным для каждого правила, но если правило не одно, то удобнее иметь общий префикс для всех правил.
/var/log/iptables.log — файл в который писать лог. rsyslogd Property-Based Filters
service rsyslog restart
Настройка ротации логов iptables с помощью Описание и примеры настройки logrotate в Linux. Создадим файл /etc/logrotate.d/iptables.
- iptables
-
varlogiptables.log { rotate 10 daily missingok notifempty compress delaycompress sharedscripts postrotate reload rsyslog >/devnull 2>&1 || true # for Debian invoke-rc.d rsyslog reload > devnull # for RHEL service rsyslog reload > devnull # for CentOS endscript }
How To Setup¶
First, you need to create a working directory for rsyslog. This is where
it stores its queue files (should need arise). You may use any location
on your local system.
Next, you need to do is instruct rsyslog to use a disk queue and then
configure your action. There is nothing else to do. With the following
simple config file, you forward anything you receive to a remote server
and have buffering applied automatically when it goes down. This must be
done on the client machine.
$ModLoad imuxsock # local message reception $WorkDirectory /rsyslog/work # default location for work (spool) files $ActionQueueType LinkedList # use asynchronous processing $ActionQueueFileName srvrfwd # set file name, also enables disk mode $ActionResumeRetryCount -1 # infinite retries on insert failure $ActionQueueSaveOnShutdown on # save in-memory data if rsyslog shuts down *.* @@server:port
The port given above is optional. It may not be specified, in which case
you only provide the server name. The “$ActionQueueFileName” is used to
create queue files, should need arise. This value must be unique inside
rsyslog.conf. No two rules must use the same queue file. Also, for
obvious reasons, it must only contain those characters that can be used
inside a valid file name. Rsyslog possibly adds some characters in front
and/or at the end of that name when it creates files. So that name
should not be at the file size name length limit (which should not be a
problem these days).
Please note that actual spool files are only created if the remote
server is down and there is no more space in the in-memory queue. By
default, a short failure of the remote server will never result in the
creation of a disk file as a couple of hundred messages can be held in
memory by default.
If you would like to test if your buffering scenario works, you need to
stop, wait a while and restart you central server. Do not watch for
files being created, as this usually does not happen and never happens
immediately.
Some Sample Data¶
Below is some sample data created with the template specified above.
Note the priority recording at the start of each line.
kern.info<6>: Jun 15 18:10:38 host kernel: PCI: Sharing IRQ 11 with 00:04.0 kern.info<6>: Jun 15 18:10:38 host kernel: PCI: Sharing IRQ 11 with 01:00.0 kern.warn<4>: Jun 15 18:10:38 host kernel: Yenta IRQ list 06b8, PCI irq11 kern.warn<4>: Jun 15 18:10:38 host kernel: Socket status: 30000006 kern.warn<4>: Jun 15 18:10:38 host kernel: Yenta IRQ list 06b8, PCI irq11 kern.warn<4>: Jun 15 18:10:38 host kernel: Socket status: 30000010 kern.info<6>: Jun 15 18:10:38 host kernel: cs: IO port probe 0x0c00-0x0cff: clean. kern.info<6>: Jun 15 18:10:38 host kernel: cs: IO port probe 0x0100-0x04ff: excluding 0x100-0x107 0x378-0x37f 0x4d0-0x4d7 kern.info<6>: Jun 15 18:10:38 host kernel: cs: IO port probe 0x0a00-0x0aff: clean. local7.notice<189>: Jun 15 18:17:24 host dd: 1+0 records out local7.notice<189>: Jun 15 18:17:24 host random: Saving random seed: succeeded local7.notice<189>: Jun 15 18:17:25 host portmap: portmap shutdown succeeded local7.notice<189>: Jun 15 18:17:25 host network: Shutting down interface eth1: succeeded local7.notice<189>: Jun 15 18:17:25 host network: Shutting down loopback interface: succeeded local7.notice<189>: Jun 15 18:17:25 host pcmcia: Shutting down PCMCIA services: cardmgr user.notice<13>: Jun 15 18:17:25 host /etc/hotplug/net.agent: NET unregister event not supported local7.notice<189>: Jun 15 18:17:27 host pcmcia: modules. local7.notice<189>: Jun 15 18:17:29 host rc: Stopping pcmcia: succeeded local7.notice<189>: Jun 15 18:17:30 host rc: Starting killall: succeeded syslog.info<46>: Jun 15 18:17:33 host exiting on signal 15. syslog.info<46>: Jun 18 10:55:47 host restart user.notice<13>: Jun 18 10:55:50 host rger: test syslog.info<46>: Jun 18 10:55:52 host exiting on signal 2.``
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
Configuration Problems¶
Rsyslog has support for
configuration checking. It offers a special command line switch (-N<value>)
that puts it into “config verification mode”. In that mode, it interprets
and checks the configuration file, but does not startup. This mode can be
used in parallel to a running instance of rsyslogd.
The value is a set of binary values. Currently, there only is
| value | meaning |
| 1 | turn on config checking |
| 2 | permit checking of include files |
Where 2 automatically turns on config checking mode, if not given. In that
sense and are equivalent.
Values other than given in the table above are not supported and may lead
to unpredictable results.
When set to check include files, some conditions are relaxed. For example,
rsyslog usually requires that at least one action is defined somewhere in
the configuration. For obvious reasons, it would not make much sense to run
an instance without any action. However, when an include file is checked,
it may happen that it contains no actions as all. As such, the requirement
to include one action has been lifted in include file checking.
To check a full rsyslog configuration, run rsyslog interactively as follows:
$ /path/to/rsyslogd -f/path/to/config-file -N1
You should also specify other options you usually give.
Any problems experienced are reported to stderr .
If you would like to check just an include file, instead use:
$ /path/to/rsyslogd -f/path/to/config-file -N3
Sometimes problems are rooted in config include files, and especially the
order in which they are processed. To troubleshoot these kinds of issues, you
can use the rsyslogd -o option: it permits to specify a file that shall
receive a full copy of rsyslog’s current configuration as rsyslog sees it.
This means all include file content is directly inside that file at
exactly the spot where rsyslog sees it. The output file is almost a
verbatim copy of the original full rsyslog config. For troubleshooting
purposes it additionally contains comment lines that indicate where
content from specific include files begins and ends. The include file
is correctly named in these comments.
This option can be used together with -N. Again, it is best to run
rsyslog interactively. Do as such:
