在工作中或多或少接触过部分监控工具的构建，开发和完善。结合自己的一些看法，简单地谈下一个完整的监控系统所包含的组件，欢迎大家补充。
从监控的层面来看，一个比较完整的监控系统应该包含如下的层次：
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，发送至对应业务的对应负责人。
本文出自 “菜光光的博客” 博客，请务必保留此出处
生活是一段奇妙的旅行，就在那一去无返的火车上。
