Журналирование событий (Syslog\rsyslog)
В данной статье мы рассмотрим стандартный демон логирования syslog. Он немного устарел, но с ним разобраться стоит потому, что все современные системы логирования построены по такому же принципу и имеют лишь небольшие отличия и небольшие улучшения, немного расширенный функционал.
Система логирования в любой операционной системе играет важнейшую роль. Это связанно с тем, что с помощью нее осуществляется разбор ошибок, поиск неисправностей и восстановление работоспособности сервисов. Очень часто бывает так что операционная система или сервисы ведут себя не так, как мы ожидаем от них и лучший способ разобраться с проблемой заглянуть в журнал логирования.
В данной статье разберем, как настраивается стандартный демон syslog, понятия источников событий и приоритета событий. В операционной системе windows тоже есть данный функционал, но развит не так хорошо, как в операционных системах Linux.
Итак, Стандарт конфигурации событий выглядит следующим образом:
Мы пишем для каждого источника события, источник, приоритет и куда такие события отправлять, т.е действие. Формат:
источник.приоритет назначение.
Источников в операционной системе Linux может быть много более 20 штук. Самые популярные представлены на картинке.
В операционной системе windows, есть 3 уровня приоритетов Информационные, предупреждения и ошибка. У операционной системы linux приоритетов 8 штук, разберем их:
1. Emergency – чрезвычайная ситуация;
2. Alert – тревога;
3. Critical – критическое событие;
4. Error – ошибка;
5. Warning – предупреждение;
6. Notice – замечание;
7. Info – информационное сообщение;
8. Debug – отладочное событие;
И последняя колонка на картинке – это примеры куда мы можем записывать те или иные события:
1. Файл – мы можем записывать в журнал;
2. Консоль – мы можем выводить в консоль;
3. Конвеер – мы можем передавать с помощью конвеера сразу следующей команде;
4. Удаленная система – можем передавать удаленной системе;
5. Группа пользователей – можем передавать группе пользователей;
К сожалению, открыть файл cat /etc/syslog.conf (CentOS 5) не получится, т.к является устаревшим, но подходит для объяснения принципа настройки. Например современный rsyslog , настраивается практически идентично в разных системах находится в разных местах на виртуальной машине Ubuntu 20.04 расположен /etc/rsyslog.d/ 50-default.conf
Примерно таким образом выглядит конфигурационный файл. В данном файле все настройки демона. Мы можем увидеть ,что все события ядра kern.* выводятся в файл /var/log/kern.log . Символ “*” говорит о том, что события с любым приоритетом. Мы можем изменить указав явно приоритет например kern.info или kern.debug , можем так же изменить куда выводить например в консоль /dev/console.
У нас в файле есть строчка закомментированная *.info; *.=notice;*.=warn;\ отправлять в /var/log/messages, если мы ее раскомментируем, то данные все события будут уходить в указанный файл.
Есть строчка auth,authpriv.* /var/log/auth.log, которая означается, что все события авторизации , в том числе и с вводом паролей будут записываться в отдельный файл /var/log/auth.log , это сделано специально, в целях информационной безопасности. На отдельный файл проще поставить особые права доступа.
Есть в файле еще интересная строчка mail.* -/var/log/mail.log, которая говорит нам о том , что все почтовые события будут записываться в журнал /var/log/mail.log.
Обратите внимание, что некоторые файлы имеет значок “-” перед указанием пути. Этот символ указывает демону на то, что после использования данного журнала, не нужно выгружать из оперативной памяти. Это сделано для того, чтобы более оперативно работать с журналами и в оперативной памяти всегда есть кэш данного файла. Есть и минус такого подхода. Если у нас случится паника ядра, т.е аппаратная ошибка и система вылетит, то те события, которые находились в оперативке, не успеют сбросится на жесткий диск и мы их потеряем.
#Linux #open source