Chinaunix首页 | 论坛 | 博客
  • 博客访问: 39470
  • 博文数量: 5
  • 博客积分: 192
  • 博客等级: 入伍新兵
  • 技术积分: 70
  • 用 户 组: 普通用户
  • 注册时间: 2011-03-01 21:24
文章分类

全部博文(5)

文章存档

2011年(5)

我的朋友

分类: 系统运维

2011-03-07 00:18:18

监控系统的核心模型OSV模型是监控系统的骨髓,是开发监控系统最基本的核心数据结构,可谓万变不离其中。今天我们来谈谈监控系统的骨骼部分,监控体系的四层监控模型。

监控是运营的核心和基础,手段是将所有与运营相关的关键监控对象都监控起来,例如我们要监控设备有没有宕机、服务器负载有没有跑高、网络有没有中断、服务有没有崩溃、服务质量有没有达到用户期望、SLA有没有达到等等不一而足。不同行业所要监控的监控对象集不同,为了满足特定行业的运营需要我们必须对监控对象集进行定制。

在分析OSV模型时,我们发现监控对象绝非是离散孤立可以独立决策的,监控对象间是有层级依赖关系的。为了构建完善的监控体系,确保我们精准掌握运营状况并精确发现运营异常和风险,我们除了必须对监控对象集进行定制外,还必须理清各监控对象间的决策依赖关系。

今天我们介绍的四层模型是一个框架,适用于大部分互联网行业运营监控体系的构建。基于此框架,与公司业务结合我们就可以清晰定义出该业务运营所必须的监控体系。

监控体系的四层模型如下图所示:

业务层  |

服务层  |

网络层  |

网元层  |

 

网元层:针对我们的网元设备(服务器、交换机、路由器等)做硬件和系统级别的监控,例如:

监控并及时发现硬件的异常状况,例如磁盘坏掉、cpu过热、磁盘耗尽、硬件配置和规划不符等情况;

监控并及时发现系统异常状况,例如宕机、负载过高、流量异常、内存使用率异常等情况;

 

网络层:针对网元所在的网络环境做监控。例如:

监控机房内部的网络状况,及时发现异常;

监控机房间的网络状况,及时发现异常;

监控机房到最终用户间的网络状况,及时发现异常;

区分机器宕机和不可达状况;

 

服务层:针对业务相关的一些应用服务(例如apacheftpmysql等)做监控,例如:

监控进程存活及耗费资源状况;

监控提供服务的能力;

根据本层和下层的监控数据,判断服务健康状况;

对于不能提供服务的情况及时报警;

 

业务层:业务级别的监控,例如:

从用户的角度检测产品提供服务的能力;

SLA监控;

根据本层和下层的监控数据,判断产品的健康状况;

对于不能提供服务的情况及时报警;

 

上述四层模型是构建完整监控体系的指导框架,同时对监控系统的架构设计具有重指导意义。

四层模型中,上层监控对象的报警决策依赖于下层监控对象的状态,而最下层监控对象的状态可以独立决策。在设计大型监控系统时,我们就可以已经此特性设计立体式决策的监控系统提升决策速率,从而打造高效的智能监控系统。

目前的众多开源监控系统基本上都不能完美支持立体监控体系的概念,像nagioszabbix虽然通过Trigger实现了依赖检测功能,但远不能满足复运营需要。另外,开源监控系统没有一个能真正切合运营视角进行监控和报警展现的,当然这不是开源监控系统的错,是需求特殊性使然。因此,想要好用高效的监控系统,必须自主开发。

阅读(2460) | 评论(1) | 转发(0) |
给主人留下些什么吧!~~

terencewk2011-03-30 15:47:55

很多监控都是搞了一堆,报警出来都不知道该怎么处理。
有层级概念,将来就可以组合,可以做真正的运营支撑,才是真正的监控平台。