Понимание rsyslog в Red Hat Enterprise Linux

В этой статье мы рассмотрим процесс создания журналов сообщений на сервере Linux. Мы собираемся использовать Red Hat Linux Enterprise (RHEL), который я предпочитаю при работе с Linux. Однако большинство концепций можно использовать в самых разных Linux-системах, даже не входящих в семейство Red Hat. В Red Hat Enterprise Linux есть два метода анализа журналов. Ортодоксальный способ — использование демона rsyslog, и этому посвящена данная статья. Однако существует также реализация journald, которая появилась, когда платформа перешла на Systemd. О втором методе мы расскажем в отдельной статье.

При использовании Microsoft Azure и Log Analytics становится крайне важно понять, что Azure собирается собирать с вашей виртуальной машины Linux, когда агент мониторинга включен, и мы узнаем все это в этой статье.

Понимание rsyslog

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

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

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

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

Существует центральный файл, который управляет всеми операциями rsyslog на данном сервере, и он называется /etc/rsyslog.conf. Файл имеет несколько разделов, таких как модули, фильтры, правила переадресации и так далее.

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

Хорошо, теперь мы понимаем игроков. Следующим этапом является просмотр доступных переменных, и более глубокое знание и устранит этот пробел.

Средство является первой частью перед знаком точки (.) и соответствует подсистеме, которая создает сообщение журнала. Мы можем использовать числа вместо этих имен. Например, сообщения kern равны 0, пользовательские сообщения — 1 и т. д.

• керн(0)
• пользователь
• почта
• демон
• авторизация
• системный журнал
• лпр
• Новости
• хрон
• авторизация
• фтп
• локальный0 в локальный7

Вторая часть головоломки — это приоритет, и он варьируется от 0 до 7. Вот краткое описание уровня с его заголовком и числами, которые мы можем использовать вместо этого.

• появление (уровень 0)
• оповещение (уровень 1)
• крит (уровень 2)
• ошибаться (уровень 3)
• предупреждение (уровень 4)
• уведомление (уровень 5)
• информация (уровень 6)
• отладка (уровень 7)

Теперь мы можем заглянуть в раздел в и понять смысл имеющейся там информации.

Есть некоторые правила при вводе правил. Я попытаюсь обобщить здесь некоторые золотые правила, которые помогут вам при игре с этим файлом.

• * является подстановочным знаком и применяется ко всему, например, вся информация о подсистеме будет регистрироваться (*.info) и все сообщения журнала будут записываться (cron.*)
• Если вы определяете приоритет (*.info), это означает, что будет регистрироваться вся информация о приоритете или выше (все, кроме уровня , потому что он содержит больше информации, чем уровень )
  • Если вы хотите определить только один приоритет, нам нужно ввести знак равенства ( ) перед приоритетом (пример: )
  • Если вы собираетесь что-то исключить, вы можете использовать восклицательный знак ( )
• Мы можем использовать точку с запятой (;), чтобы разделить набор объектов.priority в одной строке (пример: *.info;mail.none)
• Мы можем использовать none в приоритете, чтобы исключить объект из текущего правила.

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

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

Мы можем управлять жизненным циклом наших журналов с помощью утилиты logrotate. По умолчанию он запускается ежедневно службой . Файл конфигурации можно найти в . Системный журнал имеет собственный файл конфигурации в /etc/logrotate.d/syslog.

Если вы не хотите ждать следующего запуска, вы можете инициировать выполнение, запустив logrotate -f /etc/logrotate.conf.

Использование системных команд для чтения информации журнала

Есть несколько команд, которые могут сэкономить массу времени при устранении неполадок с файлами rsyslog. Мы можем использовать tail и head для проверки последних или первых 10 строк файла соответственно. Мы можем добавить -n 6, чтобы определить количество строк.

Если вы проверяете сообщения журнала в реальном времени, это может быть полезно, например, при проверке попыток входа в систему с использованием службы или сообщений httpd. Мы можем использовать tail -f /var/log/file, и это сохранит файл живым, и любые изменения будут запрашиваться автоматически.

Мы можем использовать традиционную команду less, чтобы увидеть все содержимое файла и перемещаться по страницам, нажимая <space> для перехода на следующую страницу и b для возврата на страницу назад. Если вы хотите найти что-то в текущем тексте, введите / , и строка будет выделена по всему тексту.

Команда less не загружает сразу все содержимое файла, как обычный редактор (например, vi или vim), и это помогает при просмотре больших файлов, что может иметь место при работе с содержимым /var/log.

Примечание. Что мне не нравится в команде less, так это то, что при выходе из сеанса весь контент исчезает. Если вы хотите избежать этого странного поведения, используйте -X до того, как имя файла и проблема будут решены!