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 工作区 法律 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。

  6. 如果目录或文件缺失：

    1. Azure Monitor代理无法从 Azure Monitor 配置服务（AMCS）下载数据收集规则（DCR）。
    2. 这通常表示以下项之一：
    3. 虚拟机不与任何 DCR 相关联。
    4. 由于网络或 DNS 限制，虚拟机无法访问 AMCS。
    5. Azure Monitor 代理服务在启动期间未运行或启动失败。

  7. 执行以下操作：

    1. 确认 DCR 与 VM 相关联：

      • Azure门户→ 数据收集规则 → 选择数据收集规则 (DCR) → 资源
      • 确保虚拟机显示在列表中。

    2. 检查 VM 的出站网络连接：

      curl -v https://global.handler.control.monitor.azure.cn

    3. 成功的 TLS 连接确认 VM 可以访问 AMCS。

    4. 重启代理：

      sudo systemctl restart azuremonitoragent
sudo systemctl status azuremonitoragent

    5. 检查代理错误日志：

      sudo tail -f /var/opt/microsoft/azuremonitoragent/log/mdsd.err

  8. 有效的配置文件如下所示：

    1. /etc/opt/microsoft/azuremonitoragent/config-cache/configchunks/下的每个文件都表示从Azure下载的已分析数据收集规则。

    2. Example:

      ls /etc/opt/microsoft/azuremonitoragent/config-cache/configchunks/

    3. 输出：

      dcr_1a2b3c4d.json
dcr_5e6f7g8h.json

    4. 检查文件：

      cat /etc/opt/microsoft/azuremonitoragent/config-cache/configchunks/dcr_1a2b3c4d.json

    5. 典型内容包括：

      {
"dataSources": {
"syslog": [
{
"facilityNames": ["daemon"],
"logLevels": ["Info", "Warning", "Error"]
}
]
},
"destinations": {
"logAnalytics": [
{
"workspaceResourceId": "/subscriptions/<subscription-id>/resourceGroups/<resource-group>/providers/Microsoft.OperationalInsights/workspaces/<workspace-name>"
}
]
}
}

如果这些文件为空、缺失或格式不正确，则代理不会收集或上传数据。

收集 Syslog 时出现问题

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

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

    以下示例显示，在之前的 2022-02-28T19:55:23.5432920Z15 分钟内，代理收到了 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 事件引入，可以在文件中-T 0x2002MDSD_OPTIONS末尾追加跟踪标志/etc/default/azuremonitoragent，然后重启代理：

    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 的服务器身份验证要求。

有关Azure Monitor代理和Azure Arc创建的 Linux 用户帐户的完整列表，请参阅安装过程中创建的 Linux 用户帐户。

有关虚拟机规模集自动升级的问题

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

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

  1. 转到 Azure 门户。
  2. 打开 虚拟机规模集。
  3. 转到 实例。
  4. 选择要升级的实例。
  5. 在顶部菜单栏中，选择“ 升级>应用最新模型”。

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

小窍门

可以将升级策略更改为 “滚动” ，以便未来的模型更改会自动流转。 运行以下 CLI 命令，并将<resource-group>和<vmss>替换为您的资源组和虚拟机规模集的名称：

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

如果特定虚拟机仍未更新，请检查 实例保护（保护免受规模集操作），如果已设置，请将其清除。

后续步骤

  • Last updated on