排查 Log Analytics Linux 代理的问题

本文可帮助你排查在 Azure Monitor 中使用适用于 Linux 的 Log Analytics 代理时可能会遇到的错误。

Log Analytics 故障排除工具

适用于 Linux 的 Log Analytics 代理故障排除工具是一个脚本，可帮助查找和诊断 Log Analytics 代理的问题。 代理安装会自动包括该工具。 将该工具作为诊断问题的第一步运行。

使用故障排除工具

若要运行故障排除工具，请将以下命令粘贴到具有 Log Analytics 代理的计算机上的终端窗口中：

sudo /opt/microsoft/omsagent/bin/troubleshooter

手动安装

Log Analytics 代理的安装会自动包括故障排除工具。 如果安装失败，还可以手动安装该工具：

1. 由于排除故障时需要使用 GNU Project 调试器 (GDB)，因此请确保计算机中已安装该应用程序。
2. 将疑难解答捆绑包复制到你的计算机上：wget https://raw.github.com/microsoft/OMS-Agent-for-Linux/master/source/code/troubleshooter/omsagent_tst.tar.gz
3. 解开该捆绑包：tar -xzvf omsagent_tst.tar.gz
4. 运行手动安装：sudo ./install_tst

涵盖的方案

故障排除工具检查以下方案：

• 代理运行不正常，检测信号无法正常工作。
• 代理未启动，或无法连接到 Log Analytic。
• 代理 Syslog 无效。
• 代理的 CPU 或内存使用率高。
• 代理面临安装问题。
• 代理自定义日志无效。
• 无法收集代理日志。

有关详细信息，请参阅 GitHub 上的故障排除工具文档。

清除并重新安装 Linux 代理

代理的全新重新安装可修复大多数问题。 此任务可能是支持团队为使代理进入未损坏状态的第一个建议。 运行故障排除工具和日志收集器工具并尝试全新重新安装有助于更快地解决问题。

1. 下载清除脚本：

   $ wget https://raw.githubusercontent.com/microsoft/OMS-Agent-for-Linux/master/tools/purge_omsagent.sh

2. 运行清除脚本（使用 sudo 权限）：

   $ sudo sh purge_omsagent.sh

重要的日志位置和日志收集器工具

使用日志收集器工具获取重要的日志以进行故障排除或在提交 GitHub 问题之前。 若要详细了解该工具及其运行方法，请参阅 OMS Linux 代理日志收集器。

重要的配置文件

安装错误代码

载入错误代码

启用调试日志记录

OMS 输出插件调试

FluentD 支持特定于插件的日志记录级别，因此可以为输入和输出设置不同的日志级别。 若要为 OMS 输出设置不同的日志级别，请在以下位置 /etc/opt/microsoft/omsagent/<workspace id>/conf/omsagent.conf更新常规代理配置。

在 OMS 输出插件中，将 log_level 属性从 info 更改为 debug，并且在配置文件结束之前完成此操作。

<match oms.** docker.**>
  type out_oms
  log_level debug
  num_threads 5
  buffer_chunk_limit 5m
  buffer_type file
  buffer_path /var/opt/microsoft/omsagent/<workspace id>/state/out_oms*.buffer
  buffer_queue_limit 10
  flush_interval 20s
  retry_limit 10
  retry_wait 30s
</match>

调试日志会向您显示已批量上传到 Azure Monitor 的内容，并按照类型、数据项数量和发送时间进行分类。

以下为启用调试日志的示例：

Success sending oms.nagios x 1 in 0.14s
Success sending oms.omi x 4 in 0.52s
Success sending oms.syslog.authpriv.info x 1 in 0.91s

详细输出

可以直接将数据项发送到 stdout，而不是使用 OMS 输出插件。 可以在适用于 Linux 的 Log Analytics 代理日志文件中看到此输出。

在 Log Analytics 常规代理配置文件中的 /etc/opt/microsoft/omsagent/<workspace id>/conf/omsagent.conf 处，通过在每一行的前面添加 # 注释禁止 OMS 输出插件：

#<match oms.** docker.**>
#  type out_oms
#  log_level info
#  num_threads 5
#  buffer_chunk_limit 5m
#  buffer_type file
#  buffer_path /var/opt/microsoft/omsagent/<workspace id>/state/out_oms*.buffer
#  buffer_queue_limit 10
#  flush_interval 20s
#  retry_limit 10
#  retry_wait 30s
#</match>

在输出插件下面，通过在每一行的前面删除 # 注释禁止以下部分：

<match **>
  type stdout
</match>

问题：无法通过代理连接到 Azure Monitor

可能的原因

• 在载入期间指定了不正确的代理。
• 数据中心批准的列表不包括 Azure Monitor 和 Azure Automation 服务终结点。

解决方法

1. 使用适用于 Linux 的 Log Analytics 代理重新载入 Azure Monitor。 使用以下命令，并启用 -v 选项。 此选项提供通过代理连接到 Azure Monitor 的代理的详细输出： /opt/microsoft/omsagent/bin/omsadmin.sh -w <Workspace ID> -s <Workspace Key> -p <Proxy Conf> -v

2. 查看 “更新代理设置” 部分，验证是否已正确配置代理以通过代理服务器进行通信。

3. 请再次确认 Azure Monitor 网络防火墙要求 列表中提到的终结点是否已正确添加到放行名单中。 如果使用 Azure 自动化，则之前还会链接必要的网络配置步骤。

问题：尝试载入时收到 403 错误

可能的原因

• Linux 服务器上的日期和时间不正确。
• 工作区 ID 和工作区密钥不正确。

解决方法

1. 使用 date 命令检查 Linux 服务器上的时间。 如果时间与当前时间的差异超过 15 分钟，则入职流程会失败。 若要更正此问题，请更新 Linux 服务器的日期和时间或时区。
2. 验证是否已安装适用于 Linux 的 Log Analytics 代理的最新版本。 如果时间倾斜导致载入失败，最新版本现在会通知你。
3. 请按照本文前面所述的安装说明使用正确的工作区 ID 和工作区密钥重新载入。

问题：载入后，日志文件中立即显示 500 和 404 错误

此错误是 Linux 数据首次上传到 Log Analytics 工作区时出现的已知问题。 此问题不会影响正在发送的数据或服务体验。

问题：你看到 omiagent 使用100% CPU

可能的原因

nss-pem 包 v1.0.3-5.el7 中的回归会导致严重的性能问题。 此问题经常出现在 Redhat 和 CentOS 7.x 分发版中。 有关此问题的详细信息，请参阅 libcurl 中的1667121性能回归。

与性能相关的 bug 并不总是发生，它们很难重现。 如果您遇到有关 omiagent 的问题，请使用脚本 omiHighCPUDiagnostics.sh。 该脚本在超过某一阈值时收集 omiagent 的堆栈跟踪。

1. 下载脚本：
   wget https://raw.githubusercontent.com/microsoft/OMS-Agent-for-Linux/master/tools/LogCollector/source/omiHighCPUDiagnostics.sh

2. 使用 30% CPU 阈值运行诊断 24 小时：
   bash omiHighCPUDiagnostics.sh --runtime-in-min 1440 --cpu-threshold 30

3. 调用堆栈在omiagent_trace文件中转储。 若发现大量 curl 和 NSS 函数调用，请按照以下步骤解决问题。

解决方法

1. 将 nss-pem 包升级到 v1.0.3-5.el7_6.1：
   sudo yum upgrade nss-pem

2. 如果 nss-pem 不可用于升级（主要发生在 CentOS 上），则将 curl 降级到 7.29.0-46。 如果错误地运行“yum 更新”，curl 将升级到 7.29.0-51，并再次出现问题：
   sudo yum downgrade curl libcurl

3. 重启 OMI：
   sudo scxadmin -restart

问题：看不到转发的 Syslog 消息

可能的原因

• 应用于 Linux 服务器的配置不允许收集已发送的设施或日志级别。
• Syslog 无法正确转发到 Linux 服务器。
• 每秒转发的消息数太大，Log Analytics Linux 代理基本配置无法处理。

解决方法

• 验证 Syslog 的 Log Analytics 工作区中的配置是否具有所有设施和正确的日志级别。 查看在 Azure 门户中配置 Syslog 收集。
• 验证本机 Syslog 消息守护程序（rsyslog、syslog-ng）能否接收转发的消息。
• 若要确保未阻止消息，请检查 Syslog 服务器上的防火墙设置。
• 通过使用 logger 命令来模拟向 Log Analytics 发送的 Syslog 消息：
  logger -p local0.err "This is my test message"

问题：收到的 Errno 地址已在 omsagent 日志文件中使用

在 omsagent.log 中看到 [error]: unexpected error error_class=Errno::EADDRINUSE error=#<Errno::EADDRINUSE: Address already in use - bind(2) for "127.0.0.1" port 25224>。

可能的原因

此错误表示 Linux 诊断扩展 (LAD) 与 Log Analytics Linux VM 扩展并行安装。 它们都对 Syslog 数据收集使用与 omsagent 相同的端口。

解决方法

1. 以root用户身份运行以下命令。 端口号 25224 是一个示例，你可能会在环境中看到 LAD 使用的其他端口号。

   /opt/microsoft/omsagent/bin/configure_syslog.sh configure LAD 25229
   
   sed -i -e 's/25224/25229/' /etc/opt/microsoft/omsagent/LAD/conf/omsagent.d/syslog.conf
   

   然后，你需要编辑正确的 rsyslogd 或 syslog_ng 配置文件，并更改要写入到端口 25229 的 LAD 相关配置。

2. 如果 VM 正在运行 rsyslogd，请修改 /etc/rsyslog.d/95-omsagent.conf （如果存在）或 /etc/rsyslog。 如果 VM 正在运行 syslog_ng，请修改 /etc/syslog-ng/syslog-ng.conf。

3. 运行 sudo /opt/microsoft/omsagent/bin/service_control restart 来重启 omsagent。

4. 重启 Syslog 服务。

问题：无法使用清除选项卸载 omsagent

可能的原因

• Linux 诊断扩展已安装。
• 已安装并卸载 Linux 诊断扩展。 但是，你仍然看到一个关于 omsagent 被 mdsd 使用的错误，并且无法将其删除。

解决方法

1. 卸载 Linux 诊断扩展。
2. 如果计算机中存在 Linux 诊断扩展文件，请从计算机中删除这些文件： /var/lib/waagent/Microsoft.Azure.Diagnostics.LinuxDiagnostic-<version>/ 以及 /var/opt/microsoft/omsagent/LAD/。

问题：看不到任何 Nagios 数据

可能的原因

• omsagent 用户没有权限从 Nagios 日志文件中进行读取。
• Nagios 源和筛选器未在 omsagent.conf 文件中取消注释。

解决方法

1. 按照以下omsagent添加用户以读取 Nagios 文件。

2. 在 Log Analytics Linux 代理常规配置文件的 /etc/opt/microsoft/omsagent/<workspace id>/conf/omsagent.conf 处，确保 Nagios 源和筛选器均已被注释掉。

   <source>
     type tail
     path /var/log/nagios/nagios.log
     format none
     tag oms.nagios
   </source>
   
   <filter oms.nagios>
     type filter_nagios_log
   </filter>
   

问题：看不到任何 Linux 数据

可能的原因

• 加入 Azure Monitor 失败。
• 已阻止连接到 Azure Monitor。
• 虚拟机已重新启动。
• 与安装 Linux 包的 Log Analytics 代理版本相比，OMI 包已手动升级到较新版本。
• OMI 已冻结，正在阻止 OMS 代理。
• DSC 资源在 日志文件中记录“找不到类”错误。
• Log Analytics 代理数据已备份。
• DSC 在 日志文件中记录“当前配置不存在。请先使用 -Path 参数执行 Start-DscConfiguration 命令，以指定配置文件并创建当前的配置。”，但不存在有关 omsconfig.log 操作的日志消息。

解决方法

1. 安装所有依赖项，例如已审核的包。

2. 通过检查是否存在以下文件，来检查是否已成功加入 Azure Monitor：/etc/opt/microsoft/omsagent/<workspace id>/conf/omsadmin.conf。 如果不存在，使用 omsadmin.sh 命令行指令重新载入。

3. 如果使用代理服务器，请检查前面的代理服务器故障排除步骤。

4. 在某些 Azure 分发系统中，omid OMI 服务器后台程序在重新启动虚拟机后未启动。 如果此条件为 true，则看不到 Audit、ChangeTracking 或 UpdateManagement 解决方案相关数据。 解决方法是通过运行 sudo /opt/omi/bin/service_control restart 来手动启动 OMI 服务器。

5. 手动将 OMI 包升级到较新版本后，必须手动重启它，以便 Log Analytics 代理继续运行。 升级后 OMI 服务器不会自动启动的某些发行版需要此步骤。 若要重启 OMI，请运行 sudo /opt/omi/bin/service_control restart。

   在某些情况下，OMI 可能会冻结。 OMS 代理可能会进入等待 OMI 的阻塞状态，这样会阻止所有数据收集。 OMS 代理进程正在运行，但没有活动。 在omsagent.log中没有新的日志行（例如发送的心跳信号）。 使用 sudo /opt/omi/bin/service_control restart 来恢复代理并重启 OMI。

6. 如果在 omsconfig.log 中看到 DSC 资源“找不到类”错误，请运行 。

7. 在某些情况下，当适用于 Linux 的 Log Analytics 代理无法与 Azure Monitor 通信时，代理会将数据备份到 50 MB 的完整缓冲区大小。 通过运行以下命令重启代理： /opt/microsoft/omsagent/bin/service_control restart

   备注

   此问题已在代理版本 1.1.0-28 或更高版本中解决。

   • omsconfig.log如果日志文件未指示系统PerformRequiredConfigurationChecks操作正在定期运行，则 cron 作业或服务可能存在问题。 请确保 /etc/cron.d/OMSConsistencyInvoker 下存在 cron 作业。 如果需要，请运行以下命令创建 cron 作业：

     mkdir -p /etc/cron.d/
     echo "*/15 * * * * omsagent /opt/omi/bin/OMSConsistencyInvoker >/dev/null 2>&1" | sudo tee /etc/cron.d/OMSConsistencyInvoker
     

   • 此外，请确保 cron 服务正在运行。 可以将 service cron status 与 Debian、Ubuntu 和 SUSE 结合使用，或者将 service crond status 与 RHEL、CentOS 和 Oracle Linux 结合使用，来检查此服务的状态。 如果该服务不存在，则可以使用以下说明安装二进制文件并启动该服务：

     Ubuntu/Debian

     # To Install the service binaries
     sudo apt-get install -y cron
     # To start the service
     sudo service cron start
     

     SUSE

     # To Install the service binaries
     sudo zypper in cron -y
     # To start the service
     sudo systemctl enable cron
     sudo systemctl start cron
     

     RHEL/CentOS

     # To Install the service binaries
     sudo yum install -y crond
     # To start the service
     sudo service crond start
     

     Oracle Linux

     # To Install the service binaries
     sudo yum install -y cronie
     # To start the service
     sudo service crond start
     

问题：在从 Syslog 或 Linux 性能计数器的门户配置收集时，未应用这些设置

可能的原因

• 适用于 Linux 的 Log Analytics 代理未选取最新的配置。
• 未应用门户中的已更改设置。

解决方法

背景：omsconfig 是每隔五分钟便会查找一次新门户端配置的 Log Analytics Linux 代理的配置代理。 然后，此配置将应用于位于/etc/opt/microsoft/omsagent/conf/omsagent.conf的 Linux 配置文件的 Log Analytics 代理。

在某些情况下，适用于 Linux 的 Log Analytics 代理配置代理无法与门户配置服务通信。 此方案导致未应用最新配置。

1. 通过运行 omsconfig 或 dpkg --list omsconfig 检查是否已安装 rpm -qi omsconfig 代理。 如果未安装，请重新安装适用于 Linux 的 Log Analytics 代理的最新版本。

2. 通过运行以下命令检查 omsconfig 代理是否可以与 Azure Monitor 进行通信：sudo su omsagent -c 'python /opt/microsoft/omsconfig/Scripts/GetDscConfiguration.py'。 此命令返回代理从该服务中收到的配置（包括 Syslog 设置、Linux 性能计数器和自定义日志）。 如果此命令失败，请运行以下命令：sudo su omsagent -c 'python /opt/microsoft/omsconfig/Scripts/PerformRequiredConfigurationChecks.py'。 此命令会强制 omsconfig 代理与 Azure Monitor 进行通信并检索最新的配置。

问题：看不到任何自定义日志数据

可能的原因

• 加入 Azure Monitor 失败。
• 未选择 “将以下配置应用于我的 Linux 服务器 ”设置。
• omsconfig 未获取服务中的最新自定义日志配置。
• Linux 用户 omsagent 的 Log Analytics 代理由于访问权限或日志未找到而无法访问自定义日志。 你可能会看到以下错误：
  • [DATETIME] [warn]: file not found. Continuing without tailing it.
  • [DATETIME] [error]: file not accessible by omsagent.
• 已知的争用条件问题在 Log Analytics Linux 代理版本 1.1.0-217 中已修复。

解决方法

1. 通过检查是否存在以下文件，验证是否已成功加入 Azure Monitor：/etc/opt/microsoft/omsagent/<workspace id>/conf/omsadmin.conf。 如果不存在，则可以：

   • 使用 omsadmin.sh 命令行 说明重新载入。
   1. 在 Azure 门户的“高级设置”下，确保已启用“将以下配置应用于我的 Linux 服务器”设置。

2. 通过运行以下命令检查 omsconfig 代理是否可以与 Azure Monitor 进行通信：sudo su omsagent -c 'python /opt/microsoft/omsconfig/Scripts/GetDscConfiguration.py'。 此命令返回代理从该服务中收到的配置（包括 Syslog 设置、Linux 性能计数器和自定义日志）。 如果此命令失败，请运行以下命令：sudo su omsagent -c 'python /opt/microsoft/omsconfig/Scripts/PerformRequiredConfigurationChecks.py'。 此命令会强制 omsconfig 代理与 Azure Monitor 进行通信并检索最新的配置。

背景： Log Analytics Linux 代理不是以具有特权的用户 root 身份运行，而是以 omsagent 用户身份运行。 在大多数情况下，必须向此用户授予显式权限才能读取某些文件。 要为 omsagent 用户授予权限，请运行以下命令︰

1. 将 omsagent 用户添加到特定组：sudo usermod -a -G <GROUPNAME> <USERNAME>。
2. 授予对所需文件：sudo chmod -R ugo+rx <FILE DIRECTORY> 的通用读取权限。

这是 1.1.0-217 之前的 Log Analytics Linux 代理版本中已知的争用条件问题。 更新到最新代理后，运行以下命令以获取最新版本的输出插件：sudo cp /etc/opt/microsoft/omsagent/sysconf/omsagent.conf /etc/opt/microsoft/omsagent/<workspace id>/conf/omsagent.conf。

问题：正尝试重新载入到新工作区

当你尝试将代理重新载入新的工作区时，载入之前需要清理 Log Analytics 代理配置。 若要清理代理中的旧配置，请使用 --purge 运行shell 捆绑包：

sudo sh ./omsagent-*.universal.x64.sh --purge

或

sudo sh ./onboard_agent.sh --purge

可以在使用 --purge 选项后继续重新载入。

问题：在 Azure 门户中，log Analytics 代理扩展标记为失败状态：预配失败

可能的原因

• 您从操作系统中删除了 Log Analytics 代理。
• Log Analytics 代理服务已关闭、已禁用或未配置。

解决方法

1. 从 Azure 门户删除扩展。
2. 按照说明安装代理。
3. 运行以下命令重启代理：
   sudo /opt/microsoft/omsagent/bin/service_control restart。
4. 等待几分钟，直到预配状态更改为“预配成功”。

问题：Log Analytics 代理升级按需进行

可能的原因

主机上的 Log Analytics 代理程序包已过期。

解决方法

1. 查看该 GitHub 页面上的最新版本。

2. 下载安装脚本（1.4.2-124 是示例版本）：

   wget https://github.com/Microsoft/OMS-Agent-for-Linux/releases/download/OMSAgent_GA_v1.4.2-124/omsagent-1.4.2-124.universal.x64.sh
   

3. 通过执行以下命令升级程序包：sudo sh ./omsagent-*.universal.x64.sh --upgrade。

问题：安装失败，并显示 Python2 不支持 ctype，即使正在使用 Python3

可能的原因

对于此已知问题，如果 VM 的语言不是英语，则验证使用哪个版本的 Python 时，检查将失败。 此问题会导致代理始终假定使用 Python 2，如果没有 Python 2，则失败。

解决方法

将虚拟机的环境语言更改为英语：

export LANG=en_US.UTF-8