本节内容
- 为什么要做监控?
- 常用监控系统设计讨论
- 监控需求讨论
- 如何实现监控服务器的水平扩展?
- 监控系统架构设计
一、为什么要做监控?
- 熟悉IT监控系统的设计原理
- 开发一个简版的类Zabbix监控系统
- 掌握自动化开发项目的程序设计思路及架构解藕原则
二、常用监控系统设计讨论
成熟的监控
- Zabbix
- Nagios/cacti
- ganglia
- openfalcon go
三、监控系统需求讨论
1.可监控常用系统服务、应用、网络设备等
网络层
- 网络质量
- 流量,丢包率、带宽
系统层
- cpu
- disk
- ram
- load
- port
应用层
- mysql 连接数
- nginx 并发数
- cdn 命中率
- 页面是否被篡改
业务逻辑层
- 每小时订单数
- 当前在线用户
2.一台主机上可监控多个不同服务、不同服务的监控间隔可不同
服务A:
- cpu 30
- disk 90
- load 120
服务B:
- cpu 45
- ram 60
- mysql 20
3.同一个服务在不同主机上的监控间隔、报警阈值可不同
报警阀值:
- 重要的服务 cpu使用率超过80%就报警,要抄送给CTO
- 不重要重要的服务 cpu使用率超过100%报警,给运维工程师
4.可以批量的给一批主机添加、删除、修改要监控的服务
监控模板
linuxservices
- cpu
- disk
- memory
5.告警级别:
-
不同的服务 因为业务重要程度不同,如果出了问题可以设置不同的报警级别
- 重要的服务,cup使用率打到80%,就报警
- 普通的服务,cup使用百分之98%,报警
-
可以指定特定的服务或告警级别的事件通知给特定的用户
- 重要的服务,抄送给CTO
- 不重要的只发送给运维工程师
-
告警的升级设定
- 发送给底层运维工程师没处理,就发送给运维经理
- 再过半个小时没处理,就发送给cto
-
报警合并
有一个报警池,有一个脚本对池的分析
6.历史数据 的存储和优化
- 实现用最少的空间占用量存储最多的有效数据
- 如何做到1s中之内取出一台主机上所有服务的5年的监控数据?
监控数据的处理
1、存下来,趋势图
大数据分析 ,视角越大,越失真
时间越长,越失真
2、报警处理
7. 数据可视化,如何做出简洁美观的用户界面?
8.如何实现单机支持5000+机器监控需求?
- 列式存储
- redis 支持集群,数据量大加机器就可以
9.采取何种通信方式?主动、被动?
1、server 主动 监控 客户端
- 好处:不用装客户端,使用所有的网络设备,snmp,配置简单
- 坏处:服务器压力大,不适合大型网络环境,不能监控复杂的指标
2、server 被动 接收 客户端
- 好处:大型网络环境、监控复杂的指标、扩展能力强
- 坏处:装客户端、网络设备不适用、维护起来相对复杂一点
3、主流的:混合式
1、客户端知道监控什么指标?
客户端主动去问服务器我要监控什么
2、客户端扫描本地所有服务,全部汇报给服务器
openfalcon把机器上所有能检测到的都抓上[2014年自动检测到(支持一千多项)]
四、如何实现监控服务器的水平扩展?
1、采用什么架构?
•Mysql
- 数据量太大,mysql超过1千万条查询起来就特别慢,
- 我在看趋势图时前端要查好几分钟,为什么zabbix的那么快?
- 他们是怎么做的?zabbix优秀是在2000-3000台还可以,要是上万台就会太慢
- 不要把你的监控数据存到mysql,因为会存在很多的问题
•主动通信? Snmp,wget…
server 主动 监控 客户端
- 好处:不用装客户端,使用所有的网络设备,snmp,配置简单
- 坏处:服务器压力大,不适合大型网络环境,不能监控复杂的指标
•被动通信?Agent ---how to communicate with the monitor server
server 被动 接收 客户端
- 好处:大型网络环境、监控复杂的指标、扩展能力强
- 坏处:装客户端、网络设备不适用、维护起来相对复杂一点
总结:主流的的还是混合模式好
•Socket server –> Sockect client
不可以,很多坑
•能否用现成的c/s架构? Rabbit mq, redis 订阅发布, http ?
2、采用HTTP好处
1.接口设计简单
2.容易水平扩展做分布式
3.Socket稳定成熟,省去较多的通信维护精力
3、Http特性:
1.短连接
2.无状态
3.安全认证
4.被动通信
五、监控系统架构设计