Puppet 是基于 C/S 架构的集中配置管理系统，基于自有描述性语言，可以实现对配置文件、用户、定时任务、软件包、系统服务等管理，保证大规模集群基础配置一致性。
我们用 Puppet 管理了上千台服务器，经过多次优化监控，自动化灰度发布保证了所有集群基础配置一致性。本文探讨了如何对 Puppet 系统进行监控，也将典型问题和解决方案一并分享给大家。
监控选型
Foreman 提供了较全面的交互设施，包括 Web 前端、CLI 和 RESTful API。在此基础之上，可以构建监控管理系统，以及实现报警等功能。
核心业务流程
可以简单将 Puppet 的工作流程抽象为四部分：
-
请求阶段：Agent 基于 SSL 将自身信息发送给 Server；
-
响应阶段：Server 基于客户端信息解析相应的配置，并最终将伪代码（catalog）发送回 Agent；
-
执行阶段：Agent 接收 catalog 并执行命令或者更新文件；
-
汇报阶段：Agent 把结果汇报给 Server。
监控概览
对 Puppet 的核心监控主要覆盖如下环节：
-
Agent 与 Master 通信是否正常；
-
Agent 策略执行是否生效；
-
Puppet 发布的策略生效时间及范围；
-
Master 及其所管理集群的运行状态。
黑盒监控
Puppet 黑盒监控指标不符合预期，说明集群不能正常工作或出现异常，黑盒监控指标有：所有策略是否都生效，策略生效范围是否符合预期，策略生效结果是否符合预期。
所有策略是否都生效
说明：将一批测试节点，加入到线上 Puppet 集群，通过定期运行检查脚本验证所有策略是否都生效。
策略生效范围
说明：策略上线后，需要确认其生效范围是否符合预期，即策略是否仅在指定的节点生效。
实现：通过 Puppet 模块 MCollective 定时执行检查任务（检查实际生效的机器列表和服务树机器列表是否一致），如下图，集群 hn-xdata 有 98% 的机器符合预期，2% 不符合。
策略生效结果是否符合预期
说明：策略上线后，需要确保所有策略在所有机器都生效。
实现：通过 Puppet 模块 MCollective 定时执行检查任务，（检查实际生效的机器列表和服务树机器列表是否一致），如下图，每一个策略有一张饼图。
白盒监控
白盒监控是黑盒监控的补充，服务于故障定位，从集群容量、流量、延迟、错误四个方面梳理。
数据采集方式：
-
通过 Foreman API
-
Master 日志分析
容量
Master 所在实例的 CPU，网络连接数指标，网卡
流量
Agent PV，基于 Puppet Master 的访问日志 puppetserver-access.log 来计算流量
延迟
单个 Agent 更新策略需要的时间：puppet_report_time_total
说明：puppet_report_time_total 是 Agent 从连接 Master 到发送报告给 Master 总时间，0-3s 的占 50%，0-11s 的占 90%，0-15s 占 99%。
错误
-
No reports：没有报告的实例数量；
-
Error agent：执行策略出错的实例数量；
-
Out of sync：执行策略超时、主机名重复、主机连不上 Master 的实例数量。
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 该模块即可。
功能监控发现所同步的文件非预期
问题：Master 采用集群方式部署，在策略变更期间多台 Master 上数据可能不同步，此时，同一 Agent 拉取到的文件可能不一致 。
原因：由于有多台 Master，其中一台 Master 没有更新文件，LB 通过轮询策略进行转发，当 Agent 请求 Master 时是 Master A，再拉取文件时请求的可能是 Master B，两台 Master 数据不一致。
解决方案：LB 策略更新为源 IP 哈希。
本文经授权转自公众号京东云，原文链接为：
注册/登录 InfoQ 发表评论