排查 Linux 代理中缺少检测信号的问题

  • 项目

本文可帮助你排查基于 Linux 的计算机上的 Microsoft Azure Log Analytics 代理中缺少检测信号的问题。

注意

Linux 代理中似乎缺少检测信号的原因有很多。 但是，本文只讨论导致问题发生的方案的采样。

先决条件

  • 受支持的 Linux 分发版和未强化的版本。 如果不知道分发版或版本是什么，请在 shell 中运行 cat /etc/system-release 命令以显示此信息。

  • x86 或 x64 CPU 体系结构。

  • 不是多个工作区的多宿主的 Log Analytics 代理。 若要验证代理的多宿主状态，请运行 omsadmin.sh 脚本：

    sudo sh /opt/microsoft/omsagent/bin/omsadmin.sh -l

  • 为以下代理资源配置的防火墙或代理：

    • *.ods.opinsights.azure.com
    • *.oms.opinsights.azure.com
    • *.blob.core.windows.net
    • *.azure-automation.net

    请确保这些资源在出站方向使用端口 443，并且允许绕过 HTTPS 检查。 有关详细信息，请参阅网络要求。

  • 在 Linux 计算机上运行的 Operations Management Suite Linux 代理日志收集器 。 Operations Management Suite (OMS) 是适用于 Linux 的 Log Analytics 代理的另一个名称。

    如果日志收集器工具不适用于操作系统，请手动收集 重要日志位置和日志收集器工具中提到的日志和配置文件。

症状

在 Azure 门户 中查看 Log Analytics 工作区时，不会从 Linux 虚拟机上的 Log Analytics 代理报告检测信号 (VM) 。

原因 1：代理配置为向另一个工作区报告

如果 Linux 代理 (与 Log Analytics 工作区的工作区 ID 不同的 GUID) 调用工作区 ID，该怎么办？ 在这种情况下，代理配置为将其检测信号和数据发送到另一个工作区。

若要获取 Linux 代理使用的工作区 ID，请运行用于检查代理多宿主状态的相同 omsadmin.sh 脚本：

sudo sh /opt/microsoft/omsagent/bin/omsadmin.sh -l

若要在 Azure 中获取工作区 ID，请执行以下步骤：

  1. 在Azure 门户中，找到并选择“Log Analytics 工作区”。

  2. 在 Log Analytics 工作区列表中，选择要将代理数据发送到的工作区。

  3. 在所选工作区的“ 概述 ”页上，找到 工作区 ID 中列出的 GUID 值。 此值是否与 omsadmin.sh 脚本的输出中显示的工作区 ID 不同？ 如果存在，则你已发现问题的原因。

解决方案：重新配置代理以指向正确的工作区

更改代理配置以使用Azure 门户中显示的工作区 ID。 必须调查代理配置为向其他工作区报告的原因。 代理可能有正当理由将数据发送到自己的工作区以外的工作区。

原因 2：代理进程未启动

代理进程 (omsagent) 未成功启动，因此没有任何可用的检测信号数据。

运行以下命令，该命令使用 ps 和 grep 工具来列出当前正在运行的进程：

ps -ef | grep -i oms | grep -v grep

找到该 ps 命令后，检查以下命令的命令输出 omsagent ， (作为在 Ruby 中调用的单行) ：

/opt/microsoft/omsagent/ruby/bin/ruby /opt/microsoft/omsagent/bin/omsagent \
  -d /var/opt/microsoft/omsagent/<workspace-id>/run/omsagent.pid \
  -o /var/opt/microsoft/omsagent/<workspace-id>/log/omsagent.log \
  -c /etc/opt/microsoft/omsagent/<workspace-id>/conf/omsagent.conf \
  --no-supervisor

注意

工作区< id> 占位符是 GUID。

如果找不到此命令调用，则表示代理进程未启动。

解决方案：手动启动代理进程

在 Linux shell 中，运行以下命令以手动启动代理：

/opt/microsoft/omsagent/bin/service_control start

运行此命令后，验证 omslinux.out 中的输出现在是否包含之前查找的预期文本。

原因 3：影响 VM SSL 设置的问题

可能存在影响 VM 上的安全套接字层 (SSL) 连接的问题。 若要检查 SSL 问题，请执行以下步骤：

  1. 运行以下 wget 命令，将 Ruby 测试脚本下载到本地 VM：

    wget https://raw.githubusercontent.com/ruby/openssl/master/test/openssl/test_ssl.rb

  2. 将脚本移动到 /tmp 目录。

  3. 确保 omsagent 用户可以访问根 CA 证书。

  4. 使用以下命令运行测试脚本：

    sudo --user=omsagent /opt/microsoft/omsagent/ruby/bin/ruby /tmp/test_ssl.rb

测试脚本确定问题是否影响 VM SSL 连接。

解决方案：修复 CA 证书和 SSL 连接

请确保 SSL 根 CA 证书有效，并且 VM 可以具有 SSL 连接。

原因 4：代理生成检测信号，但无法将其传输到工作区

omsagent.log 文件显示代理正在生成检测信号，但它不会将检测信号成功传输到 Log Analytics 工作区。 若要确保检测信号已记录到该文件中，请运行以下命令 tail 以查看日志文件的末尾：

tail omsagent.log

在 文件中，是否看到包含以下字符串的多个日志条目？

[信息]：发送 OMS 检测信号成功

例如，是否看到类似于以下文本的条目？

2022-03-19 05：18：52 +0000 [info]：发送 OMS 检测信号成功，at 2022-03-19T05：18：52.812Z

此类条目表示代理正在生成检测信号并成功将这些检测信号发送到工作区。

或者，你是否看到类似于“遇到可重试异常”的信息性消息，而不是此类条目。 是否稍后重试发送数据“以及警告消息，例如”未能刷新缓冲区“或”已取消同一堆栈跟踪“？ 如果输出包含此类消息，则代理无法将其检测信号发送到工作区。 例如，你可能会看到类似于以下文本的条目：

传输失败日志

2019-04-02 19：27：43 -0500 [info]：发送 OMS 检测信号成功 2019-04-03T00：27：43.729Z

2019-04-02 19：28：43 -0500 [info]：发送 OMS 检测信号成功 2019-04-03T00：28：43.729Z

2019-04-02 19：29：31 -0500 [info]： 遇到可重试异常。稍后将重试发送数据。

2019-04-02 19：29：31 -0500 [warn]： 暂时无法刷新缓冲区。 next_retry=2019-04-02 19：38：01 -0500 error_class=“RuntimeError” error=“Net：：HTTP。Post 引发异常：Net：：OpenTimeout，'execution expired'“ plugin_id=”object：2ab334e31fcc”

2019-04-02 19：29：31 -0500 [warn]： 已抑制相同的堆栈跟踪

2019-04-02 19：29：43 -0500 [info]：发送 OMS 检测信号成功 2019-04-03T00：29：43.730Z

2019-04-02 19：30：43 -0500 [info]：发送 OMS 检测信号成功 2019-04-03T00：30：43.731Z

2019-04-02 19：31：43 -0500 [info]：发送 OMS 检测信号成功 2019-04-03T00：31：43.731Z

2019-04-02 19：32：04 -0500 [info]： 遇到可重试异常。稍后将重试发送数据。

2019-04-02 19：32：04 -0500 [warn]： 暂时无法刷新缓冲区。 next_retry=2019-04-02 19：36：34 -0500 error_class=“RuntimeError” error=“Net：：HTTP。Post 引发异常：Net：：OpenTimeout，'execution expired'“ plugin_id=”object：2ab3347a61e4”

2019-04-02 19：32：04 -0500 [warn]： 已抑制相同的堆栈跟踪

2019-04-02 19：32：43 -0500 [info]：发送 OMS 检测信号成功 2019-04-03T00：32：43.732Z

2019-04-02 19：33：43 -0500 [info]：发送 OMS 检测信号成功 2019-04-03T00：33：43.733Z

2019-04-02 19：34：43 -0500 [info]：发送 OMS 检测信号成功 2019-04-03T00：34：43.734Z

2019-04-02 19：35：43 -0500 [info]：发送 OMS 检测信号成功 2019-04-03T00：35：43.735Z

2019-04-02 19：36：43 -0500 [info]：发送 OMS 检测信号成功 2019-04-03T00：36：43.736Z

2019-04-02 19：37：04 -0500 [info]： 遇到可重试异常。稍后将重试发送数据。

2019-04-02 19：37：04 -0500 [warn]： 无法刷新缓冲区。 error_class=“RuntimeError” error=“Net：：HTTP。Post 引发异常：Net：：OpenTimeout，'execution expired'“ plugin_id=”object：2ab3347a61e4”

如果未将检测信号传输到工作区，请使用以下命令运行 Log Analytics 代理 Linux 故障排除工具 ：

sudo /opt/microsoft/omsagent/bin/troubleshooter

故障排除工具将列出选项菜单。 选择选项 2 (Agent doesn't start, can't connect to Log Analytic Services) 。 然后，该工具将尝试确定失败的原因。

解决方案：从基础结构或网络团队获取帮助以访问必要的终结点

如果故障排除工具返回任何涉及终结点连接的错误，请参阅 Log Analytics 代理的网络要求。 能够发送检测信号数据的必要 URL 是 <workspace-id.ods.opinsights.azure.com>。 如果在使用该 URL 时遇到故障，请咨询基础结构或网络团队以还原访问权限。

原因 5：影响 Log Analytics 引入的问题

在 Log Analytics 工作区中，查找 Linux 检测信号的以下 Kusto 查询不返回任何结果：

Heartbeat
| where OSType == "Linux"
| summarize arg_max(TimeGenerated, *) by Computer

由于其他代理也不能发送检测信号，因此这种情况指示影响 Log Analytics 中引入的一般问题。

解决方案 1：检查中断通知

验证代理是否有 引入延迟延迟。 如果检测到明显的引入延迟，检查 Azure 服务运行状况，以确定是否存在任何中断通知。

解决方案 2：等待 Azure 服务或区域的引入问题清除

此问题可能是由 Azure 服务或 Azure 区域中的引入问题引起的。 检查 Azure 服务和区域的状态。 如果发现问题，请等待受影响的服务或区域恢复运行状况。 然后，重新检查是否向工作区报告检测信号。

联系我们寻求帮助

如果你有任何疑问或需要帮助，请创建支持请求或联系 Azure 社区支持。 还可以向 Azure 反馈社区提交产品反馈。