Puppet监控速查问题的原因及解决方案是什么

Foreman提供了较全面的交互设施，包括Web前端、CLI和RESTful API。在此基础之上，可以构建监控管理系统，以及实现报警等功能。

可以简单将Puppet的工作流程抽象为四部分：

• 请求阶段：Agent基于SSL将自身信息发送给Server；

• 响应阶段：Server基于客户端信息解析相应的配置，并最终将伪代码（catalog）发送回Agent；

• 执行阶段：Agent接收catalog并执行命令或者更新文件；

• 汇报阶段：Agent把结果汇报给Server。

图1 Puppet工作流程

监控概览

对Puppet的核心监控主要覆盖如下环节：

• Agent与Master通信是否正常；

• Agent策略执行是否生效；

• Puppet发布的策略生效时间及范围；

• Master及其所管理集群的运行状态。

黑盒监控

Puppet黑盒监控指标不符合预期，说明集群不能正常工作或出现异常，黑盒监控指标有：所有策略是否都生效，策略生效范围是否符合预期，策略生效结果是否符合预期。

所有策略是否都生效

说明：将一批测试节点，加入到线上Puppet集群，通过定期运行检查脚本验证所有策略是否都生效。

策略生效范围

说明：策略上线后，需要确认其生效范围是否符合预期，即策略是否仅在指定的节点生效。

实现：通过Puppet模块MCollective定时执行检查任务（检查实际生效的机器列表和服务树机器列表是否一致），如下图，集群hn-xdata 有98%的机器符合预期，2%不符合。

图2 Puppet策略生效范围监控

策略生效结果是否符合预期

说明：策略上线后，需要确保所有策略在所有机器都生效。

实现：通过Puppet模块MCollective定时执行检查任务，（检查实际生效的机器列表和服务树机器列表是否一致），如下图，每一个策略有一张饼图。

图3 Puppet策略结果监控

白盒监控

白盒监控是黑盒监控的补充，服务于故障定位，从集群容量、流量、延迟、错误四个方面梳理。

数据采集方式：

• 通过Foreman API

• Master日志分析

表1 通过Foreman API获取采集的白盒指标概览

容量

Master所在实例的CPU，网络连接数指标，网卡

流量

Agent PV，基于Puppet Master的访问日志puppetserver-access.log来计算流量

图4 Agent PV流量图

延迟

单个Agent更新策略需要的时间：puppet_report_time_total

说明：puppet_report_time_total 是Agent从连接Master到发送报告给Master总时间，0-3s的占50%，0-11s的占90%，0-15s占99%。

图5 Agent 延迟

错误

• No reports：没有报告的实例数量；

• Error agent：执行策略出错的实例数量；

• Out of sync：执行策略超时、主机名重复、主机连不上Master的实例数量。

图6 Foreman错误监控指标

Puppet监控发现的问题

Agent覆盖所有机器

问题：不能保证所有机器Agent都正常运行。

解决方案：基于服务树或者CMDB相关系统将所有机器填加Agent进程监控。

Agent执行策略超时

问题：大文件并发下载时，出现超时告警。

排查方法：在Agent上执行命令“puppet agent -t --debug”, 发现在拉取文件时超时，由于文件较大，在Master上同时很多Agent拉取，导致超时。

解决方案：将大文件存放在云存储上，提高下载速度。

分组不止仅限于现有Facter属性

问题：策略分组和灰度发布分组现有Facter属性不满足。

原因：随着接入业务越来越多，业务分组也越多。

解决方案：自定义Facter。

Agent不同步（Out of Sync）

问题：Agent报不同步。

原因及解决方案：

表二

策略发布到非预期集群

问题：策略生效范围出错。

原因：Puppet Master入口文件统一为site.pp，由于策略分组多，在灰度发布阶段，相应分支也会很多，运维工程师很容易操作出错。

解决方案：将site.pp作为一个策略模块进行管理，策略模块中包含默认default分组，以及需要灰度发布的分组。manifest文件夹下的site.pp只需include该模块即可。

图7 site.pp优化后default分组策略

图8 策略发布灰度阶段分组

功能监控发现所同步的文件非预期

问题：Master采用集群方式部署，在策略变更期间多台Master上数据可能不同步，此时，同一Agent拉取到的文件可能不一致 。

原因：由于有多台Master，其中一台Master没有更新文件，LB通过轮询策略进行转发，当Agent请求Master时是Master A，再拉取文件时请求的可能是Master B，两台Master数据不一致。

解决方案：LB策略更新为源IP哈希。