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

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

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

Создание DCR

Создайте DCR с помощью процесса сбора данных из клиента виртуальной машины с помощью Azure Monitor.

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

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

Выберите минимальный уровень журнала для каждого объекта или NONE , чтобы не собирать события для этого объекта. Чтобы настроить несколько объектов одновременно, установите флажок и выберите уровень журнала в разделе "Задать минимальный уровень журнала" для выбранных объектов.

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

1. Отладка
2. Информация
3. Примечание.
4. Предупреждение
5. Ошибка
6. Критически важно
7. Предупреждение
8. Аварийная ситуация

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

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

Проверка сбора данных

Чтобы убедиться, что данные собираются, проверьте наличие записей в таблице Syslog . На виртуальной машине или в рабочей области Log Analytics на портале Azure выберите журналы и нажмите кнопку "Таблицы ". В категории "Виртуальные машины" нажмите кнопку "Выполнить рядом с системным журналом".

Настройка системного журнала в агенте 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 автоматически перезапускается, чтобы изменения вступили в силу.

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

$ 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 автоматически перезапускается, чтобы изменения вступили в силу.

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

$ 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);
}; 

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

Поддерживаемые объекты

Сборщик Syslog поддерживает следующие возможности:

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

Агент Azure Monitor (AMA) перенаправляет данные системного журнала по мере получения. Он не изменяет содержимое сообщения. Однако точка с запятой (;) в сообщениях системного журнала удаляется во время приема в Azure Log Analytics.

Если необходимо сохранить точку с запятой, попробуйте изменить сообщение Syslog в источнике перед приемом. Например, можно заменить запятой другой символ, например запятую или канал (|), или кодировать содержимое сообщения перед отправкой в Azure Monitor.

Дальнейшие действия

• Дополнительные сведения об агенте Azure Monitor.
• Подробнее о правилах сбора данных.