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

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

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

监控体系

本部分接昨天的内容继续。

对复杂度要节制

监控的输入是建立在其他应用程序的输出上的，监控系统本身就是一项复杂的工程项目，监控系统应避免任何不确定的功能：如试图自动学习阈值或自动检测故障原因等。

监控系统应保持简单，便于在故障报警后，可以依靠高效的事后统计整合界面简单定位和深入调试，必须能被运维团队中任何一个人所理解。

复杂是没有止境的，尽量避免对不同的延迟阈值，不同的中位数，基于各种指标进行分别报警配置，避免根据故障可能的原因构建对应的监控台页面、脚本、自动处理等，不然复杂度和相关性很快超出人的理解，经常出现监控系统的各种问题，监控系统的变更也会变的非常困难，维护起来难度很大。

监控简化原则1：最能反映真实故障的规则应该越简单越好，可预测性强，要非常可靠。

监控简化原则2：不常用的数据收集、汇总以及警报配置应该定时删除。

监控简化原则3：收集到的信息，但是没有暴露给任何监控台，或者被任何警报规则使用的应该定时删除。

监控中指标的收集和汇总，加上报警和监控台展示，作为一个相对独立的系统运行比较好。这些与其它复杂系统相结合（性能统计、进程调试、异常或崩溃跟踪，负载测试、日志收集和分析、流量检测等）成复杂系统会导致监控过于复杂，容易出现问题。各模块保持松耦合接口是更好的策略。

误报控制

紧急警报的处理会占用员工的宝贵时间，如果该员工正在工作时间段，该警报的处理会相断他原本的工作流程。如果该员工正在家，紧急警报的处理则会影响他的个人生活，甚至是把他从睡眠中叫醒。当紧急警报出现得太频繁时，员工会进行“狼来了”效应，怀疑警报的有效性甚至忽略该警报，以至于忽略了真实发生的故障，无效信息太多，分析和修复可能会变慢，故障时间也会相应延长。高效的警报系统应该提供足够的信息，并且误报率非常低。

当为监控系统和警报系统增加新规则时，回答以下问题以减少误报的自检问题

必要性：该规则是否能够检测到一个目前检测不到的、紧急的、有操作性的可见故障可忽略性：是否可以忽略这个警报？什么情况可能会导致用户忽略这条警报，如何避免用户体验：这条警报是否确实显示了用户正在受到的影响？是否存在用户没有受到影响也可以触发这条规则的情况？可操作性：收到警报后，是否要进行某个操作？是否需要立即执行该操作或可以延迟多久？该操作是否可以被安全的自动化？操作的效果是长期的短期的？通知范围：是否也会有其他人收到相关的紧急报警，这些紧急报警是否是不必要的。

报警数量控制

紧急警报设置原则

警报应是需要进行某种操作，每天不能进行过多，太多会有“狼来了”效应警报应是可以具体操作的警报的消除应该需要某种智力分析过程，而不是固定的机械动作。机械处理不应是紧急报警。每个紧急警报应该是关于某个新问题的，而不是上一个问题的关联问题

补丁式处理控制

监控系统需要跟随不断演变的软件一起变化，一些不常见的警报可能很快就变成一个经常触发、需要临时处理的琐事。应尽快找到根源问题，如果找不到就要想办法自动化处理这条警报，但这种打补丁式的自动处理会增加系统复杂度，管理者应记入系统债务本，继续支持和优先处理这些长期修复问题的工作，因为通过一些补丁可以使一个不稳定的系统保持一定的高可用性，但这种方案通常不能持久。相对的接受可控制的可用性降低可以换取一些系统长期性的提升。管理人员应对系统实际健康状况、运维压力有全面了解，运维人员应拿捏这种补丁式处理过程的数量。

回应管理

监控系统应有报警的回应管理，规定时间内没有人员回应则自动升级，以及自动升级管理

传统监控系统：探针模式+图形趋势展示，探针是监控系统的一部分。

时间序列监控系统：将收集时间序列信息作为监控系统的首要任务，利用时间序列信息操作语言，将该语言数据转化为图表。是海量信息收集和中央化规则计算、统一分析和报警的模型。

时间序列监控系统保持了系统监控项和监控系统的松耦合模式，使得被监控系统可以独立于监控系统报警规则之外自由扩展。同时这些报警规则都基于一种抽象的time-series模型也更易于维护。保证监控系统的维护成本与服务部署规模呈非线性相关增长是非常关键的。

监控埋点方式：每个服务都默认包含一个HTTP服务，应用程序利用编程接口将内部变更暴露出来或简单加工。使用HTTP服务，而不是像传统监控系统使用SNMP服务。该方法实际上就是把白盒监控变相的变成了黑盒监控。

被监控变量的表示：zone（数据中心名）_service（服务类别）_job（服务器类型名）_instance(实例）_time-series(时间序列）_var（变量值）

监控系统的建设我们就聊到这里，明天我们开始聊聊监控体系的分布式链路追踪。