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

当告警达到精准有效（即召回率和精确率达到比较理想平衡），就需在告警触发时，给出根因分析，以及建议处理方法。这需将各种告警信息以及系统变更信息 (业务发布，扩缩容等) 进行联动，分析出告警原因以及建议处理方案。
【微服务环境如何设计用户友好的监控系统？】当监控系统比较稳定，与业务系统形成平衡。监控需根据现网运营，对业务设计和运营给出合理建议和反馈。
上述是监控系统演进大致脉络。具体系统实现过程并不严格按照上述线性发展。如上文提到的，除了监控方法发展，监控系统自身生技术架构也需要不断升级。随着技术发展，技术选型相应变化。如实时计算框架不断升级，监控引擎开发语言从 C/C++ 演化到 Go 等。
如上所述监控从早期基于阈值配置的单层监控逐渐演化成适用于微服务环境的立体多维监控体系的分层架构。
文章插图
监控体系从下往上依次 (智能贯穿这五层，每一层呈不一样体现):

资源监控层
系统监控层
逻辑监控层
业务监控层
综合监控层

第一层：资源监控层，主要对业务消耗资源进行监控，如 CPU/ 内存 / 网络 / 硬盘 / 网卡饱和度等。该层重点需知道资源相关故障影响范围和可能恢复时间，并及时通过告警信息总线将相关异常通知其它监控层，方便业务定位异常原因以及主动采取措施，如隔离相关故障。早期这一层监控相对简单，明确。随着云时代和微服务设计方式广泛应用，资源自身演化成服务，监控遇到挑战也越来越多。
第二层：系统监控层，主要使用业务系统上报数据 (如错误码，耗时等) 触发告警。该层监控设计者需要熟悉业务系统设计原理，服务架构 Topo ，技术选型原因以及可能需要重点监控模块。系统故障根因往往需从这层相关数据解释，验证，因而通常采用白盒监控方法。该层监控类似业务系统的影子系统，是整个监控体系实现架构和逻辑最重一层。该层与业务开发人员交互最多，大多数告警治理发生在这一层。具体实现可根据系统服务不同功能采用不同监控方法。如网关类型服务就需将网关上下游服务衔接起来。该层智能主要体现告警收敛和故障定因。
下面介绍一种分层检测方案，异常检测按以下分类：

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

基本做到业务开发只需要负责数据上报和检测类型，不需手工设置阈值。
这一层是整个监控体系基石，需在该层发现系统大多数异常。该层也比较容易对业务设计形成反馈。若系统经常故障，可以确认故障是否集中，是否存在系统的短板服务，抑或系统整体设计是否合理。如服务告警容易漏报，确认监控系统设计能否覆盖该类型异常数据，或该服务数据上报是否规范。
第三层: 逻辑监控层，该层跟测试关系比较密切，采用方法是白盒和黑盒之间类似灰色，即了解系统实现逻辑，做一些针对性验证。比如针对游戏营销中限量服务旁路验证，对涉及支付类业务对账。这一层实现难度比较大，具体实现往往带有策略。
第四层: 业务监控层，该层对系统输出关键指标 (比如流量变化，在游戏营销场景下道具发放量) 进行监控，一般采用方法通常是黑盒法。检测方法有一定通用性。
该层和系统监控层形成互补。如: 业务不上报异常数据，系统监控层不能发现业务异常。但比较严重异常，业务输出关键指标往往会突然变化，这时业务监控层就能不依赖业务上报轻松发现系统异常。反过来，如果业务系统有机器宕机或者灰度新版本等引起异常，这是往往有可能系统关键指标变化不明显，但是业务上报异常数据往往能有从零到一定数量突增，系统监控层就能发现这个异常。这一层相当部分工作是数据分析。
第五层：综合监控层，这一层主要通过获取用户反馈发现异常，或周边相关系统告警。