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

前言

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

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

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

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

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

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

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

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

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

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

统一的调用链id

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

时间戳

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

异步传输

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

延时聚合

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

最后的难点

如果不追求无侵入，提供一个空接口。所有需要记录日志的实现接口，就已经达到了目标的一半。

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

本篇暂时写到这里结束。

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