构建一个比较完善的监控系统

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

构建一个比较完善的监控系统

科技小先锋 2017-11-14 03:03:00 浏览708
展开阅读全文
在工作中或多或少接触过部分监控工具的构建,开发和完善。结合自己的一些看法,简单地谈下一个完整的监控系统所包含的组件,欢迎大家补充。

从监控的层面来看,一个比较完整的监控系统应该包含如下的层次:

1.网络层面
主要包含各个机房间网络状况,机房内机器网络状况,通过开源的工具smokeping可以做到

2.主机层面
对于网络设备来说,包括cpu,内存,端口速率,流量等

对于服务器来说,从硬件到系统层面都要进行完善的监控,底层的比如raid卡状态,磁盘容量使用状态,inode使用状况,是否只读,是否有坏道,内存使用,网卡是否百M,网卡流量等。
再上面比如负载,cpu使用,磁盘io,操作系统参数,文件描述符,网络连接数,队列,系统日志等等,现在用的比较多的工具是zabbix,nagios和cacti。

3.应用层面可用性监控
包括进程的状态,端口的状况,存活的检查等,比如监控nginx,需要监控nginx的端口状态,进程是否存活,监控dns,需要监控端口,进程,还可以监控记录是否正常解析。
这些可以简单地通过zabbix实现。

4.应用层面性能监控
在应用层仅仅做可用性的监控是不够的,还要对应用的性能做监控,这就需要用户对应用的性能影响点有深入的了解。比如监控redis,需要监控redis的cpu使用情况,cache的效率等。
监控tomcat这种jvm容器,需要监控java heap,gc,java thread等相关信息。这类监控数据也可以集成搭配zabbix里面来做

5.服务的可用性
简单地来说就是业务正不正常,这个可以在业务上线的时候统一提供一个监控url来做检测,判断url的返回码或者是内容来判断服务是否正常。提供的检测url要做一些可用性方面的简单地判
断,比如如果应用用到了redis就要去操作一下redis。这一层的监控可以通过自己开发一个小的监控程序来实现(目前我们是通过pycurl+nagios+django+bootstrap来做的)。

6.服务的qos监控
服务的可用性监控有了,服务的质量状况也需要监控。
这个又包括服务器端的和面向用户的。
1)服务器端的数据一般是通过分析访问日志来实现,比如域名的nginx的响应时间分布,平均响应时间,服务的状态(2xx,3xx,4xx,5xx占的比例),平均body size大小状况,各个pool的调用状
况,具体到省市的qos等等。
服务器端的数据也分为实时的和离线的,实时的可以借助flume+hadoop+impala或者storm的流式计算框架来实现(各个域名的nginx日志),离线的数据可以通过hadoop + hive来实现(商业cdn qos数据)

2)面向用户的数据是通过在页面埋点来实现的,通过在页面中埋入js代码,可以在用户访问页面时,将所需要的数据通过url的形式记录在访问日志上,然后交由后端处理。


通过分析服务器端的和面向用户的qos数据相结合,可以很清楚的了解到网站的qos状况。

7.安全方面的监控
又包括主机层和服务层,比如webshell检测,主机入侵检测,后门检测,文件校验等等。

8.最后就是业务上的监控了,这个没怎么接触过,就不写了

监控的数据有了之后就是报警的问题了,这里我们倾向于:

1.通过一个中心化的事件处理平台来处理报警信息,集成cmdb的信息,把报警信息分组,定义级别并发送至相关责任人处理

2.报警邮件要包含足够多的信息,比如具体到一个域名的http code不正常,需要在报警邮件中有breakdown到http code,server,url等的相关信息,这样,报警处理人就可以快速的定位到问题。

最后附一个之前画的一个基于zabbix的一个监控的流程图:
1)用户提交监控配置和脚本至puppet server,并关联cmdb的业务和puppet的module,由puppet 实现zabbix agent的部署,更新,reload。
2)用户通过zabbix api一键式添加模板,服务器根据主机名,运行应用自动link到对应的模板,主机组等。
3)使用zabbix的server-proxy结构,zabbix agent使用passive的模式,proxy使用active的模式,由proxy负责收集数据,sync到server。
4)server的db做ms高可用,并将slave中zabbix的历史数据(history*表,trends表)通过sqoop导入hadoop集群,load至hive中归档。
5)用户可以基于hive中的历史数据做性能分析和容量规划报表。
6)zabbix server负责报警产生,并通过消息机制发送至事件处理中心,事件处理中心关联cmdb,发送至对应业务的对应负责人。

spacer.gif174507765.png


本文转自菜菜光 51CTO博客,原文链接:http://blog.51cto.com/caiguangguang/1344826,如需转载请自行联系原作者

网友评论

登录后评论
0/500
评论
科技小先锋
+ 关注