关于python应用监控平台的话题

最近的更新：

先说明，这不是人人业务的监控框架，是我在以前公司参与的一个项目。。。

刚入行的时候，对于监控方面，用的是nagios和cacti。 两个都很强大的监控平台，可扩展性也都很不错。要是想用一个平台实现报警和性能信息的展示的话，他俩都需要加点东西。两个的合体可以考虑zabbix。操作和理解都挺简单的。唯一让人不爽的是存在myql里面，国外有个老外可以改到我钟爱的mongodb里面，但是我看不懂，也没有操作成功。。。 php  这个真不会。。。

后来到了大公司后，才发现他们的监控用的多种多样。。。比如业务数据的收集，他们用的更多的是ganglia、graphite之类的产品。监控的话，更多的是自己开发，或者是针对业务对开源的产品二次开发。  基本是这两种。。。

我从去年开始接触公司监控平台的项目，说来做监控平台有段时日啦。

我们的框架一改再改。。。。 我把平台的升级过程和原因给大家说下。

源地址 ：  

最开始监控的框架：

用gevent撑起并发，redis的mq通信，bottle做的web，mysql做的库，微信做的报警。

后期为了扩展做了队列系统，防止行为的堵塞和超多任务进程崩溃。。。存储方面用了mongodb。 考虑到微信接口的不稳定，又加了邮件告警。

源地址 ：  

首先把监控任务的大队列的分离，不做进程间的queue通信了。现把redis独立做队列，并做了监控点的健康状态，分布式的监控点也多了几个，可以写成多进程，也可以是部署到服务器上。

源地址 ：  

微信的接口时常的出问题和发信的次数，所以用了多个接口进行轮训并状态检测。。。

对于被动模式的监控，该项目中只是在websocket应用过。。。

小总结：

           首先要确认监控的需求，简单实现页面管理监控items，展现数据。 后期要从各方面改进性能   比如分布式集群的方式  有两种   1  监控点去 被监控点 取数据，在大量主机的情况下可能会慢，可以用队列来解决，也可以用gearman这样的任务派发系统来解决。。。  2   被监控点把数据主动给监控点。这个方法够简单，对于master来说压力也很小，但是缺点也很明显，告警的逻辑方面有点复杂。。。 在这种情况下，master要主动和client的mq进行通信，证明他是活着的，他要是怪了，那把告警的优先度升高。剩下的监控业务和系统信息 如 内存 硬盘啥的，就根据pub过来的信息，进行对比，然后自己通过api接口发微信和邮件。 方式多种多样。。。。  

我们根据需求选择适合自己的业务的监控方式，进行开发。