Руководство по устранению неполадок с журналом syslog для агента Azure Monitor на Linux

2025-07-08

Агент Azure Monitor устанавливает конфигурацию вывода для демона Syslog системы во время установки. Эта конфигурация определяет, как события перенаправляются из управляющей программы в агент Azure Monitor и находятся по адресу:

/etc/rsyslog.d/10-azuremonitoragent-omfwd.conf для rsyslog (большинство дистрибутивов Linux)
/etc/syslog-ng/conf.d/azuremonitoragent-tcp.conf для syslog-ng

Агент Azure Monitor прослушивает TCP-порт (зафиксированный в /etc/opt/microsoft/azuremonitoragent/config-cache/syslog.port) для получения событий из rsyslog или syslog-ng. Он фильтрует эти события на основе категории или уровня серьезности, определенных в правиле сбора данных (DCR), расположенном в /etc/opt/microsoft/azuremonitoragent/config-cache/configchunks/. События, которые не соответствуют конфигурации DCR, удаляются.

Примечание.

До версии 1.28 агент Azure Monitor использовал сокет домена Unix вместо TCP-порта для получения событий из rsyslog. Выходной omfwd модуль в rsyslog предусматривает механизмы спулинга и повторных попыток для повышения надежности.

Агент Azure Monitor анализирует входящие сообщения Системного журнала в соответствии с RFC3164 и RFC5424 , а также поддерживает другие форматы. Он определяет конечную точку назначения для каждого события из DCR и пытается передать их соответствующим образом.

Примечание.

Если агент мониторинга Azure недоступен или возникают задержки, демон Syslog буферизирует события, используя свои внутренние очереди.
Если агент Azure Monitor не может отправлять события, полученные из rsyslog или syslog-ng, он помещает их в очередь с /var/opt/microsoft/azuremonitoragent/events помощью локального механизма сохраняемости.

Проблемы

Могут возникнуть следующие проблемы:

Данные Rsyslog не отправляются из-за полного места на диске в агенте Azure Monitor для Linux

Симптом

Данные системного журнала не загружаются: при проверке журналов ошибок /var/opt/microsoft/azuremonitoragent/log/mdsd.errвы видите записи об ошибке при вставке элемента в локальное стабильное хранилище ... Не осталось места на устройстве ... аналогично следующему фрагменту:

2021-11-23T18:15:10.9712760Z: Error while inserting item to Local persistent store syslog.error: IO error: No space left on device: While appending to file: /var/opt/microsoft/azuremonitoragent/events/syslog.error/000555.log: No space left on device

Причина

Агент Azure Monitor для Linux буферизирует события /var/opt/microsoft/azuremonitoragent/events перед поглощением. При установке агента Azure Monitor по умолчанию для Linux этот каталог занимает около 650 МБ места на диске бездействия. Размер диска увеличивается при постоянной нагрузке ведения журнала. Она очищается примерно каждые 60 секунд и уменьшается до ~650 МБ при возвращении нагрузки в состояние простоя.

Подтверждение проблемы с полным диском

Команда df показывает, что почти нет свободного места на /dev/sda1, как показано в следующих результатах выполнения. Необходимо проверить элемент строки, который коррелирует с каталогом журнала (например, /var/log или /var/).

df -h

Filesystem Size  Used Avail Use% Mounted on
udev        63G     0   63G   0% /dev
tmpfs       13G  720K   13G   1% /run
/dev/sda1   29G   29G  481M  99% /
tmpfs       63G     0   63G   0% /dev/shm
tmpfs      5.0M     0  5.0M   0% /run/lock
tmpfs       63G     0   63G   0% /sys/fs/cgroup
/dev/sda15 105M  4.4M  100M   5% /boot/efi
/dev/sdb1  251G   61M  239G   1% /mnt
tmpfs       13G     0   13G   0% /run/user/1000

С помощью du команды можно проверить диск, чтобы определить, какие файлы вызывают заполнение диска. Например:

cd /var/log
du -h syslog*

6.7G    syslog
18G     syslog.1

В некоторых случаях du может не сообщать о любых больших файлах или каталогах. Возможно, файл, помеченный как удаленный, занимает место. Это может произойти, когда один процесс пытается удалить файл, но другой процесс по-прежнему открыт.

Чтобы проверить наличие таких файлов, можно использовать lsof команду. В следующем примере мы видим, что /var/log/syslog помечен как удаленный, но он занимает 3,6 ГБ дискового пространства. Файл не был удалён, так как он все еще открыт процессом с PID 1484.

sudo lsof +L1

COMMAND   PID   USER   FD   TYPE DEVICE   SIZE/OFF NLINK  NODE NAME
none      849   root  txt    REG    0,1       8632     0 16764 / (deleted)
rsyslogd 1484 syslog   14w   REG    8,1 3601566564     0 35280 /var/log/syslog (deleted)

Rsyslog по умолчанию регистрирует все объекты в /var/log/

В некоторых популярных дистрибутивах (например, Ubuntu 18.04 LTS), rsyslog поставляется с файлом конфигурации по умолчанию (/etc/rsyslog.d/50-default.conf), который записывает события из почти всех объектов на диск /var/log/syslog. События Syslog из семейства RedHat хранятся в /var/log/, но в другом файле: /var/log/messages.

Агент Azure Monitor не зависит от регистрации Syslog-событий в журнале /var/log/. Вместо этого служба rsyslog настраивает пересылку событий через TCP-порт напрямую в процесс службы azuremonitoragent (mdsd).

Исправление: удалите объекты большого объема из /etc/rsyslog.d/50-default.conf

Если вы отправляете большой объем журналов через rsyslog и система настроена для регистрации событий для этих объектов, попробуйте изменить конфигурацию rsyslog по умолчанию, чтобы избежать ведения журнала и хранения их в /var/log/. События для этого объекта по-прежнему будут перенаправляться в агент Azure Monitor, так как rsyslog использует другую конфигурацию для переадресации, размещенной в /etc/rsyslog.d/10-azuremonitoragent-omfwd.conf.

Например, чтобы удалить события local4, записываемые в /var/log/syslog или /var/log/messages, измените эту строку в /etc/rsyslog.d/50-default.conf из этого фрагмента кода:
```
*.*;auth,authpriv.none          -/var/log/syslog
```
В этот фрагмент кода (добавьте local4.none;):
```
*.*;local4.none;auth,authpriv.none          -/var/log/syslog
```
sudo systemctl restart rsyslog