排查适用于 Linux 的 Log Analytics 代理的问题

本文可帮助你排查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 Analytics。
• 代理 Syslog 不起作用。
• 代理的 CPU 或内存使用率高。
• 代理面临安装问题。
• 代理自定义日志无效。
• 无法收集代理日志。

有关详细信息，请参阅 GitHub 上的 Troubleshooting Tool 文档。

清除并重新安装 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 监视器的批量数据按类型、数据项数量和发送时间进行了分隔。

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

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 代理中看到此输出。

在 /etc/opt/microsoft/omsagent/<workspace id>/conf/omsagent.conf 的 Log Analytics 通用代理配置文件中，通过在每行前添加 # 来注释掉 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 自动化 服务端点。

解决方法

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 服务器。
• 每秒转发的消息数太大，无法处理 linux 的 Log Analytics 代理的基本配置。

解决方法

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

问题：您在 omsagent 日志文件中收到“Errno 地址已被使用”错误

在 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. 在 /etc/opt/microsoft/omsagent/<workspace id>/conf/omsagent.conf 的 Log Analytics 代理的 Linux 常规配置文件中，确保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的连接。
• 虚拟机已重新启动。
• 与 Log Analytics Linux 代理包中安装的版本相比，OMI 包已被手动升级到了较新版本。
• OMI 已冻结，阻止了 OMS 代理。
• DSC 资源在 日志文件中记录“omsconfig.log”错误。
• 用于数据备份的Log Analytics代理程序。
• DSC 在 日志文件中记录“当前配置不存在。请先使用 -Path 参数执行 Start-DscConfiguration 命令，以指定配置文件并创建当前的配置。”，但不存在有关 omsconfig.log 操作的日志消息。

解决方法

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

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

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 代理未选取最新的配置。
• 未应用更改的门户设置。

解决方法

Background：omsconfig是适用于 Linux 的 Log Analytics 代理和配置代理，每五分钟查找新的门户端配置。 然后，此配置将应用于位于 /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.
• Linux 版本 1.1.0-217 的 Log Analytics 代理修复了一个已知的竞争条件问题。

解决方法

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

   • 使用 omsadmin.sh 命令行重新载入 instructions。
   1. 在 Azure 门户的 Advanced Settings 中，确保设置 将以下配置应用到我的 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通信并检索最新配置。

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

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

与早于 1.1.0-217 的 Linux 版本的 Log Analytics 代理的争用条件存在已知问题。 更新到最新代理后，运行以下命令以获取最新版本的输出插件：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

相关内容

• 从 Log Analytics 代理迁移到 Azure Monitor 代理
• 排查 Linux 虚拟机上的 Azure Monitor 代理问题
• Azure Monitor 代理概述