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

  1. 云栖社区>
  2. 博客>
  3. 正文

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

从此启程 2018-09-11 10:00:00 浏览590
展开阅读全文

前言

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

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

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

理想中的分布式监控

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

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

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

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

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

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

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

如何设计一款实用的监控

统一的调用链id

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

时间戳

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

异步传输

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

延时聚合

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

最后的难点

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

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

本篇暂时写到这里结束。

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

作者:从此启程/范存威

出处:http://www.cnblogs.com/fancunwei/

本文版权归作者和博客园共有,欢迎转载,但未经作者同意必须保留此段声明,且在文章页面明显位置给出原文链接。如文章对您有用,烦请点个推荐再走,感谢! 本博客新开通打赏,鼠标移到右侧打赏浮动处,即可赏博主点零花钱,感谢您的支持!

网友评论

登录后评论
0/500
评论
从此启程
+ 关注