Устранение неполадок с системным журналом с помощью агента Azure Monitor в Linux

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

Во время установки агент 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.

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

Диагностика сбоев отправки системного журнала

Если агент Azure Monitor успешно получает события системного журнала из rsyslog или syslog-ng, но данные не отображаются в рабочей области Log Analytics, наиболее распространенные причины связаны с подключением, конфигурацией или проверкой подлинности — не использование локального диска.

Наиболее вероятные причины:

• Правило сбора данных (DCR) не связано с компьютером
  Если вы не связываете DCR (или если связываете неправильный DCR), агент Azure Monitor не знает, куда отправлять данные.

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

• Компьютер не может достичь конечных точек приема Azure Monitor
  Это условие обычно вызвано следующими причинами:

  • Ограничения исходящего брандмауэра
  • Неправильная настройка прокси
  • Отсутствуют теги служб или необходимые конечные точки в ограниченных сетях

• Конфигурация TLS или прокси-сервера предотвращает исходящие подключения
  Если прокси-сервер является обязательным и не настроен для агента Azure Monitor, попытка отправки завершается ошибкой.

• Управляемое удостоверение или учетные данные Azure, используемые агентом, не могут пройти проверку подлинности
  Эта ситуация может возникнуть, если расширение агента не настроено правильно.

Сведения об устранении неполадок при отправке и подключении см. в следующих рекомендациях.

• Устранение неполадок агента Azure Monitor на виртуальных машинах и масштабируемых наборах Linux
• Как использовать средство устранения неполадок агента Linux Azure Monitor
• Конечные точки сети для агента Azure Monitor

Если агент Azure Monitor получает события системного журнала, но не может передать их, обычно он регистрирует ошибки, связанные с подключением или проверкой подлинности в:

/var/opt/microsoft/azuremonitoragent/log/mdsd.err

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

Симптом

Данные системного журнала не загружаются: при просмотре журналов ошибок /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 не зависит от событий системного журнала, зарегистрированных в /var/log/. Вместо этого служба rsyslog настраивает пересылку событий через TCP-порт напрямую в процесс службы azuremonitoragent (mdsd).

Удаление высокообъемных функций из конфигурации rsyslog по умолчанию

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

1. Чтобы удалить записи о 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
   

2. sudo systemctl restart rsyslog

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

Если действия, описанные в этой статье, не устраняют проблему, ознакомьтесь со следующими статьями:

• Устранение неполадок с агентом Azure Monitor на виртуальных машинах Linux и масштабируемых группах
• Использовать средство устранения неполадок агента Azure Monitor Linux
• конфигурация сети агента Azure Monitor
• Создание запроса поддержка Azure