ITPub博客

首页 > 架构设计 > 操作系统 > Puppet监控速查手册:问题/原因→解决方案

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

原创 操作系统 作者:京东云 时间:2018-12-06 16:30:36 0 删除 编辑


导语

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


本期作者:木槿

京东云

应用研发部

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/,如需转载,请注明出处,否则将追究法律责任。

请登录后发表评论 登录
全部评论

注册时间:2018-10-12

  • 博文量
    13
  • 访问量
    4507