小型互联网公司内部监控解决方案

[架构设计]小型互联网公司内部监控解决方案

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

目前市面上，有许许多多互联网公司，对于类似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完了，继续搬砖了！

如有雷同，纯属巧合

原文地址http://www.3fwork.com/b300/000924MYM025677/