Azure Log Analytics Agent排错指南
云计算时代，越来越多的企业将其IT基础架构迁移到公有云平台提供业务支撑，传统上我们可以自己部署一套例如ZABBIX监控平台，外加日志分析平台ELK（Elasticsearch、Logstash、Kibana）实现全局监控，但是当业务迁移到公有云平台时，其监视内容就不仅仅是传统的计算、存储、网络、硬件设备了，还需要对云平台做监视，以便清楚的知道公有云平台运行状况是否影响”我”的业务，这个时候就是云原生监控平台的价值体现了，以Microsoft Azure为例，借助Azure Monitor可以：
以下是Azure Monitor的一个简单示意架构图
近日在帮一个客户借助Azure Monitor服务实现企业级云原生监控平台，就使用到了上述若干组件。先看下效果图
但是在实施过程中也遇到不少问题，尤其是日志分析服务Log Analytics，发现无法正常推送Log Analytics Agent（又称为OMSAgent），
无法通过Azure Portal卸载或者通过Log Analytics 断开 VM 连接
今天这里就简单总结一下遇到的问题以及对应的解决办法
在开始之前首先查看Azure Linux Agent是否正常运行，可以管理 Linux 与 FreeBSD 预配，以及 VM 与 Azure 底层控制器之间的交互，它是实现其他IaaS VM扩展的前提， 除了提供预配功能的 Linux 代理外，Azure 还提供对某些 Linux OS 使用 cloud-init 的选项。如果非正常运行或者版本较低建议您重新安装或者升级到较新版本。可参考官方网站：https://docs.microsoft.com/zh-cn/azure/virtual-machines/extensions/agent-linux
问题一：代理通信问题：
使用Log Analytics 故障排除工具查找和诊断 Log Analytics 代理问题，主要检查：
- 代理运行不正常，检测信号无法正常工作
- 代理未启动，无法连接到 Log Analytic 服务
- 代理系统日志无效
- 代理的 CPU/内存使用率高
- 代理存在安装问题
- 代理自定义日志无效
- 收集代理日志
将以下命令粘贴到具有 Log Analytics 代理的计算机上的终端窗口中，可以运行故障排除工具：
| sudo /opt/microsoft/omsagent/bin/troubleshooter |
收集并分析Log Analytics Agent for Linux日志
| 文件 | 路径 |
| Log Analytics Linux 代理日志文件 | /var/opt/microsoft/omsagent/<workspace id>/log/omsagent.log |
| Log Analytics 代理配置日志文件 | /var/opt/microsoft/omsconfig/omsconfig.log |
通过日志可以发现Omsconfig.log中看到有报错信息：
|
2020/11/03 08:44:30: ERROR: null(0): EventId=1 Priority=ERROR Job 10B65B80-B048-413C-B1FF-2341EC407ADD : DSC Engine Error : Error Message Inventory mof does not exist. Error Code : 1 |
解决办法：
运行命令：
| sudo su omsagent -c ‘python /opt/microsoft/omsconfig/Scripts/GetDscConfiguration.py’ |
此命令返回代理从门户网站看到的配置，包括系统日志设置，Linux性能计数器和自定义日志。根据提示完成相关建议操作
安装PaPing，检查防火墙
| #wget https://storage.googleapis.com/google-code-archive-downloads/v2/code.google.com/paping/paping_1.5.5_x86-64_linux.tar.gz #tar zxvf paping_1.5.5_x86-64_linux.tar.gz |
检查防火墙：(黄色部分替换为对应的WorkSpaceID)
| ./paping -p 443 -c 10 [WorkSpaceID].ods.opinsights.azure.cn ./paping -p 443 -c 10 [WorkSpaceID]. oms.opinsights.azure.cn |
重新启动OMSAgent
| sudo /opt/microsoft/omsagent/bin/service_control restart [WorkSpaceID] |
验证更改是否生效
| sudo /opt/microsoft/omsagent/bin/omsadmin.sh -l |
问题二：无法通过代理连接到 Azure Monitor
解决办法：
使用以下命令（启用 -v 选项）通过 Log Analytics Linux 代理重新载入到 Azure Monitor。 它允许通过代理服务器重新连接到 Azure Monitor 的代理。
| /opt/microsoft/omsagent/bin/omsadmin.sh -w <Workspace ID> -s <Workspace Key> -p <Proxy Conf> -v |
重新启动OMSAgent
| sudo /opt/microsoft/omsagent/bin/service_control restart [WorkSpaceID] |
验证更改是否生效
| sudo /opt/microsoft/omsagent/bin/omsadmin.sh -l |
问题三：在 Azure 门户中，log Analytics 代理扩展标记为失败状态：预配失败
解决办法：
Azure Portal中断开log Analytics连接
Azure Portal删除VM扩展
使用下面的命令清除之前产生的配置文件
| sudo rm -rf /etc/opt/microsoft/omsagent sudo rm -rf /var/opt/microsoft/omsagent sudo rm -rf /opt/microsoft/omsagent sudo yum remove -y scx omi omsagent omsconfig auoms |
使用下面的命令联机下载Agent
| wget https://raw.githubusercontent.com/Microsoft/OMS-Agent-for-Linux/master/installer/scripts/onboard_agent.sh –no-check-certificate |
使用下面的命令解压并安装Agent
| sh onboard_agent.sh -w [WorkSpaceID] -s [WorkSpace Key] -d opinsights.azure.cn |
重新启动OMSAgent
| sudo /opt/microsoft/omsagent/bin/service_control restart [WorkSpaceID] |
验证更改是否生效
| sudo /opt/microsoft/omsagent/bin/omsadmin.sh -l |
问题四：无法断开log Analytics无法删除VM扩展，获取Agent状况
解决办法：
登录VM直接联机下载清除脚本卸载当前Agent【传说中的重启重装换电脑的第二大法宝】
| wget https://raw.githubusercontent.com/microsoft/OMS-Agent-for-Linux/master/tools/purge_omsagent.sh |
执行清除卸载Agent
| sudo sh purge_omsagent.sh |
使用下面的命令联机下载Agent
| wget https://raw.githubusercontent.com/Microsoft/OMS-Agent-for-Linux/master/installer/scripts/onboard_agent.sh –no-check-certificate |
使用下面的命令解压并安装Agent
| sh onboard_agent.sh -w [WorkSpaceID] -s [WorkSpace Key] -d opinsights.azure.cn |
重新启动OMSAgent
| sudo /opt/microsoft/omsagent/bin/service_control restart [WorkSpaceID] |
验证更改是否生效
| sudo /opt/microsoft/omsagent/bin/omsadmin.sh -l |
返回log Analytics Portal，查看Agent状况【应该处于未连接状态】
再次点击”连接”应该就工作正常了
在我的这个客户CASE里面，以上几个问题全部遇到，以及绝大部分采用了”重装大法”
此时我们就可以检索当前连接到Log Analytics 工作区的CPU负载情况（Top10）
最后需要注意的是，当我们针对某一特定主机做日志查询与分析的时候，一定要看Log Analytics工作区里显示的名称，发现computer参数调取的是虚拟机的计算机名称，而不是Azure Portal中虚拟机名称。
使用如下命令可以遍历整个Log Analytics 工作区的服务器信息
|
Heartbeat | where OSType == ‘Linux’ | summarize arg_max(TimeGenerated, *) by SourceComputerId | sort by Computer | render table |
以上，就是Log Analytics Agent排错的答题思路，希望可以帮助到大家。
最后，在这个CASE的解决中非常感谢世纪互联蓝云技术专家的大力支持。
本文固定链接: http://365vcloud.azurewebsites.net/2020/12/10/log-analytics-troubleshooting/ | 365vCloud的云计算之旅
【下一篇】Azure 实战之Policy定义资源创建时间
