3.1 什么是好的监控服务

我们在工作过程中会接触到各种各样的监控服务，有功能完备的集团监控服务，也有小巧轻便的专项监控服务。作为监控服务的使用方，我们一方面享有监控服务提供的便利，另一方面也要承担维护监控服务配置的成本。在满足功能的前提下，选择合适的监控服务，才能达到事半功倍的效果。衡量监控服务是否合适，可以从以下几个角度出发。

3.1.1 稳定

稳定是监控服务重要的属性，也是监控服务的最低标准。线上业务的可用性由运维团队保障，运维团队保障线上业务的可用性依赖监控服务。如果线上故障因为监控服务的不可用而没有被运维团队发现，那么这对业务团队和运维团队都是一场灾难。

监控服务系统是一种典型的数据处理类系统，稳定性问题可能出现在数据流转的各个阶段，包含以下几个场景。

1.数据源稳定

数据源是监控服务的起点，实现的方式多种多样。例如，一些监控服务的维护者会提供一种 Agent（探针）工具，部署在监控节点上收集目标机器的运行状态。此时运维团队需要了解Agent在目标机器上的性能开销，了解Agent 在异常场景下的资源释放策略，了解Agent 的核心执行机制，以便在Agent出现故障时能快速定位问题并恢复服务。而作为Agent的服务提供方，运维团队要能保证Agent 的服务开销可控、资源申请和释放可控、Agent调度行为可控。即使在最极端的Agent服务不可用的情况下，也不能干扰目标节点下除Agent之外其他任务的正常执行。

2.网络稳定

网络稳定是监控服务常见问题之一，一方面是在内网中多网络环境之间可能存在网络连通性问题，这类问题需要运维团队同监控服务维护团队合作，打通网络之间的壁垒^[1]；另一方面是网络质量问题，这类问题在外网环境中尤其明显，外网环境容易受多种因素影响，造成网络质量大幅下降。良好的监控服务要能适配不同的网络环境，并在网络质量下降时，通过服务降级、业务容错等方式减少对监控服务使用方的影响。

3.数据处理稳定

数据处理模块承担绝大部分数据计算压力，是监控服务重要的部分。数据处理相关逻辑容易出现功能耦合放大故障、消费存在热点无法水平扩容、对外依赖复杂、可用性差等现象。良好的监控服务需要合理的架构设计和健壮的运维部署方案，针对重要功能要制订 SLA（服务质量协议），使运维团队能放心地接入监控服务。

4.存储稳定

海量监控数据要能实时写入数据存储组件，并在有需要时快速读出，这对存储服务提出了很高的要求。部分监控服务还依赖存储组件做离线报警和数据归档的情况，这又会对存储组件造成更大的压力。存储组件出现异常，轻则造成数据短时间内无法访问，重则造成数据丢失，更有甚者还会影响报警功能的正常触发。良好的监控服务会在存储稳定性方面做出充分的考量，以合理的表结构和索引设计保障数据均衡写入、快速读出，以数据多备份来防御硬件故障时的数据丢失，有条件的情况下，还可以用冷备或热备的方式部署双机房镜像存储，进一步提高存储服务可靠性。

3.1.2 准确

好的监控服务发出的报警要尽量准确，在能发现故障的前提下，减少对用户的骚扰。在日常工作中报警消息数量过多，会使运维工程师精神麻痹，出现故障时不能引起足够的重视。在故障发生时报警消息过多，会造成核心报警被淹没，不利于运维工程师发现和定位问题。

报警准确性对监控服务而言尤为重要，是运维监控领域的一个难题。报警准确性问题与实际业务场景结合后，往往会变得非常棘手。报警准确性可分为漏报和误报两类，为了压制报警数量而放松报警触发条件，会提升漏报率；而为了避免漏报而调低报警阈值，则又会造成报警过多，提升误报率。

监控服务会提供一些手段来提高报警准确性，如同环比报警、基线预测、智能抑制压缩、故障根源定位等。但仅凭监控服务提供的手段并不能彻底解决有效性问题，就像智能在监控领域的各项实践，虽然催生出很多新的处理思路，但脱离了运维工程师的干预也难以在各方面达到预期效果。Kafka服务数据消费堆积如图3-1所示。

从图3-1所示的监控曲线中可知，业务数据在Kafka服务队列内会出现明显堆积，持续一段时间后堆积数量逐渐减少，随后处于震荡波动阶段。如图3-1所示的监控曲线对于不同的业务场景，会有完全不同的异常结论。

场景一，Kafka 里存储的是用户订单数据，之后的消费业务是订单处理服务。此时这条曲线预示着两个线上故障——订单无法及时处理、用户交易失败。这两个线上故障可能是消费服务存在异常，数据消费被阻塞；也可能是用户请求数量超过消费服务处理容量上限，造成数据消费堆积。无论是哪种原因，监控服务都有必要在出现异常时发送报警通知运维团队。

场景二，Kafka 里存储的是用户操作日志，之后的消费业务是离线日志处理服务。消费业务把Kafka当作缓存队列暂存数据，数据在Kafka内堆积符合业务预期。在这种情况下，监控服务就不应该对短时间内数据堆积情况太敏感，这种报警发送给用户是无意义的。

因此，要提高图3-1中对应业务的报警准确率，需要运维团队从业务的角度提供更多配置信息。

综上所述，报警准确率的提高是监控服务和运维团队合作的结果，运维团队要向监控服务表达被监控业务的特征，监控服务要将业务特征转化成各种报警能力，最终体现在提高报警准确率方面。理想的报警是要结合业务数据的实际情况，使用多种指标维度，再结合监控服务提供的各种抑制机制，最终在漏报和误报之间达到最佳平衡。

3.1.3 易用

好的监控服务系统要易于使用。监控服务系统是典型的 ToB 系统（面向企业级用户），ToB 系统通常要求有强大而又复杂的功能以满足在各类业务场景下的复杂需求。但强大而又复杂的功能往往会降低产品的易用性，好的监控服务能在功能复杂性和产品易用性上达到良好的平衡。

监控服务系统是运维团队在日常工作中频繁使用的系统之一，无论是监控配置还是故障排查都离不开监控服务系统。随着业务规模扩大、复杂度提升，运维团队的线上运维压力也在持续增加。对于新增资源，运维团队要使用监控服务系统配置监控服务；对于现存资源，运维团队要跟随业务负载变化和结构调整，维护原有监控配置以保证监控有效。

维护监控配置对运维团队而言是个“体力活”，当需要运维的资源太多时，精细化运维每个资源将变得非常困难，如一个运维工程师要负责上千个应用和上万台机器的运维工作。监控服务系统有必要在产品易用性方面做更多的设计和思考，减少运维工作的压力。例如，自动发现监控实例，能减少新增资源接入监控服务的工作量；场景化监控模板，能快速为某类应用增加多维度监控能力；批量修改监控配置，能减少相似应用配置复杂度；无阈值报警，能减少监控阈值的新增和调整工作量。

易用的监控服务系统总是为运维团队做了很多工作，在使用者提供必要信息后，就能输出一定质量的监控服务。只有选择这样的监控服务系统，才能使运维的工作事半功倍。