Логи ошибок линукс

Время на прочтение
6 мин

Количество просмотров 427K

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

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

Основные лог файлы

Все файлы журналов, можно отнести к одной из следующих категорий:

• приложения;
• события;
• службы;
• системный.

Большинство же лог файлов содержится в директории /var/log.

• /var/log/syslog или /var/log/messages содержит глобальный системный журнал, в котором пишутся сообщения с момента запуска системы, от ядра Linux, различных служб, обнаруженных устройствах, сетевых интерфейсов и много другого.
• /var/log/auth.log или /var/log/secure — информация об авторизации пользователей, включая удачные и неудачные попытки входа в систему, а также задействованные механизмы аутентификации.
• /var/log/dmesg — драйвера устройств. Одноименной командой можно просмотреть вывод содержимого файла. Размер журнала ограничен, когда файл достигнет своего предела, старые сообщения будут перезаписаны более новыми. Задав ключ --level= можно отфильтровать вывод по критерию значимости.

Поддерживаемые уровни журналирования (приоритеты):
   emerg - система неиспользуемая
   alert - действие должно быть произведено немедленно
    crit - условия критичности
     err - условия ошибок
    warn - условия предупреждений
  notice - обычные, но значимые условия
    info - информационный
   debug - отладочные сообщения

(5:520)$ dmesg -l err
[1131424.604352] usb 1-1.1: 2:1: cannot get freq at ep 0x1
[1131424.666013] usb 1-1.1: 1:1: cannot get freq at ep 0x81
[1131424.749378] usb 1-1.1: 1:1: cannot get freq at ep 0x81

• /var/log/alternatives.log — Вывод программы update-alternatives, в котором находятся символические ссылки на команды или библиотеки по умолчанию.
• /var/log/anaconda.log — Записи, зарегистрированные во время установки системы.
• /var/log/audit — Записи, созданные службой аудита auditd.
• /var/log/boot.log — Информация, которая пишется при загрузке операционной системы.
• /var/log/cron — Отчет службы crond об исполняемых командах и сообщения от самих команд.
• /var/log/cups — Все, что связано с печатью и принтерами.
• /var/log/faillog — Неудачные попытки входа в систему. Очень полезно при проверке угроз в системе безопасности, хакерских атаках, попыток взлома методом перебора. Прочитать содержимое можно с помощью команды faillog.
• var/log/kern.log — Журнал содержит сообщения от ядра и предупреждения, которые могут быть полезны при устранении ошибок пользовательских модулей встроенных в ядро.
• /var/log/maillog/ или /var/log/mail.log — Журнал почтового сервера, используемого на ОС.
• /var/log/pm-powersave.log — Сообщения службы экономии заряда батареи.
• /var/log/samba/ — Логи файлового сервера Samba, который используется для доступа к общим папкам Windows и предоставления доступа пользователям Windows к общим папкам Linux.
• /var/log/spooler — Для представителей старой школы, содержит сообщения USENET. Чаще всего бывает пустым и заброшенным.
• /var/log/Xorg.0.log — Логи X сервера. Чаще всего бесполезны, но если в них есть строки начинающиеся с EE, то следует обратить на них внимание.

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

• /var/log/yum.log — Для программ установленных с помощью Yum в RedHat Linux.
• /var/log/emerge.log — Для ebuild-ов установленных из Portage с помощью emerge в Gentoo Linux.
• /var/log/dpkg.log — Для программ установленных с помощью dpkg в Debian Linux и всем семействе родственных дистрибутивах.

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

• /var/log/lastlog — Последняя сессия пользователей. Прочитать можно командой last.
• /var/log/tallylog — Аудит неудачных попыток входа в систему. Вывод на экран с помощью утилиты pam_tally2.
• /var/log/btmp — Еже один журнал записи неудачных попыток входа в систему. Просто так, на всякий случай, если вы еще не догадались где следует искать следы активности взломщиков.
• /var/log/utmp — Список входов пользователей в систему на данный момент.
• /var/log/wtmp — Еще один журнал записи входа пользователей в систему. Вывод на экран командой utmpdump.

(5:535)$ sudo utmpdump /var/log/wtmp
[5] [02187] [l0  ] [        ] [4.0.5-gentoo     ] [0.0.0.0     ] [Вт авг 11 16:50:07 2015]
[1] [00000] [~~  ] [shutdown] [4.0.5-gentoo     ] [0.0.0.0     ] [Вт авг 11 16:50:08 2015]
[2] [00000] [~~  ] [reboot  ] [3.18.12-gentoo   ] [0.0.0.0     ] [Вт авг 11 16:50:57 2015]
[8] [00368] [rc  ] [        ] [3.18.12-gentoo   ] [0.0.0.0     ] [Вт авг 11 16:50:57 2015]
[1] [20019] [~~  ] [runlevel] [3.18.12-gentoo   ] [0.0.0.0     ] [Вт авг 11 16:50:57 2015]

И другие журналы

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

• /var/log/mysql/ — Лог базы данных MySQL.
• /var/log/httpd/ или /var/log/apache2/ — Лог веб сервера Apache, журнал доступа находится в access_log, а ошибки — в error_log.
• /var/log/lighthttpd/ — Лог веб сервера lighttpd.

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

• ~/.xsession-errors — Вывод stderr графических приложений X11.

Initializing  "kcm_input" :  "kcminit_mouse"
Initializing  "kcm_access" :  "kcminit_access"
Initializing  "kcm_kgamma" :  "kcminit_kgamma"
QXcbConnection: XCB error: 3 (BadWindow), sequence: 181, resource id: 10486050, major code: 20 (GetProperty), minor code: 0
kf5.kcoreaddons.kaboutdata: Could not initialize the equivalent properties of Q*Application: no instance (yet) existing.
QXcbConnection: XCB error: 3 (BadWindow), sequence: 181, resource id: 10486050, major code: 20 (GetProperty), minor code: 0
Qt: Session management error: networkIdsList argument is NULL

• ~/.xfce4-session.verbose-log — Сообщения рабочего стола XFCE4.

Чем просматривать — lnav

Почти все знают об утилите less и команде tail -f. Также для этих целей сгодится редактор vim и файловый менеджер Midnight Commander. У всех есть свои недостатки: less неважно обрабатывает журналы с длинными строками, принимая их за бинарники. Midnight Commander годится только для беглого просмотра, когда нет необходимости искать по сложному шаблону и переходить помногу взад и вперед между совпадениями. Редактор vim понимает и подсвечивает синтаксис множества форматов, но если журнал часто обновляется, то появляются отвлекающие внимания сообщения об изменениях в файле. Впрочем это легко можно обойти с помощью <:view /path/to/file>.

Недавно я обнаружил еще одну годную и многообещающую, но слегка еще сыроватую, утилиту — lnav, в расшифровке Log File Navigator.

Установка пакета как обычно одной командой.

$ aptitude install lnav #Debian/Ubuntu/LinuxMint
$ yum install lnav #RedHat/CentOS
$ dnf install lnav #Fedora
$ emerge -av lnav #Gentoo, нужно добавить в файл package.accept_keywords
$ yaourt -S lnav #Arch

Навигатор журналов lnav понимает ряд форматов файлов.

• Access_log веб сервера.
• CUPS page_log
• Syslog
• glog
• dpkg.log
• strace
• Произвольные записи с временными отметками
• gzip, bzip
• Журнал VMWare ESXi/vCenter

Что в данном случае означает понимание форматов файлов? Фокус в том, что lnav больше чем утилита для просмотра текстовых файлов. Программа умеет кое что еще. Можно открывать несколько файлов сразу и переключаться между ними.

(5:471)$ sudo lnav /var/log/pm-powersave.log /var/log/pm-suspend.log

Программа умеет напрямую открывать архивный файл.

(5:471)$ lnav -r /var/log/Xorg.0.log.old.gz

Показывает гистограмму информативных сообщений, предупреждений и ошибок, если нажать клавишу <i>. Это с моего syslog-а.

Mon May 02 20:25:00        123 normal         3 errors         0 warnings         0 marks
Mon May 02 22:40:00          2 normal         0 errors         0 warnings         0 marks
Mon May 02 23:25:00         10 normal         0 errors         0 warnings         0 marks
Tue May 03 07:25:00         96 normal         3 errors         0 warnings         0 marks
Tue May 03 23:50:00         10 normal         0 errors         0 warnings         0 marks
Wed May 04 07:40:00         96 normal         3 errors         0 warnings         0 marks
Wed May 04 08:30:00          2 normal         0 errors         0 warnings         0 marks
Wed May 04 10:40:00         10 normal         0 errors         0 warnings         0 marks
Wed May 04 11:50:00        126 normal         2 errors         1 warnings         0 marks

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

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

1. lnav — An Advanced Log File viewer for Linux
2. What Are Linux Logs? How to View Them, Most Important Directories, and More
3. Как посмотреть логи в Linux

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

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

1. emerg — авария, наивысший приоритет;
2. alert — тревога;
3. crit — критическое событие;
4. err — ошибка;
5. warn — внимание;
6. notice — уведомление;
7. info — информационное сообщение;
8. debug — отладочная информация;

На сегодняшний день в Linux основными службами сбора логов являются rsyslog и systemd-journald, они работают независимо друг от друга и входят в состав большинства современных дистрибутивов.

rsyslog

Журналы службы находятся в директории “/var/log/” в виде обычных текстовых файлов. В зависимости от типа события, сообщения записываются в разные файлы. Например файл “/var/log/auth.log” содержит информацию о входе пользователей в систему, а в файл “/var/log/kern.log” записываются сообщения ядра. В разных дистрибутивах названия файлов могут отличаться, поэтому для точного понимания куда именно происходит запись сообщений рассмотрим файл конфигурации “/etc/rsyslog.d/50-default.conf”.

Правила описывают место хранения логов в зависимости от типа сообщения. В левой части строки указан тип сообщения в формате “[Источник].[Приоритет]”, а в правой части имя файла журнала. При записи типа сообщения можно применять символ “*”, обозначающий любое значение или параметр “none”, обозначающий исключение из списка. Рассмотрим более подробно первые два правила.

“auth,authpriv.* /var/log/auth.log”
“*.*;auth,authpriv.none -/var/log/syslog”

Первое правило означает, что все сообщения принятые от механизма авторизации будут записаны в файл “/var/log/auth.log”. В этом файле будут зарегистрированы все попытки входа пользователей в систему, как удачные так и не удачные. Второе правило говорит о том, что все сообщения, кроме тех, которые связаны с авторизацией будут записаны в файл “/var/log/syslog”. Именно к этим файлам приходится обращаться наиболее часто. Следующие правила определяют место хранения журналов ядра “kern.*” и почтовой службы “mail.*”

Журналы логов можно открыть любой утилитой для просмотра текста, например less, cat, tail. Откроем файл “/var/log/auth.log”

less /var/log/auth.log

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

1. Дата и время регистрации сообщения — “Feb 12 06:18:33”
2. Имя компьютера, с которого пришло сообщение — “vds”
3. Имя программы или службы, к которой относится сообщение — “sshd”
4. Идентификатор процесса, отправившего сообщение — [653]
5. Текст сообщения — “Accepted password for mihail from 188.19.42.165 port 2849 ssh2”

Это был пример успешного подключения по ssh.
А так выглядит неудачная попытка:

В этом файле также фиксируется выполнение команд с повышенными правами.

Откроем файл /var/log/syslog

На скриншоте выделено сообщение о выключении сетевого интерфейса.

Для поиска нужной информации в больших текстовых файлах можно использовать утилиту grep. Найдем все сообщения от службы pptpd в файле “/var/log/syslog”

grep 'pptpd' /var/log/syslog

Во время диагностики можно использовать утилиту tail, которая выводит последние строки в файле. Команда “tail -f /var/log/syslog” позволит наблюдать запись логов в реальном времени.

Служба rsyslog является очень гибкой, высокопроизводительной и может использоваться для сбора логов как на локальных системах, так и на уровне предприятия. Полную документацию можно найти на официальном сайте https://www.rsyslog.com/

Запись логов происходит непрерывно и размер файлов постоянно растет. Механизм ротации обеспечивает автоматическое архивирование старых журналов и создание новых. В зависимости от правил, обработка журналов может выполняться ежедневно, еженедельно, ежемесячно или при достижении файлом определенного размера. По мере создания новых архивов, старые могут быть просто удалены или предварительно отправлены по электронной почте. Ротация выполняется утилитой logrotate. Основная конфигурация находится в файле “/etc/logrotate.conf”, также обрабатывается содержимое файлов в директории “/etc/logrotate.d/”

Новые правила можно записывать в основной файл конфигурации, но более правильным будет создание отдельного файла в директории “/etc/logrotate.d/” По умолчанию в директории уже содержится несколько файлов.

Рассмотрим файл “/etc/logrotate.d/rsyslog”, который содержит правила ротации для журналов службы rsyslog.

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

• rotate 7 — необходимо постоянно хранить 7 файлов
• daily — ежедневно будет создаваться новый файл
• compress — старые файлы необходимо архивировать.

На скриншоте видно, что в каталоге “/var/log/” находится основной журнал “syslog” и семь архивов, что соответствует правилам ротации.

Более подробное описание по настройке утилиты logrotate можно найти в мануале, выполнив команду “man logrotate”

journald

Служба сбора логов systemd-journald является частью системы инициализации systemd. Файлы журнал хранятся в директории “/var/log/journal/” в специальном формате и могут быть открыты с помощью утилиты journalctl. Формат записей такой же как у службы rsyslog.

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

• вывод записей с момента последней загрузки
  journalctl -b
• вывод записей за определенный период времени
  journalctl -S "2020-02-17 12:00" -U "2020-02-17 12:10"
• вывод записей, принятых от определенной службы
  journalctl -u pptpd
• вывод сообщений ядра
  journalctl -k
• вывод сообщений с определенным приоритетом, в данном случае будут выведены ошибки и более высокие приоритеты(crit, alert, emerg).
  journalctl -p err
• вывод сообщений в реальном времени
  journalctl -f

Для более гибкого поиска опции можно совмещать. Выведем все ошибки службы pptpd

journalctl -u pptpd -p err

Если в качестве аргумента указать путь к исполняемому файлу, утилита выведет все сообщения, отправленные этим файлом. Выведем сообщения, отправленные файлом “/usr/bin/sudo” начиная с 04:15 18-го февраля 2020 года. Фактически будут выведены все команды, выполненные с повышенными правами.

journalctl -S "2020-02-18 04:15" /usr/bin/sudo

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

journalctl --disk-usage

Для ограничения объема журнала размером 1Gb выполним команду

journalctl --vacuum-size=1G

Открытие бинарных файлов

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

/var/log/wtmp — содержит информацию об успешном входе пользователей в систему, для открытия используется утилита last

/var/log/btmp — в файле регистрируются все неудачные попытки входа в систему, открывается командой lastb с повышенными правами. Параметр -n определяет количество выводимых строк начиная с конца файла.

/var/log/lastlog — содержит время последнего входа для каждой учетной записи, может быть открыт одноименной утилитой lastlog

👨‍🏫️ Что такое логи?

Логи (журнал сервера, англ. 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.

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

Системные журналы могут
находиться в двух местах: в 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-стек.

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