Puppet监控速查手册：问题/原因→解决方案

导语

基于京东云丰富的实战经验，我们将陆续分享运维方面的干货，帮助小伙伴们进阶为运维达人，欢迎持续关注。首先带来的是“监控”专题系列。

本期作者：木槿

京东云

应用研发部

Puppet是基于C/S架构的集中配置管理系统，基于自有描述性语言，可以实现对配置文件、用户、定时任务、软件包、系统服务等管理，保证大规模集群基础配置一致性。

我们用Puppet管理了上千台服务器，经过多次优化监控，自动化灰度发布保证了所有集群基础配置一致性。本文探讨了如何对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获取采集的白盒指标概览

指标	说明
No reports	没有汇报的主机
Error	连上了但是执行策略出错
Out of sync	执行策略超时；主机名重复；主机连不上
Active	Agent拉取策略正常
Pending	容量指标，Master处理不过来
No changes	Agent正常拉取策略但是没有变更
puppet_report_time_total	Agent执行策略总时间
Pv	每分钟访问量

容量

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报不同步。

原因及解决方案：

表二

原因	解决方案
主机名重复	修改Agent Hostname后重新认证
主机认证后重命名	直接在Foreman控制台中删除原名称认证的机器
Agent服务异常	在Agent上重启Puppet服务
Agent磁盘打满	清理磁盘后，Agent会自行启动并恢复
Agent端证书error	在Agent上删除/etc/puppetlabs/puppet/ssl文件夹后，执行puppet agent –t重新认证
Agent端puppet.conf文件为空	将相应的[Agent]配置写入puppet.conf文件中即可恢复
Master端puppe.conf文件为空	将相应[Master]配置写入puppet.conf文件中即可恢复
Foreman服务down掉	在Foreman机器上执行service httpd restart、service foreman restart
Could not request certificate	1)Agent与Master时间不同步，ntpdate master –IP同步时间；2)Agent与Master端网络不通；3)Master端8140端口不通

策略发布到非预期集群

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

原因：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哈希。

来自 “ ITPUB博客 ” ，链接：http://blog.itpub.net/31557889/viewspace-2284410/，如需转载，请注明出处，否则将追究法律责任。

转载于:http://blog.itpub.net/31557889/viewspace-2284410/