«Помедленнее, я записываю»: туториал по системным логам Linux

Из этой статьи вы узнаете, что такое журналы Linux, какие инструменты их генерируют и где эти журналы хранятся, — пишет proglib.io. — Рассмотрим, как и зачем искать и читать результаты journald и syslog, а также о том, как собрать логи нескольких серверов в одном месте.

Что такое логи?

Логи (журнал сервера, англ. server log) – это записываемые фрагменты данных, описывающие то, что в конкретный момент времени делает сервер, ядро, службы и приложения. Вот пример лога SSH из /var/log/auth.log:

May 5 08:57:27 ubuntu-bionic sshd[5544]: pam_unix(sshd:session): session opened for user vagrant by (uid=0)

Обратите внимание, что непосредственно перед сообщением лог содержит несколько полей: метка времени, имя хоста, инициатор события и идентификатор процесса.

Логи в Linux поступают из разных источников. Ниже перечислены основные.

Подсистема systemd. Большинство дистрибутивов Linux для управления службами имеют в своём составе systemd. Подсистема инициализации и управления ловит выходные данные служб и записывает их в журнал. Для работы с логами systemd используется система журналирования journalctl (шпаргалка по работе с journalctl):

$ journalctl
...
May 05 08:57:27 ubuntu-bionic sshd[5544]: pam_unix(sshd:session): session opened for user vagrant by (uid=0)
...

Сообщения процессов по стандарту syslog. При отсутствии systemd такие процессы, как SSH, могут записывать данные в UNIX-сокет в формате syslog. Демон syslog, например, rsyslog, выбирает сообщение, анализирует и по умолчанию записывает его в /var/log.

Ядро Linux пишет собственные логи в особый буфер. Подсистемы systemd или syslog могут считывать журналы из этого буфера, а затем записывать их в свои журналы или файлы – обычно /var/log/kern.log. Чтобы посмотреть логи ядра, воспользуйтесь dmesg:

$ dmesg -T
...
[Tue May 5 08:41:31 2020] EXT4-fs (sda1): mounted filesystem with ordered data mode. Opts: (null)
...

Audit logs. Особый случай сообщений ядра, предназначенных для аудита событий, таких как доступ к файлам. Обычно для прослушивания таких журналов безопасности, существует специальная служба, например, auditd, записывающая свои сообщения в /var/log/audit/audit.log.

Журнал приложений. Несистемные приложения имеют тенденцию записывать данные в /var/log:

• Apache (httpd) обычно пишет в /var/log/httpd или /var/log/apache2. Журналы HTTP-доступа находятся в файле /var/log/httpd/access.log.
• Логи MySQL обычно находятся в /var/log/mysql.log или /var/log/mysqld.log.
• Старые версии Linux могут записывать свои логи загрузки с помощью bootlogd в /var/log/boot или /var/log/boot.log. В современных ОС об этом заботится systemd: вы можете просматривать связанные с загрузкой журналы с помощью journalctl -b. Дистрибутивы без systemd снабжены syslog-демоном, считывающим данные из буфера ядра. Таким образом, вы можете найти свои boot/reboot-журналы в /var/log/messages или /var/log/syslog.

Если коротко: где искать логи?

Как правило, вы найдете журналы пингвиньего сервера в каталоге /var/log и подкаталогах. Это место, где syslog-демонам даны полные права на запись. Также это то место, которое у большинства приложений (например, Apache) указано по умолчанию, как место хранения логов.

Для systemd расположение по умолчанию – /var/log/journal, но просматривать файлы логов напрямую не получится – они хранятся в двоичном формате. Как же быть?

Как анализировать журналы

Если ваш дистрибутив Linux использует Systemd (как и большинство современных дистрибутивов), то все ваши системные журналы находятся в специальной области journal. Просмотреть их можно с помощью journalctl (наиболее важные команды journalctl).

Если ваш дистрибутив использует syslog, для их просмотра используются стандартные инструменты: cat, less или grep:

# grep "error" /var/log/syslog | tail
Mar 31 09:48:02 ubuntu-bionic rsyslogd: unexpected GnuTLS error -53 - this could be caused by a broken connection. GnuTLS reports: Error in the push function. [v8.2002.0 try https://www.rsyslog.com/e/2078 ]
...

Если для управления журналами вы используете auditd, всё найдётся в файле /var/log/audit.log. В поиске и анализе поможет ausearch.

Заметим, что хорошим тоном является хранение всех логов централизованно, в одном месте. Особенно если у вас несколько серверов. Обсудим эту задачу подробнее.

Централизация логов в Linux

Системные журналы могут находиться в двух местах: в systemd или в обычных текстовых файлах, записанных демоном syslog. В некоторых дистрибутивах, например, Ubuntu, есть и то, и другое: journald настроен на пересылку в syslog. Это осуществляется путем установки ForwardToSyslog=Yes в конфиге journald.conf.

Централизация журналов с помощью Journald

Если в ваш дистрибутив включён systemd, для централизации журналов мы рекомендуем использовать journal-upload.

Централизация журналов с помощью syslog

Существует несколько случаев, в которых подойдет централизация с применением syslog:

• Если в ваш дистрибутив не включён journald. Это означает, что системные журналы направляются непосредственно в syslog-демон.
• Когда необходимо собирать и анализировать журналы приложений. Например, в случае с журналами для Apache через rsyslog и Elasticsearch.
• Если вы хотите перенаправить записи – ForwardToSyslog=Yes. Для этого в качестве транспорта следует использовать syslog-протокол. Однако подход приведет к потере некоторых структурированных данных journald т. к. он пересылает только поля syslog-specific.
• Когда вы настроили syslog-демон для чтения из журналов (как это делает journalctl). Такой подход не приводит к потере структурированных данных, но более чувствителен к ошибкам (например, в случае повреждения журнала) и увеличивает накладные расходы.

Во всех перечисленных ситуациях информация будут проходить через демон syslog, а оттуда их можно отправить в любое место и использовать на своё усмотрение.

Большинство дистрибутивов Linux поставляются с rsyslog. Чтобы пересылать данные на другой сервер через TCP, добавьте следующую строку в /etc/rsyslog.conf:

*.* @@logsene-syslog-receiver.example.com

Эта строка будет заворачивать данные на сервер example.com. Вы можете заменить logsene-syslog-receiver.[…..] именем своего syslog-хоста.

Некоторые демоны могут выводить данные в Elasticsearch через HTTP/HTTPS. Одним из них является наш rsyslog. Например, если вы юзаете rsyslog на Ubuntu, сначала установите модуль Elasticsearch:

sudo apt-get install rsyslog-elasticsearch

Затем в конфигурационном файле вам потребуется поправить два элемента: шаблон JSON для Elasticsearch:

template(name="LogseneFormat" type="list" option.json="on") {
 constant(value="{")
 constant(value="\"@timestamp\":\"")
 property(name="timereported" dateFormat="rfc3339")
 constant(value="\",\"message\":\"")
 property(name="msg")
 constant(value="\",\"host\":\"")
 property(name="hostname")
 constant(value="\",\"severity\":\"")
 property(name="syslogseverity-text")
 constant(value="\",\"facility\":\"")
 property(name="syslogfacility-text")
 constant(value="\",\"syslog-tag\":\"")
 property(name="syslogtag")
 constant(value="\",\"source\":\"")
 property(name="programname")
 constant(value="\"}")
}

и action, который пересылает данные в Elasticsearch, используя указанный выше шаблон:

module(load="omelasticsearch")
action(type="omelasticsearch"
 template="LogseneFormat" # шаблон,объявленный ранее
 searchIndex="LOGSENE_APP_TOKEN_GOES_HERE"
 server="logsene-receiver.example.com"
 serverport="443"
 usehttps="on"
 bulkmode="on"
 queue.dequeuebatchsize="100" # сколько сообщений отправлять за раз
 action.resumeretrycount="-1") # буфер сообщений

В приведенном примере показано, как отправлять сообщения в API Elasticsearch на example.com. Настройте action на ваш локальный Elasticsearch:

• searchIndex – будет вашим алиасом;
• server – имя хоста (ноды) Elasticsearch;
• serverport может быть 9200 или кастомным, главное, чтобы на нем слушал Elasticsearch;
• usehttps= "off" – отправление данных по http.

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

Это не значит, что файлы в /var/log бесполезны. Они пригодятся в следующих случаях:

• приложения пишут туда свои логи, например, HTTP, FTP, MySQL и т. д.,
• требуется обработать системные журналы, например, с помощью grep.

Важные файлы журналов для мониторинга

Здесь мы рассмотрим ключевые файлы логов, какую информацию они хранят, как настраивается rsyslog для записи и как посмотреть информацию с помощью journalctl.

Журнал /var/log/syslog или /var/log/messages

Это «всеохватывающий» системный лог:

# logger "this is a test"
# tail -1 /var/log/syslog
May 7 15:33:11 ubuntu-bionic test-user: this is a test

Вы найдёте здесь все сообщения: ошибки, информационные сообщения и все другие серьёзности. Исключением является stop action.

Если в /var/log/syslog или /var/log/messages пусто, скорее всего, journald не перенаправляет данные в syslog. Все те же данные можно просмотреть, вызвав journalctl без параметров.

# journalctl --no-pager | grep "this is a test"
May 07 15:33:11 ubuntu-bionic test-user[7526]: this is a test

Журналы /var/log/kern.log или /var/log/dmesg

Сюда по умолчанию отправляются сообщения ядра:

Apr 17 16:47:28 ubuntu-bionic kernel: [ 0.004000] console [tty1] enabled

И снова, если у вас нет syslog (или файл пустой/отсутствует) – используйте journalctl:

kern.* /var/log/kern.log

Журналы /var/log/auth.log или /var/log/secure

Здесь вы найдете сообщения об аутентификации, генерируемые такими службами, как sshd:

May 7 15:03:09 ubuntu-bionic sshd[1202]: pam_unix(sshd:session): session closed for user vagrant

Вот ещё один фильтр по значениям auth и authpriv:

auth,authpriv.* /var/log/auth.log

Вы можете использовать такие фильтры в journalctl, используя числовые уровни объектов:

# journalctl SYSLOG_FACILITY=4 SYSLOG_FACILITY=10
…
May 7 15:03:09 ubuntu-bionic sshd[1202]: pam_unix(sshd:session): session closed for user vagrant
…

Журнал /var/log/cron.log

Сюда отправляются ваши cron-сообщения (jobs-ы, выполняемые регулярно):

May 06 08:19:01 localhost.localdomain anacron[1142]: Job `cron.daily' started

Пример фильтра:

cron.* /var/log/cron

С journalctl можно сделать так:

# journalctl SYSLOG_FACILITY=9

Журнал /var/log/mail.log или /var/log/maillog

Практически все демоны (такие как Postfix, cron и т. д.) обычно пишут свои логи в syslog. Затем rsyslog раскладывает эти логи по файлам:

mail.* /var/log/mail.log

С помощью journald просматривать журналы можно так:

# journalctl SYSLOG_FACILITY=2

Подведём итоги

• Расположение и формат системных журналов Linux зависят от того, как настроен дистрибутив.
• Большинство дистрибутивов имеют systemd, и все логи «живут» там. Чтобы что-то просмотреть и найти, используйте journalctl.
• Некоторые дистрибутивы передают системные журналы в syslog, либо напрямую, либо через journal. В этом случае у вас, скорее всего, есть логи, записанные в отдельные файлы в /var/log.
• Если вы управляете несколькими серверами, вам потребуется централизовать журналирование с помощью специального ПО или использовать собственный ELK-стек.

Логгирование событий невероятно важная и серьёзная штука в любой сфере администрирования и ОС. Рекомендуем отнестись ответственно к данной теме – она будет полезна при дебагинге, разработке и просто в управлении инфраструктурой.

[customscript]techrocks_custom_after_post_html[/customscript]

[customscript]techrocks_custom_script[/customscript]