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

Что такое системное логирование в Linux

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

Из нее можно понять:

• когда произошло событие;
• на каком сервере;
• какой процесс его создал;
• что именно произошло;
• с какого IP-адреса была попытка входа.

Логи бывают текстовыми, как в классической syslog-модели, и бинарными структурированными, как в systemd journal.

Зачем нужно логирование

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

Логирование помогает:

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

Основные источники логов в Linux

В Linux сообщения могут поступать из разных источников:

• ядро Linux – ошибки оборудования, сетевые события, сообщения драйверов, OOM Killer;
• systemd-сервисы – запуск, остановка, падение служб;
• демоны и приложения – nginx, Apache, PostgreSQL, MySQL, Docker, OpenSSH;
• аутентификация – входы пользователей, sudo, SSH, PAM;
• cron и systemd timers – запуск регулярных задач;
• сетевые службы – DHCP, DNS, VPN, firewall;
• контейнеры и виртуализация – Docker, containerd, libvirt;
• пользовательские приложения – backend, скрипты, API-сервисы.

Часть сообщений попадает в journald, часть – в rsyslog, часть может писаться приложением напрямую в отдельный файл, например /var/log/nginx/access.log.

Что такое syslog

Syslog – это классическая модель системного логирования в Unix/Linux. Она описывает, как приложения отправляют сообщения, как эти сообщения классифицируются и куда затем записываются.

Сообщения syslog обычно содержат:

• дату и время события;
• имя хоста;
• источник сообщения;
• уровень важности;
• текст события.

Пример syslog-сообщения:

Apr 27 12:41:02 server01 sshd[1542]: Failed password for invalid user admin from 192.168.1.25

В syslog используются два важных понятия:

• Facility – источник или категория сообщения. Например, auth, authpriv, cron, daemon, kern, mail, user и local0-local7.
• Priority – уровень важности события. Например, debug, info, notice, warning, err, crit, alert и emerg.

Правило:

auth.*    /var/log/auth.log

это сигнал системе, что нужно записывать все сообщения, которые связаны с авторизацией, в файл /var/log/auth.log.

Как работает rsyslog

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

Упрощенно схема работы выглядит так:

источник события –> rsyslog –> фильтрация –> действие

Источниками могут быть ядро Linux, системные службы, приложения, cron-задачи, SSH, sudo и другие компоненты. Получив сообщение, rsyslog определяет его категорию, уровень важности, имя программы и другие параметры.

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

Что такое journald

journald – это служба логирования, входящая в состав systemd. Она собирает системные сообщения, логи служб, события ядра, а также вывод программ из stdout и stderr.

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

Особенности journald:

• собирает логи systemd-служб, ядра и приложений;
• хранит записи в структурированном виде;
• позволяет фильтровать события через journalctl;
• может сохранять логи после перезагрузки при включенном постоянном хранении;
• может передавать сообщения в syslog или rsyslog;
• умеет ограничивать размер журнала, чтобы он не занял весь диск.

journald полезен тем, что хорошо интегрирован с systemd. Если служба запускается через systemd, ее сообщения обычно автоматически попадают в journal.

Отличия journald и rsyslog

Где хранятся системные логи

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

Расположение файлов зависит от дистрибутива:

Если система использует journald, часть логов хранится не как обычные текстовые файлы, а в журнале systemd. При постоянном хранении записи находятся в каталоге /var/log/journal/.

Полноценная настройка системного логирования, сбор логов приложений и анализ системных событий требуют доступа к серверу и его файловой системе. Важно иметь возможность работать с каталогом /var/log/, настраивать rsyslog, менять параметры journald и управлять хранением журналов. Для таких задач подходят виртуальные серверы: VPS позволяет гибко управлять конфигурацией rsyslog и journald, подключать логи приложений, настраивать ротацию, хранение и передачу событий на централизованный лог-сервер.

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

Зависит от того, где конкретно они хранятся: в текстовых файлах /var/log/ или в журнале systemd-journald, который открывается через journalctl. На современных серверах обычно используются оба варианта: часть событий доступна в journal, а часть – в отдельных файлах приложений, например nginx, PostgreSQL, MySQL или Docker.

Самый простой способ посмотреть текстовый лог – открыть его через less:

less /var/log/syslog

Посмотреть последние строки файла можно через tail:

tail -n 100 /var/log/syslog

Если нужно следить за логом в реальном времени, используйте:

tail -f /var/log/syslog

Для поиска по логам часто используют grep. Например, так можно найти строки с ошибками:

grep -i "error" /var/log/syslog

Ключ -i отключает чувствительность к регистру, поэтому команда найдет и error, и Error, и ERROR.

Чтобы просмотреть journal, используйте команду journalctl. Она покажет сообщения, собранные systemd-journald Без параметров команда может вывести очень много данных, поэтому лучше сразу отфильтровать данные. Например, чтобы терминал показал логи текущей загрузки, пропишите:

journalctl -b

Несколько быстрых полезный команд, которые вы можете использовать:

Настройка rsyslog

rsyslog используют для классического системного логирования: он принимает сообщения от системы и приложений, распределяет их по правилам, записывает в файлы /var/log/ или отправляет на удаленный сервер. На современных Linux-системах rsyslog часто работает вместе с journald: journal собирает события systemd, а rsyslog сохраняет их в привычном текстовом виде.

Сначала стоит проверить, работает ли служба:

systemctl status rsyslog

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

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

local0.*    /var/log/myapp.log

Здесь local0 – категория сообщений, а * означает все уровни важности. Для проверки можно отправить тестовую запись через logger и посмотреть, появилась ли она в нужном файле.

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

После изменения конфигурации нужно проверить синтаксис и перезапустить службу:

sudo rsyslogd -N1
sudo systemctl restart rsyslog

Еще одна важная возможность rsyslog – отправка логов на центральный сервер. Передача по TCP обозначается двойным символом @@, по UDP – одним @:

*.*    @@192.168.1.10:514

Настройка journald

Проверить работу службы можно командой:

systemctl status systemd-journald

Основная конфигурация находится в файле /etc/systemd/journald.conf. Лучше не редактировать его напрямую, а создавать отдельные файлы в каталоге /etc/systemd/journald.conf.d/.

Одна из главных настроек для сервера – постоянное хранение логов. Без него часть записей может пропадать после перезагрузки. Для включения постоянного хранения используют параметр:

[Journal]
Storage=persistent

После изменения конфигурации службу нужно перезапустить:

sudo systemctl restart systemd-journald

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

[Journal]
Storage=persistent
SystemMaxUse=1G
SystemKeepFree=2G
MaxRetentionSec=30day
Compress=yes

Подобная конфигурация включает хранение journal на диске, ограничивает его размер, оставляет запас свободного места и удаляет слишком старые записи.

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

sudo journalctl --vacuum-size=500M

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

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

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

Централизованное логирование чаще всего строят одним из способов:

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

Пример отправки всех логов на удаленный сервер по TCP:

*.*    @@192.168.1.10:514

Здесь 192.168.1.10 – адрес лог-сервера, 514 – стандартный syslog-порт, а @@ означает передачу по TCP. Для UDP используется один символ @, но для серверной инфраструктуры TCP обычно надежнее.

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

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

Логи постоянно растут, поэтому без ограничений они могут занять все свободное место на диске. Для текстовых логов в Linux используют logrotate – инструмент, который автоматически переименовывает старые файлы, создает новые, сжимает архивы и удаляет устаревшие записи.

Задача ротации – держать размер логов под контролем. Например, файл /var/log/nginx/access.log может каждый день получать тысячи строк. logrotate периодически переносит старый файл в архив, создает новый лог и оставляет только нужное количество архивных копий.

Основной конфигурационный файл:

/etc/logrotate.conf

Конфигурации отдельных служб обычно находятся в следующем файле:

/etc/logrotate.d/

Пример простой настройки для пользовательского приложения:

/var/log/myapp.log {
    daily
    rotate 14
    compress
    missingok
    notifempty
    create 0640 syslog adm
}

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

Основные параметры logrotate:

Для journald обычно не используют logrotate, потому что его размер и срок хранения настраиваются отдельно через journald.conf. Например, можно задать лимиты SystemMaxUse и MaxRetentionSec. А вот для текстовых файлов в /var/log/ ротация обязательна: она защищает сервер от переполнения диска и делает хранение логов предсказуемым.

Анализ логов и поиск ошибок

Анализ логов лучше начинать с конкретного вопроса: какой сервис работает неправильно, когда появилась проблема и какая ошибка видна пользователю. Это помогает не просматривать весь журнал подряд, а сразу сузить поиск.

Для начала проверьте статус службы:

systemctl status nginx

Если сервис не запускается или работает с ошибками, откройте его журнал:

journalctl -u nginx -b

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

journalctl -u nginx -p err -b

Для текстовых логов используют grep. Например, в error log nginx можно быстро найти типовые проблемы:

grep -Ei "error|failed|timeout|refused" /var/log/nginx/error.log

Простой пример: сайт возвращает ошибку 502. В этом случае стоит проверить не только nginx, но и приложение, к которому он обращается:

journalctl -u nginx --since "30 minutes ago"
journalctl -u myapp --since "30 minutes ago"

Если в логах nginx видно connection refused, причина часто не в самом nginx, а в backend-сервисе: он не запущен, слушает другой порт или завершился с ошибкой.

Итоги

Логирование в Linux строится вокруг двух основных механизмов: journald и rsyslog. journald удобен для работы с systemd-сервисами и структурированными журналами, а rsyslog полезен для классических текстовых логов, гибкой фильтрации и централизованной отправки событий.

Правильно настроенные логи не просто занимают место на диске. Они становятся главным инструментом диагностики, безопасности и спокойной эксплуатации Linux-сервера.