排查 Log Analytics Linux 代理的问题

  • 项目

本文介绍如何排查可能遇到的 Azure Monitor 中的 Log Analytics Linux 代理的相关错误。

Log Analytics 故障排除工具

Log Analytics Linux 代理故障排除工具是一个脚本，旨在帮助查找和诊断 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

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

文件 `Path`
Log Analytics Linux 代理日志文件 /var/opt/microsoft/omsagent/<workspace id>/log/omsagent.log
Log Analytics 代理配置日志文件 /var/opt/microsoft/omsconfig/omsconfig.log

我们建议你在进行故障排除或提交 GitHub 问题之前使用日志收集器工具来检索重要日志。 若要详细了解该工具及其运行方法，请参阅 OMS Linux 代理日志收集器。

重要的配置文件

Category 文件位置
Syslog /etc/syslog-ng/syslog-ng.conf 或 /etc/rsyslog.conf 或 /etc/rsyslog.d/95-omsagent.conf
性能、Nagios、Zabbix、Log Analytics 输出和常规代理 /etc/opt/microsoft/omsagent/<workspace id>/conf/omsagent.conf
额外配置 /etc/opt/microsoft/omsagent/<workspace id>/conf/omsagent.d/*.conf

备注

如果从 Azure 门户中的代理配置为你的工作区配置集合，那么性能计数器的编辑配置文件和 Syslog 将会被覆盖。 要禁用所有代理的配置，请通过“旧版代理程序管理”禁用集合。 要禁用单个代理的配置，请运行以下脚本：

sudo /opt/microsoft/omsconfig/Scripts/OMS_MetaConfigHelper.py --disable && sudo rm /etc/opt/omi/conf/omsconfig/configuration/Current.mof* /etc/opt/omi/conf/omsconfig/configuration/Pending.mof*

安装错误代码

错误代码 含义
NOT_DEFINED 由于未安装必需的依赖项，因此不会安装 auoms auditd 插件。 auoms 安装失败。 已审核安装包。
2 提供给 shell 捆绑包的选项无效。 运行 sudo sh ./omsagent-*.universal*.sh --help 获取使用情况。
3 未向 shell 捆绑包提供任何选项。 运行 sudo sh ./omsagent-*.universal*.sh --help 获取使用情况。
4 无效的包类型或无效的代理设置。 omsagent-rpm.sh 包只能安装在基于 RPM 的系统上。 omsagent-deb.sh 包只能安装在基于 Debian 的系统上。 建议使用最新版本中的通用安装程序。 另外还应该进行查看以验证你的代理服务器设置。
5 必须以 root 身份执行 shell 捆绑包或在载入期间返回 403 错误。 使用 sudo 运行你的命令。
6 包体系结构无效或在载入期间返回 200 错误。 omsagent-*x64.sh 包只能在 64 位系统上安装。 omsagent-*x86.sh 包只能在 32 位系统上安装。 从最新版本为你的体系结构下载正确的程序包。
17 OMS 程序包安装失败。 仔细查看命令输出查找根源故障。
18 OMSConfig 包安装失败。 仔细查看命令输出查找根源故障。
19 OMI 程序包安装失败。 仔细查看命令输出查找根源故障。
20 SCX 程序包安装失败。 仔细查看命令输出查找根源故障。
21 Provider 工具包安装失败。 仔细查看命令输出查找根源故障。
22 捆绑的程序包安装失败。 仔细查看命令输出查找根源故障
23 SCX 或 OMI 程序包已安装。 使用 --upgrade 而不是 --install 安装 shell 捆绑包。
30 内部捆绑包错误。 请提交 GitHub 问题，并附带输出中的详细信息。
55 不受支持的 openssl 版本或无法连接到 Azure Monitor 或 dpkg 已锁定或缺少 curl 程序。
61 缺少 Python ctypes 库。 安装 Python ctypes 库或程序包 (python-ctypes)。
62 缺少 tar 程序。 安装 tar。
63 缺少 sed 程序。 安装 sed。
64 缺少 curl 程序。 安装 curl。
65 缺少 gpg 程序。 安装 gpg。

载入错误代码

错误代码 含义
2 提供给 omsadmin 脚本的选项无效。 运行 sudo sh /opt/microsoft/omsagent/bin/omsadmin.sh -h 获取使用情况。
3 提供给 omsadmin 脚本的配置无效。 运行 sudo sh /opt/microsoft/omsagent/bin/omsadmin.sh -h 获取使用情况。
4 提供给 omsadmin 脚本的代理无效。 验证代理，并参阅我们的有关使用 HTTP 代理服务器的文档。
5 从 Azure Monitor 收到 403 HTTP 错误。 请参阅完整的 omsadmin 脚本输出了解详细信息。
6 从 Azure Monitor 收到非 200 HTTP 错误。 请参阅完整的 omsadmin 脚本输出了解详细信息。
7 无法连接到 Azure Monitor。 请参阅完整的 omsadmin 脚本输出了解详细信息。
8 载入 Log Analytics 工作区时出错。 请参阅完整的 omsadmin 脚本输出了解详细信息。
30 内部脚本错误。 请提交 GitHub 问题，并附带输出中的详细信息。
31 生成代理 ID 时出错。 请提交 GitHub 问题，并附带输出中的详细信息。
32 生成证书时出错。 请参阅完整的 omsadmin 脚本输出了解详细信息。
33 生成 omsconfig 的元配置时出错。 请提交 GitHub 问题，并附带输出中的详细信息。
34 不存在元配置生成脚本。 重新尝试使用 sudo sh /opt/microsoft/omsagent/bin/omsadmin.sh -w <Workspace ID> -s <Workspace Key> 载入。

启用调试日志记录

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

详细输出

如果不使用 OMS 输出插件，可以将数据项直接输出到 Log Analytics Linux 代理日志文件中可见的 stdout。

在 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 自动化服务终结点。

解决方法

  1. 使用以下命令（启用了 -v 选项）通过 Log Analytics Linux 代理重新载入到 Azure Monitor。 它允许通过代理服务器连接到 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. 验证是否安装了最新版本的 Log Analytics Linux 代理。 如果时间偏差导致了载入故障，最新版本现在会发出通知。
  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 超过特定阈值时收集 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 update”，则 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 扩展并行安装。 它使用与 omsagent 相同的 Syslog 数据收集端口。

解决方法

  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. 重新启动 omsagent sudo /opt/microsoft/omsagent/bin/service_control restart。

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

解决方法

  1. 安装 auditd 程序包等所有依赖项。

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

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

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

  5. OMI 程序包手动升级到较新版本后，必须手动重新启动，Log Analytics 代理才能继续运行。 对于其中 OMI 服务器在升级之后无法自动启动的分发，此为必需步骤。 运行 sudo /opt/omi/bin/service_control restart 以重新启动 OMI。

    在某些情况下，OMI 可能会冻结。 OMS 代理可能会进入等待 OMI 的阻塞状态，这样会阻止所有数据收集。 OMS 代理进程将运行，但将没有任何活动，omsagent.log 中不存在新的日志行（如发送的检测信号）就证明了这一点。 使用 sudo /opt/omi/bin/service_control restart 重启 OMI 以恢复代理。

  6. 如果在 omsconfig.log 中看到 DSC 资源“找不到类”错误，请运行 sudo /opt/omi/bin/service_control restart。

  7. 在某些情况下，当 Log Analytics Linux 代理无法与 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 性能计数器的门户配置收集时，未应用这些设置

可能的原因

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

解决方法

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

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

  1. 通过运行 dpkg --list omsconfig 或 rpm -qi omsconfig 检查是否已安装 omsconfig 代理。 如果未安装，请重新安装最新版本的 Log Analytics 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 进行通信并检索最新的配置。

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

可能的原因

  • 加入 Azure Monitor 失败。
  • 未选择“将下列配置应用于我的 Linux 服务器”设置。
  • omsconfig 未从该服务获取最新的自定义日志配置。
  • Log Analytics Linux 代理用户 omsagent 无法访问自定义日志，原因是没有权限或者找不到该日志。 你可能会看到以下错误：
    • [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。 如果不存在，则可以：

    1. 使用 omsadmin.sh 命令行指令重新载入。
    2. 在 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。

问题：安装失败，提示为即使正在使用 Python3，Python2 也并不支持 ctypes

可能的原因

对于此已知问题，如果虚拟机采用的语言不是英语，则在验证正在使用的 Python 版本时，检查将会失败。 此问题会导致代理始终假设正在使用 Python2，而如果没有 Python2，则检查会失败。

解决方法

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

export LANG=en_US.UTF-8