使用 Azure Monitor 代理排查 Linux 上的 syslog 问题

使用本文诊断和解决 Linux VM 上的 syslog 事件未通过 Azure Monitor 代理收集或转发到Log Analytics工作区的问题。

在安装期间，Azure Monitor 代理程序为系统的 syslog 守护进程安装了输出配置。此配置定义如何将事件从守护程序转发到 Azure Monitor 代理。可以在以下位置找到它：

/etc/rsyslog.d/10-azuremonitoragent-omfwd.conf 用于 rsyslog （大多数 Linux 发行版）
/etc/syslog-ng/conf.d/azuremonitoragent-tcp.conf for syslog-ng

Azure Monitor 代理会侦听 TCP 端口（记录于 /etc/opt/microsoft/azuremonitoragent/config-cache/syslog.port），以接收来自 rsyslog 或 syslog-ng 的事件。它根据位于/etc/opt/microsoft/azuremonitoragent/config-cache/configchunks/的数据收集规则（DCR）中定义的类别或严重性值来筛选这些事件。代理会删除与 DCR 配置不匹配的事件。

Note

在版本 1.28 之前，Azure Monitor 代理使用 Unix 域套接字而不是 TCP 端口从 rsyslog 接收事件。 rsyslogomfwd 中的输出模块提供后台处理和重试机制，以提高可靠性。

Azure Monitor 代理依据 RFC3164 和 RFC5424 分析传入的 syslog 消息，同时还支持其他格式。它确定 DCR 中每个事件的目标终结点，并尝试相应地上传事件。

Note

如果Azure Monitor代理无法访问或遇到延迟，则 syslog 守护程序会使用其内部队列缓冲事件。
如果 Azure Monitor 代理无法上传从 rsyslog 或 syslog-ng，则通过使用其本地持久性机制将其排入。

诊断 syslog 上传失败

如果Azure Monitor代理从 rsyslog 或 syslog-ng 成功接收 syslog 事件，但数据不会显示在Log Analytics工作区中，则最常见的原因与连接、配置或身份验证（而不是本地磁盘使用情况）相关。

常见原因包括：

数据收集规则（DCR）与计算机不关联
如果不关联 DCR（或者关联错误的 DCR），Azure 监视代理将不知道应将数据发送到何处。
DCR 不包括 syslog 数据源，或者设施/严重性不匹配
在这种情况下，Azure Monitor代理在收到事件后删除事件。
计算机无法访问Azure Monitor引入终结点
这种情况通常是由以下原因引起的：
- 出站防火墙限制
- 代理配置错误
- 受限网络中缺少服务标签或所需的端点
TLS 或代理配置可防止出站连接
如果需要代理，并且未为 Azure Monitor 代理配置代理，则上传尝试会失败。
代理使用的托管标识或Azure凭据无法进行身份验证
如果未正确预配代理扩展，则可能会出现此情况。

若要排查上传和连接问题，请参阅以下指南：

如果 Azure Monitor 代理正在接收 syslog 事件，但无法上传这些事件，通常会记录与连接或身份验证相关的错误：

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

由于磁盘空间不足，Rsyslog 数据不会上传

Symptom

Syslog 数据未上传：检查错误日志 /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

Cause

用于 Linux 的 Azure Monitor 代理会在引入之前将事件缓冲到 /var/opt/microsoft/azuremonitoragent/events。在 Linux 安装的默认Azure Monitor代理上，此目录在空闲时占用大约 650 MB 的磁盘空间。在持续的日志记录负载下，磁盘上的大小会增加。大约每 60 秒清理一次，当负载恢复为空闲时，它可减少到大约 650 MB。

确认磁盘空间已满的问题

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 GB。不会删除它，因为具有 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 RedHat 系列 Syslog 事件存储在/var/log/以下，但存储在其他文件中： /var/log/messages

Azure Monitor 代理不依赖记录到/var/log/的 Syslog 事件。取而代之的是，它将 rsyslog 服务配置为通过 TCP 端口将事件直接转发到 azuremonitoragent 服务进程 (mdsd)。

从 rsyslog 默认配置中删除高负载设施

如果通过 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

后续步骤

如果本文中的步骤无法解决问题，请参阅：

Last updated on 2026-04-27