Linux 虚拟机和规模集上的 Azure Monitor 代理的故障排除指南

Azure Monitor 代理概述

进一步阅读前，必须先了解 Azure Monitor 代理和数据收集规则。

术语

基本故障排除步骤

按照以下步骤对 Linux 虚拟机上运行的最新版 Azure Monitor 代理进行排查：

1. 仔细查看此处的先决条件。

2. 验证是否已成功安装和预配扩展，如果成功则会在计算机上安装代理二进制文件：

   1. 打开 Azure 门户 > 选择你的虚拟机 > 从左侧窗格打开“设置: 扩展 +应用程序” 应显示“AzureMonitorLinuxAgent”，并显示“状态: 预配成功”

   2. 如果未看到列出的扩展，请检查计算机是否可以访问 Azure，并使用以下命令查找要安装的扩展：

      az vm extension image list-versions --location <machine-region> --name AzureMonitorLinuxAgent --publisher Microsoft.Azure.Monitor
      

   3. 等待 10 到 15 分钟，因为扩展可能处于正在转换状态。 如果如上仍未显示，请再次卸载并安装扩展。

   4. 检查计算机上位于 /var/log/azure/Microsoft.Azure.Monitor.AzureMonitorLinuxAgent/ 的扩展日志是否存在任何错误

3. 验证代理是否正在运行：

   1. 使用以下查询检查代理是否正在将心跳日志发送到 Log Analytics 工作区。 如果“自定义指标”是 DCR 中的唯一目标，则跳过：

      Heartbeat | where Category == "Azure Monitor Agent" and Computer == "<computer-name>" | take 10
      

   2. 检查代理服务是否正在运行

      systemctl status azuremonitoragent
      

   3. 检查计算机上位于 /var/opt/microsoft/azuremonitoragent/log/mdsd.* 的内核代理日志是否存在任何错误

4. 验证 DCR 是否存在且是否与虚拟机关联：

   1. 如果使用 Log Analytics 工作区作为目标，请验证 DCR 是否位于 Log Analytics 工作区所在的物理区域。
   2. 打开 Azure 门户 > 选择你的数据收集规则 > 打开左侧窗格中的“配置: 资源” 此处应显示虚拟机。
   3. 如果未显示，请单击“添加”并从资源选取器中选择虚拟机。 在所有 DCR 上重复相同的步骤。

5. 验证代理是否能够从 AMCS 服务下载相关的 DCR：

   1. 检查是否显示在此位置 /etc/opt/microsoft/azuremonitoragent/config-cache/configchunks/ 下载的最新 DCR

收集 Syslog 时出现问题

若要详细了解如何排查 Azure Monitor 代理的 syslog 问题，请查看此处。

• 服务质量 (QoS) 文件 /var/opt/microsoft/azuremonitoragent/log/mdsd.qos 可以以 CSV 格式对已处理事件进行 15 分钟的聚合，且包含有关指定时间范围内已处理 syslog 事件数量的信息。 此文件可用于跟踪 Syslog 事件摄取下降。

  例如，以下片段显示，在 2022-02-28T19:55:23.5432920Z 之前的 15 分钟内，代理收到了 77 个带有设备守护程序和级别信息的 syslog 事件，并将上述 77 个事件发送到了上传任务。 此外，代理上传任务收到了 77 条消息并成功上传了全部 77 条 daemon.info 消息。

  #Time: 2022-02-28T19:55:23.5432920Z
  #Fields: Operation,Object,TotalCount,SuccessCount,Retries,AverageDuration,AverageSize,AverageDelay,TotalSize,TotalRowsRead,TotalRowsSent
  ...
  MaRunTaskLocal,daemon.debug,15,15,0,60000,0,0,0,0,0
  MaRunTaskLocal,daemon.info,15,15,0,60000,46.2,0,693,77,77
  MaRunTaskLocal,daemon.notice,15,15,0,60000,0,0,0,0,0
  MaRunTaskLocal,daemon.warning,15,15,0,60000,0,0,0,0,0
  MaRunTaskLocal,daemon.error,15,15,0,60000,0,0,0,0,0
  MaRunTaskLocal,daemon.critical,15,15,0,60000,0,0,0,0,0
  MaRunTaskLocal,daemon.alert,15,15,0,60000,0,0,0,0,0
  MaRunTaskLocal,daemon.emergency,15,15,0,60000,0,0,0,0,0
  ...
  MaODSRequest,https://e73fd5e3-ea2b-4637-8da0-5c8144b670c8_LogManagement,15,15,0,455067,476.467,0,7147,77,77
  

故障排除步骤

1. 首先查看通用 Linux AMA 排查步骤。 如果代理正在发出心跳信号，请继续执行步骤 2。

2. 分析后的配置存储在 /etc/opt/microsoft/azuremonitoragent/config-cache/configchunks/。 检查是否定义了 Syslog 集合，并检查日志目标与 DCR UI/DCR JSON 中构造的是否相同。

   1. 如果是，则继续执行第 3 步。 如果否，则问题出在配置工作流中。
   2. 调查 mdsd.err 下的 mdsd.warn、mdsd.info、/var/opt/microsoft/azuremonitoragent/log 文件是否存在潜在配置错误。

3. 验证 Syslog 收集工作流的布局，确保所有必要部分部署到位且可访问：

   1. 对于 rsyslog 用户，确保 /etc/rsyslog.d/10-azuremonitoragent.conf 文件存在、不为空，且可由 rsyslog 守护程序（syslog 用户）访问。
      1. 在 /etc/rsyslog.conf 和 /etc/rsyslog.d/* 处检查 rsyslog 配置，查看是否有任何输入绑定到非默认规则集，因为来自这些输入的消息不会转发到 Azure Monitor 代理。 例如，不会转发来自配置了非默认规则集（如 input(type="imtcp" port="514" ruleset="myruleset")）的输入的消息。
   2. 对于 syslog-ng 用户，确保 /etc/syslog-ng/conf.d/azuremonitoragent.conf 文件存在、不为空，且可由 syslog-ng 守护程序（syslog 用户）访问。
   3. 确保文件 /run/azuremonitoragent/default_syslog.socket 存在，且可以由 rsyslog 或 syslog-ng 访问。
   4. 检查 syslog 守护程序队列是否溢出导致上传失败，请参阅此处的指南：由于 AMA Linux 代理上的磁盘空间不足，Rsyslog 数据没有上传。

4. 若要进一步调试 syslog 事件引入，你可以在文件 中的 MDSD_OPTIONS 末尾追加跟踪标志 -T 0x2002，然后重新启动代理：

   export MDSD_OPTIONS="-A -c /etc/opt/microsoft/azuremonitoragent/mdsd.xml -d -r $MDSD_ROLE_PREFIX -S $MDSD_SPOOL_DIRECTORY/eh -L $MDSD_SPOOL_DIRECTORY/events -e $MDSD_LOG_DIR/mdsd.err -w $MDSD_LOG_DIR/mdsd.warn -o $MDSD_LOG_DIR/mdsd.info -T 0x2002"
   

5. 在启用跟踪标志的情况下重现问题后，你将在 /var/opt/microsoft/azuremonitoragent/log/mdsd.info 中找到更多调试信息。 检查文件是否存在造成 syslog 收集问题的潜在原因，例如分析/处理/配置/上传错误。

   警告

   确保在调试会话之后删除跟踪标志设置 -T 0x2002，因为它会生成许多跟踪语句，从而迅速填满磁盘或导致难以直观地分析日志文件。

排查已启用 Arc 的服务器上的问题

如果在检查基本故障排除步骤后，没有看到 Azure Monitor Agent 发出日志或在 日志文件中未找到“未能从 IMDS 终结点获取 MSI 令牌”错误，则可能是 /var/opt/microsoft/azuremonitoragent/log/mdsd.err 用户不是 syslog 组的成员。 如果 syslog 用户不是 himds 用户组的成员，请将此用户添加到此组。 如有必要，请创建 syslog 用户和 syslog 组，并确保用户位于该组中。 有关详细信息，请查看此处了解已启用 Azure Arc 的服务器的身份验证要求。

VMSS 上的自动升级问题

在 VMSS 上为 启用“自动扩展升级”时，标志会首先更新规模集模型。AzureMonitorLinuxAgent 如果规模集的升级策略设置为 “手动”，则在应用模型更新之前，此更改不会传播到现有实例。

可以在 Azure 门户中应用最新模型，也可以以编程方式应用。

az vmss update-instances -g <resource-group> -n <vmss> --instance-ids "*"

Update-AzVmssInstance -ResourceGroupName <resource-group> -VMScaleSetName <vmss> -InstanceId "*"

这会将当前规模集模型（包括已更新的 enableAutomaticUpgrade 标志）强制应用于所选实例。

az vmss update -g <resource-group> -n <vmss> --set upgradePolicy.mode=Rolling

如果特定虚拟机仍然未更新，请检查 实例保护（防止规模集操作），如果已启用，请将其清除。