Сбор событий системного журнала с помощью агента Azure Monitor

Статья
10/18/2023

Внимание

Эта статья ссылается на CentOS, дистрибутив Linux, который приближается к состоянию конца жизни (EOL). Пожалуйста, рассмотрите возможность использования и планирования соответствующим образом. Дополнительные сведения см. в руководстве centOS End Of Life.

Системный журнал — это протокол ведения журнала событий, который является общим для Linux. Вы можете использовать управляющую программу Системного журнала, встроенную на устройствах Linux и (модуль) для сбора локальных событий указанных типов. Затем вы можете отправить эти события в рабочую область Log Analytics. Приложения отправляют сообщения, которые могут храниться на локальном компьютере или доставлены сборщику Системного журнала.

Когда агент Azure Monitor для Linux установлен, он настраивает локальную управляемую программу Системного журнала для пересылки сообщений агенту при включении сбора системных журналов в правилах сбора данных (DCR). Затем агент Azure Monitor отправляет сообщения в рабочую область Azure Monitor или Log Analytics, в которой в таблице Syslog создается соответствующая запись системного журнала.

Сборщик syslog поддерживает следующие объекты:

нет
Керн
Пользователь
mail
daemon
auth
syslog
lpr
news
uucp
ftp
ntp
audit
предупреждение
mark
local0
local1
local2
local3
local4
local5
local6
local7

Для некоторых типов устройств, которые не разрешают локальную установку агента Azure Monitor, агент можно установить вместо этого на выделенном сервере пересылки журналов под управлением Linux. Исходное устройство должно быть настроено для отправки событий Syslog в управляющую программу Syslog на этом сервере пересылки, а не в локальную управляющую программу. Дополнительные сведения см. в руководстве по Sentinel.

Настройка Syslog

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

Настройка системного журнала на портале Azure

Настройте системный журнал из меню "Правила сбора данных" в Azure Monitor. Эта конфигурация передается в файл конфигурации на каждом агенте Linux.

Выберите Добавить источник данных.
Для параметра Тип источника данных выберите Системный журнал Linux.

События системного журнала можно собирать с различным уровнем журнала для каждого объекта. По умолчанию собираются все типы объектов Syslog. Если вы не хотите собирать события типа, выберите NONE в списке "Минимальный auth уровень журнала" для auth объекта и сохраните изменения. Если необходимо изменить уровень журнала по умолчанию для событий Системного журнала и собирать только события с уровнем журнала, начиная с УВЕДОМЛЕНИЯ или более высокого приоритета, выберите LOG_NOTICE в списке "Минимальный уровень журнала".

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

Создание правила сбора данных

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

Войдите на портал Azure.
Найдите и откройте монитор.
В разделе Параметры выберите Правила сбора данных.
Нажмите кнопку создания.

Добавление ресурсов

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

Добавление источника данных

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

Добавление назначения

Выберите Добавить пункт назначения.

Введите следующие значения:

Поле	значение
Тип назначения	Azure Monitor Logs
Отток подписок	Выберите соответствующую подписку
Учетная запись или пространство имен	Выберите соответствующую рабочую область Log Analytics

Выберите Добавить источник данных.
По завершении выберите Next: Отзыв и создание.

Создание правила

Нажмите кнопку создания.
Подождите 20 минут, прежде чем перейти к следующему разделу.

Если у виртуальной машины нет агента Azure Monitor, развертывание DCR активирует установку агента на виртуальной машине.

Настройка системного журнала в агенте Linux

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

При использовании rsyslog:

Во многих дистрибутивах Linux управляющая программа rsyslogd отвечает за использование, хранение и маршрутизацию сообщений журнала, отправленных с помощью API системного журнала Linux. Агент Azure Monitor использует выходной модуль TCP-пересылки (omfwd) в rsyslog для пересылки сообщений журнала агенту Azure Monitor.

Установка агента Azure Monitor включает файлы конфигурации по умолчанию, которые помещаются в следующий каталог: /etc/opt/microsoft/azuremonitoragent/syslog/rsyslogconf/

При добавлении системного журнала в DCR эти файлы конфигурации устанавливаются в etc/rsyslog.d системный каталог и rsyslog автоматически перезапускаются, чтобы изменения вступили в силу. Эти файлы используются rsyslog для загрузки выходного модуля и пересылки событий в управляющая программа агента Azure Monitor с помощью определенных правил.

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

$ cat /etc/rsyslog.d/10-azuremonitoragent-omfwd.conf
# Azure Monitor Agent configuration: forward logs to azuremonitoragent

template(name="AMA_RSYSLOG_TraditionalForwardFormat" type="string" string="<%PRI%>%TIMESTAMP% %HOSTNAME% %syslogtag%%msg:::sp-if-no-1st-sp%%msg%")
# queue.workerThreads sets the maximum worker threads, it will scale back to 0 if there is no activity
# Forwarding all events through TCP port
*.* action(type="omfwd"
template="AMA_RSYSLOG_TraditionalForwardFormat"
queue.type="LinkedList"
queue.filename="omfwd-azuremonitoragent"
queue.maxFileSize="32m"
action.resumeRetryCount="-1"
action.resumeInterval="5"
action.reportSuspension="on"
action.reportSuspensionContinuation="on"
queue.size="25000"
queue.workerThreads="100"
queue.dequeueBatchSize="2048"
queue.saveonshutdown="on"
target="127.0.0.1" Port="28330" Protocol="tcp")

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

template(name="AMA_RSYSLOG_TraditionalForwardFormat" type="string" string="%TIMESTAMP% %HOSTNAME% %syslogtag%%msg:::sp-if-no-1st-sp%%msg%\n")

При использовании syslog-ng:

Файл конфигурации для syslog-ng устанавливается по адресу /etc/opt/microsoft/azuremonitoragent/syslog/syslog-ngconf/azuremonitoragent-tcp.conf. При добавлении коллекции системного журнала в DCR этот файл конфигурации помещается в /etc/syslog-ng/conf.d/azuremonitoragent-tcp.conf системный каталог и syslog-ng автоматически перезапускается, чтобы изменения вступили в силу.

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

$ cat /etc/syslog-ng/conf.d/azuremonitoragent-tcp.conf 
# Azure MDSD configuration: syslog forwarding config for mdsd agent
options {};

# during install time, we detect if s_src exist, if it does then we
# replace it by appropriate source name like in redhat 's_sys'
# Forwrding using tcp
destination d_azure_mdsd {
	network("127.0.0.1" 
	port(28330)
	log-fifo-size(25000));			
};

log {
	source(s_src); # will be automatically parsed from /etc/syslog-ng/syslog-ng.conf
	destination(d_azure_mdsd);
	flags(flow-control);
};

Примечание.

Azure Monitor поддерживает коллекцию сообщений, отправленных rsyslog или syslog-ng, где rsyslog является управляющей программой по умолчанию. Программа syslog по умолчанию в версии 5 Red Hat Enterprise Linux, CentOS и Oracle Linux (sysklog) не поддерживается для сбора событий Системного журнала. Чтобы собирать данные системного журнала из этой версии этих дистрибутивов, необходимо установить и настроить управляющая программа rsyslog для замены sysklog.

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

Необходимые компоненты

Необходимые компоненты:

Рабочая область Log Analytics, в которой есть по крайней мере участник прав.
Конечная точка сбора данных.
Разрешения на создание объектов DCR в рабочей области.
Сообщения системного журнала должны соответствовать стандартам RFC (RFC5424 или RFC3164)

Свойства записей системного журнала

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

Свойство	Description
Компьютер	Компьютер, с которого было получено событие.
Помещение	Определяет часть системы, которая создала сообщение.
HostIP	IP-адрес системы, отправившей сообщение.
HostName	Имя системы, отправившей сообщение.
SeverityLevel	Уровень серьезности события.
SyslogMessage	Текст сообщения.
ProcessID	Идентификатор процесса, создавшего сообщение.
EventTime	Дата и время создания события.

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

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

Query	Description
Системный журнал	Все системные журналы
Syslog \| where SeverityLevel == "error"	Все записи системного журнала с серьезностью ошибки
Системный журнал \| where Facility == "auth"	Все записи системного журнала с типом объекта проверки подлинности
Syslog \| summarize AggregatedValue = count() by Facility	Количество записей системного журнала по объекту

Следующие шаги

См. также: