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

周期性检测，检测异常是否有周期规律

其它

基本做到业务开发只需要负责数据上报和检测类型，不需手工设置阈值。
这一层是整个监控体系基石，需在该层发现系统大多数异常。该层也比较容易对业务设计形成反馈。若系统经常故障，可以确认故障是否集中，是否存在系统的短板服务，抑或系统整体设计是否合理。如服务告警容易漏报，确认监控系统设计能否覆盖该类型异常数据，或该服务数据上报是否规范。
第三层: 逻辑监控层，该层跟测试关系比较密切，采用方法是白盒和黑盒之间类似灰色，即了解系统实现逻辑，做一些针对性验证。比如针对游戏营销中限量服务旁路验证，对涉及支付类业务对账。这一层实现难度比较大，具体实现往往带有策略。
第四层: 业务监控层，该层对系统输出关键指标 (比如流量变化，在游戏营销场景下道具发放量) 进行监控，一般采用方法通常是黑盒法。检测方法有一定通用性。
该层和系统监控层形成互补。如: 业务不上报异常数据，系统监控层不能发现业务异常。但比较严重异常，业务输出关键指标往往会突然变化，这时业务监控层就能不依赖业务上报轻松发现系统异常。反过来，如果业务系统有机器宕机或者灰度新版本等引起异常，这是往往有可能系统关键指标变化不明显，但是业务上报异常数据往往能有从零到一定数量突增，系统监控层就能发现这个异常。这一层相当部分工作是数据分析。
第五层：综合监控层，这一层主要通过获取用户反馈发现异常，或周边相关系统告警。
现网故障往往是因变化引起：如业务版本更新，外部流量变化，业务资源调整。监控需主动接入各种变更信息。监控最主要工作就是检测系统变化，并判断是不是异常。主动规范变更流程: 在一些时间点，如假期或 (吃) 饭点尽量减少系统特性变更，如需变更尽量事先通知相关同事。
告警根因分析也需通过告警信息总线将各种变更信息和各层告警信息汇总。如业务监控层和综合监控层一般是不能单独给出根因分析，必须结合其它几层以及变更信息才能给出告警合理分析。
监控作为现网运营系统，也存在失效可能性，即监控系统不工作。通常有以下情况：

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

除完善监控程序健壮性设计 (如业务流量突增，在基本不影响监控功能前提下，进行削峰限流) ，同时需对监控系统进行监控，即引入元监控。
元监控指对监控系统进行监控的系统，可以用实现机理和部署环境不同的一个独立监控系统，对监控系统进行监控。元监控也可用独立第三方监控系统。元监控需支持监控系统上报心跳，对监控系统主动查询，以及查询。通过一些简单指标查询，能确认当前监控系统正常工作。业务系统异常通过 (立体) 监控体系收敛， (立体) 监控体系收敛到元监控，元监控收敛到人 (监控系统运营开发人员) 。
监控即使健壮 / 智能也离不开人的主动查询。理想的监控系统需要人查询发现系统异常概率很低，即监控系统异常能主动发出告警通知相关人员，开发运营人员只要很低频的查询监控系统，以确定监控系统正常运营。系统监控层 / 逻辑监控层 / 业务监控层除了互补，本身也有冗余防止单层失效。
监控系统设计除了需要建设立体监控体系，同时也需设计合理的用户交互。没有合理用户交互设计，有可能使强大的监控体系不能发挥理想作用。伴随监控系统演进，与用户的交互也在不断演化。下面结合运营实践讨论几个相关设计原则。
1. 整体设计原则，避免打补丁式增加功能。如：在系统运营中时有告警没及时处理，造成现网故障。一种常见建议: 如异常还在，每隔一定时间持续告警。这种方案相对容易实现。但对监控系统整体设计可能不理想。一方面会骚扰那些及时处理异常用户，另一面多出告警有可能淹没其它重要告警。会陷入告警多收敛，处理不及时增加告警……收敛告警……增加告警…… 。这种场景因分析告警不及时处理原因。