Как распечатать 20 последних событий из журнала Linux

Обновлено: 22.11.2024

Системным администраторам Linux часто приходится просматривать файлы журналов для устранения неполадок. Фактически, это первое, что сделает любой системный администратор.

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

В этом руководстве мы рассмотрим различные части механизма ведения журнала Linux.

Отказ от ответственности

Команды в этом руководстве были протестированы в обычных установках CentOS 6.4, Ubuntu 12 и Debian 7.

Расположение файла журнала по умолчанию

По умолчанию для файлов журналов в Linux используется каталог /var/log.

Вы можете просмотреть список файлов журналов в этом каталоге с помощью простой команды ls -l /var/log.

Вот что я вижу в своей системе CentOS:

Просмотр содержимого файла журнала

Вот некоторые распространенные файлы журналов, которые вы найдете в /var/log:

maillog или mail.log

auth.log или безопасный

Файлы wtmp и utmp отслеживают вход пользователей в систему и выход из нее. Вы не можете напрямую прочитать содержимое этих файлов с помощью cat — для этого есть специальные команды.

Теперь мы будем использовать некоторые из этих команд.

Чтобы узнать, кто в данный момент подключен к серверу Linux, просто используйте команду who. Эта команда получает значения из файла /var/run/utmp (для CentOS и Debian) или /run/utmp (для Ubuntu).

Вот пример из CentOS:

В данном конкретном случае я являюсь единственным пользователем системы. Я запускал сервер из Oracle VirtualBox и обращался к нему с правами root как из консоли, так и из сеанса SSH. Две другие учетные записи пользователей (sysadmin и joebolg) также имели доступ к системе.

Последняя команда сообщает нам историю входов пользователей:

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

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

Результат может выглядеть так

Чтобы узнать, когда кто-то в последний раз входил в систему, используйте lastlog:

В моей системе вывод выглядел так:

Для других текстовых файлов журнала вы можете использовать команды cat, head или tail для чтения содержимого.

В приведенном ниже примере я пытаюсь просмотреть последние десять строк файла /var/log/messages в окне Debian:

Демон rsyslog

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

Файл конфигурации rsyslog

Демон rsyslog получает информацию о конфигурации из файла rsyslog.conf. Файл находится в каталоге /etc.

По сути, файл rsyslog.conf сообщает демону rsyslog, где сохранять сообщения журнала. Эта инструкция представляет собой серию строк, состоящих из двух частей, внутри файла.

Этот файл можно найти по адресу rsyslog.d/50-default.conf в Ubuntu.

Инструкция, состоящая из двух частей, состоит из селектора и действия. Две части разделены пробелом.

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

Сам селектор снова разделен на две части, разделенные точкой (.). Первая часть перед точкой называется *acility (происхождение сообщения), а вторая часть после точки называется приоритетом (серьезность сообщения).

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

Вот выдержка из файла CentOS rsyslog.conf:

Чтобы понять, что все это значит, давайте рассмотрим различные типы средств, распознаваемых Linux. Вот список:

  • auth или authpriv: сообщения, поступающие от событий, связанных с авторизацией и безопасностью
  • kern: любое сообщение, поступающее от ядра Linux.
  • почта: сообщения, созданные почтовой подсистемой
  • cron: сообщения, связанные с демоном Cron
  • демон: сообщения, поступающие от демонов
  • новости: сообщения, поступающие из подсистемы сетевых новостей
  • lpr: печать связанных сообщений журнала
  • пользователь: регистрировать сообщения, поступающие от пользовательских программ.
  • local0 to local7: зарезервировано для локального использования

А вот список приоритетов в порядке возрастания:

  • debug: информация об отладке программ.
  • информация: простое информационное сообщение — вмешательство не требуется
  • уведомление: условие, которое может потребовать внимания
  • предупреждать: предупреждение
  • ошибка: Ошибка
  • crit: критическое состояние
  • оповещение: состояние, требующее немедленного вмешательства
  • emerg: аварийное состояние

Теперь давайте рассмотрим следующую строку из файла:

Это просто указывает демону rsyslog сохранять все сообщения, поступающие от демона cron, в файл с именем /var/log/cron. Звездочка (*) после точки (.) означает, что будут регистрироваться сообщения всех приоритетов. Точно так же, если средство было указано звездочкой, это означало бы все источники.

Удобства и приоритеты могут быть связаны разными способами.

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

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

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

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

В первом случае файл mail.info будет содержать все, что имеет приоритет ниже, чем info. Во втором случае файл будет содержать все сообщения с приоритетом выше info.

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

Несколько источников (facility.priority) в одной строке разделяются точкой с запятой.

Когда действие помечено звездочкой (*), это означает всех пользователей. Эта запись в моем файле CentOS rsyslog.conf говорит именно об этом:

Попробуйте узнать, что говорит rsyslog.conf в вашей системе Linux. Вот выдержка из сервера Debian, на котором я работаю:

Как видите, Debian сохраняет все сообщения уровня безопасности/авторизации в /var/log/auth.log, тогда как CentOS сохраняет их в /var/log/secure .

Конфигурации для rsyslog также могут быть получены из других пользовательских файлов. Эти пользовательские файлы конфигурации обычно находятся в разных каталогах в /etc/rsyslog.d. Файл rsyslog.conf включает эти каталоги с помощью директивы $IncludeConfig.

Вот как это выглядит в Ubuntu:

Содержимое каталога /etc/rsyslog.d выглядит следующим образом:

Теперь место назначения для сообщения журнала не обязательно должно быть файлом журнала; сообщение может быть отправлено на консоль пользователя. В этом случае поле действия будет содержать имя пользователя. Если несколько пользователей должны получить сообщение, их имена пользователей разделяются запятыми. Если сообщение необходимо отправить всем пользователям, оно обозначается звездочкой (*) в поле действия.

Поскольку демон rsyslog является частью сетевой операционной системы, он может не только локально сохранять сообщения журнала, но и пересылать их на другой сервер Linux в сети или выступать в качестве репозитория для других систем. Демон прослушивает сообщения журнала через UDP-порт 514. В приведенном ниже примере критически важные сообщения ядра пересылаются на сервер с именем «texas».

Создание и тестирование собственных сообщений журнала

Настало время создать собственные файлы журналов.

Чтобы проверить это, мы сделаем следующее

Добавить спецификацию файла журнала в файл /etc/rsyslog.conf

Перезапустите демон rsyslog

Проверьте конфигурацию с помощью утилиты logger

В следующем примере я добавляю две новые строки в файл rsyslog.conf моей системы CentOS Linux. Как видите, каждый из них исходит из объекта под названием local4, и у них разные приоритеты.

Затем служба перезапускается, поэтому данные файла конфигурации перезагружаются:

Чтобы сгенерировать сообщение журнала сейчас, вызывается приложение регистратора:

В каталоге /var/log теперь отображаются два новых файла:

Размер файла local4info.log не равен нулю. Итак, когда он открыт, я вижу, что сообщение было записано:

Ротация файлов журнала

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

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

Ротация запускается с помощью утилиты logrotate.

Файл конфигурации logrotate

Как и rsyslog, logrotate также зависит от файла конфигурации, и имя этого файла — logrotate.conf. Он находится в папке /etc.

Вот что я вижу в файле logrotate.conf моего сервера Debian:

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

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

Пользовательские настройки ротации журналов хранятся в каталоге etc/logrotate.d. Они также включены в logrotate.conf директивой include. Установка Debian показывает мне содержимое этого каталога:

Содержимое rsyslog показывает, как повторно использовать несколько файлов журнала:

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

Также стоит отметить директиву postrotate. Указывает действие, которое происходит после завершения ротации всего журнала.

Проверка поворота

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

Чтобы увидеть, как это работает, вот неполный список файлов журналов в каталоге /var/log на моем тестовом сервере CentOS:

Частично содержимое файла logrotate.conf выглядит следующим образом:

Затем мы запускаем команду logrotate:

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

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

Последние слова

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

Хотите узнать больше? Присоединяйтесь к сообществу DigitalOcean!

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

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

Системные журналы

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

Журнал авторизации

Отслеживает системы авторизации, такие как запрос пароля, команду sudo и удаленный вход в систему.

Журнал демона

Демоны – это программы, работающие в фоновом режиме, обычно без участия пользователя. Например, сервер отображения, сеансы SSH, службы печати, Bluetooth и т. д.

Журнал отладки

Предоставляет отладочную информацию из системы и приложений Ubuntu.

Журнал ядра

Журналы ядра Linux.

Системный журнал

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

Журналы приложений

Некоторые приложения также создают журналы в /var/log . Ниже приведены некоторые примеры.

Журналы Apache

Расположение: /var/log/apache2/ (подкаталог)

Apache создает несколько файлов журналов в подкаталоге /var/log/apache2/. В файле access.log записываются все запросы к серверу на доступ к файлам. error.log записывает все ошибки, выдаваемые сервером.

Журналы сервера X11

Сервер X11 создает отдельный файл журнала для каждого из ваших дисплеев. Номера дисплеев начинаются с нуля, поэтому ваш первый дисплей (дисплей 0) будет записываться в Xorg.0.log . Следующий дисплей (дисплей 1) будет вести журнал в Xorg.1.log и т. д.

Журналы, не предназначенные для чтения человеком

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

Журнал неудачных попыток входа

Содержит информацию о сбоях входа в систему. Вы можете просмотреть его с помощью команды faillog.

Журнал последних входов

Содержит информацию о последних входах в систему. Вы можете просмотреть его с помощью команды lastlog.

Журнал записей входа

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

Это не исчерпывающий список!
Вы можете поискать в Интернете дополнительные места, относящиеся к тому, что вы пытаетесь отладить. Здесь также есть более длинный список.

3. Просмотр журналов с помощью средства просмотра системных журналов GNOME

Просмотр системного журнала GNOME предоставляет простой графический интерфейс для просмотра и мониторинга файлов журнала. Если вы используете Ubuntu 17.10 или выше, он будет называться Logs. В противном случае он будет называться «Системный журнал».

Интерфейс просмотра системного журнала

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

Просмотрщик журналов не только отображает, но и отслеживает изменения в файлах журналов. Жирный текст (как видно на снимке экрана выше) указывает на новые строки, которые были зарегистрированы после открытия файла. Когда журнал, который в данный момент не выбран, обновляется, его имя в списке файлов становится жирным (как показано auth.log на снимке экрана выше).

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

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

Подробнее

Если вы хотите узнать больше о средстве просмотра системного журнала GNOME, вы можете посетить официальную документацию.

4. Просмотр и мониторинг журналов из командной строки

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

Следующие команды будут полезны при работе с файлами журналов из командной строки.

Просмотр файлов

Самый простой способ просмотра файлов из командной строки — использование команды cat. Вы просто передаете имя файла, и он выводит все содержимое файла: cat file.txt .

Это может быть неудобно при работе с большими файлами (что не редкость для журналов!). Мы могли бы использовать редактор, хотя это может быть излишним только для просмотра файла. Здесь появляется команда less. Мы передаем ей имя файла (less file.txt), и она открывает файл в простом интерфейсе. Отсюда мы можем использовать клавиши со стрелками (или j/k, если вы знакомы с Vim) для перемещения по файлу, использовать / для поиска и нажать q для выхода. Есть еще несколько функций, все из которых описаны нажатием h, чтобы открыть справку.

Просмотр начала или конца файла

Мы также можем быстро просмотреть первые или последние n строк файла. Здесь пригодятся команды head и tail. Эти команды работают так же, как cat , хотя вы можете указать, сколько строк от начала/конца файла вы хотите просмотреть. Чтобы просмотреть первые 15 строк файла, мы запускаем head -n 15 file.txt, а чтобы просмотреть последние 15, запускаем tail -n 15 file.txt. Из-за того, что файлы журналов добавляются внизу, команда tail обычно более полезна.

Мониторинг файлов

Чтобы отслеживать файл журнала, вы можете передать флаг -f в tail . Он будет продолжать работать, печатая новые дополнения к файлу, пока вы его не остановите (Ctrl + C). Например: tail -f файл.txt .

Поиск файлов

Один из рассмотренных нами способов поиска файлов — открыть файл в меньшем размере и нажать / . Более быстрый способ сделать это — использовать команду grep. Мы указываем, что мы хотим искать, в двойных кавычках вместе с именем файла, и grep напечатает все строки, содержащие этот поисковый запрос в файле. Например, чтобы найти строки, содержащие «тест» в файле.txt, вы должны запустить команду grep «test» file.txt.

Если результат поиска grep слишком длинный, вы можете направить его в команду less , что позволит вам прокручивать его и выполнять поиск: grep "test" file.txt | меньше .

Редактирование файлов

Самый простой способ редактировать файлы из командной строки — использовать nano . nano — это простой редактор командной строки, в котором все самые полезные сочетания клавиш выведены прямо на экран. Чтобы запустить его, просто дайте ему имя файла ( nano file.txt ). Чтобы закрыть или сохранить файл, нажмите Ctrl + X. Редактор спросит вас, хотите ли вы сохранить изменения. Нажмите y для да или n для нет. Если вы выберете «да», он попросит вас указать имя файла для сохранения файла. Если вы редактируете существующий файл, имя файла уже будет там.Просто оставьте все как есть, и оно будет сохранено в соответствующий файл.

5. Заключение

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

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

В этом разделе мы покажем вам, как использовать некоторые из этих инструментов и как решения для управления журналами, такие как SolarWinds® Loggly ®, могут помочь автоматизировать и оптимизировать процесс анализа журналов.

Поиск с помощью Grep

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

Чтобы выполнить простой поиск, введите строку поиска, а затем файл, который нужно найти. Здесь мы ищем в журнале аутентификации строки, содержащие «user hoover».

Обратите внимание, что возвращаются строки, содержащие точное совпадение. Это делает его полезным для поиска, когда вы точно знаете, что ищете.

Регулярные выражения

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

Например, мы хотим найти попытки аутентификации на порту 4792. Простой поиск «4792» будет соответствовать порту, но он также может соответствовать отметке времени, URL-адресу или другому номеру. В данном случае он совпал с журналом Apache, в URL которого оказалось 4792.

Чтобы предотвратить это, мы могли бы использовать регулярное выражение, которое возвращает только экземпляры 4792, которым предшествует "порт" и пустое место. Мы делаем это, используя технику, известную как положительный взгляд назад. Наше выражение выглядит следующим образом (флаг -P указывает, что мы используем синтаксис регулярных выражений Perl).

Объемный поиск

Использование объемного поиска возвращает количество строк до или после совпадения. Это обеспечивает контекст для каждого события, позволяя отслеживать события, которые привели к событию или сразу последовали за ним. Флаг -B указывает, сколько строк должно быть возвращено до события, а флаг -A указывает количество строк после.

Например, давайте найдем попытки входа с недопустимым именем пользователя и покажем соответствующие результаты. Мы видим, что пользователи, которым не удается войти в систему, также не проходят проверку обратного сопоставления. Это означает, что у клиента нет действительной обратной DNS-записи, что характерно для общедоступных подключений к Интернету. Это не означает, что ваш SSH-сервер уязвим, но может означать, что злоумышленники активно пытаются получить к нему доступ.

Tail — это еще один инструмент командной строки, который может отображать последние изменения из файла в режиме реального времени. Это полезно для мониторинга текущих процессов, таких как перезапуск службы или проверка изменения кода. Вы также можете использовать tail для печати последних нескольких строк файла или соединить его с grep для фильтрации вывода из файла журнала.

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

Команда cut позволяет анализировать поля из журналов с разделителями. Разделители — это символы, такие как знаки равенства или запятые, которые разбивают поля или пары "ключ-значение".

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

Мы можем использовать команду cut, чтобы получить восьмое совпадение. Этот пример относится к системе Ubuntu.

Фильтрация и анализ с помощью Awk

Фильтрация позволяет выполнять поиск по определенному значению поля вместо полнотекстового поиска. Это делает анализ журнала более точным, поскольку он игнорирует нежелательные совпадения из других частей сообщения журнала. Чтобы выполнить поиск по значению поля, вам нужно сначала проанализировать свои журналы или, по крайней мере, иметь способ поиска на основе структуры события. Для этого мы можем использовать awk.

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

Вот как вы можете использовать команду awk. Во-первых, мы используем регулярное выражение /sshd.*invalid user/ для сопоставления строк недействительного пользователя sshd. Затем напечатайте девятое поле, используя разделитель по умолчанию (символ пробела) с помощью < print $9 >. Это выводит имена пользователей.

Фильтрация ошибок с помощью Awk

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

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

Этот пример дает вам вывод в следующем формате. Вы можете видеть, что серьезность в этом сообщении — «ошибка»:

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

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

Поиск с помощью систем управления журналами

Системы управления журналами упрощают процесс анализа и поиска в больших коллекциях файлов журналов. Они могут автоматически анализировать распространенные форматы журналов, такие как события системного журнала, журналы SSH и журналы веб-сервера. Они также индексируют каждое поле, чтобы вы могли быстро выполнять поиск по гигабайтам или даже терабайтам данных журнала. Они часто используют языки запросов, такие как Apache Lucene, чтобы обеспечить более гибкий поиск, чем grep, с более простым синтаксисом поиска, чем регулярное выражение. Это экономит время и усилия, поскольку вам не нужно создавать собственную логику синтаксического анализа для каждого уникального поиска.

Например, здесь мы собираем журналы с сервера Debian с помощью SolarWinds® Loggly®, облачной службы управления журналами. Вот пример сообщения журнала от sshd, который автоматически анализирует поле пользователя.

Проанализированная Loggly неудачная попытка входа в систему.

Вы также можете выполнять пользовательский анализ нестандартных форматов. Используя производные поля, мы можем проанализировать непроанализированную часть сообщения, определив его макет. Это позволяет нам индексировать каждое отдельное поле в непроанализированных данных вместо того, чтобы рассматривать его как одну строку. Например, мы можем создать новое поле с именем «auth_stage» и использовать его для хранения стадии процесса аутентификации, на которой произошла ошибка, в данном примере это «preauth».

Просмотр производного поля в обозревателе полей Loggly.

Фильтрация ошибок с помощью систем управления журналами

Системы управления журналами упрощают фильтрацию ошибок, поскольку они автоматически анализируют журналы для нас. Во многих случаях можно просто щелкнуть нужное поле и ввести значение для фильтрации полученных журналов. Например, мы можем просмотреть ошибки в Loggly, щелкнув поле серьезности системного журнала и выбрав «Ошибка».

Фильтрация сообщений системного журнала с серьезностью «Ошибка» в SolarWinds Loggly.

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

В этой статье вы изучите следующие основы ведения журналов в Linux:

  • Где хранятся файлы журналов Linux, как они форматируются и как их читать.
  • Как читать наиболее важные журналы (например, системный журнал).
  • Как настроить демон системного журнала Ubuntu.
  • Что такое ротация журналов Linux и как использовать утилиту logrotate.

Предпосылки

Прежде чем перейти к остальной части этого руководства, убедитесь, что у вас есть базовые знания о работе с командной строкой Linux. Хотя многие концепции, обсуждаемые в этой статье, в целом применимы ко всем дистрибутивам Linux, мы будем демонстрировать их только в Ubuntu, поэтому обязательно настройте сервер Ubuntu 20.04, который включает пользователя без полномочий root с доступом sudo.

Шаг 1. Поиск системных журналов Linux

Все системные журналы Ubuntu хранятся в каталоге /var/log. Перейдите в этот каталог в терминале с помощью команды ниже:

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

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

Давайте рассмотрим несколько важных файлов системного журнала, которые могут находиться в каталоге /var/log, и их содержимое:

  • /var/log/syslog: хранит общую информацию о любых глобальных действиях в системе.
  • /var/log/auth.log : отслеживает все действия, связанные с безопасностью (вход в систему, выход из системы или активность пользователя root).
  • /var/log/kern.log: хранит информацию о событиях, происходящих из ядра Linux.
  • /var/log/boot.log : хранит сообщения о запуске системы.
  • /var/log/dmesg: содержит сообщения, связанные с драйверами устройств.
  • /var/log/faillog: отслеживает неудачные попытки входа в систему, что может пригодиться при расследовании попыток нарушения безопасности.

Каталог /var/log также используется для хранения различных журналов приложений. Например, если ваш дистрибутив связан с Apache или MySQL или установлен позже, их файлы журналов также будут найдены здесь.

Шаг 2. Просмотр содержимого файла журнала Linux

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

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

Обычные файлы журнала

Эти журналы представляют собой простые текстовые файлы со стандартным форматом содержимого. Ubuntu использует шаблон журнала под названием RSYSLOG_TraditionalFileFormat. Этот формат журнала состоит из четырех основных полей с разделителем-пробелом:

  1. Отметка времени указывает время создания записи журнала в формате МММ дд ЧЧ:мм:сс (например, 28 сентября 19:00:00 ). Обратите внимание, что этот формат не включает год.
  2. Имя хоста – это хост или система, которая изначально создала сообщение.
  3. Приложение — это приложение, которое создало сообщение.
  4. Сообщение содержит фактические сведения о событии.

Давайте рассмотрим некоторые файлы журналов в текстовом формате. Выполните приведенную ниже команду, чтобы распечатать содержимое файла /var/log/syslog с помощью утилиты tail:

Читайте также: