> For the complete documentation index, see [llms.txt](https://antons-organization-1.gitbook.io/administrirovanie-linux/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://antons-organization-1.gitbook.io/administrirovanie-linux/servisy-linux/rsyslog-syslog-server-v-linux.md). # Rsyslog: syslog сервер в Linux Если вы хотите обеспечить безопасность своей системы, вы должны знать, что в ней происходит; это можно сделать с помощью **журналов** (**логов**). С помощью журналов можно диагностировать проблемы и определять состояние системы и приложений. ## Служба журналирования Большинство дистрибутивов Linux поставляется с предустановленным **RSyslog** (преемником **syslog**), а также с компонентом протоколирования systemd - **systemd-journald** (**journald**). Если он не предустановлен, для установки можно использовать следующие команды: Для RHEL/CentOS: ``` $ yum install rsyslog ``` Для Ubuntu/Debian: ``` $ apt install rsyslog ``` ## RSyslog daemon С помощью утилиты RSyslog можно создавать и хранить читаемые сообщения о событиях, чтобы системные администраторы могли управлять своими системами. Вы можете проверить, запущена ли служба или нет: ``` systemctl status rsyslog ``` RSyslog может отправлять свои выходные данные в различные места назначения, например: * Текстовые файлы в виде файлов **/var/log/\*** * БД SQL * Различные хосты Поддерживаются следующие базы данных: MySQL, PostgreSQL, Oracle, SQLite, Microsoft SQL, Sybase, Firebird и mSQL. Каждая запись журнала содержит дату, время, имя хоста, имя процесса, PID и сообщение журнала. ## Настройка Rsyslog Конфигурационный файл демона RSyslog - `/etc/rsyslog.conf`. В некоторых дистрибутивах Linux, таких как Ubuntu или Linux Mint, вы найдете эти строки в файле: ``` /etc/rsyslog.d/default.conf ``` Каждая строка содержит **селектор** и **действие**. ``` kern.*        /var/log/messages ``` **Kernel** является объектом, а приоритет - это звездочка **(\*)**, поэтому ядро будет отправлять все сообщения в **/var/log/messages**. Мы должны знать, какие объекты есть в нашей системе и какие приоритеты существуют. ## Порт Rsyslog Для служб журналирования используются порты 514 UDP/TCP. По умолчанию **RSyslog** использует порт 514 TCP. Использование TCP происходит после указания символов @@. Убедиться в наличии порта **RSyslog** можно с помощью команды `netstat`: ``` $ netstat -tnlp | grep rsyslog ``` ## Возможности RSyslog Источник сообщения RSyslog мы называем **объектом**. В Linux существуют некоторые функции, демоны и другие приложения, к которым прикреплены объекты. Ниже приведен список объектов **RSyslog** в Linux: | auth | Сообщения, связанные с безопасностью. | | --------- | ----------------------------------------- | | auth-priv | Сообщения о приватной аутентификации. | | cron | Сообщения, генерируемые подсистемой cron. | | daemon | Сообщения служб. | | kern | Сообщения ядра. | | mail | Сообщения mail. | | syslog | Сообщения syslog. | У вас есть еще два специальных объекта: **звездочка (\*)**, которая означает все объекты, и **(none)**, которая означает отсутствие объекта. Для понимания этих специальных объектов рассмотрим следующие примеры. ``` *.emerg    /var/log/emerg ``` Эта строка предписывает отправлять все сообщения аварийного приоритета в файл **/var/log/emerg**. ``` mail.none /var/log/maillog ``` Строка выше запрещает **RSyslog** регистрировать почтовые сообщения в файле **/var/log/maillog**. ## Приоритеты Rsyslog Приоритет сообщения позволяет определить важность того или иного события для системы. Приоритеты бывают следующие: * 0 (**Emergency**) система не работоспособна. **Emerg**. * 1 (**Alert**) система требует немедленного вмешательства. **Alert**. * 2 (**Critical**) состояние системы критическое. **Crit**. * 3 (**Error**) сообщения об ошибках. **Err**. * 4 (**Warning**) предупреждения о возможных проблемах. **Warning**. * 5 (**Notice**) сообщения о нормальных, но важных событиях. **Notice**. * 6 (**Informational**) информационные сообщения. **Info**. * 7 (**Debug**) отладочные сообщения. **Debug.** Также, можно использовать звёздочку "**\***" для выбора всех приоритетов или "**none**" для того, чтобы не выбрать ничего. Также можно использовать знак равенства (**=**) или восклицательный знак(**!**). Рассмотрим пример, ``` kern.=crit ``` Здесь мы выбираем сообщения, полученные от ядра, у которых стоит приоритет "crit" ``` kern.!crit ``` А здесь мы выбираем все сообщения ядра, кроме тех, которые имеют приоритет "crit". ## Действия RSyslog Каждое уведомление о событии, полученное сервером syslog в Linux, отправляется на указанное действие, в предыдущих примерах мы видели, что журналы отправляются в файлы, но можно сделать и больше действий. RSyslog может выполнять следующие действия: * Писать журнал в файл. * Писать журнал в файл-устройство. * Выводить журнал на экран пользователя. * Отправлять журнал в созданный pipe. * Отправлять журнал на удаленный узел. Чтобы лучше понять вышеописанные действия, рассмотрим следующие примеры:
auth.err/var/log/messages
daemon.*/dev/lpr2
auth-privroot,likegeeks
kern.crit|/var/log/mypipe
mail@@likegeeks.local
auth.*>dbhost,dbname,dbuser,dbpassword;dbtemplate
В 1-й строке все сообщения **auth** с приоритетом **err** записываются в файл **/var/log/messages**. Во 2-й строке все сообщения полученные от демона, вне зависимости от приоритета отправляются на локальный принтер **lpr2**. 3-я строка посылает приватные сообщения аутентификации пользователям **root** и **likegeeks**, если они вошли в систему. 4-я строка отправляет все сообщения ядра (kernel) с приоритетом **crit** в созданный pipe **/var/log/mypipe**. Создать pipe можно с помощью команды `mkfifo`. 5-я строка отправляет все почтовые сообщения на хост **likegeeks.local** на TCP-порт 514. Для этого необходимо, чтобы демон RSyslog был запущен с опцией **-r**, иначе порт не откроется. Следует использовать двойной знак @, например **@@likegeeks.local**, для принудительного использования протокола TCP службой RSyslog для передачи журналов. Шестая строка отправляет все сообщения **auth** в таблицу базы данных с указанными параметрами, причем поле **dbtemplate** является необязательным. > Следует помнить, что открывать порт **514** в своей системе опасно, злоумышленник может завалить систему сообщениями. Если требуется удаленное журналирование, то следует использовать **syslog-NG**, о котором мы поговорим далее. Вы можете заметить строку, подобную следующей 
/etc/rsyslog.conf
``` mail.*    -/var/log/maillog ``` Она позволяет RSyslog отменить синхронизацию файлов после записи журналов, но при этом возможна потеря данных, если процесс записи не завершится успешно. ## Совмещение селекторов RSyslog **Объект** и **приоритет** вместе составляют **селектор**. Вы можете комбинировать селекторы в файле `rsyslog.conf` следующим образом: ``` mail,kern.emerg           /var/log/log ``` Думаю, понять эту строку несложно. Мы будем отправлять всю почту и все сообщения от ядра (**kern)** с приоритетом **emerg** или выше в файл `/var/log/log`. ## Фильтры RSyslog Для фильтрации можно использовать селекторы, но что делать, если нужно отфильтровать сообщения? Можно отфильтровать сообщения с помощью фильтров на основе свойств, например, так: ``` :property, compare-operation, "value" ``` В следующих примерах показана фильтрация сообщений, содержащих ошибку: ``` :msg, contains, "error" ``` Операциями сравнения являются: **contains**, **isequal**, **startswith**, **regex**, **ereregex**. ``` :msg, regex, "login .* failed" ``` Этот фильтр перехватывает все сообщения, содержащие слова *"login"* и *"failed"* и любой текст между ними. ## Служба systemd-journald **Systemd-Journald** - это компонент **systemd**, который работает как служба для сбора данных, подобно **RSyslog**. Он хранит данные в индексированных журналах, что делает его более быстрым по сравнению с другими инструментами. Многие дистрибутивы Linux поставляются с **systemd-journald**, интегрированным вместе с **RSyslog**. Вы можете запускать их одновременно на одной системе и даже передавать данные из одного в другой. Основным инструментом для работы с файлами журналов является `journalctl`. С помощью `journalctl` можно запросить и просмотреть содержимое журналов, которое собирает служба **systemd-journald**. ``` $ journalctl ```
Для навигации по сообщениям можно использовать клавиатуру, а после завершения работы нажать **q** для выхода. Вы можете заметить, что некоторые строки имеют цвет, а другие выделены жирным шрифтом. Красным цветом выделены приоритеты crit \[2], alert \[1] и emerg \[0]. Красным цветом и **жирным шрифтом** выделены строки с приоритетами **warn \[4]**, **crit \[2]**, **alert \[1]** и **emerg \[0]**. Строки с приоритетом debug (7) и выше info \[6] отображаются нормально. Самое замечательное в команде `journalctl` то, что сообщения можно фильтровать с помощью некоторых гибких опций. Вы можете вывести на экран определенное количество строк следующим образом: ``` $ journalctl -n 3 ```
В режиме реального времени можно показывать сообщения, сформированные следующим образом: ``` $ journalctl -f ``` Кроме того, можно показывать сообщения за определенное количество дней: ``` $ journalctl --since="3 days ago" ``` Или можно показывать сообщения между днями следующим образом: ``` $ journalctl --since="5 days ago" --until="2 days ago" ``` Также можно указать нужную дату: ``` $ journalctl --since="2017-03-14" ``` Возможно, вам нужно определенное время: ``` $ journalctl --since="2017-03-14 15:00" --until="2017-03-14 15:30" ``` При этом можно указать нужный приоритет: ``` $ journalctl --since="2017-03-14 15:00" --until="2017-03-14 15:30" -p warning ``` Вы можете отобразить сообщения, связанные с конкретным пользователем, следующим образом: ``` $  journalctl _UID=1001 ``` Вы можете просмотреть сообщения, выдаваемые программой типа **/sbin/init**: ``` $ journalctl /sbin/init ``` Кроме того, можно проверить сообщения на диске: ``` $ journalctl /dev/sda1 ``` ## Syslog-ng Еще одним преемником **syslog** является **syslog-ng**. Этот инструмент лучше и безопаснее. Кроме того, **syslog-ng** позволяет осуществлять более сложную фильтрацию, манипулирование и взаимодействие с сообщениями. Некоторые предпочитают **syslog-ng**, поскольку он имеет более чистый синтаксис, чем **RSyslog**. Конфигурационный файл имеет следующий вид: ``` /etc/syslog-ng/syslog-ng.conf ``` Этот файл содержит следующие блоки:
options{}Глобальные опции.
source{}Определяет источник сообщений.
destination{}Определяет место назначения сообщений.
filter{}Определяет фильтр для фильтрации сообщений.
log{}Записывает логи из источника в место назначения, указанное из приведенных выше утверждений.
Идея **syslog-ng** состоит в том, чтобы указать **source{}**, **destination{}** и **filter{}**, а затем использовать их в операторе **log{}**. Мы рассмотрим, как написать каждый из них и как написать окончательный оператор **log**. ### Указание источника отчётов Syslog-ng ``` source my_udp { udp(ip(1.2.3.4) ;}; ``` В этой строке указывается источник сообщений - IP-адрес 1.2.3.4. Можно также указать файл в качестве источника журналирования: ``` source my_file { file("/proc/kmsg"); }; ``` Кроме того, в качестве источника можно указать созданный pipe: ``` source my_pipe { pipe("/var/mypipe"); }; ``` ### Указание места назначения отчётов Syslog-ng Вы можете указать место назначения отчётов следующим образом: ``` destination my_dest { file("/var/log/mylogs" owner(likegeeks) group(likegeeks) perm(0644)); }; ``` Вы указываете имя файла и его принадлежность.\ Также, можно использовать созданный pipe как источник: ``` destination my_dest { pipe("/var/mypipe"); }; ``` Готовые макросы расширения файла можно использовать следующим образом: ``` destination my_dest { file("/var/log/hosts/$HOST/$FACILITY$YEAR$MONTH$DAY"); }; ``` В качестве места назначения (адресата) может выступать вошедший в систему пользователь, как показано ниже: ``` destination my_dest { usertty("root"); }; ``` ### Фильтрация журналов Syslog-ng Вы можете задать фильтр, указав объекты и приоритеты, которые вы хотите отобрать, следующим образом: ``` filter my_filter { facility(kern); priority(notice .. crit) }; ``` Приведенный выше оператор фильтрации выбирает все сообщения от **ядра (kern)** с приоритетами от **notice** до **crit**. Диапазон приоритетов разделяется **двумя точками (..)**. Можно выполнять фильтрацию по хостам: ``` filter my_filter { host(likegeeks); }; ``` Или по конкретному приложению: ``` filter my_filter { program("telnet.*") }; ``` Или можно использовать регулярные выражения для фильтрации сообщений: ``` filter my_filter { match("YOUR REGEX"); }; ``` Также, можно фильтровать сообщения по отсутствию в них регулярных выражений: ``` filter my_filter { not match("YOUR REGEX"); }; ``` ### Журналирование Syslog-ng Мы разобрались с операторами источника, назначения и фильтрации. Осталось написать операторы журналирования, которые будут выполнять собственно журналирование. В отличие от других операторов, операторы журналирования можно не называть, поскольку они не будут использоваться в других местах. ``` log { source(my_src); destination(my_dest); }; ``` Эта строка отправляет сообщения из **my\_src** в **my\_dest**. В приведенном выше выражении используется один источник, а как насчет объединения нескольких источников? ``` log { source(my_src); source(my_kern); filter(my_filter); destination(my_dest); }; ``` Всё удалось! ## Журналирование сообщений syslog-ng в БД SQL Syslog-ng поддерживает множество баз данных в качестве backend. В следующем примере мы будем использовать MySQL. ``` destination my_dest { sql(type(mysql) host("localhost") username("likegeeks") password("likegeeks") database("dblogs") table("logs") columns("datetime", "host", "program", "pid", "logmessage") values("$YEAR-$MONTH-$DAY $HOUR:$MIN:$SEC", "${HOST}", "${PROGRAM}", "${PID}", " $MSG") indexes("datetime", "host", "program", "pid", "logmessage")); }; ``` В данном примере журналы отправляются в базу данных MySQL, работающую на localhost'е. **Syslog-ng** автоматически создает необходимые таблицы и колонки. Затем вы можете использовать это место назначения в любом операторе журналирования. ## Расположение журналов Расположение журналов по умолчанию, которые могут пригодиться при troubleshooting'е:
/var/log/messagesСодержит общие системные логи
/var/log/kern.logЛоги ядра (Kernel)
/var/log/cronЛоги демона Cron
/var/log/btmpСодержит неудачные попытки входа в систему
/var/log/mail.logСодержит логи от почтового сервера
/var/log/wtmpСодержит все попытки входа и выхода из системы.
/var/log/dmesgСодержит логи ядра
/var/log/secureСодержит логи, связанные с безопасностью.
/var/log/mariadbЛоги БД MariaDB
/var/log/mysqlЛоги БД MySQL.
/var/log/httpd/Логи веб-сервера Apache
Для CPanel журналы apache находятся в этом месте:
/usr/local/apache/logs/Логи сервера Apache.
/usr/local/apache/domlogs/Логи, специфичные для домена.
/var/log/exim/Логи почтового сервера Exim.
/var/log/yum.logЛоги менеджера пакетов Yum.
/var/log/boot.logСодержит информацию о времени загрузки системы.
> cPanel — платная панель управления веб-хостингом. Функционирует посредством отдельной копии веб-сервера, работающей, как правило, на порту 2082. В состав cPanel входит большое количество свободного ПО, основным из которого является Apache, MySQL, PHP, exim. ## Автоматическая ротация журналов с помощью Logrotate С помощью анализа журналов можно понять, что работает не так, почему произошла ошибка и как решить возникшую проблему. Однако существует некоторая проблема - размер журналов постоянно растет, они занимают все больше и больше места на диске, поэтому необходимо вовремя удалять устаревшие записи, чтобы они не мешали нормальной работе компьютера. Делать это можно вручную или воспользоваться утилитой logrotate. Утилита **logrotate** предназначена для автоматизации обработки журналов. Она может выполнять необходимые действия в зависимости от определенных условий и правил соответствия. Например, можно сжимать журналы в архив или отправлять на другой сервер, когда они достигают определенного размера, возраста или других параметров. Проверку условий можно настроить *ежедневно*, *еженедельно* или *ежемесячно* - это позволяет создать схему ротации логов, удобную именно для вас и вашего сервера. **Logrotate** — популярная утилита, поэтому в большинстве дистрибутивов она поставляется по умолчанию. Конфигурация **logrotate** находится в файле **/etc/logrotate.conf**. Для дополнительных настроек в основном файле указана папка **/etc/logrotate.d**. Собственные настройки лучше сохранять именно в данном каталоге, так ими будет проще управлять. ``` weekly rotate 4 create ``` В этой конфигурации журналы ротируются еженедельно, после четырехкратной ротации файл журналов удаляется, затем создаются новые файлы. Вы можете изменить процесс ротации журналов по своему усмотрению. Кроме того, можно включить свои журналы. В файле **logrotate.conf** можно использовать любую из следующих опций:
dailyежедневная ротация
weeklyеженедельная ротация
monthlyежемесячная ротация
yearlyежегодная ротация
compressсжатие старых файлов, прошедших ротацию
includeВключение большего количества файлов .conf
По умолчанию настроена еженедельная (***weekly***) проверка. Рассмотрим основные параметры управления и обработки журналов: * **rotate** — указывает, сколько старых логов нужно хранить (в параметрах передается количество); * **create** — создание пустого файла лога после перемещения старого; * **dateext** — перед заголовком старого лога добавляется дата ротации; * **compress** — сжатие логов; * **delaycompress** — не сжимать последний и предпоследний журнал; * **extension** — сохранять оригинальный лог-файл после ротации, если у него указано расширение; * **mail** — отправлять e-mail после завершения ротации; * **maxage** — выполнять ротацию журналов, если они старше, чем указано; * **missingok** — не выдавать ошибки, если лог-файла не существует; * **olddir** — перемещать старые логи в отдельную папку; * **postrotate/endscript** — выполнить произвольные команды после ротации; * **start** — номер, с которого будет начинаться нумерация старых логов; * **size** — размер лога, когда он будет перемещен. По умолчанию настроено хранение четырех старых файлов журналов, создание нового пустого файла журнала после перемещения старых и использование даты ротации при создании файлов журнала. Вы можете проверить сценарий оболочки, выполняемый ежедневно для ротации журнала, в файле **/etc/cron.daily/logrotate**. {% embed url="" %} {% embed url="" %} {% embed url="" %} {% embed url="" %}