运维体系建设(稳定性保障体系2)

运维体系建设(稳定性保障体系2)

（本字共1969字，大约需要阅读5分钟）

监控体系

图 67监控输出

监控系统的输出可以分为警报（alert）、工单（ticket）、日志（logging）三类。

当系统无法自动修复某个问题时，需要一个人来立即调查这项警报，以决定目前是否存在真实故障，采取一定操作缓解故障，避免即将发生的问题，最终找出导致故障的根源问题。警报的目标对象是向某个人手机发送一条短信或进行现场声光报警。系统出现严重情况的警报是发送给当前值守的运维工程师的，且警报应该和值班表相关联，只向当前值守的工程师进行报警。

系统中重要但不紧急的报警形成的工单是发送给工单系统的，接受工单的用户应该执行某种操作，但是并非立即执行。如果用户在几天内执行这项操作，系统不会受到任何影响。工单的目标对象可以是向某个系统地址的一个通知，系统可以是工单系统，邮箱等。

系统中不重要也不紧急的事件记入日志系统，并在服务监控台展示使用。日志事件可备调试和事后分析，日志提供的两项基本功能是对比服务更新前后的状态变化、检查资源使用量随时间的变化情况。

注意事项：

1.借助邮箱系统容易变成噪声报警，不太重要的报警应直接页面展示，紧急的报警直接进行短信报警，明确需要处理的进入工单系统，应尽量不要使用邮箱系统参与到监控系统的输出信息中。

2.提升监控系统可用性的办法：通过故障模拟或产品事故验证。如果一个产品事故没有触发警报，它就揭示了监控系统中的漏洞。

3. 报警粒度：监控系统应该主要从高级服务质量目标层面进行报警，而不是关注业务系统或中间件的细节参数，但是也应该保持足够的粒度，可以追踪到某个具体组件。

在监控系统中一些概念需要提前了解一下：

根源问题（root cause）：指系统（软件或流程）中的某种缺陷。某一个故障情况可能同时具有多个根源问题。

节点/机器（node/machine）：指在物理机、虚拟机、或者容器内运行的某个实例。

推送（push）：关于对某个服务正在运行的软件或者其配置文件的进行的任何改动行为。

图68监控配置原则

黄金指标

黄金指标是指在监控系统中通用的监控指标，这些指标通常可以保障监控的有效性。具体指标如下：

延迟指标：指系统输入与输出的时间差。

流量：指使用系统中的某个高层次的指标对系统负载所进行的度量。对web应用通常是请求数（分类为静态和动态请求）；流媒体这个指标通常是网络IO速率，或者并发会话数量；对存储系统为每秒读写操作数量。

错误：请求失败的速度。系统的访问请求分为成功请求和失败请求两种，但请求成功后系统也可能主动返回错误，称为快错误。对应的，请求失败后的错误称为慢错误。快错误可能延迟很低，但慢错误通常代表系统正在经历更极端的情况。在Http协议中中，快错误对应（HTTP5XX类型的显式错误或http 200回复中包含的内容错误），慢错误对应请求超过（超过可能是应用原因或网络策略原因）。

在监控系统中，当跟踪协议内部的错误代码无法表达全部的失败情况时，可以利用其他信息状态来跟踪一部分特定故障情况,如http 500错误可在中间件或负载器上检测，但只有端到端的拨测工具才能检测到http 200回复中包含的内容错误。

饱和度（saturation）：代表系统容量有多“满”，通常是系统中目前最为受限的某种资源的某个具体指标的度量。很多系统在达到100%利用率之前性能会严重下降，所以监控系统中需要增加一个系统饱和度警戒线。系统延迟的增加是饱和度过高的前导现象，可以做为饱和度预警指标。饱和度警戒线可配合容量扩缩容评估时进行记录，以便对饱和度可进行预测。

长尾关注

长尾问题：系统延迟高，反应“慢”，但在统计“慢”的情况时要区分平均值的“慢”和长尾值的“慢”。如进行了100次访问请求，100次访问的平均值和100次访问排序的第50位值可能差别很大，而真正影响用户体验的往往是排序在后面的那些访问（长尾），长尾延迟的监控方法是将请求按延迟分组计数（直方图），将直方图的边界定义为指数型增长，如0-10ms，30-100ms,100-300ms等。

统计精度的配置

系统的不同部分应该以不同的精度进行度量和监控。高频率的收集、存储监控原始数据可能成本很高，可以采用及时汇总的方式降低成本。比如对一个系统指标每秒记录一次，那么一直保存这些每秒的记录会消耗很多存储空间，而且分析计算时非常缓慢，所以要及时对这些原始记录进行汇总。

汇总分为仿原始数据法和周期汇总法。

仿原始数据法：切片采样，汇总记录。如将1分钟分成60次采样，但每次记录值采用百分位中间值（适用于实时数据）

周期汇总法：将所有记录周期性的采用百分位中间值或分组统计，然后删除原始数据（适用于超过几天的数据）

监控系统的配置有很高的原则性，我们明天继续聊！晚安了。