Var log syslog linux

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

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

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

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

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

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

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

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

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

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:

Если для управления журналами вы используете 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 :

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

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

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

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

В приведенном примере показано, как отправлять сообщения в 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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Источник

Логи в Linux. Как найти и прочитать?

Обновл. 20 Май 2021 |

Процесс загрузки системы, работа приложений и служб, различные действия пользователей, сообщения ядра ОС и многое другое — все эти события регистрируются в специальных журналах операционной системы, так называемых log-файлах (или «логах»). Если в работе системы что-то пойдет не так, то эти файлы станут для вас полезным источником информации, с помощью которого вы сможете разобраться в причинах возникших проблем и самостоятельно их устранить.

Как посмотреть логи в Linux?

Большинство логов в Linux генерируются системными демонами syslogd или rsyslogd и хранятся в обычном текстовом файле ASCII в каталоге /var/log. Этот каталог содержит лог-файлы самой ОС, служб и различных приложений, запущенных в системе. Вот как этот каталог выглядит в типичной системе Debian Linux:

Если вы попробуете просмотреть какой-нибудь лог-файл от имени обычного пользователя, то в 99% случаев система ответит вам сообщением о нехватке прав доступа. Поэтому я заранее переключился на пользователя root (команда su –) и все дальнейшие действия будут выполняться от его имени.

Теперь можно перейти к непосредственному изучению содержимого лог-файлов. И для начала, мы заглянем внутрь boot.log. Данный лог-файл содержит информацию обо всех этапах загрузки операционной системы:

root@debian:/var/log# tail boot.log

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

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

tail — вывод последних 10 строк;

head — вывод первых 10 строк;

cat — вывод содержимого всего лог-файла;

grep — поиск в лог-файле всех вхождений заданного выражения или фильтрация лог-файла по заданному выражению;

zcat — отображает всё содержимое сжатых лог-файлов (с расширением *.gz);

zmore — постраничный просмотр сжатых лог-файлов, без их распаковки;

zgrep — поиск внутри сжатого лог-файла.

Основные логи

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

Многие из этих лог-файлов располагаются в каталоге var/log. Наиболее распространенными логами являются:

/var/log/boot.log — журнал загрузки системы (в нем хранится вся информация, связанная с этапами загрузки ОС);

/var/log/kern.log — журнал ядра (в нем хранятся сообщения и предупреждения, поступающие непосредственно из ядра Linux);

/var/log/syslog или /var/log/messages — журналы, в которых хранится информация об общей активности в системе (включая сообщения этапа загрузки);

/var/log/auth.log или /var/log/secure — журналы аутентификации и безопасности (в них хранятся записи обо всех попытках входа в систему, включая как успешные, так и неудачные);

/var/log/debug — журнал отладки (в нем хранится подробная отладочная информация системы и приложений);

/var/log/daemon.log — журнал демонов (содержит информацию о событиях, связанных с различными запущенными в системе демонами/службами);

/var/log/maillog или /var/log/mail.log — журналы почтовых серверов (в них хранится информация, относящаяся к почтовым серверам и архивированию электронных писем);

/var/log/cron — журнал, в котором хранится информация о запланированных задачах (заданиях cron);

/var/log/faillog — информация о неудачных входах в систему. Журнал полезен для изучения потенциальных нарушений безопасности, таких как: взломы учетных записей, попытки перебора паролей и пр.;

/var/log/dmesg — журнал сообщений драйверов устройств. Просмотреть содержимое данного журнала можно с помощью команды dmesg . Стоит заметить, что при достижении своего предела, старые сообщения перезаписываются более новыми.

/var/log/Xorg.x.log — журнал сообщений X-сервера.

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

/var/log/dpkg.log — журнал пакетов, установленных через утилиту dpkg в системах на основе Debian Linux.

/var/log/yum.log — журнал пакетов, установленных через утилиту yum в системах на основе Red Hat Linux.

/var/log/emerge.log — журнал пакетов (ebuild), установленных через утилиту emerge в Gentoo Linux.

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

/var/log/utmp и /var/log/utmp — журналы учета входов пользователей в систему. Для просмотра сообщений применяется команда utmpdump , например:

/var/log/lastlog — журнал с информацией о последних входах пользователей. Для просмотра сообщений применяется команда lastlog :

Ротация лог-файлов

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

Цель ротации заключается в сжатии устаревших лог-файлов, которые занимают много места. Лог-файлы, в конце имен которых добавлены нули, являются ротируемыми (их имена были автоматически изменены системой). Ротацию лог-файлов можно выполнить с помощью команды logrotate, например:

Настройки ротации лог-файлов хранятся в соответствующем файле конфигурации /etc/logrotate.conf:

var/log/имя_журнала.log <
Missingok
Notifempty
Compress
Size 20k
Daily
Create 0600 root root
>

Разберем детально каждую строку вышеприведенного фрагмента:

Missingok — указывает команде logrotate не выводить ошибку, если лог-файл отсутствует.

Notifempty — если лог-файл пуст, то ротации не будет.

Compress — лог-файл необходимо сжать.

Size 20k — гарантирует, что лог-файл не превышает заданного размера, в противном случае производится его ротация.

Daily — ротация лог-файлов по ежедневному расписанию. Также можно задавать ежечасный ( Hourly ), еженедельный ( Weekly ), ежемесячный ( Monthly ) или ежегодный ( Yearly ) график.

Create 0600 root root — создает экземпляр лог-файла, владельцем и группой которого является root.

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

systemd и journald

systemd — это подсистема инициализации и управления службами в Linux, фактически вытеснившая в 2010-е годы традиционную подсистему init. В связке с ней работает и journald — демон сбора логов, являющийся частью systemd. Он собирает логи со всей системы и хранит их в бинарном виде в каталоге /var/log/journal. Для того чтобы их просмотреть, создана специальная утилита journalctl. Рассмотрим несколько примеров её применения.

Чтобы просмотреть последние 10 строк логов всех запусков системы, достаточно выполнить следующую команду:

# journalctl —list-boots | tail

Видите столбец, который я обвел красным? Цифрой 0 в нем обозначена текущая загрузка системы, цифрой -1 — предыдущая и т.д. Если вы хотите просмотреть логи какой-то конкретной загрузки, например, позапрошлой, то достаточно ввести:

Также можно просмотреть информацию по выбранной службе, например, по NetworkManager:

# journalctl -u NetworkManager

Или же вывести сообщения ядра ОС:

Для получения своих, каких-то более конкретных результатов, допускается комбинировать опции и параметры команды journalctl :

# journalctl -b -1 -u NetworkManager

Для вывода информации только по нескольким последним записям, применяется опция -n , задающая их количество:

# journalctl -u NetworkManager -n 5

Если говорить про systemd, то, наверное, стоит упомянуть и про команду systemd-analyze, которая отвечает за сбор статистики загрузки системы. Применение данной команды без параметров отобразит общее время загрузки системы:

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

Приоритет сообщений в лог-файлах

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

emerg — наивысший приоритет, что-то сломалось, повод паниковать;

alert — тревога, стоит волноваться;

crit — критическое событие, стоит насторожиться;

err — ошибка;

warning — предупреждение;

notice — уведомление, можно не заморачиваться;

info — информационное сообщение, принять к сведению и забыть;

debug — отладочная информация.

Применяя вышеописанные значения приоритетов, можно просматривать сообщения лог-файлов, фильтруя их по заданному приоритету:

# grep ‘err’ /var/log/syslog

Или же для journalctl:

# journalctl -p warning -b 0

Заключение

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

Поделиться в социальных сетях:

Источник