排查 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 代理后,将自动包含故障排除工具。 如果安装失败,还可以手动安装该工具:
- 由于排除故障时需要使用 GNU Project 调试器 (GDB),因此请确保计算机中已安装该应用程序。
- 将疑难解答捆绑包复制到你的计算机上:
wget https://raw.github.com/microsoft/OMS-Agent-for-Linux/master/source/code/troubleshooter/omsagent_tst.tar.gz
- 解开该捆绑包:
tar -xzvf omsagent_tst.tar.gz
- 运行手动安装:
sudo ./install_tst
涵盖的方案
故障排除工具检查以下方案:
- 代理运行不正常,检测信号无法正常工作。
- 代理未启动,或无法连接到 Log Analytic。
- 代理 Syslog 无效。
- 代理的 CPU 或内存使用率高。
- 代理存在安装问题。
- 代理自定义日志无效。
- 无法收集代理日志。
有关详细信息,请参阅 GitHub 上的故障排除工具文档。
备注
遇到问题时,请运行日志收集器工具。 从一开始便记录日志将帮助我们的支持团队更快解决你的问题。
清除并重新安装 Linux 代理
清理代理并重新安装可以解决大多数问题。 要让代理恢复未中断状态,我们的支持团队提出的第一个建议应该就是执行该任务。 运行故障排除工具和日志收集器工具,尝试清理代理并重新安装,有助于更快地解决问题。
下载清除脚本:
$ wget https://raw.githubusercontent.com/microsoft/OMS-Agent-for-Linux/master/tools/purge_omsagent.sh
运行清除脚本(使用 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 自动化服务终结点。
解决方法
使用以下命令(启用了
-v
选项)通过 Log Analytics Linux 代理重新载入到 Azure Monitor。 它允许通过代理服务器连接到 Azure Monitor 的代理能够进行详细输出:/opt/microsoft/omsagent/bin/omsadmin.sh -w <Workspace ID> -s <Workspace Key> -p <Proxy Conf> -v
请查看更新代理设置部分,验证是否已将代理正确配置为通过代理服务器进行通信。
仔细检查 Azure Monitor 网络防火墙要求列表中列出的终结点是否已正确添加到允许列表中。 如果使用 Azure 自动化,则还会在上面链接必要的网络配置步骤。
问题:尝试载入时收到 403 错误
可能的原因
- Linux 服务器上的日期和时间不正确。
- 工作区 ID 和工作区密钥不正确。
解决方法
- 使用 date 命令检查 Linux 服务器上的时间。 如果时间比当前时间快/慢 15 分钟,则无法加入。 若要纠正此情况,请更新 Linux 服务器的日期和/或时区。
- 验证是否安装了最新版本的 Log Analytics Linux 代理。 如果时间偏差导致了载入故障,最新版本现在会发出通知。
- 请按照本文前面所述的安装说明使用正确的工作区 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 的堆栈跟踪。
下载脚本:
wget https://raw.githubusercontent.com/microsoft/OMS-Agent-for-Linux/master/tools/LogCollector/source/omiHighCPUDiagnostics.sh
使用 30% CPU 阈值运行诊断 24 小时:
bash omiHighCPUDiagnostics.sh --runtime-in-min 1440 --cpu-threshold 30
调用堆栈将转储到 omiagent_trace 文件中。 若发现大量 curl 和 NSS 函数调用,请按照以下步骤解决问题。
解决方法
将 nss-pem 包升级到 v1.0.3-5.el7_6.1:
sudo yum upgrade nss-pem
如果 nss-pem 不可用于升级(主要发生在 CentOS 上),则将 curl 降级到 7.29.0-46。 如果错误地运行了“yum update”,则 curl 将升级到 7.29.0-51,问题将再次发生:
sudo yum downgrade curl libcurl
重启 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 数据收集端口。
解决方法
以 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 相关配置。如果 VM 正在运行
rsyslogd
,要修改的文件是/etc/rsyslog.d/95-omsagent.conf
(如果不存在,则修改/etc/rsyslog
)。 如果 VM 正在运行syslog_ng
,要修改的文件是/etc/syslog-ng/syslog-ng.conf
。重新启动 omsagent
sudo /opt/microsoft/omsagent/bin/service_control restart
。重启 Syslog 服务。
问题:无法使用清除选项卸载 omsagent
可能的原因
- Linux 诊断扩展已安装。
- Linux 诊断扩展已安装和卸载,但仍会看到以下相关错误:omsagent 已被 mdsd 使用,无法删除。
解决方法
- 卸载 Linux 诊断扩展。
- 如果 Linux 诊断扩展文件出现在以下位置:
/var/lib/waagent/Microsoft.Azure.Diagnostics.LinuxDiagnostic-<version>/
和/var/opt/microsoft/omsagent/LAD/
,请从计算机中删除它。
问题:看不到任何 Nagios 数据
可能的原因
- omsagent 用户没有权限从 Nagios 日志文件中进行读取。
- Nagios 源和筛选器未从 omsagent.conf 文件中注释掉。
解决方法
按照以下这些说明添加 omsagent 用户以从 Nagios 文件进行读取。
在 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
操作的日志消息。
解决方法
安装 auditd 程序包等所有依赖项。
通过检查是否存在以下文件,来检查是否已成功加入 Azure Monitor:
/etc/opt/microsoft/omsagent/<workspace id>/conf/omsadmin.conf
。 如果不存在,使用 omsadmin.sh 命令行指令重新载入。如果使用代理服务器,请检查前面的代理服务器故障排除步骤。
在某些 Azure 分发系统中,omid OMI 服务器后台程序在重新启动虚拟机后未启动。 如果是这种情况,则看不到 Audit、ChangeTracking 或 UpdateManagement 解决方法相关数据。 解决方法是通过运行
sudo /opt/omi/bin/service_control restart
来手动启动 OMI 服务器。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 以恢复代理。如果在 omsconfig.log 中看到 DSC 资源“找不到类”错误,请运行
sudo /opt/omi/bin/service_control restart
。在某些情况下,当 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 代理配置代理可能无法与门户配置服务进行通信。 此方案导致未应用最新配置。
通过运行
dpkg --list omsconfig
或rpm -qi omsconfig
检查是否已安装omsconfig
代理。 如果未安装,请重新安装最新版本的 Log Analytics Linux 代理。通过运行以下命令检查
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 中已修复。
解决方法
通过检查是否存在以下文件,验证是否已成功加入 Azure Monitor:
/etc/opt/microsoft/omsagent/<workspace id>/conf/omsadmin.conf
。 如果不存在,则可以:- 使用 omsadmin.sh 命令行指令重新载入。
- 在 Azure 门户的“高级设置”下,确保已启用“将以下配置应用于我的 Linux 服务器”设置。
通过运行以下命令检查
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
用户授予权限,请运行以下命令︰
- 将
omsagent
用户添加到特定组:sudo usermod -a -G <GROUPNAME> <USERNAME>
。 - 授予对所需文件:
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 代理服务已关闭、已禁用或未配置。
解决方法
- 从 Azure 门户删除扩展。
- 按照说明安装代理。
- 运行以下命令重启代理:
sudo /opt/microsoft/omsagent/bin/service_control restart
。 - 等待几分钟,直到预配状态更改为“预配成功”。
问题:Log Analytics 代理升级按需进行
可能的原因
主机上的 Log Analytics 代理程序包已过期。
解决方法
查看该 GitHub 页面上的最新版本。
下载安装脚本(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
通过执行以下命令升级程序包:
sudo sh ./omsagent-*.universal.x64.sh --upgrade
。
问题:安装失败,提示为即使正在使用 Python3,Python2 也并不支持 ctypes
可能的原因
对于此已知问题,如果虚拟机采用的语言不是英语,则在验证正在使用的 Python 版本时,检查将会失败。 此问题会导致代理始终假设正在使用 Python2,而如果没有 Python2,则检查会失败。
解决方法
将虚拟机的环境语言更改为英语:
export LANG=en_US.UTF-8