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

Управление логированием[править]

Со временем объём логов растёт, и они занимают всё больше места на жёстком диске. Узнать объём имеющихся на текущий момент логов можно с помощью команды:

journalctl --disk-usage

Ротация логов

Настройка ротации логов осуществляется с помощью опций −−vacuum-size и −−vacuum-time.
Первая из них устанавливает предельно допустимый размер для хранимых на диске логов (в нашем примере — 1 ГБ):

journalctl --vacuum-size=1G

Как только объём логов превысит указанную цифру, лишние файлы будут автоматические удалены.
Аналогичным образом работает опция −−vacuum-time. Она устанавливает для логов срок хранения, по истечении которого они будут автоматически удалены:

journalctl --vacuum-time=1years

Настройка ротации в конфигурационном файле. Настройки ротации логов можно также прописать в конфигурационном файле /еtc/systemd/journald.conf, который включает в числе прочих следующие параметры:
- SystemMaxUse= — максимальный объём, который логи могут занимать на диске;
- SystemKeepFree= — объём свободного места, которое должно оставаться на диске после сохранения логов;
- SystemMaxFileSize= — объём файла лога, по достижении которого он должен быть удален с диска;
- RuntimeMaxUse= — максимальный объём, который логи могут занимать в файловой системе /run;
- RuntimeKeepFree= — объём свободного места, которое должно оставаться в файловой системе /run после сохранения логов;
- RuntimeMaxFileSize= — объём файла лога, по достижении которого он должен быть удален из файловой системы /run.

Единицы измерения: K, M, G, T, P, E.

Автоматический запуск

Задание на автоматический запуск создается по умолчанию в файле /etc/cron.daily/logrotate. Если изучить его содержимое, мы увидим, что идет запуск logrotate, который читает все файлы в директории /etc/logrotate.d/ и выполняющий для каждого из них ротацию.

Если для какого-то приложения необходимо выполнять ротацию лога по особому расписанию, узнаем полный путь до утилиты logrotate:

which logrotate

* в моем случае, это было /usr/sbin/logrotate.

Получив путь, создаем правило в cron:

crontab -e

0 0 * * * /usr/sbin/logrotate -f /etc/logrotate.d/logstash

* в данном примере в 00:00 будет запускаться logrotate и чистить логи с нашей настройкой для logstash-forwarder.

или запуск чистки всех логов:

0 0 * * * /usr/sbin/logrotate -f /etc/logrotate.conf

Настройка Rsyslog в Linux

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

Основной конфигурационный файл — /etc/rsyslog.conf, в нем подключены все файлы из папки /etc/rsyslog.d/ с помощью директивы IncludeConfig в самом начале файла:

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

Синтаксис конфигурационного файла очень прост:

$ переменная значение

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

# provides UDP syslog reception

#$ModLoad imudp
#$UDPServerRun 514

# provides TCP syslog reception

#$ModLoad imtcp
#$InputTCPServerRun 514

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

Модули ввода — можно рассматривать, как способ сбора информации из различных источников, начинаются с im.
Модули вывода — позволяют отправлять сообщения в файлы или по сети, или в базу данных, имя начинается на om;
Модули фильтрации — позволяют фильтровать сообщения по разным параметрам, начинаются с fm;
Модули парсинга — предоставляют расширенные возможности для синтаксического анализа сообщения, начинаются с pm.

Сначала загружается модуль imuxsock, который позволяет сервису получать сообщения из сокетов, а второй imklog получает сообщения ядра. Следующим загружается модуль mark, который позволяет маркировать соединения, или же выводить сообщения о том, что syslog все еще работает. Например, вы можете попросить rsyslog выводить сообщения каждые 20 минут:

Дальше идут глобальные директивы:

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

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

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

Выше была более общая настройка syslog, ну а теперь самое интересное — правила сортировки логов. Вот набор правил по умолчанию:

Каждое правило имеет свой синтаксис, сначала идет источник и приоритет, затем действие. Если источник и приоритет совпадают, сообщение отправляется в указанный файл. Например, мы можем отправить больше сообщений в лог системы linux /var/messages:

В этой строке мы выбираем все сообщения уровня info, кроме mail,authpriv и cron. Шаблон mail.none будет означать, что не нужно логировать ни один уровень сообщений. Соответственно конструкция *.info — значит логировать сообщения от всех источников, но только с уровнем info, *.* — это вообще все сообщения, со всеми уровнями.

Источник и приоритет нечувствительны к регистру. Также заметьте, что приоритеты уровней error, warn и panic больше не используются, так как считаются устаревшими. В целом, в качестве источников вы можете использовать:

auth;
authpriv;
cron;
daemon;
kern;
lpr;
mail;
mark;
news;
security (эквивалентно auth);
syslog;
user;
uucp;
local0 … local7;

А в качестве приоритетов вы можете применить:

emerg (раньше panic);
alert;
crit;
error (раньше err);
warn (раньше warning);
notice;
info;
debug;

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

Вы можете выполнять фильтрацию сообщений с помощью такого синтаксиса:

:поле, сравнение, «значение» путь_к_файлу

В качестве операции сравнения вы можете использовать такие варианты:

contains — поле содержит указанное значение;
isequal — поле должно быть идентичным значению;
startswith — поле должно начинаться со значения;
regex — сравнивает поле с регулярным выражением.

Например, отфильтруем сообщения только от определенной программы:

Кроме того, можно использовать более простой синтаксис, в виде выражения if. Вот основной синтаксис:

if $поле сравнение ‘значение’ then файл

Здесь используются те же самые компоненты, только выглядит немного проще. Например:

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

Было бы очень удобно, если бы логи со всех серверов сети собирались на одной машине. Здесь бы были все важные сообщения об ошибках и неполадках. Вы могли бы все это очень быстро проанализировать. Отправить лог на удаленный сервер достаточно просто, для этого достаточно указать @ и ip адрес удаленной машины, на которой запущен rsyslog:

Здесь 514 — это порт, на котором слушает rsyslog. Настройка rsyslog на прием логов заключается в запуске сервиса с модулями imtcp и imudp. Далее, все что нужно для того чтобы получить логи с определенной машины, отфильтровать их из общего потока с помощью фильтров:

Без фильтров, сообщения с разных машин будут писаться в один общий лог системы linux в зависимости от того как вы их распределите.

Сервер

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

Загрузим нужные модули и выключим , иначе в принятых логах все переводы строки заменятся на

Теперь создадим RuleSet, разбирающий прилетевшие логи и раскладывающий их по папкам. Службы, полагающиеся для логирования исключительно на syslog, ожидают, что он сохранит время сообщения. Поэтому логи, прилетевшие со стандартными facility, мы будем сохранять в формате syslog, а для прилетевших с facility local0-local7 будем вынимать имя лога из поля , и записывать только само сообщение без остальных полей syslog. Проблема с приклеенным к сообщению пробелом остаётся для RELP, потому что возникает ещё на этапе разбора сообщений, мы будем этот пробел отрезать.

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

Writing To the System Log

Sometimes we need to write custom messages to our system log during the troubleshooting process. Both the Gnome Log and the Log File Viewer programs are built to display a customized message that you can write through the Terminal.

Open the Ubuntu Terminal and type the following command:

$ logger “This is a custom message”

You can see the custom log message, at the end of the above log list, displayed in the graphical log file viewer.

You can also use the logger command within a script for providing additional information. In that case, please use the following command within your script:

$ logger -t scriptname “This is a custom message”

By practicing along with this tutorial, you can learn to troubleshoot your system and application issues by accessing and understanding system logs.

How to View System Log Files on Ubuntu 18.04 LTS

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

Устанавливаем и запускаем rsyslog по инструкции, . После приступаем к настройке клиента.

Все логи

Для начала можно настроить отправку всех логов на сервер. Создаем конфигурационный файл для rsyslog:

vi /etc/rsyslog.d/all.conf

Добавляем:

*.* @@192.168.0.15:514

* где 192.168.0.15 — IP-адрес сервера логов. *.* — перенаправлять любой лог.

Перезапускаем rsyslog:

systemctl restart rsyslog

Для определенных категорий

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

vi /etc/rsyslog.d/kern.conf

Добавим строку:

kern.* @@192.168.0.15:514

Перезапускаем сервис логов:

systemctl restart rsyslog

Возможные категории для логов (facility):

№	Категория	Описание
kern	Сообщения, отправляемые ядром
1	user	Пользовательские программы
2	mail	Почта
3	daemon	Сервисы (демоны)
4	auth	Безопасность/вход в систему/аутентификация
5	syslog	Сообщения от syslog
6	lpr	Логи печати
7	news	Новостные группы (usenet)
8	uucp	Unix-to-Unix CoPy (копирование файлов между компьютерами)
9	cron	Планировщик заданий
10	authpriv	Безопасность/вход в систему/аутентификация — защищенный режим
11	ftp	Логи при передачи данных по FTP
12	ntp	Лог службы синхронизации времени (существует не везде)
13	security, log audit	Журнал аудита (существует не везде)
14	console, log alert	Сообщения, отправляемые в консоль (существует не везде)
15	solaris-cron, clock daemon	Cron в solaris (существует не везде)
16-23	local0 — local7	Зарезервированы для локального использования. Уровень серьезности определяется числом от 0 до 7.

Для определенного уровня

Если мы хотим передавать только сообщения об ошибках, добавляем строку в файл конфигурации rsyslog:

vi /etc/rsyslog.d/erors.conf

*.err @@192.168.0.15:514

Перезапускаем сервис логов:

systemctl restart rsyslog

Возможные уровни логов:

Возможные категории для логов (severity):

№
Уровень
Расшифровка
emerg
Система не работает (PANIC)
1
alert
Серьезная проблема, требующая внимания
2
crit
Критическая ошибка
3
err
Ошибка (ERROR)
4
warning
Предупреждение (WARN)
5
notice
Важное информационное сообщение
6
info
Информационное сообщение
7
debug
Отладочная информация

Аудит определенного лог-файла

Мы можем настроить слежение за изменением определенного лога и передавать их на сервер. Для этого нужно настроить и сервер, и клиента.

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

Создаем новый конфигурационный файл:

vi /etc/rsyslog.d/audit.conf

$ModLoad imfile
$InputFileName /var/log/audit/audit.log
$InputFileTag tag_audit_log:
$InputFileStateFile audit_log
$InputFileSeverity info
$InputFileFacility local6
$InputRunFileMonitor
*.* @@192.168.0.15:514

* в данном примере мы будем отслеживать изменения лог-файла /var/log/audit/audit.log; нас интересуют события от уровня info и выше; все события будет отмечены категорией local6 и переданы на сервер 192.168.0.15.

Перезапускаем сервис на клиенте:

systemctl restart rsyslog

Настройка сервера (фильтрация сообщений)

На сервере нам нужно фильтровать все сообщения категории local6 (такую категорию мы выбрали, когда настроили клиента) и перенаправлять их в нужных нам файл. Открываем на редактирование конфигурационный файл rsyslog:

vi /etc/rsyslog.conf

Создаем новый шаблон для захвата логов:

$template HostAudit, «/var/log/rsyslog/%HOSTNAME%/audit.log»
local6.* ?HostAudit

* в данном примере мы создаем шаблон HostAudit; rsyslog будет принимать логи категории local6 и сохранять в файле /var/log/rsyslog/<имя компьютера, откуда пришел лог>/audit.log.

Перезапускаем сервер:

systemctl restart rsyslog

Лог определенного приложения

Некоторые приложения умеют отправлять лог напрямую на syslog. Например, nginx (начиная с версии 1.7.1). Для этого открываем конфигурационной файл (основной или конфиг виртуального домена):

vi /etc/nginx/nginx.conf

Добавляем или редактируем соответствующие настройки для логов:

…
access_log syslog:server=192.168.0.15:514 info;
error_log syslog:server=192.168.0.15:514 warn;
error_log /var/log/nginx/error.log warn;
…

* в данном примере мы настроили хранение логов для nginx на сервере 192.168.0.15. Для ошибок также сохраняется локальный лог в файле /var/log/nginx/error.log.

Проверяем корректность конфигурационного файла nginx:

nginx -t

Перезапускаем сервис:

systemctl restart nginx

Проблемы с графической оболочкой

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

При проблемах с графической оболочкой вы можете всегда переключиться в режим терминала с помощью сочетания клавиш Ctrl+Alt+F1. Далее, вам нужно ввести логин и пароль, затем можете вводить команды терминала.

Посмотреть логи графической оболочки вы можете в том же файле ~/.xsession-erros.

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

Подготовка сервера

На сервере нужно, предварительно, выполнить следующие настройки.

Время

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

Сначала задаем правильный часовой пояс:

\cp /usr/share/zoneinfo/Europe/Moscow /etc/localtime

* в данном примере мы использовали московское время.

Затем устанавливаем и запускаем chrony.

а) на системе CentOS / Red Hat:

yum install chrony

systemctl enable chronyd

systemctl start chronyd

б) на системе Ubuntu / Debian:

apt-get install chrony

systemctl enable chrony

systemctl start chrony

Брандмауэр

Если используется брандмауэр, необходимо открыть порты TCP/UDP 514.

а) с помощью firewalld:

firewall-cmd —permanent —add-port=514/{tcp,udp}

firewall-cmd —reload

б) с помощью iptables:

iptables -A INPUT -p tcp —dport 514 -j ACCEPT

iptables -A INPUT -p udp —dport 514 -j ACCEPT

в) с помощью ufw:

ufw allow 514/tcp

ufw allow 514/udp

ufw reload

SELinux

Проверяем, работает ли в нашей системе SELinux:

getenforce

Если мы получаем в ответ:

Enforcing

… необходимо либо настроить SELinux:

semanage port -m -t syslogd_port_t -p tcp 514

semanage port -m -t syslogd_port_t -p udp 514

… либо отключить его командами:

setenforce 0

sed -i ‘s/^SELINUX=.*/SELINUX=disabled/g’ /etc/selinux/config

Логи Linux

Теперь по сути. Основные файлы логов лежат в папке /var/log.

Для начала рассмотрим какие вообще есть логи Linux и что в них пишется. Конечно прям все мы обсуждать не будем, дабы не плодить много букв. Возьмем только те которые мне кажуться наиболее актуальными. Кстати, в разных дистрибутивах Linux названия одних и тех-же логов могут отличаться. Для более глубокого понимания можно заглянуть в конфиг службы rsyslog. Именно она является одной из основных служб Linux отвечающей за сбор логов. Её конфиг лежит: /etc/rsyslog.d/50-default.conf

Здесь описываются правила хранения логов в зависимости от их типа. Все достаточно просто: слева указывается какой тип информации. а справа в какой лог её записывать. Символ «звездочка» обозначает «любое значение» или исключение из списка. Так, для примера первая строка обозначает, что все авторизационные данные должны записываться в файл auth.log, а вторая обозначает что все данные кроме авторизационных, должны записываться в файл syslog. Я думаю общий смысл понятен, а сами службы и их настройку, разберем чуть позже.

Типы логов

А сейчас разберем, собственно сами логи, точнее какие бывают логи:

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

/var/log/auth.log (может называться /var/log/secure) — это информация об авторизации пользователей, а также информация о использованных механизмах аутентификации. В этот лог записываются как удачные, так и не удачные попытки входа всех пользователей. Если подключение удаленное, то также будет виден ip c которого подключились. В этот же лог записываются все изменения касающиеся списка пользователей и групп пользователей. Но тут, на всякий случай нужно помнить, что факт создания нового пользователя будет записан в лог только в том случае если пользователь создавался из графического интерфейса или из терминала, командой useradd. Если вписать пользователя руками в файлы /etc/passwd (список всех пользователей системы) и /etc/shadow (там в зашифрованном виде хранятся пароли) то записей в журнале не будет. Правда они все равно появятся когда пользователь войдет в систему, но помнить об этом моменте нужно.

/var/log/dmesg — лог драйверов устройств. Чтобы его посмотреть достаточно ввести в терминале dmesg;

/var/log/boot.log — лог загрузки системы т.е. все что касается загрузки системы храниться здесь;

/var/log/dpkg.log — лог менеджера пакетов. Название может отличаться в зависимости от используемого в системе менеджера пакетов;

/var/log/faillog — лог неудачных попыток входа в систему;

/var/log/apache2/ (может называться /var/log/httpd/) — лог веб-сервера Apache. Журнал доступа это access_log, а ошибки записываются в error_log;

/var/log/mysql/ — лог базы данных MySQL.

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

systemd и journald

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

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

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

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

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

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

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

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

Что такое Rsyslog?

Развитие rsyslog началось в 2004 году, в качестве форка используемого тогда сервиса Syslog. Программа очень быстро набрала популярность среди пользователей и сейчас она поставляется по умолчанию во многих дистрибутивах Linux.

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

Вот основные возможности:

Многопоточность;
TCP, SSL, TLS, RELP;
Поддержка MySQL, PostgreSQL, Oracle;
Фильтрация журналов;
Полностью настраиваемый формат вывода.

Выбор формата вывода

$ journalctl  -u nginx.service -o json

{ "__CURSOR" : "s=13a21661cf4948289c63075db6c25c00;i=116f1;b=81b58db8fd9046ab9f847ddb82a2fa2d;m=19f0daa;t=50e33c33587ae;x=e307daadb4858635", "__REALTIME_TIMESTAMP" : "1422990364739502", "__MONOTONIC_TIMESTAMP" : "27200938", "_BOOT_ID" : "81b58db8fd9046ab9f847ddb82a2fa2d", "PRIORITY" : "6", "_UID" : "0", "_GID" : "0", "_CAP_EFFECTIVE" : "3fffffffff", "_MACHINE_ID" : "752737531a9d1a9c1e3cb52a4ab967ee", "_HOSTNAME" : "desktop", "SYSLOG_FACILITY" : "3", "CODE_FILE" : "src/core/unit.c", "CODE_LINE" : "1402", "CODE_FUNCTION" : "unit_status_log_starting_stopping_reloading", "SYSLOG_IDENTIFIER" : "systemd", "MESSAGE_ID" : "7d4958e842da4a758f6c1cdc7b36dcc5", "_TRANSPORT" : "journal", "_PID" : "1", "_COMM" : "systemd", "_EXE" : "/usr/lib/systemd/systemd", "_CMDLINE" : "/usr/lib/systemd/systemd", "_SYSTEMD_CGROUP" : "/", "UNIT" : "nginx.service", "MESSAGE" : "Starting A high performance web server and a reverse proxy server...", "_SOURCE_REALTIME_TIMESTAMP" : "1422990364737973" }

$ journalctl -u nginx.service -o json-pretty

{
    "__CURSOR" : "s=13a21661cf4948289c63075db6c25c00;i=116f1;b=81b58db8fd9046ab9f847ddb82a2fa2d;m=19f0daa;t=50e33c33587ae;x=e307daadb4858635",
    "__REALTIME_TIMESTAMP" : "1422990364739502",
    "__MONOTONIC_TIMESTAMP" : "27200938",
    "_BOOT_ID" : "81b58db8fd9046ab9f847ddb82a2fa2d",
    "PRIORITY" : "6",
    "_UID" : "0",
    "_GID" : "0",
    "_CAP_EFFECTIVE" : "3fffffffff",
    "_MACHINE_ID" : "752737531a9d1a9c1e3cb52a4ab967ee",
    "_HOSTNAME" : "desktop",
    "SYSLOG_FACILITY" : "3",
    "CODE_FILE" : "src/core/unit.c",
    "CODE_LINE" : "1402",
    "CODE_FUNCTION" : "unit_status_log_starting_stopping_reloading",
    "SYSLOG_IDENTIFIER" : "systemd",
    "MESSAGE_ID" : "7d4958e842da4a758f6c1cdc7b36dcc5",
    "_TRANSPORT" : "journal",
    "_PID" : "1",
    "_COMM" : "systemd",
    "_EXE" : "/usr/lib/systemd/systemd",
    "_CMDLINE" : "/usr/lib/systemd/systemd",
    "_SYSTEMD_CGROUP" : "/",
    "UNIT" : "nginx.service",
    "MESSAGE" : "Starting A high performance web server and a reverse proxy server...",
    "_SOURCE_REALTIME_TIMESTAMP" : "1422990364737973"
}

cat — только сообщения из логов без служебных полей;
export — бинарный формат, подходит для экспорта или резервного копирования логов;
short — формат вывода syslog;
short-iso — формат вывода syslog с метками времени в формате ISO 8601;
short-monotonic — формат вывода syslog c метками монотонного времени (monotonic timestamp);
short-precise — формат вывода syslog с метками точного времени (время событий указывается с точностью до микросекунд);
verbose — максимально подробный формат представления данных (включает даже те поля, которые в других форматах не отображаются).