Сбор событий системного журнала с помощью агента Azure Monitor
Внимание
Эта статья ссылается на CentOS, дистрибутив Linux, который приближается к состоянию конца жизни (EOL). Пожалуйста, рассмотрите возможность использования и планирования соответствующим образом. Дополнительные сведения см. в руководстве centOS End Of Life.
Системный журнал — это протокол ведения журнала событий, который является общим для Linux. Вы можете использовать управляющую программу Системного журнала, встроенную на устройствах Linux и (модуль) для сбора локальных событий указанных типов. Затем вы можете отправить эти события в рабочую область Log Analytics. Приложения отправляют сообщения, которые могут храниться на локальном компьютере или доставлены сборщику Системного журнала.
Когда агент Azure Monitor для Linux установлен, он настраивает локальную управляемую программу Системного журнала для пересылки сообщений агенту при включении сбора системных журналов в правилах сбора данных (DCR). Затем агент Azure Monitor отправляет сообщения в рабочую область Azure Monitor или Log Analytics, в которой в таблице Syslog создается соответствующая запись системного журнала.
Примечание.
Агент Azure Monitor использует TCP-порт для получения сообщений, отправленных rsyslog или syslog-ng, однако, если SELinux включен, и мы не можем использовать semanage для добавления правил tcp-порта, мы будем использовать сокеты Unix.
Сборщик syslog поддерживает следующие объекты:
- нет
- Керн
- Пользователь
- 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")
Следующая конфигурация используется при использовании 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
В некоторых устаревших системах, таких как 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);
};
Следующая конфигурация используется при использовании 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, 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 | Количество записей системного журнала по объекту |
Следующие шаги
См. также: