.Net架构篇:思考如何设计一款实用的分布式监控系统？

前言

不管从最先期的unix操做系统，仍是曾经大行其道的单体式应用，仍是如今日益流行的微服务架构，始终都离不开监控的身影。如windows的任务管理器，linux的top命令，均可以看做是监控的面板。

再联系起现实生活，无处不在的路网摄像头，为交通机关监控交通人流提供了方便。

系统规模越大，越离不开监控。缺乏了监控，就像盲人摸象，窥不到全貌。

理想中的分布式监控

进入互联网时代，系统调用规模日益庞大，对监控的需求更是迫切。好比一个页面打开很慢，怎么分析哪里慢？是网站接受请求慢仍是链接数据库慢，或者消息队列挂了，或者redis请求慢？咱们须要监控系统能提供这些信息供咱们追踪分析。

因此理想中的分布式监控应该记录从请求发起那一刻，所调用的公开方法，接触过的数据库，缓存，队列等步骤，以及每一步所消耗的时间。这些都须要大量的日志去记录。

第二点，理想中的分布式监控必须是对代码无侵入，应用程序员无需对每一个方法去调用监控代码。这样彻底解藕的监控系统，才更容易使用，加入每一个方法，都要调一下监控接口，那不要累死人，代码也及其不友好。

第三点，理想中分布式监控应该对性能不形成损耗或者极小的损耗。若是流量一大，监控系统CPU飙生的话，那这个监控无疑是失败的。

第四点，许多方法有层级，方法内调用其余方法，应该能经过报表聚合查看，进入每一个方法的时间以及调用耗时，调用方法的层级树。

第五点，分布式时代，一个调用请求会横跨不少站点，理想的分布式监控应该提供调用链上全部站点的聚合报表查看，要极力避免死循环，两个站点长官相互调用的状况下，应该用双箭头代表调用关系。

第六点，能提供接入监控的服务器cpu，内存，硬盘空间等指标，并根据警惕线发送通知。这个优先级能够下降，能够借助云服务器自身提供的监控，阿里云和Ucloud都有本身的服务器监控面板。

如何设计一款实用的监控

统一的调用链id

根据软件的调用链特性，从一个请求开始到最终的结束，应该具备一个统一的调用链id。

时间戳

调用各类方法的时间也应该是顺序的，须要一个精确的时间戳，来描述调用方法的进入与离开的时间。

异步传输

为了避免影响性能，应该以异步传输，定时落库的方式。

延时聚合

若是能作到实时聚合更好，若是实现困难能够采用延时聚合报表，延时的时间应该小于一分钟。这个时间使用人群应该能接受，固然若是能缩短到几秒钟，那使用人群会更加高兴。聚合报表应首先提供最近时间内的耗时排序，能够查看调用的方法树，能够查看调用链的全部站点，其余需求能够后期开发，解决核心需求。

最后的难点

若是不追求无侵入，提供一个空接口。全部须要记录日志的实现接口，就已经达到了目标的一半。

为了完成对应用无侵入的目标，咱们首先须要一款真正的aop，即静态编织Aop，这个只据说过postsharp，为何只有它能实现？或者是相似fiddler之类的抓包工具。

本篇暂时写到这里结束。

可参考的如google dapper论文，zipkin,听云。