云“战疫”：8天扩容100万核，我们是这样跟踪的

常见的监控手段为阈值监控，对业务形态比较熟练的开发、运维人员在指标上设置一个“恰当”的阈值，一旦偏离阈值，系统即发送告警到开发人员。

然而阈值设置的合理性不易判断。在数千万、上亿用户的场景下，阈值少设或多设 0.01% 都代表数千、上万人的体验受损，而且不同时间的数据，数据也会呈现一定的周期规律性，如图二所示，简单的阈值告警显然无法满足多样化的业务需求。

c. 问题发现的第一时间，开发、运维人员迫切需要知道问题的表现根因。以便快速介入处理，如何准确发现根因？

业务故障时，在大盘面，可能看到的是整个成功率（或用户量）的下降。但引起下降的可能性是较多的。必须在第一时间找到原因，深入排查，以减少业务故障时间。

监控的存在是为业务服务的，团队一起进行了碰头，很快形成了解决方案并实施：

梳理重点模块、重点指标。建立直观的业务可观测性

基于业务架构剖析、业务形态理解，我们梳理起若干个关键指标。所谓关键即业务生死指标，这些指标可以从以下维度来衡量：

1、对用户有损

用户有损的指标有：在线用户量，用户登陆成功率，用户进房成功率，关键接口调用成功率…

2、对收入有损

购买成功率、付费成功率、收入趋势等 ……

3、资源风险相关

分SET、分模块CPU负载、出口带宽等、以便及时介入调度。一般每个SET的容量是有限的，必须及时观察各SET容量水位及负载趋势，一方面系统自行进行SET间用户调度，一方面人为可在必要时进行调度干预。

（编辑：核心网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!