微服务环境如何设计用户友好的监控系统？

随着微服务设计广泛应用，系统中各服务逐步趋向职责单一化，相对应单服务开发门槛逐步降低。 但系统整体架构越来越复杂，高可用性逐步走到软件设计中心位置。

在经典软件工程理论中，高可用性主要通过三种手段实现：

1、预防：有软件设计层面的负载保护 / 事务等, 以及主动发现 (如测试 / 混沌工程) 等。 2、检测: 有运营环境对服务进行监控等。 3、恢复：有 (部署) 冗余服务 (异常发生时切换)，服务回滚等。

由于微服务的复杂性，系统正式上线前经过完备性测试变的越来越有挑战。除了业务系统自身设计，监控系统也逐步变成系统高可用的基础保障。监控系统的用户大部分是技术开发或则产品经理，其中许多人本身就是系统专家，在运营中易遇挑战，使监控系统设计有其自身独特性。

本文以腾讯互娱 AMS 监控系统的演进为基础探讨如何设计一个微服务环境下用户友好的监控系统。(腾讯互娱 AMS 游戏营销系统承担了腾讯游戏大部分营销活动，下文中监控系统主要指腾讯互娱 AMS 游戏营销系统的监控系统) 监控系统 (设计) 演进主要有三个方面:

1、监控方法体系 (本文讨论重点) 2、监控系统用户交互 (本文讨论几个相关原则) 3、监控系统的技术架构 (限于篇幅，本文简单介绍)

监控方法体系演进主要经过以下几个重要节点:

早期基于阈值配置，如异常数据绝对值，所占比例以及环比 / 同比倍数。阈值适用异常数据有明确指标意义，如敏感告警，达到一个固定很小值即告警，又如机器负载，强行规定达到 60% 就告警，不管达到 60% 之后负载继续上升或下降。阈值配置好处实现相对简单，一定程度方便用户基于阈值自定义。

当微服务广泛应用，阈值配置方法遇到一些挑战：

1、微服务中伴随服务节点增加，服务间交互也增加。监控收到上报数据呈笛卡尔乘积式 (各服务上报数 * 服务数) 增加。阈值配置工作量增加，使用管理成本高。

2、微服务各节点上报数据指标意义不再清晰，不能区分提醒 / 普通 / 严重等级别，或有些数据本身就是统计类信息，跟告警关系不大。其中原因各异，主观原因: 微服务设计增加系统服务数量，降低了开发门槛，系统涉及开发人员多，统一规范成高。

客观原因: 由于系统复杂，业务开发有时不清楚异常在整个系统严重等级。如对这些上报数据简单配置阈值监控，易形成告警骚扰，易淹没重要告警信息。

2、在游戏业务中，用户访问数量往往以天为周期，在一天以内有规律波动。下图为某指标一天趋势：

在这种场景若对上报数据简单阈值监控，意义不大。如: 对某服务超时进行阈值设置监控，设为 50/ 分钟。晚高峰时，在线用户量大，超时可能因为资源紧张引起，50/ 分钟或可接受。而在凌晨流量低谷 50/ 分钟很有可能是系统故障引起。设比例阈值？比如 1‰，流量峰值时若某台机器一个进程发生异常或者业务小量灰度，超时由于量小很可能异常淹没于大流量中，即达不到告警预设比例阈值。当然也可加一些完善措施，如计算上报数据 IP 分布。总体而言不理想。

针对阈值配置监控这些问题，系统采用基于曲线变化多层检测，基本做到业务只需上报数据，不需设置阈值。

采用分层检测方法后，阈值配置和告警收敛得到比较好解决。系统在运营中遇到有些服务在正式运营前比较难进行完备性测试，或即使正式运营也不能保证服务能及时发现自身异常。而这些服务往往是系统关键点，一旦异常未能及时发现，易发生现网故障。针对这种情况采用对关键节点做逻辑验证。如对关键服务输入输出进行旁路验证。这些逐步演化成系统关键节点逻辑验证 (部分类似测试工作)。

随着系统运营时有遇到告警漏报。漏报常见场景:

• 监控检测逻辑不完善，没有发现上报数据异常。这个主要通过持续优化监控逻辑来不断完善。
• 业务服务漏报数据，在生产环境中漏报原因各异。
• 业务配置问题，一般业务服务无法完全判断配置内容正确性。
• 灰产对系统非法侵蚀，如工作室对游戏道具的刷取。

针对上述情况，选取业务系统关键指标监测。如: 服务流量变化，系统输出（在游戏营销常见道具实时发放变化）。也可采用主动探测业务或心跳机制避免漏报，但具体实现可能比较重。构造现网正式请求有可能随着时间该请求会失效，有一定维护成本，特别在微服务场景监测服务多。若业务提供专门接口供探测，涉及业务改造，同时探测结果不一定准确。(在对监控系统自身监控，由于相对闭环以及作为最基础监控，则采用主动探测结合心跳机制)。这些关键指标检测逐步演化成跟安全有交集的业务监控。

当告警达到精准有效（即召回率和精确率达到比较理想平衡），就需在告警触发时，给出根因分析，以及建议处理方法。这需将各种告警信息以及系统变更信息 (业务发布，扩缩容等) 进行联动，分析出告警原因以及建议处理方案。

当监控系统比较稳定，与业务系统形成平衡。监控需根据现网运营，对业务设计和运营给出合理建议和反馈。

上述是监控系统演进大致脉络。具体系统实现过程并不严格按照上述线性发展。如上文提到的，除了监控方法发展，监控系统自身生技术架构也需要不断升级。随着技术发展，技术选型相应变化。如实时计算框架不断升级，监控引擎开发语言从 C/C++ 演化到 Go 等。

如上所述监控从早期基于阈值配置的单层监控逐渐演化成适用于微服务环境的立体多维监控体系的分层架构。

监控体系从下往上依次 (智能贯穿这五层，每一层呈不一样体现):

1. 资源监控层
2. 系统监控层
3. 逻辑监控层
4. 业务监控层
5. 综合监控层

第一层：资源监控层，主要对业务消耗资源进行监控，如 CPU/ 内存 / 网络 / 硬盘 / 网卡饱和度等。该层重点需知道资源相关故障影响范围和可能恢复时间，并及时通过告警信息总线将相关异常通知其它监控层，方便业务定位异常原因以及主动采取措施，如隔离相关故障。早期这一层监控相对简单，明确。随着云时代和微服务设计方式广泛应用，资源自身演化成服务，监控遇到挑战也越来越多。

第二层：系统监控层，主要使用业务系统上报数据 (如错误码，耗时等) 触发告警。该层监控设计者需要熟悉业务系统设计原理，服务架构 Topo，技术选型原因以及可能需要重点监控模块。系统故障根因往往需从这层相关数据解释，验证，因而通常采用白盒监控方法。该层监控类似业务系统的影子系统，是整个监控体系实现架构和逻辑最重一层。该层与业务开发人员交互最多，大多数告警治理发生在这一层。具体实现可根据系统服务不同功能采用不同监控方法。如网关类型服务就需将网关上下游服务衔接起来。该层智能主要体现告警收敛和故障定因。

下面介绍一种分层检测方案，异常检测按以下分类：

1. 一级敏感类，只要出现即告警，比较常见权限，动态语言解析错误等
2. 二级敏感类，异常产生以分钟为单位聚合告警
3. 小量升级类，异常随着时间积累到一定量触发告警
4. 陡变检测类，上报数据发生异常突变触发告警。
5. 震荡升级，服务质量不稳定触发告警
6. 自愈恢复检测，对查询类延迟告警，以判断是否恢复
7. 周期性检测，检测异常是否有周期规律
8. 其它

基本做到业务开发只需要负责数据上报和检测类型，不需手工设置阈值。

这一层是整个监控体系基石，需在该层发现系统大多数异常。该层也比较容易对业务设计形成反馈。若系统经常故障，可以确认故障是否集中，是否存在系统的短板服务，抑或系统整体设计是否合理。如服务告警容易漏报，确认监控系统设计能否覆盖该类型异常数据，或该服务数据上报是否规范。

第三层: 逻辑监控层，该层跟测试关系比较密切，采用方法是白盒和黑盒之间类似灰色，即了解系统实现逻辑，做一些针对性验证。比如针对游戏营销中限量服务旁路验证，对涉及支付类业务对账。这一层实现难度比较大，具体实现往往带有策略。

第四层: 业务监控层，该层对系统输出关键指标 (比如流量变化，在游戏营销场景下道具发放量) 进行监控，一般采用方法通常是黑盒法。检测方法有一定通用性。

该层和系统监控层形成互补。如: 业务不上报异常数据，系统监控层不能发现业务异常。但比较严重异常，业务输出关键指标往往会突然变化，这时业务监控层就能不依赖业务上报轻松发现系统异常。反过来，如果业务系统有机器宕机或者灰度新版本等引起异常，这是往往有可能系统关键指标变化不明显，但是业务上报异常数据往往能有从零到一定数量突增，系统监控层就能发现这个异常。这一层相当部分工作是数据分析。

第五层：综合监控层，这一层主要通过获取用户反馈发现异常，或周边相关系统告警。

现网故障往往是因变化引起：如业务版本更新，外部流量变化，业务资源调整。监控需主动接入各种变更信息。监控最主要工作就是检测系统变化，并判断是不是异常。主动规范变更流程: 在一些时间点，如假期或 (吃) 饭点尽量减少系统特性变更，如需变更尽量事先通知相关同事。

告警根因分析也需通过告警信息总线将各种变更信息和各层告警信息汇总。如业务监控层和综合监控层一般是不能单独给出根因分析，必须结合其它几层以及变更信息才能给出告警合理分析。

监控作为现网运营系统，也存在失效可能性，即监控系统不工作。通常有以下情况：

• 监控自身异常以及监控 (发布) 变更引起
• 监控所用基础服务异常
• 外部变更引起，如业务大促引起流量陡增等

除完善监控程序健壮性设计 (如业务流量突增，在基本不影响监控功能前提下，进行削峰限流)，同时需对监控系统进行监控，即引入元监控。

元监控指对监控系统进行监控的系统，可以用实现机理和部署环境不同的一个独立监控系统，对监控系统进行监控。元监控也可用独立第三方监控系统。元监控需支持监控系统上报心跳，对监控系统主动查询，以及查询。通过一些简单指标查询，能确认当前监控系统正常工作。业务系统异常通过 (立体) 监控体系收敛，(立体) 监控体系收敛到元监控，元监控收敛到人 (监控系统运营开发人员)。

监控即使健壮 / 智能也离不开人的主动查询。理想的监控系统需要人查询发现系统异常概率很低，即监控系统异常能主动发出告警通知相关人员，开发运营人员只要很低频的查询监控系统，以确定监控系统正常运营。系统监控层 / 逻辑监控层 / 业务监控层除了互补，本身也有冗余防止单层失效。

监控系统设计除了需要建设立体监控体系，同时也需设计合理的用户交互。没有合理用户交互设计，有可能使强大的监控体系不能发挥理想作用。伴随监控系统演进，与用户的交互也在不断演化。下面结合运营实践讨论几个相关设计原则。

1. 整体设计原则，避免打补丁式增加功能。如：在系统运营中时有告警没及时处理，造成现网故障。一种常见建议: 如异常还在，每隔一定时间持续告警。这种方案相对容易实现。但对监控系统整体设计可能不理想。一方面会骚扰那些及时处理异常用户，另一面多出告警有可能淹没其它重要告警。会陷入告警多收敛，处理不及时增加告警……收敛告警……增加告警……。这种场景因分析告警不及时处理原因。

告警不及时处理常见情况:

• 告警没有触达实际责任人
• 告警接收人不清楚告警严重程度，疏忽相关告警处理。

第一种情况与监控线下治理结合，确保告警准确到相关责任人。第二种情况可以增加其它维度告警补充。如系统层告警增加业务层告警补充。当业务开发收到系统层告警，不清楚严重程度，此时若业务层告警显示系统关键输出指标异常告警，就能引起相关人员重视。尽量避免头痛医头，脚痛医脚。

2. 结合异常恢复检测对告警收敛，合理取消业务恢复提醒，形成告警触发立刻处理，不需处理尽量不触发原则。短时间 (如 1 分钟) 恢复不影响业务（如查询服务），可不触发告警，仅在系统记录，供相关运营人员定时 review。若反复发生则触发告警。关键服务 (如跟用户相关写操作) 异常一旦发生，立刻触发告警，避免等业务恢复。

3. 平衡告警灵敏性和完整性。敏感并且意义明确的告警 (如内部服务没有权限调用) 可以秒级触发告警。对一些复杂告警 (如内部多个模块超时场景)，适当延迟，给出超时原因。以免相关人员即使第一时间收到不完整告警信息，还需花更多时间定位异常原因。

4. 报警触达到责任人时，图形展示当前变化趋势以及历史变化趋势，并能进行实时查询。

一个用户友好的监控系统不但需持续技术升级改进，也需与用户一起协作建立合理流程规范。