【原创】小型互联网公司内部监控解决方案


闲话

写这篇博客来记录下这两三个月来的所学所感。

目前市面上,有许许多多互联网公司,对于类似BAT那种级别的,我们就不说了。那种刚起步,刚经历第一轮融资或者投资的小型互联网公司比比皆是。当这些公司业务量上来的时候、用户量上来的时候,总是会有一个担忧,之前运行稳定的公司平台架构能否继续稳定的服务下去,或者哪一块地方需要重构。单凭平常的人工去分析日志看代码,其实是没什么用的费时且费力,结果也不准确。

这时,大家就会有一个统一的想法,就是怎么不去弄一个监控系统,把公司内部所有的业务接口、访问流量等等的东西全部都监控起来,然后再分析分析,看看哪里耗时最严重的,哪里的调用并发最高,哪个时段的CPU承受不住了等等,暴露出这些问题,再高薪聘请几个有大公司架构经验的架构师过来重新整理架构,一个个击破,帮助公司走上高富帅的道路。

那这个监控系统到底谁来做呢?一是由自己来开发,二请人来开发。

我们的选择是自己来开发。原因:

  • 公司内部的业务比较复杂,自己人做出来的监控能对症下药
  • 公司发展不错,招来大牛带领我们一起搞,技术这块不虚
  • 招来大牛已经花了不少钱了,再去外面找人外包,老板虚

 

监控思路

让业务接口、服务器等需要监控的地方,实时上报耗时、调用次数、错误抛出、CPU承载等信息,服务器端接受这些信息,对这些信息进行归类、分析、持久化等操作,通过一个监控报表的web站点显示分析结果、历史数据、告警操作等。


 

具体模块

通过上述的思路,已经大概了解要搞这个监控需要做哪些事情了吧。那就细化出以下这几个模块[根据各个公司的具体业务而定制]:

  • PhpSDK:供公司php相关业务上报监控数据到ApiService
  • JavaSDK:供公司java相关业务上报监控数据到ApiService
  • ApiService:提供支持高性能、低消耗的上报接口,供sdk端上报数据,并且按规则收集这些数据寄存到redis中
  • MonitorStorage:读取redis中的数据,进行峰值分析、是否按告警策略告警、统计等操作,并且把这些数据持久化到mysql中
  • Web站点:实时读取mysql中整理好的监控数据信息,以图示、表格等方式来向被监控方展示各种信息,并可以在上面配置被监控方的所有统计策略、告警策略等等

流程图如下:


 

要点事项

首先,你的监控是负责给人家监控的,不能影响人家的正常业务和效率。所以这样sdk在设计开发的时候,就必须轻量化再轻量化,都给我异步操作,意思就是说sdk就是埋个点而已,简单通过CURL上报一下数据,不需要给我返回什么,我们业务这边也不管你搞什么,就是多你这一行垃圾代码而已,几乎可以忽略的那种,这样你的SDK就是完美的。

还有,就是ApiService的性能要求非常高,因为当接入你的监控系统的业务越来越多的时候,高可靠性、高并发性是必须的,只有当所有上报成功的数据的成功率到达99.9999%的时候,你的ApiService也是吊飞了。

MonitorStorage中文就是监控存储,负责将数据分析、并且持久化,因为最后web那边数据是你这里持久化到mysql中的,所以准确性是很重要的,还有怎么样保证数据的实时同步、告警措施、分析措施是如何进行的都是需要考虑的。

报表那边的话,就是做的好看一点,功能齐全一点了。折线图什么的图示插件推荐用Highcharts或者国产百度团队的ECharts插件也是非常不错的。


个人心得

第一期的监控系统已经在生产环境开跑了,这两天都在观察、优化、各项测试进行中,希望我负责的MonitorStorage模块坚强的挺住!!!让数据量、并发量来得更猛烈些吧!

BB完了,继续搬砖了!

如有雷同,纯属巧合

 

posted @ 2016-03-09 17:37  马叉虫  阅读(2784)  评论(16编辑  收藏  举报