Старые добрые логи по-прежнему актуальны в эпоху журналов systemd.
Изучите основы ведения логов с помощью syslogd в этом руководстве.
На протяжении десятилетий ведение журналов на Linux осуществлялось демоном syslogd.
Syslogd собирал сообщения логов, которые системные процессы и приложения отправляли на псевдоустройство /dev/log.
Затем он направляет эти сообщения в соответствующие обычные текстовые файлы логов в каталоге /var/log/.
Syslogd будет знать, куда отправлять сообщения, поскольку каждое из них включает заголовки, содержащие поля метаданных (включая метку времени, происхождение и приоритет сообщения).
Логированием в Linux теперь также занимается и journald.
Я говорю “также”, потому что syslogd никуда не делся, и вы все еще можете найти большинство его традиционных файлов журналов в /var/log/.
Но вы должны знать, что в городе появился новый шериф, которого (в командной строке) зовут journalctl.
🐧 Как использовать journalctl для анализа логов на Linux
Но эта статья не о journald.
Основное внимание здесь уделено systemd, поэтому давайте разберемся в нем немного подробнее.
Логирование с помощью syslogd
Все журналы, генерируемые событиями в системе syslogd, добавляются в файл /var/log/syslog.
Но, в зависимости от их идентификационных характеристик, они также могут быть отправлены в один или несколько других файлов в том же каталоге.
В системе syslogd способ распространения сообщений определяется содержимым файла 50-default.conf, который находится в каталоге /etc/rsyslog.d/.
🐧 20 команд мониторинга Linux, которые вы должны знать
Этот пример из 50-default.conf показывает, как сообщения лога, помеченные как относящиеся к cron, будут записываться в файл cron.log.
В данном случае звездочка (*) указывает syslogd на отправку записей с любым уровнем приоритета (в отличие от одного уровня, например, emerg или err):
cron.* /var/log/cron.logРабота с файлами логов syslogd не требует специальных инструментов, таких как journalctl.
Но если вы хотите добиться хороших результатов, вам нужно знать, какая информация хранится в каждом из стандартных файлов журналов.
В таблице ниже перечислены наиболее распространенные файлы журналов syslogd и их назначение.
| Имя файла | Назначение |
|---|---|
| auth.log | Системная аутентификация и события безопасности |
| boot.log | Запись событий, связанных с загрузкой |
| dmesg | События в буфере кольца ядра, связанные с драйверами устройств |
| dpkg.log | Мероприятия по управлению программными пакетами |
| kern.log | События ядра Linux |
| syslog | Коллекция всех журналов |
| wtmp | Отслеживает сеансы пользователя (доступ к ним осуществляется с помощью команд who и last) |
🐧 Какова цель файлов utmp, wtmp и btmp на Linux
Кроме того, отдельные приложения иногда пишут в свои собственные файлы журналов.
Также часто можно увидеть целые каталоги, такие как /var/log/apache2/ или /var/log/mysql/, созданные для получения данных приложений.
Перенаправление журналов также можно контролировать с помощью любого из восьми уровней приоритета, в дополнение к символу * (для всех уровней приоритета), который вы видели ранее.
| Уровень | Описание |
|---|---|
| debug | Полезно для отладки |
| info | Информационный уровень |
| notice | Обычные условия |
| warn | Условия, требующие предупреждения |
| err | Условия возникновения ошибок |
| crit | Критические условия |
| alert | Требуется немедленное действие |
| emerg | Система неработоспособна |
Управление файлами логов с помощью sysglogd
По умолчанию syslogd обрабатывает ротацию, сжатие и удаление журналов за кулисами без какой-либо помощи с вашей стороны.
Но вы должны знать, как это делается, на случай, если у вас появятся логи, требующие особого обращения.
Какого рода особое обращение может потребовать простой журнал?
Предположим, ваша компания должна соответствовать правилам отчетности по транзакциям, связанным с нормативными или отраслевыми стандартами, такими как PCI-DSS.
Если записи вашей ИТ-инфраструктуры должны оставаться доступными в течение длительных периодов времени, то вам определенно понадобится знать, как найти путь к ключевым файлам.
Чтобы увидеть систему logrotate в действии, перечислите некоторые из содержимого каталога /var/log/. Например, файл auth.log появляется в трех различных форматах:
- auth.log – текущая активная версия, в которую записываются новые сообщения об аутентификации.
- auth.log.1 – Самый последний файл, который был выведен из эксплуатации. Он хранится в несжатом формате, чтобы облегчить быстрый вызов его обратно в случае необходимости.
- auth.log.2.gz – более старая коллекция (как видно из расширения файла .gz в следующем листинге), которая была сжата для экономии места.
Через семь дней, когда наступит дата следующей ротации, auth.log.2.gz будет переименован в auth.log.3.gz, auth.log.1 будет сжат и переименован в auth.log.2.gz, auth.log станет auth.log.1, а новый файл будет создан и получит имя auth.log.
Цикл ротации журнала по умолчанию регулируется в файле /etc/logrotate.conf.
🐧 Как настроить и управлять ротацией логов с помощью Logrotate на Linux
🎅 Как создать пользовательскую ротацию файла журнала с помощью logrotate в Linux
Как настроить logrotate для нескольких экземпляров httpd
Значения, показанные в этом листинге, ротируют файлы после одной активной недели и удаляют старые файлы через четыре недели.
# rotate log files weekly
weekly
# keep 4 weeks worth of backlogs
rotate 4
# create new (empty) log files after rotating old ones
create
# packages drop log rotation information into this directory
include /etc/logrotate.
Каталог /etc/logrotate.d/ также содержит настраиваемые конфигурационные файлы для управления ротацией журналов отдельных служб или приложений.
Перечисляя содержимое этого каталога, вы увидите эти файлы конфигурации:
$ ls /etc/logrotate.d/
apache2 apt dpkg mysql-server
rsyslog
samba
unattended-upgradeВы можете просмотреть их содержимое, чтобы узнать, какая у них конфигурация ротации журнала.
Многие администраторы предпочитают перенаправлять записи журналов на специально созданные удаленные серверы логов, где данные могут получить все специализированное внимание, которого они заслуживают. Это позволяет освободить серверы приложений для выполнения их непосредственных задач и консолидировать данные журналов в едином, легкодоступном центральном месте.
Как читать файлы syslog
Использование cat здесь следует полностью исключить.
Он просто вывалит тысячи строк на ваш экран.
Я предлагаю использовать grep для фильтрации текста в файлах.
Команда tail -f позволяет читать текущий файл журнала в режиме реального времени.
Вы можете комбинировать ее с grep для фильтрации нужного текста.
В некоторых случаях вам может потребоваться доступ к старым, сжатым журналам.
Вы всегда можете сначала извлечь файл, а затем использовать grep, less и другие команды для чтения его содержимого, однако есть и лучший вариант.
Существуют команды z, такие как zcat, zless и т.д., которые позволяют работать со сжатыми файлами без их явного извлечения.
- Примеры команд Linux zcat для новичков
- Как просмотреть содержимое архива или сжатый файл без его извлечения
Практический пример анализа логов
Вот наглядный пример, который будет искать в файле auth.log свидетельства неудачных попыток входа в систему.
Поиск по слову failure будет возвращает любую строку, содержащую фразу “Authentication failure".
Проверяя это время от времени, вы сможете обнаружить попытки взлома учетной записи путем подбора правильного пароля.
Каждый может перепутать пароль один или два раза, но слишком большое количество неудачных попыток должно вызвать у вас подозрения:
$ cat /var/log/auth.log | grep 'Authentication failure'
Sep 6 09:22:21 workstation su[21153]: pam_authenticate: Authentication failureЕсли вы из тех администраторов, которые никогда не совершают ошибок, то этот поиск может оказаться пустым.
Вы можете гарантировать себе хотя бы один результат, если вручную создадите запись в журнале с помощью программы под названием logger.
Попробуйте сделать это примерно так:
logger "Authentication failure"Вы также можете предварительно выдать настоящую ошибку, войдя в учетную запись пользователя и введя неправильный пароль.
Как вы можете видеть, grep сделал за вас эту работу, но все, что вы можете увидеть из результатов, это то, что произошел сбой аутентификации.
Разве не полезно было бы узнать, чья учетная запись была задействована?
Вы можете расширить результаты, которые выдает grep, указав ему включить строки непосредственно до и после совпадения.
В этом примере выводится совпадение вместе со строками вокруг него.
Это говорит о том, что кто-то под учетной записью david безуспешно пытался использовать команду su (switch user) для входа в систему под учетной записью studio:
$ cat /var/log/auth.log | grep -C1 failure
Sep 6 09:22:19 workstation su[21153]: pam_unix(su:auth): authentication
failure; logname= uid=1000 euid=0 tty=/dev/pts/4 ruser=david rhost=
user=studio
Sep 6 09:22:21 workstation su[21153]: pam_authenticate:
Authentication failure
Sep 6 09:22:21 workstation su[21153]: FAILED su for studio by davidЗаключение
Знать основы – это одно, а применять знания – совсем другое.
Однако знание основ помогает в различных ситуациях.
Теперь, когда вы знаете основы работы с syslogs в Linux, вам будет легче работать с логами.
