Поделиться через


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

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

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

Совет

Чтобы собирать данные с устройств, которые не разрешают локальную установку агента Azure Monitor, настройте выделенный сервер пересылки журналов на основе Linux.

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

Настройка сбора данных Системного журнала

На шаге сбора и доставки DCR выберите системный журнал Linux в раскрывающемся списке типа источника данных.

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

Номер индекса приоритета Приоритет Имя
{нет} Нет при
0 Мужик
1 Пользователь
2 mail
3 daemon
4 auth
5 системный журнал
6 lpr
7 news
8 uucp
9 Cron
10 authpriv
11 ftp
12 ntp
13 audit
14 предупреждение
15 clock
16 local0
17 local1
18 local2
19 local3
20 local4
21 local5
22 local6
23 local7

Снимок экрана: страница для выбора типа источника данных и минимального уровня журнала.

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

Назначения

Данные системного журнала можно отправлять в следующие расположения.

Назначение Таблица или пространство имен
Рабочая область Log Analytics Syslog

Примечание.

Azure Monitor Linux Agent версии 1.15.2 и более поздних версий поддерживают форматы syslog RFC, включая Cisco Meraki, Cisco ASA, Cisco FTD, Sophos XG, Juniper Networks, Corelight Zeek, CipherTrust, NXLog, McAfee и Common Event Format (CEF).

Снимок экрана: настройка назначения журналов Azure Monitor в правиле сбора данных.

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

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

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

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

Установка агента Azure Monitor включает файлы конфигурации по умолчанию, расположенные в /etc/opt/microsoft/azuremonitoragent/syslog/rsyslogconf/. При добавлении системного журнала в DCR эта конфигурация устанавливается в etc/rsyslog.d системный каталог и rsyslog автоматически перезапускается, чтобы изменения вступили в силу.

Примечание.

В системах на основе rsyslog агент Linux Azure Monitor добавляет правила пересылки в набор правил по умолчанию, определенный в конфигурации rsyslog. Если используются несколько наборов правил, входные данные, привязанные к наборам правил, не перенаправляются в агент Azure Monitor. Дополнительные сведения о нескольких наборах правил в rsyslog см. в официальной документации.

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

$ 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"
queue.maxDiskSpace="1g"
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")

Следующая конфигурация используется при использовании SELinux и решаете использовать сокеты Unix.

$ cat /etc/rsyslog.d/10-azuremonitoragent.conf
# Azure Monitor Agent configuration: forward logs to azuremonitoragent
$OMUxSockSocket /run/azuremonitoragent/default_syslog.socket
template(name="AMA_RSYSLOG_TraditionalForwardFormat" type="string" string="<%PRI%>%TIMESTAMP% %HOSTNAME% %syslogtag%%msg:::sp-if-no-1st-sp%%msg%") 
$OMUxSockDefaultTemplate AMA_RSYSLOG_TraditionalForwardFormat
# Forwarding all events through Unix Domain Socket
*.* :omuxsock: 
$ cat /etc/rsyslog.d/05-azuremonitoragent-loadomuxsock.conf
# Azure Monitor Agent configuration: load rsyslog forwarding module. 
$ModLoad omuxsock

В некоторых устаревших системах могут возникнуть проблемы с форматированием журнала 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:

Установка агента Azure Monitor включает файлы конфигурации по умолчанию, расположенные в /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);
};

Следующая конфигурация используется при использовании SELinux и решаете использовать сокеты Unix.

$ cat /etc/syslog-ng/conf.d/azuremonitoragent.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 unix domain socket 
destination d_azure_mdsd { 
	unix-dgram("/run/azuremonitoragent/default_syslog.socket" 
	flags(no_multi_line) ); 
};
 
log {
	source(s_src); # will be automatically parsed from /etc/syslog-ng/syslog-ng.conf 
	destination(d_azure_mdsd);
}; 

Примечание.

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

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

Поддерживаемые средства

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

Индекс Pri Имя Pri
0 None
1 Мужик
2 Пользователь
3 mail
4 daemon
4 auth
5 системный журнал
6 lpr
7 news
8 uucp
9 ftp
10 ntp
11 audit
12 предупреждение
13 mark
14 local0
15 local1
16 local2
17 local3
18 local4
19 local5
20 local6
21 local7

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

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

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

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

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

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

      Syslog
    
  • Все записи системного журнала с серьезностью ошибки

      Syslog
      | where SeverityLevel == "error"
    
  • Все записи системного журнала с типом объекта проверки подлинности

      Syslog
      | where facility == "auth"
    
  • Количество записей системного журнала по объекту

      Syslog
      | summarize AggregatedValue = count() by facility
    

Устранение неполадок

Выполните следующие действия, если вы не собираете данные из журнала JSON, который вы ожидаете.

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

Дополнительные сведения: