Использование syslog для логирования работы программскриптов


Содержание

Использование syslog для логирования работы программ/скриптов

Сообщения об ошибках один из методов анализа правильности работы программы. Причем это не только сообщения для пользователя, но и сообщения об ошибках на этапе отладки приложения при разработке.

Вывод сообщений обычно делается через стандартный поток stderr, который перенаправляет все данные на консоль. Можно делать это и через stdout, но он может быть перенаправлен в файл или куда-либо еще, к тому же он обладает буфером, который ему не позволяет выводить данные моментально и если программа резко «обрушится», то Вы можете не увидеть нужных сообщений вообще. В потоке stderr буфер отключен, поэтому вызов функции fflush(stderr) не обязателен.

Все это конечно хорошо, если Вы разрабытаваете пользовательское консольное приложение, но как быть, если Ваша программа является сетевым приложением, например POP3 или каким-нибудь другим сервером. В этом случае работа с stderr не возможна, и отладка мягко выражаясь может сильно усложниться. Но не все так печально. Для этих случаев существует демон сообщений syslogd, который все сообщения от ядра и программ записывает в файлы хранящиеся в папке /var/log.

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

Предназначение функции closelog() думаю ясно, она закрывает дескриптор, который использовался для передачи сообщений в system logger. Ее использование опционально и, если вы забудете ее вызвать, то ничего катастрофичного не произойдет.

Для начала вывода сообщений Вам придется передать в функцию openlog() несколько необходимых параметров:

  • ident — текстовый идентификатор программы, обычно ее название. Он добавляется к началу каждого сообщения для того, чтобы было видно от какой программы поступают сообщения.
  • option — установки открываемого соединения, которые посредством операции OR могут складываться из следующих:
    • LOG_CONS — вывод напрямую в системную консоль, если вдруг происходит ошибка во время отправления сообщения
    • LOG_NDELAY — открывать соединение сразу, обычно соединение открывается после появления первого сообщения
    • LOG_PERROR — выводить сообщения в stderr
    • LOG_PID — добавлять PID программы в каждое сообщение. Полезно когда может работать одновременно несколько одинаковых программ, в этом случае их можно различить по идентификатору процесса.
  • facility — позволяет задать тип программы, которая выводит сообщение. Это полезно для того, чтобы разделять сообщения от различных программ и записывать их в разные файлы. Все это настраивается для syslogd файлом конфигурации /etc/syslog.conf. А значения этого параметра могут быть следующими:
    • LOG_AUTH — сообщения безопасности/авторизации (рекомендуется использовать LOG_AUTHPRIV)
    • LOG_AUTHPRIV — приватные сообщения безопасности/авторизации
    • LOG_CRON — сообщения от демонов времени (например, cron или at)
    • LOG_DAEMON — сообщения от других демонов системы
    • LOG_KERN — сообщения ядра системы
    • LOG_LOCAL0. LOG_LOCAL7 — зарезервированы для локального использования
    • LOG_LPR — подсистема принтера
    • LOG_MAIL — почтовая подсистема
    • LOG_NEWS — подсистема новостей USENET
    • LOG_SYSLOG — внутренние сообщения сгенерированные syslogd
    • LOG_USER (по умолчанию) — сообщения пользовательского уровня
    • LOG_UUCP — сообщения системы UUCP

Вызов функции openlog() также не обязателен, она будет автоматически вызвана при необходимости во время использования syslog(), но идентификатор программы будет установлен в NULL, что я думаю не будет считаться хорошим тоном.

Ну, и чтобы выводить сами сообщения надо использовать функцию syslog(), работа с которой похожа на работу с функцией printf, за исключением того, что сообщению можно задать приоритет(или тип), т.е. его важность. Задается приоритет параметром priority, который может иметь следующие значения:

  • LOG_EMERG — система не работает, грубо говоря в обмороке и требует госпитализации :)
  • LOG_ALERT — необходимо немедленно принять меры
  • LOG_CRIT — критическое состояние
  • LOG_ERR — ошибочное состояние
  • LOG_WARNING — состояние предупреждения
  • LOG_NOTICE — нормальное, но значимое, состояние
  • LOG_INFO — информационное сообщение
  • LOG_DEBUG — сообщение отладки, то что как раз нужно при разработке

А теперь попробуем написать программу test.c, использующую syslog:

Компилируем программу и попробуем запустить:

Теперь можем зайти в файл /var/log/messages и посмотреть, что там получилось. А получилось вот что:

Помоему классно, но почему-то не хватает некоторых сообщений. Посмотрим /var/log/debug и увидим, что все на месте :)

То есть тут мы можем увидеть, что сообщения разных типов выводятся в разные файлы. Настроить это можно с помощью файла /etc/syslog.conf. К примеру в данном случае он выглядит вот так:

Обратите также внимание, что сообщения, которые должны были выводиться в stderr дублируются в файл. Т.е. по большому счету, даже если поток stderr будет не доступен, то сообщения программы все равно дойдут до вас и это очень хорошо.

Настраиваем rsyslog на логирование в отдельные файлы

С целью минимально замусоривать /var/log/syslog, а также для удобства чтения журналов отдельных сервисов, перенаправляем вывод системного журнала в отдельные файлы.

Начнем с cron

для начала создадим файл для логированя

В файле /etc/rsyslog.d/50-default.conf раскоментируем строку

И, если мы не хотим, чтоб записи дублировались в /var/log/syslog, изменяем строку

dhcpd ( а точнее isc-dhcp-server)

для начала создадим файл для логированя

Создадим файл с нашими описаниями лог-файлов /etc/rsyslog.d/10-mylogs.conf с содержанием:

В данном случае мы определяем, что для сервиса dhcpd мы хотим логировать все сообщения в /var/log/dhcpd.log

вторая строчка говорит rsyslog-у, что мы больше не хотим обрабатывать журналируемое сообщение, или, проще говоря, больше не хотим писать сообщение от dhcpd в какой-либо файл. В более старых версиях rsyslog, возможно, нужно будет заменить stop на

dhclient, named, pppd, sshd,NetworkManager

Для указанных выше сервисов делаем все аналогично.

Итого наш файл /etc/rsyslog.d/10-mylogs.conf будет выглядеть так:

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

АйТи бубен

Инструменты пользователя

Инструменты сайта


Содержание

Использование syslog

syslog — стандарт отправки сообщений о происходящих в системе событиях (логов), использующийся в компьютерных сетях, работающих по протоколу IP. Настройка syslog производится через файл syslog.conf. syslog использует порт UDP 514.

Протокол syslog прост: отправитель посылает короткое текстовое сообщение, размером меньше 1024 байт получателю сообщения. Получатель при этом носит имя «syslogd», «syslog daemon», либо же, «syslog server». Сообщения могут отправляться как по UDP, так и по TCP. Как правило, такое сообщение отсылается в открытом виде. Тем не менее, используя специальные средства (такие, как Stunnel, sslio или sslwrap), возможно шифрование сообщений и отправка их по SSL сертификаты для для сайта, почты/TLS. Syslog используется для удобства администрирования и обеспечения информационной безопасности. Он реализован под множество платформ и используется в множестве устройств. Поэтому, использование syslog позволяет обеспечить сбор информации с разных мест и хранение её в едином репозитории.

В случае аварии системы, сообщение о возникшей проблеме, скорее всего, не будет записано на диск.

Примеры настроек syslog.conf

Файл syslog.conf служит для настройки протокола Использование syslog . После любых изменений в конфигурационном файле демон syslogd должен быть перезапущен, например так

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

Настройка syslog для iptables

По умолчанию Правила iptables логи записывает в журналы /var/log/messages, /var/log/syslog, и /var/log/kern.log. Настроим протоколирование iptables в отдельный файл iptables.log. Уровень протоколирования выбран –log-level INFO

Алгоритм изменений syslog:

Feanor184.ru

SysAdmin-s notepad. DoFollow.

Rsyslog и LogAnalyzer — поднимаем сервер логирования на Linux

LogAnalyzer – это web приложение, которое предназначено для просмотра логов системных событий, полученных от syslog, при помощи веб-браузера.

Rsyslog – это приложение, представляющее собой расширение стандартного демона syslog , одной из особенностью которого является возможность сохранять события в БД MySQL .

При помощи двух этих программ, можно создать централизованный сервер логов, где можно будет просматривать все события от различных устройств в сети, с удобным архивированным поиском событий на всех сетевых устройствах в сети. В данной статье будет описана процедура установки на Linux CentOS ( как установить Centos ? ) службы Rsyslog (сбор событий s yslog ) и LogAnalyzer (предоставляет отличный интерфейс для просмотра и поиска по собранным логам).

Сначала необходимо установить ряд дополнительных пакетов RPM. Т.к. службы LogAnalyzer , Rsyslog и MySQL будут работать на одном сервере, нужно установить следующие пакеты:

Теперь нужно удостоверится, что MySQL и Apache настроены на автоматический запуск, после чего запустим их:

По умолчанию, пользователь root БД MySQL , имеет пустой пароль, поэтому следует обезопасить конфигурацию, задав новый пароль:

Далее импортируем схему базы данных rsyslog в MySQL . В зависимости от версии rsyslog , измените путь к файлу “ createDB.sql ”.

Рекомендуется ограничение доступа приложений к базе данных, поэтому мы создадим специального пользователя для доступа к БД rsyslog . Для ещё большего затягивания настроек безопасности, можно создать отдельные учетные записи для rsyslog и LogAnalyzer . Необходимо предоставить доступ пользователя rsyslog к базе MySQL только с локального интерфейса localhost . Также мы должны выполнить MySQL команду “ flush privileges ” для немедленного применения всех прав.

Теперь пора перейти к редактированию файла” /etc/rsyslog.conf ”. Здесь нужно настроить пересылку сообщений syslog в базу данных MySQL . Первая команда загружает драйвер MySQL . Во второй строке мы говорим, что необходимо принимать логи любого уровня важности от “ authpriv ”, куда включены большинство важных сообщений. Если необходимо сохранять все системные сообщения в MySQL , нужно указать *.*. Мой сервер БД MySQL слушает на адресе 127.0.0.1, Syslog – это имя базы MySQL, и, наконец, указываем имя и пароль MySQL пользователя rsyslog . Здесь можно настроить сбор и запись любых сообщений, каждую комбинацию нужно отделять «;» (например, mail.*;authpriv.* : ommysql…).

Теперь нам нужно выключить существующую службу syslog и включить rsyslog :

Настала пора скачать LogAnalyzer . Последнюю версию можно найти тут: http://loganalyzer.adiscon.com/downloads.

Или скачать LogAnalyzer прямо с Linux сервера (должен быть установлен wget ):

Распакуем файлы LogAnalyzer :

Теперь нужно скопировать файлы LogAnalyzer в каталог веб-сервера Apache (стандартный конфиг).

Перейдем в созданный каталог LogAnalyzer , запустим скрипт configure.sh . В результате создастся пустой файл конигурации config.php , который наполнится в следующих шагах.

Настраиваем LogAnalyser

Для дальнейшей настройки LogAnalyzer нам понадобится веб-браузер. В любимом интернет-браузере наберите http://web1/loganalyzer. (web1 – имя нашего web1 сервера, loganalyzer – каталог apache)

В середине окна выберем ссылку “Click here to Install” и далее кнопку «Next».

Настроим параметры отображения журналов и опять нажмем «Next».

Теперь нужно указать адрес сервера с базой данных, имя пользователя и пароль для доступа к ней (БД называется rsyslog ). Нажав кнопку «Next», видим результат проверки правильности введенных данных и корректность подключения.

Илон Маск рекомендует:  Php руководство по рнр 3 0 solid (надежные) функции

И последний этап.

В том случае, если все настроено правильно, должна открыться главная страница LogAnalyzer , на которой по мере получения будут отображаться логи. Т.к. в настройках стоят — логирование событий типа “ authpriv ”, это означает, что в лог будут попадать такие события, как вход/выход пользователя, или же вызов команды переключения пользователя ( su ).

Настройка Rsyslog для удаленного сбора логов

Теперь, когда нам есть чем обрабатывать логи, можно переходить к настройке службы rsyslog для сбора, непосредственно, самих событий syslog с различных сетевых устройств. Сначала необходимо сконфигурировать сетевой экран, чтобы он пропускал входящий трафик по 514 порту. Можно добавить два правила, разрешающих как TCP , так и UDP трафик. По умолчанию syslog принимает только сообщения, отправленные по порту 514 UDP , однако в rsyslog добавлена возможность принимать и TCP трафик. Добавьте в файл “ /etc/sysconfig/iptables ” следующие правила:


Теперь нужно настроить rsyslog для приема входящих сообщений syslog . Настраиваем прием сообщений по TCP/ UDP от localhost и всех хостов в подсети 192.168.20.0. В файл “ /etc/rsyslog.conf ” нужно добавить следующие строки (перед стройкой, где настраивалась связь с базой MySQL ).

Не забудьте перезапустить службу rsyslog на центральном сервере ведения логов:

Следующий этап – настройка удаленных клиентов для отправки событий на центральный сервер rsyslog . Если на клиенте запущен rsyslog , в файл “ /etc/rsyslog.conf ” необходимо добавить, например, следующую строку:

Перезапускаем сервер rsyslog на клиенте и пробуем зайти/выйти на данную систему. Если мы ничего не упустили, на веб странице LogAnalyzer появится соответствующее событие!

Централизация логов с помощью Rsyslog, Logstash и Elasticsearch в Ubuntu 14.04

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

Программное обеспечение с открытым исходным кодом rsyslog, Elasticsearch и Logstash – удобное средство для передачи, преобразования и хранения данных логов.

Это руководство поможет создать централизованное хранилище логов нескольких систем и настроить передачу данных в Elasticsearch с помощью Logstash.

Централизованное логирование позволяет быстро выявить и устранить проблемы сервера или приложений.

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

Rsyslog собирает важную информацию из ядра и программ, необходимых для работы UNIX-подобных серверов. Поскольку syslog — это стандарт, многие программные проекты поддерживают отправку данных в syslog. Централизуя данные логов, вы можете быстро проводить аудит безопасности, отслеживать поведение приложений и другую важную информацию о сервере.

Затем можно переслать данные в Logstash, чтобы проанализировать данные логов перед отправкой в Elasticsearch.

Требования

Для выполнения руководства нужна инфраструктура из трёх серверов, находящихся в одном ЦОД, с включенной частной сетью.

  • Сервер 1: Ubuntu 14.04, который будет называться rsyslog-client.
  • Сервер 2: Ubuntu 14.04 (1 Гб минимум), который будет называться rsyslog-server. На нём будут храниться логи и Logstash.
  • Сервер 3: Ubuntu 14.04 с предварительно установленной платформой Elasticsearch (инструкции по установке здесь).
  • Пользователь с доступом к sudo на каждом сервере (больше об этом – здесь).
  • Частная сеть.

Примечание: Чтобы увеличить производительность, Logstash попытается выделить 1 гигабайт памяти по умолчанию, поэтому убедитесь, что размер сервера 2 может это позволить.

1: Определение внутренних IP-адресов

Для начала нужно узнать внутренний IP-адрес каждого сервера.

Для этого можно использовать команду:

sudo ifconfig -a

Флаг –a выбирает все интерфейсы. Это позволяет найти внутренний IP-адрес сервера (он не доступен в сети Интернет, только в локальной сети), привязанный к интерфейсу eth1.

Команда вернёт примерно такой вывод:

eth0 Link encap:Ethernet HWaddr 04:01:06:a7:6f:01
inet addr:123.456.78.90 Bcast:123.456.78.255 Mask:255.255.255.0
inet6 addr: fe80::601:6ff:fea7:6f01/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:168 errors:0 dropped:0 overruns:0 frame:0
TX packets:137 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:18903 (18.9 KB) TX bytes:15024 (15.0 KB)
eth1 Link encap:Ethernet HWaddr 04:01:06:a7:6f:02
inet addr:10.128.2.25 Bcast:10.128.255.255 Mask:255.255.0.0
inet6 addr: fe80::601:6ff:fea7:6f02/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:6 errors:0 dropped:0 overruns:0 frame:0
TX packets:5 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:468 (468.0 B) TX bytes:398 (398.0 B)
lo Link encap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0
inet6 addr: ::1/128 Scope:Host
UP LOOPBACK RUNNING MTU:16436 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:0 (0.0 B) TX bytes:0 (0.0 B)

Обратите внимание на строку inet addr в разделе eth1. В данном случае внутренним IP-адресом является 10.128.2.25.

Запустите команду на каждом из трех серверов. Скопируйте или запишите внутренние IP-адреса.

2: Настройка адреса Elasticsearch

Если вы следовали руководству Установка и настройка Elasticsearch в Ubuntu 14.04, вы умеете привязывать Elasticsearch к локальному хосту. Но в таком случае другие серверы не смогут взаимодействовать с этим инструментом.

Вместо локального хоста укажите в настройках Elasticsearch внутренний IP-адрес сервера, на котором установлен этот инструмент.

Перейдите на этот сервер (в данном случае это сервер 3) и откройте файл:

sudo nano /etc/elasticsearch/elasticsearch.yml

Найдите в нём строку network.bind_host. Если она закомментирована, раскомментируйте её и укажите внутренний IP-адрес текущего сервера:

sudo service elasticsearch restart

Примечание: Возможность подключаться к Elasticsearch должны иметь только заведомо безопасные серверы. Ограничьте доступ к серверу с помощью брандмауэра (например, iptables).

3: Настройка сервера для централизованного хранения логов

Примечание: Данный раздел нужно выполнить на сервере rsyslog-server (согласно списку требований, это сервер 2).

Сервер rsyslog-server должен получать данные других серверов на порт 514.

Для этого откройте файл /etc/rsyslog.conf:


sudo nano /etc/rsyslog.conf

Найдите в файле следующие закомментированные строки:

# provides UDP syslog reception
#$ModLoad imudp
#$UDPServerRun 514
# provides TCP syslog reception
#$ModLoad imtcp
#$InputTCPServerRun 514

Строки $ModLoad imudp и $ModLoad imtcp загружают модули imudp (input module udp) и imtcp (input module tcp). Эти модули прослушивают входящие данные, поступающие от других серверов.

Строки $UDPSerververRun 514 и $TCPServerRun 514 указывают, что rsyslog должен запустить серверы UDP и TCP на порт 514 (стандартный порт syslog).

Чтобы включить эти модули и серверы, раскомментируйте строки:

# provides UDP syslog reception
$ModLoad imudp
$UDPServerRun 514
# provides TCP syslog reception
$ModLoad imtcp
$InputTCPServerRun 514

sudo service rsyslog restart

Теперь сервер для централизованного хранения данных будет прослушивать сообщения удалённых серверов syslog.

Примечание: Чтобы проверить конфигурационный файл rsyslog, запустите:

sudo rsyslogd -N1

4: Настройка rsyslog для удаленной отправки данных

Теперь нужно настроить сервер rsyslog-client (сервер 1) для отправки данных логов на ryslog-server.

В стандартной установке rsyslog в Ubuntu каталог /etc/rsyslog.d содержит два файла:

Перейдите на сервер rsyslog-client и откройте конфигурационный файл:

sudo nano /etc/rsyslog.d/50-default.conf

Добавьте следующую строку перед строкой log by facility (вместо private_ip_of_ryslog_server укажите внутренний IP-адрес сервера ryslog_server).

Сохраните и закройте файл.

Точка в начале означает, что нужно отправлять все сообщения. Инструмент rsyslog может отправлять сообщения избирательно, но эта тема не рассматривается в данном руководстве. Символ @ перед IP-адресом значит, что сообщения нужно передавать по UDP. Чтобы использовать вместо этого TCP, введите @@.

Чтобы обновить настройки, перезапустите rsyslog:

sudo service rsyslog restart

Примечание: Чтобы проверить конфигурационный файл rsyslog, запустите:

sudo rsyslogd -N1

5: Преобразование логов в JSON

Elasticsearch требует, чтобы передаваемые данные были в формате JSON. Инструмент rsyslog предоставляет шаблон преобразования данных.

На данном этапе нужно настроить сервер 2 (rsyslog-server) для использования шаблона JSON. Это позволит отформатировать данные, прежде чем передать их в Logstash и Elasticsearch.

Вернитесь на сервер rsyslog-server и создайте новый конфигурационный файл, который будет форматировать логи в JSON.

sudo nano /etc/rsyslog.d/01-json-template.conf

Скопируйте следующие параметры и вставьте их в файл:

template(name=»json-template»
type=»list») <
constant(value=» <")
constant(value=»\»@timestamp\»:\»») property(name=»timereported» dateFormat=»rfc3339″)
constant(value=»\»,\»@version\»:\»1″)
constant(value=»\»,\»message\»:\»») property(name=»msg» format=»json»)
constant(value=»\»,\»sysloghost\»:\»») property(name=»hostname»)
constant(value=»\»,\»severity\»:\»») property(name=»syslogseverity-text»)
constant(value=»\»,\»facility\»:\»») property(name=»syslogfacility-text»)
constant(value=»\»,\»programname\»:\»») property(name=»programname»)
constant(value=»\»,\»proc )
constant(value=»\»>\n»)
>

Обратите внимание: все строки (кроме первой и последней) содержат запятую в начале. Это должно поддержать структуру JSON и выровнять все отступы. Этот шаблон форматирует сообщения так, как этого требуют Elasticsearch и Logstash. Вот как они будут выглядеть:

<
«@timestamp» : «2015-11-18T18:45:00Z»,
«@version» : «1»,
«message» : «Your syslog message here»,
«sysloghost» : «hostname.example.com»,
«severity» : «info»,
«facility» : «daemon»,
«programname» : «my_program»,
«procid» : «1234»
>

Примечание: На сайте rsyslog можно найти больше переменных для форматирования данных логов.

Шаблон для форматирования готов, теперь нужно настроить сервер для его использования.

6: Настройка отправки данных в Logstash

Теперь нужно настроить сервер rsyslog server для передачи данных в Logstash.

При запуске rsyslog будет читать файлы /etc/rsyslog.d и создавать конфигурации на их основе.

На сервере rsyslog-server создайте файл /etc/rsyslog.d/60-output.conf:


sudo nano /etc/rsyslog.d/60-output.conf

Вставьте в файл следующие строки:

# This line sends all lines to defined IP address at port 10514,
# using the «json-template» format template
*.* @private_ip_logstash:10514;json-template

Строка, которая начинается с *.*, будет применена ко всем сообщениям. Символ @ перед IP-адресом значит, что сообщения нужно передавать по UDP. Чтобы использовать вместо этого TCP, введите @@. Сообщения будут передаваться на адрес или хост, указанный после символа @. В данном случае используется внутренний IP-адрес сервера rsyslog-server (поскольку Logstash установлен на этом же сервере).

Примечание: Этот адрес должен совпадать с IP-адресом, указанным в настройках Logstash (в следующем разделе).

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

Не перезапускайте rsyslog. Сначала нужно настроить Logstash для получения сообщений.

7: Настройка Logstash для получения сообщений JSON

Теперь нужно настроить Logstash для получения сообщений rsyslog и передачи полученных данных в Elasticsearch.

Для работы Logstash нужно установить Java 7+. Инструкции по установке можно найти в руководстве Установка и настройка Elasticsearch в Ubuntu 14.04.

Установите ключ репозитория Logstash:

wget -qO — https://packages.elastic.co/GPG-KEY-elasticsearch | sudo apt-key add —

Добавьте определение репозитория в /etc/apt/sources.list:

echo «deb http://packages.elastic.co/logstash/2.3/debian stable main» | sudo tee -a /etc/apt/sources.list

Примечание: Используйте метод echo, описанный выше, чтобы добавить репозиторий Logstash. Не используйте add-apt-repository; эта команда добавит запись deb-src, но Elastic не предоставляет исходный пакет. Это приведет к ошибке при попытке запустить apt-get update.

Обновите индекс пакетов:

sudo apt-get update

sudo apt-get install logstash

По умолчанию конфигурационные файлы Logstash находятся в /etc/logstash/conf.d. Отредактируйте конфигурационный файл:

sudo nano /etc/logstash/conf.d/logstash.conf

Добавьте следующие строки в /etc/logstash/conf.d/logstash.conf:

# This input block will listen on port 10514 for logs to come in.
# host should be an IP on the Logstash server.
# codec => «json» indicates that we expect the lines we’re receiving to be in JSON format
# type => «rsyslog» is an optional identifier to help identify messaging streams in the pipeline.
input <
udp <
host => «logstash_private_ip»
port => 10514
codec => «json»
type => «rsyslog»
>
>
# This is an empty filter block. You can later add other filters here to further process
# your log lines
filter < >
# This output block will send all events of type «rsyslog» to Elasticsearch at the configured
# host and port into daily indices of the pattern, «rsyslog-YYYY.MM.DD»
output <
if [type] == «rsyslog» <
elasticsearch <
hosts => [ «elasticsearch_private_ip:9200» ]
>
>
>

Согласно определению протоколом syslog является UDP.

В блоке input укажите IP-адрес сервера rsyslog-server, на котором установлен инструмент Logstash.

Блок input запускает прослушивание Logstash порта 10514. Для прослушивания портов меньше 1024 необходимо запускать Logstash как root, а это может быть опасно для сервера.

Обязательно замените elasticsearchprivateip внутренним IP-адресом сервера Elasticsearch. Блок output настраивает поиск событий rsyslog.

Протестируйте изменения настроек Logstash:

sudo service logstash configtest

Команда должна вернуть:

Илон Маск рекомендует:  Что такое код mb_output_handler

Если команда сообщила об ошибках, исправьте их.

После этого можно запустить Logstash:

sudo service logstash start

sudo service rsyslog restart

Убедитесь, что Logstash прослушивает порт 10514:

netstat -na | grep 10514

Команда должна вернуть:

udp6 0 0 10.128.33.68:10514 . *

Вы увидите внутренний IP-адрес сервера rsyslog-server и порт, который он прослушивает (10514).

Примечание: Чтобы устранить неисправности Logstash, остановите службу с помощью команды sudo service logstash stop и запустите:


/opt/logstash/bin/logstash -f /etc/logstash/conf.d/logstash.conf —verbose

Эта команда предоставит подробный вывод, в том числе и IP-адрес и UDP-порт Logstash.

Starting UDP listener <:address=>«10.128.33.68:10514», :level=>:info>

8: Тестирование Elasticsearch

Платформа Elasticsearch прослушивает внутренний IP-адрес сервера, на котором она установлена. Теперь она получает сообщения Logstash. Убедитесь, что Elasticsearch может получать данные.

Серверы rsyslog-client и rsyslog-server должны отправлять все данные логов в Logstash, а оттуда данные будут передаваться в Elasticsearch. Сгенерируйте сообщение безопасности, чтобы убедиться, что Elasticsearch получает сообщения.

Перейдите на rsyslog-client и введите:

sudo tail /var/log/auth.log

В конце вывода вы увидите сообщение лога локальной системы:

May 2 16:43:15 rsyslog-client sudo: 8host : TTY=pts/0 ; PWD=/etc/rsyslog.d ; USER=root ; COMMAND=/usr/bin/tail /var/log/auth.log
May 2 16:43:15 rsyslog-client sudo: pam_unix(sudo:session): session opened for user root by 8host(u >

Создайте простой запрос, чтобы проверить работу Elasticsearch.

Запустите следующую команду на сервере Elasticsearch или в любой системе, у которой есть доступ к этой платформе.

Вместо elasticsearch_ip укажите внутренний IP-адрес сервера Elasticsearch.

curl -XGET ‘http://elasticsearch_ip:9200/_all/_search?q=*&pretty’

Обратите внимание: в логе указано имя сервера, который сгенерировал сообщение rsyslog (rsyslog-client).

Теперь установка полностью готова к работе.

Заключение

Вы настроили централизацию логов с помощью Elasticsearch и Logstash.

Настройка связки ELK для центрального логирования, как принять логи с rsyslog-клиентов?

Доброго времени суток! Имеется задача поднять связку по сбору логов через UDP с клиентов. Делаю пробную тестовую версию, но подводные камни повсюду.

Имеется:
поток логов с нескольких клиентов (*.*@logstash-server);
logstash, настроенный на прием и отправку в elasticsearch + kibana.

Конфиг logstash (по сути скопировано с оф. документации для приема и обработки логов rsyslog-клиентов)

Проблема: логи сыпятся, если посмотреть вывод tcpdump. Порты открыты. Logstash слушает нужный порт.
Но логов нигде не видно. Они сыпятся на интерфейс, но куда они сохраняются? И сохраняются ли вообще?
В elasticsearch никаких настроек не делал, кроме как получения доступа через браузер.
Как корректно принять логи от rsyslog-клиентов?
Не нашел ни одного мануала, где бы logstash использовался как приемник от rsyslog с последующей отправкой в elasticsearch.
Буду признателен за наводки и\или подсказки.

  • Вопрос задан более двух лет назад
  • 1749 просмотров

Нашёл проблему, всё оказалось просто. Упрощенный базовый конфиг:

PS Логстэш слушает на 50514, а iptables перенаправляет входящий трафик на порт 514:

Настройка логирования с помощью Rsyslog и Loganalyzer

В статье рассматривается настройка централизованного сбора логов и графического отображения статистики по ним в веб-интерфейсе с помощью пакетов Rsyslog и Loganalyzer на CentOS 7. Для настройки использовались две машины: Сервер – ip 192.168.32.115, клиент – ip 192.168.32.116, hostname – client1. Настройка сервера: Перед установкой Rsyslog установить пакеты libestr и libee. Установка репозитория mysql Установка необходимых […]

В статье рассматривается настройка централизованного сбора логов и графического отображения статистики по ним в веб-интерфейсе с помощью пакетов Rsyslog и Loganalyzer на CentOS 7.

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

Сервер – ip 192.168.32.115, клиент – ip 192.168.32.116, hostname – client1.

Настройка сервера:

Перед установкой Rsyslog установить пакеты libestr и libee.

Установка репозитория mysql

Установка необходимых пакетов.


Добавление в автозагрузку и запуск служб:

Теперь можно установить пакеты rsyslog:

Добавляем в автозагрузку rsyslog и запускаем сервис.

После установки mysql для того, чтобы найти временный пароль для входа с правами администратора выполнить команду:

Т.к. временный пароль хранится в простом текстовом файле /var/log/mysqld.log, для изменения пароля пользователя root в консоли mysql ввести:

Также, в консоли mysql:

Настройка конфигурационного файла /etc/rsyslog.conf.

Открываем файл для редактирования:

Далее сохраняем изменения в конфигурационном файле, и перезапускаем rsyslog для применения настроек.

Установка LogAnalyzer

Создаем директорию, копируем файлы LogAnalyzer.

Последняя команда создаст пустой файл config.php и предоставит право записи в него. Далее необходимо запустить

для проверки создания файла config.php. Настройка через браузер внесет изменения в этот файл.

Создание пользователя и базы данных в mysql:

Дальнейшие настройки производятся в веб. В браузере необходимо перейти по адресу ip_адрес_сервера/log.

Нажать далее (Next)

Проверка прав на запись для файла config.php

Настройка базовой конфигурации

Проверка создания таблиц

Создание учетной записи для входа в LogAnalyzer

Создание источника системных сообщений

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

И проверить установленное время и часовой пояс:

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

На клиенте также устанавливаем Rsyslog

Для отправки всех логов.

Открываем конфигурационный файл

Добавляем в конфигурационный файл

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

После авторизации на сервере в веб панели LogAnalyzer отображаются недавние сообщения Rsyslog.

При переходе в пункт меню Statistics – данные отображаются в виде графиков.

В LogAnalyzer можно отфильтровать вывод применив фильтры по колонкам Facility (Обьект), Severity (Серьезность), Host (Хост), Syslogtag (Системный журнал), Messagetype (Тип сообщения) нажав на какое-либо значение-тэг. После нажатия появится контекстное меню Available searches(список фильтров для поиска). Например, для хоста client1:

Add ‘client1’ to filterset – Добавить ‘client1’ в поле фильтров поиска (доступно, если хотя бы один фильтр поиска был установлен ранее)

Exclude ‘client1’ from filterset – Исключить ‘client1’ в поле фильтров поиска (доступно, если хотя бы один фильтр поиска был установлен ранее)

Filter ‘client1’ only – Фильтровать вывод только по значению ‘client1’

Show all except ‘client1’ – Вывести все, исключая ‘client1’

Предположим, необходимо просмотреть только системные сообщения для хоста client1 – выбираем третий пункт Filter ‘client1’ only.

После этого в выводе появятся сообщения, относящиеся только к хосту client1.


Для возврата и сброса фильтров можно нажать на одну из иконок раскрывающегося списка (после столбца Messagetype) Back to unfiltered view with this message at top – возврат к выводу без фильтров с текущим сообщением в топе (в зависимости от того на какой строке было выбрано).

Программная реализация системы журнальной регистрации в Linux: Конфигурирование syslogd

Тонкости в работе syslogd. Ротация журнальных файлов. Программа logrotate.

Описание: В статье показано, как в системах Linux реализована работа с программами syslogd и logrotate и какие они выполняют задачи. Материал будет полезен начинающим системным администраторам, которые хотят разобраться с основами и принципами ведения журнальных файлов в GNU/Linux.

Введение

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

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

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

В основном, Linux-приложения записывают журнальную информацию в файлы, находящиеся в каталоге /var/log, а отдельные дистрибутивы используют для этого каталог /var/adm. Большинство журнальных файлов – это обычные текстовые файлы, в которые записываются сообщения о тех или иных событиях, происходящих в системе. Важно различать журнальную регистрацию на уровне ядра, на этапе начальной загрузки (журналы стартовых скриптов) и журналы демонов. Сообщения, генерируемые ядром, обрабатываются демоном klogd. Демон может или просто создать образ журнального буфера ядра и завершить работу, или динамически извлекать сообщения из буфера по мере их появления и записывать их в файл.

Регистрацией сообщений стартовых скриптов в отдельных системах занимается программа initlog.

Утилита, которая присутствует практически во всех дистрибутивах Linux и занимается журнальной ротаций, называется logrotate.

А полнофункциональная система регистрации событий, написанная Эриком Оллманом и решающая вопросы автоматизации ведения журнальных файлов и управления журнальной регистрацией, называется syslogd.

Программа Syslogd

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

В состав системы журнальной регистрации входят демон syslogd, библиотеки, при помощи которых программы могут отсылать сообщения этому демону и программа logger, применяемая в shell script для отсылки сообщений демону syslogd.

Информация, полученная от программ, фильтруется демоном syslogd в соответствии с описанными фильтрами в конфигурационном файле /etc/syslog.conf.

Отфильтрованные сообщения могут отправляться в файл, на экран терминала и по сети на другой сервер, где также должен работать демон syslogd.

Важно помнить, что не все системные программы используют его в своей работе. Например, веб-сервер apache и прокси-сервер squid, а также samba используют собственную систему журналирования.

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

  • средство (facility);
  • уровень важности сообщения (priority).

Эти параметры определяют использование только специально зарезервированных слов. Ниже представлены наиболее важные из них:

  • auth: сообщения, связанные с аутентификацией. Возможно использование authpriv вместо указанного;
  • authpriv: сообщения, содержащие конфиденциальную информацию и сообщения, связанные с аутентификацией;
  • cron: сообщения программам cron и at;
  • daemon: сообщения различных служб;
  • kern: сообщения ядра;
  • lpr: сообщения подсистемы печати;
  • mail: сообщения постовой системы;
  • mark: внутреннее средство системы syslogd, предназначенное для генерации временных меток. Не используется в программах;
  • news: сообщения сервера новостей;
  • syslogd: внутренние сообщения системы syslogd;
  • user: сообщения, создаваемые пользовательскими программами;
  • uucp: сообщения системы uucp;
  • localo …local: набор дополнительных средств для использования программами, не подпадающими под стандартные средства.

При посылке сообщений в систему журнальной регистрации и при описании фильтров можно использовать уровни важности. Ниже перечислены наиболее важные из них:

  • debug: отладочная информация или набор вспомогательных сообщений;
  • info: информационные сообщения;
  • notice: сообщения, требующие внимания;
  • warning: предупреждающие сообщения;
  • err: ошибки, препятствующие нормальной работе;
  • crit: критические ошибки. Как правило, более серьезные, чем err;
  • alert: события, требующие срочного реагирования;
  • emerg: ошибки, останавливающие работу системы;
  • none: применяется при задании исключений в фильтрах.

В современных версиях системы syslogd, для совместимости с предыдущими, оставлены такие уровни важности, как warn (аналог warning), error (аналог err) и panic (аналог emerg).

Демон syslogd имеет свой конфигурационный файл /etc/syslog.conf , в котором описываются фильтры, выбирающие из всего потока информации нужную и место ее назначения. В общем случае, формат файла syslog.conf имеет вид:

Под «фильтр» понимается алгоритм отбора сообщений, под «действие» – система действий в отношении отобранной информации. Поля в обязательном порядке должны быть разделены одним или двумя символами табуляции.

Илон Маск рекомендует:  Основы mfc

В поле «действие» можно указывать:

  • путь к файлу;
  • именованные каналы;
  • терминалы и консоли;
  • удаленные машины;
  • списки пользователей;
  • символ «*».

Путь к файлу

Если в поле «действие» необходимо указать, что получаемая информация должна добавляться в конец файла журнала, то путь к этому файлу указывается полностью, например /var/log/file/

Отдельные версии syslogd допускают использование следующей записи: -/var/log/file (дефис перед записью).

Если информация передается демону syslogd сразу, без предварительной буферизации, то она немедленно сохраняется в файлах на жестком диске. Это улучшает шансы спасти данные в случае серьезного сбоя в работе системы. Но в случае большого объема такой информации появляется другая угроза – слишком большое потребление ресурсов сервера при записи на диск без предварительной буферизации. Если перед именем файла использовать символ ‘-‘ , то он укажет демону syslogd на то, что не надо немедленно сбрасывать информацию на диск и можно использовать стандартную буферизацию файловых систем. При сбое системы в этом случае часть информации будет утеряна, но сохранится приемлемая скорость работы сервера в силу меньшего потребления ресурсов.

Именованные каналы


Использование именованных каналов применяется крайне редко и, как правило, в режимах отладки. Первоначально с помощью mkfifo создается файл именованного канала, затем в поле «действие» файла /etc/syslog.conf можно применять следующую запись:

Терминалы и консоли

При необходимости получения информации на экран терминала, в поле «действие» следует указать файл устройства, соответствующий выбранному терминалу или консоли, например: /dev/tty9.

Удаленные машины

При использовании этой возможности в поле «действие» нужно написать одну из следующих строк: @2.3.4.5 или

при этом информация, отобранная фильтром, будет по указанному после знака @ адресу. На удаленной машине также должен работать демон syslogd, причем он должен быть запущен с опцией «-r» для приема сообщений на 514 порту (см. файл /etc/services).

Список пользователей

Критические сообщения должны выводиться в окно терминала пользователя root. При необходимости вывода таких сообщений на окна терминалов, за которыми работают другие пользователи, необходимо в поле «действие» перечислить через запятую список этих пользователей.

Символ «*»

Если этот символ указан в поле «действие», то сообщения, отобранные фильтром, будут выводиться на терминалы всех пользователей, работающих в данный момент в системе.

Поле «фильтр» конфигурационного файла /etc/syslog.conf описывает фильтры, выбирающие из всего потока информации только определенную ее часть. В фильтре в качестве условия отбора информации можно указывать только средство и уровень важности. При этом информация, поступающая демону syslogd, проверяется всеми фильтрами, указанными в конфигурационном файле. Это означает, что одна и та же информация может попадать в различные журнальные файлы. Ниже приведены некоторые примеры использования фильтров.

  • mail.debug сообщения средства mail с уровнем важности debug и выше.
  • mail.!emerg сообщения средства mail с уровнем важности меньшим, чем emerg.
  • mail,news.=notice сообщения средства mail и news с уровнем важности notice.
  • *.notice;mail.none сообщения всех средств с уровнем notice и выше, за исключением средства mail.

В одной строке можно указывать несколько фильтров, разделенных символом «;».

Ниже приведено несколько реальных примеров описания фильтров из /etc/syslog.conf.

сообщения всех средств, с уровнем важности info, за исключением сообщений средств mail, authpriv, cron и auth будут добавляться в конец файла /var/log/messages.

сообщения средств auth и authpriv любого уровня важности будут добавляться в конец файла /var/log/secure.

Тонкости в работе syslogd

Нужно учитывать, что в своей работе syslogd очень щепетильно относится к обработке файлов регистрации. Если имело место ручное редактирование файлов или они были удалены и созданы вновь, то демон syslogd не будет с ними работать, и информация будет теряться. Если файлы были изменены, то демону нужно послать сигнал HUP:

или другим путем:

При изменении конфигурационного файла /etc/syslog.conf демону тоже нужно посылать сигнал HUP.

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

при этом демону сигнал HUP посылать не нужно, он будет продолжать с ним работать.

К еще одной особенности демона можно отнести преобразование ip-адресов машин в их имена, причем демон в этом случае не использует систему DNS. Для использования имен вместо ip-адресов в файлах регистрации, нужно задать их соответствие в файле /etc/hosts.

Программа logrotate

Утилита logrotate была разработана для реализации различных схем управления журнальными файлами и для решения вопроса ограничения размера этих файлов. Изначально она являлась частью таких дистрибутивов, как RedHat и Debian, а впоследствии получила распространение и на другие дистрибутивы.

Ротация журнальных файлов происходит по определенным условиям:

  • один раз в день;
  • один раз в неделю;
  • один раз в месяц;
  • при превышении файлом заданного размера.

С помощью программы logrotate можно выполнять следующие действия:

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

Конфигурационный файл программы logrotate находится в /etc/logrotate.conf. Здесь описываются опции по умолчанию и файлы, которые будут подвергаться ротации.

Некоторые наиболее важные параметры, используемые в конфигурационном файле:

  • compress: если указан, то после ротации файлы сжимаются gzip;
  • create[mode, owner, group]: если указан, то после ротации будет создан файл с указанными параметрами;
  • include (файл или каталог): включает содержимое указанного файла в основной конфигурационный файл;
  • mail [address]: определяет почтовый адрес посылки файла после его ротации;
  • mailfirst: отсылает по почте первую копию ротированного файла;
  • maillast: отсылает по почте последнюю копию ротированного файла;
  • missingok: при отсутствии файла перейти к следующему и не выдавать сообщений об ошибке;
  • postrotate и endscript: определяют программы, выполняющиеся после ротации;
  • prerotate и andscript: определяет программы, выполняющиеся перед ротацией;
  • weekly : ротация происходит один раз в неделю;
  • size размер: как только размер файла превысит указанный, произойдет и ротация;
  • daily: ротация файла будет происходить один раз в неделю;
  • monthly: ротация файла будет происходить один раз в месяц.

Пример конфигурационного файла logrotate.conf сразу после установки системы Ubuntu Linux 8.04 LTS:

В третьей строке задается период ротации файлов один раз в неделю. Этот параметр можно переопределить при описании ротации какого-нибудь конкретного файла. В строке 5 (rotate 4) указывается, что по умолчанию будет сохранено четыре копии файла. В строке 7 (create) говорится, что программа logrotate будет создавать файлы самостоятельно. В строке 11 (include /etc/logrotate.d) подключаются все файлы из каталога /etc/logrotate.d, если они там есть. В 13 строке определяется ротация файла wtmp – один раз в месяц, файл будет создаваться с правами 0664 и принадлежать root и группе utmp. Храниться будет только одна копия файла.


Программа logrotate выполнена не в виде демона, и ее необходимо запускать каждый раз, когда необходима ротация. Добиться этого можно с помощью систем cron или anacron. После установки программы logrotate, в каталог /etc/cron.daily помещается скрипт, который запускает программу ротации. Эта программа по умолчанию будет запускаться один раз в день.

Выводы

В статье детально рассмотрены программы syslogd и logrotate. Пошагово описаны и расшифрованы опции, параметры конфигурационных файлов, применение и реальные примеры. Изложены некоторые тонкости функционирования программы syslogd.

Об авторе

Занимал должности от инженера 1 категории до начальника отдела IT. В настоящий момент работает ведущим консультантом-экспертом отдела инженерного и технического сопровождения Администрации Краснодарского края.

Нет похожих постов.

Добавить комментарий Отменить ответ

Для отправки комментария вам необходимо авторизоваться.

Использование syslog для логирования работы программ/скриптов

void openlog(const char * ident , int option , int facility );
void syslog(int priority , const char * format , . );
void closelog(void);

void vsyslog(int priority , const char * format , va_list ap );

ОПИСАНИЕ

openlog() устанавливает связь с программой, ведущей системный журнал. Строка ident добавляется к каждому сообщению и обычно представляет собой название программы. Аргумент option указывает флаг управляющий работой openlog() и соответствующих вызовов syslog() . Аргумент facility устанаваливает значение по умолчанию если не указываются соответствующие параметры при вызовах syslog() . Значения option и facility приводятся ниже. Использование openlog() тоже необязательно, оно при необходимости автоматически будет вызвано функцией syslog() , и в этом случае значение ident будет установлено равным NULL.

syslog() создает сообщение для журнала, которое передается syslogd (8). priority получаеся при логическом сложении facility и level , описанных в следующей главе. Остаются аргументы format (как и в printf (3)) и аргументы для format , кроме того, что сочетание %m будет заменено сообщением об ошибке strerror ( errno ) и будет добавлен завершающий символ новой строки.

ПАРАМЕТРЫ


option


facility .


level ,

Функция setlogmask (3) может использоваться для ограничения доступа на указанные уровни.

СООТВЕТСТВИЕ СТАНДАРТАМ


ПРИМЕЧАНИЯ ПО ИСТОРИИ


ЗАМЕЧАНИЯ

Никогда не передавайте строку с предоставленным пользователем форматом, лучше используйте syslog(«%s», string);

Ведение логов syslog

Запись логов ведётся специальным приложением syslogd или его современной версией rsyslogd. Для отправки сообщений демону используется сетевой протокол, который может использовать либо TCP/IP, либо Unix сокет /dev/log. Программист на Си может воспользоваться для записи в лог стандартной функцией syslog(3), а разработчик скриптов или обычный пользователь – утилитой logger.

Особенностью протокола syslog является доверие к клиенту, что приводит к возможности генерировать записи любого содержания в любом логе от имени любой службы (в том числе от имени ядра ОС).

Сообщение, передаваемое в syslogd, содержит класс сообщения, состоящий из категории и важности, идентификатор (имя программы) и произвольный текст. syslogd на основе класса сообщения выбирает файл для записи и сохраняет в этот файл время получения сообщения, идентификатор и текст.

Классы сообщений

По категориям: authpriv, cron, daemon, ftp, kern, lpr, mail, news, syslog, user, uucp, local0. local7

authpriv – данные могут содержать приватную информацию, например пароли при логировании процесса аутенификации. Такие данные должны сохраняться в файле, недоступном на чтение для обычных пользователей.
cron, ftp, lpr, mail, news, uucp – различные службы (в том числе устаревшие), которые генерируют большой поток сообщений. В CentOS отдельно настроены mail и cron
daemon – любая служба
user – обычный пользователь
syslog – сообщения самого syslogd
local0. local7 – отданы на усмотрение местного администратора. В CentOS local7 используется для записи сообщений во время загрузки

По важности: emerg, alert, crit, err, warning, notice, info, debug

emerg – критическая ошибка, затрагивающая всю систему (отказ диска, отключение электропитания и т.п.)
alert, crit – проблемы различной степени тяжести. Используются редко
err, warning, notice, info – диапазон, обычно используемый приложениями
debug – отладочные сообщения. Обычно нигде не сохраняются

Конфигурационные файлы syslogd/rsyslogd

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

фильтр действие

фильтр – описывает класс сообщений, для которых будет выполняться действие, и состоит из шаблонов, разделённых точкой с запятой. Каждый шаблон состоит из полей категории и важности, разделённых точкой. Фильтр выбирает те сообщения, категория и важность которых соответствуют всем шаблонам фильтра. Т.е. условия-шаблоны объединяются логическим оператором И.

Примеры фильтров:
mail.info – категория mail, важность info и выше
*.=debug – любая категория, важность – только debug
*.* – все сообщения
*.*;authpriv.none – все, кроме категории authpriv

действие – имя файла, FIFO, программы или IP адрес удаленного компьютера.

Формат записи действий:
/var/log/messages – файл
/dev/console – консоль (root’а?)
/dev/ttyS0 – последовательный порт
|/tmp/debug-log – FIFO. Удобно для отладки
@192.168.1.0 – IP адрес
* – сообщение всем залогированным пользователям

Пример из реального файла syslog.conf

Программа logger

logger -t идентификатор -p категория.важность текст

Понравилась статья? Поделиться с друзьями:
Кодинг, CSS и SQL