微服务环境如何设计用户友好的监控系统？随着微服务设计广泛应用

随着微服务设计广泛应用，系统中各服务逐步趋向职责单一化，相对应单服务开发门槛逐步降低。但系统整体架构越来越复杂，高可用性逐步走到软件设计中心位置。
在经典软件工程理论中，高可用性主要通过三种手段实现：
1、预防：有软件设计层面的负载保护 / 事务等, 以及主动发现 (如测试 / 混沌工程) 等。 2、检测: 有运营环境对服务进行监控等。 3、恢复：有 (部署) 冗余服务 (异常发生时切换) ，服务回滚等。
由于微服务的复杂性，系统正式上线前经过完备性测试变的越来越有挑战。除了业务系统自身设计，监控系统也逐步变成系统高可用的基础保障。监控系统的用户大部分是技术开发或则产品经理，其中许多人本身就是系统专家，在运营中易遇挑战，使监控系统设计有其自身独特性。
本文以腾讯互娱 AMS 监控系统的演进为基础探讨如何设计一个微服务环境下用户友好的监控系统。 (腾讯互娱 AMS 游戏营销系统承担了腾讯游戏大部分营销活动，下文中监控系统主要指腾讯互娱 AMS 游戏营销系统的监控系统)监控系统 (设计) 演进主要有三个方面:
1、监控方法体系 (本文讨论重点)2、监控系统用户交互 (本文讨论几个相关原则)3、监控系统的技术架构 (限于篇幅，本文简单介绍)
监控方法体系演进主要经过以下几个重要节点:
文章插图
早期基于阈值配置，如异常数据绝对值，所占比例以及环比 / 同比倍数。阈值适用异常数据有明确指标意义，如敏感告警，达到一个固定很小值即告警，又如机器负载，强行规定达到 60% 就告警，不管达到 60% 之后负载继续上升或下降。阈值配置好处实现相对简单，一定程度方便用户基于阈值自定义。
当微服务广泛应用，阈值配置方法遇到一些挑战：
1、微服务中伴随服务节点增加，服务间交互也增加。监控收到上报数据呈笛卡尔乘积式 (各服务上报数 * 服务数) 增加。阈值配置工作量增加，使用管理成本高。
2、微服务各节点上报数据指标意义不再清晰，不能区分提醒 / 普通 / 严重等级别，或有些数据本身就是统计类信息，跟告警关系不大。其中原因各异，主观原因: 微服务设计增加系统服务数量，降低了开发门槛，系统涉及开发人员多，统一规范成高。
客观原因: 由于系统复杂，业务开发有时不清楚异常在整个系统严重等级。如对这些上报数据简单配置阈值监控，易形成告警骚扰，易淹没重要告警信息。
2、在游戏业务中，用户访问数量往往以天为周期，在一天以内有规律波动。下图为某指标一天趋势：
文章插图
在这种场景若对上报数据简单阈值监控，意义不大。如: 对某服务超时进行阈值设置监控，设为 50/ 分钟。晚高峰时，在线用户量大，超时可能因为资源紧张引起， 50/ 分钟或可接受。而在凌晨流量低谷 50/ 分钟很有可能是系统故障引起。设比例阈值？比如 1‰ ，流量峰值时若某台机器一个进程发生异常或者业务小量灰度，超时由于量小很可能异常淹没于大流量中，即达不到告警预设比例阈值。当然也可加一些完善措施，如计算上报数据 IP 分布。总体而言不理想。
针对阈值配置监控这些问题，系统采用基于曲线变化多层检测，基本做到业务只需上报数据，不需设置阈值。
采用分层检测方法后，阈值配置和告警收敛得到比较好解决。系统在运营中遇到有些服务在正式运营前比较难进行完备性测试，或即使正式运营也不能保证服务能及时发现自身异常。而这些服务往往是系统关键点，一旦异常未能及时发现，易发生现网故障。针对这种情况采用对关键节点做逻辑验证。如对关键服务输入输出进行旁路验证。这些逐步演化成系统关键节点逻辑验证 (部分类似测试工作) 。
随着系统运营时有遇到告警漏报。漏报常见场景:

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

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