通过

你当前正在访问 Microsoft Azure Global Edition 技术文档网站。 如果需要访问由世纪互联运营的 Microsoft Azure 中国技术文档网站，请访问 https://docs.azure.cn。

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

  • 项目

Azure Monitor 代理概述

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

术语

名称 首字母缩写词 说明
Azure Monitor 代理 AMA 新的 Azure Monitor 代理
数据收集规则 DCR 按代理划分的数据收集的配置规则，即收集内容、接收对象等
Azure Monitor 配置服务 AMCS Azure 中托管的区域服务，用于控制此代理和 Azure Monitor 其他部分的数据收集。 代理调用此服务以获取 DCR。
日志终结点 -- 用于将数据发送到 Log Analytics 工作区的终结点
指标终结点 -- 用于将数据发送到 Azure Monitor 指标数据库的终结点。
实例元数据服务和混合 IMDS 和 HIMDS Azure 中托管的服务，分别提供有关当前运行的虚拟机、规模集（通过 IMDS）和启用了 Arc 的服务器（通过 HIMDS）的信息
Log Analytics 工作区 LAW 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. 调查 /var/opt/microsoft/azuremonitoragent/log 下的 mdsd.err、mdsd.warn、mdsd.info 文件是否存在潜在配置错误。

  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. 参阅此处的指南：由于 AMA Linux 代理上的完全磁盘空间问题，Rsyslog 数据未上传，检查 syslog 守护程序队列是否未溢出，从而导致上传失败

  4. 若要进一步调试 syslog 事件引入，你可以在文件 /etc/default/azuremonitoragent 中的 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 发出日志或在 /var/opt/microsoft/azuremonitoragent/log/mdsd.err 日志文件中未找到“未能从 IMDS 终结点获取 MSI 令牌”错误，则可能是 syslog 用户不是 himds 组的成员。 如果 syslog 用户不是 himds 用户组的成员，请将此用户添加到此组。 如有必要，请创建 syslog 用户和 syslog 组，并确保用户位于该组中。 有关详细信息，请查看此处了解已启用 Azure Arc 的服务器的身份验证要求。