qiurunze123/tydeus-monitor

tydeus-monitor 一种为监控而生的日志解决方案【4.30-V1】

一、监控是什么？

"监控"多种多样，网上一搜，花样百出，每个公司都会有自己的监控系统，大部分的功能都为监视+报警系统，很少有业务控制和系统控制的相关功能 监控范围我个人理解分为几大类型

• 资源【CPU、内存】使用率等
• 系统监控【系统波动异常】
• 排查监控 【开发排查工具】
• 网络安全监控【黑客攻击】
• 视频监控 【家用 开个玩笑】

本文所讲监控为业务系统相关监控

一、监控目的是什么？

个人理解，其目的通常无外乎下面三点：

• 查看系统状况：如 进线量、完结率指标等
• 查看系统是否健康、运行是否良好？
• 查看系统是否存在异常，作为后续是否需要介入进而恢复正常的依据 2、监控需要做什么 假设你现在需要去判断一个业务系统是否运行良好，你需要做什么？

（1）首先，怎么才算是“运行良好”？判断依据是什么？ 如果是开发同学，通常可能会去看CPU、内存、网络等资源利用率情况，以及HSF、MetaQ等中间件的QPS、RT、线程池等技术指标

如果是业务/运营/产品同学，他可能会去看诸如进线量、case完结率、卡片点击量等业务指标

（2）其次，运行良好的判断标准是什么？ 举个栗子： 比如，有个人说他可能发烧了，那么怎么知道他是真的发烧呢？大家都知道去测体温，正常成年人的体温通常在36.5度到37.5度之间，如果一直超出37.5度，那基本就是发烧无疑了。 所以，我们的判断标准可以是： 通过判断一个或一组指标的是否持续超出一定的范围，来判断系统是否运行良好。

三、怎么做监控？

通过前面发烧的例子，我们知道：

1、一个完整的监控包括： 1~N个指标，以及这些指标的“正常”范围。持续超出这个指标范围，那就是系统生病出现了状况了。 2、那么，要想知道业务系统是否运行良好，我们就需要做3件事： （1）首先，收集相关指标数据 从系统层面看：集团已经提供了非常稳定的采集系统

资源资利用率：CPU、内存、IO等资源利用率，网络重传率、拥塞状况等指标 中间件指标：HSF接口的 QPS、RT、线程池资源使用率等，MetaQ的队列堆积情况、消息消费速率等 从业务层面看：

虽然，HSF等中间件已经提供了接口等层级的监控指标；但在实际业务场景中我们还需要关注产品功能、业务模块级的一些监控指标。 （2）其次，确定良好的判断标准 针对系统指标、中间件指标，集团早已确定了相关判断标准，每个应用系统虽略有差异，但都是大同小异，此处不再赘述 针对业务指标，这个就需要通过对产品、模块进行一段时间的指标数据采集观察方可确定了。 针对异常指标，通常可以看一段时间的业务处理成功率、系统处理成功率等指标。偶发的异常，不代表系统就是真的病了，就像偶尔抽筋一下，不代表就有病，如果经常抽筋，那就得去找医生看看了。

（3）最后，通报异常状况 人非机器，不能实时盯着监控指标，看看系统是否正常、是否异常。正常情况，大家估计也不需要关心了。异常情况那肯定是需要多加关注的，集团提供的各种监控系统以及中间件已提供非常完善的告警通知方案，想必短信、邮件、钉钉也把大家烦的不行了吧。 四、我们的监控实现 1、确定监控内容： 目前系统层级、中间件层级集团已经提供丰富稳定的监控解决方案，那么对于我们这种业务型系统就把重点放在产品功能、业务模块层级的监控上面。

2、确定监控指标： 业务指标：

对于访问量等业务量指标我们可以通过产品功能、业务模块层级的调用PV、QPS计算得出 对于完结率、转化率这些指标，本质上都是百分比计算，我们可以通过采集分子、分母数据计算得出，这里我们只要采集 成功、失败，异常 三种数据即可 技术指标：

虽然要看产品功能、模块级的业务指标，但是这些模块的QPS、RT、处理成功率也是需要关注的 另外，为了方便排查问题，处理失败/系统异常的数据也是经常需要的，比如 traceId、异常类型、异常堆栈等 3、确定采集方案： 日志采集已经有比较成熟的产品，所以我们采用日志接入，配合告警波动

4、确定监控位置： 产品是一堆功能的集合，功能是一堆处理模块的集合，处理模块是一堆方法的集合。所以，方法是业务逻辑承载的最小单位，同时在系统中，业务模块、服务通常也都是通过一个个内部的方法或者对外的接口方法提供出来的。因此，我们在方法层级做监控日志的采集即可