通过

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

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

注意

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

先决条件

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

  • 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 虚拟机（VM）上的 Log Analytics 代理报告检测信号。

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

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

若要获取 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 命令后，检查在 Ruby 中调用的以下命令 omsagent （单行）的命令输出：

/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 检测信号在 2022-03-19T05：18：52.812Z 成功

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

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

传输失败日志

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

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

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”。引发异常：Net：：OpenTimeout， 'execution expired'“ plugin_id=”object：2ab334e31fcc”

2019-04-02 19：29：31 -0500 [警告]： 取消相同的堆栈跟踪

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

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

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

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

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

2019-04-02 19：32：04 -0500 [警告]： 取消相同的堆栈跟踪

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

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

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

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

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

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

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

如果未将检测信号传输到工作区，请使用以下命令运行 Log Analytics Agent 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 反馈社区。