那么这三类有优劣之分吗?其实没有，这里的方式都是针对于不同场景的，例如对域名的监控，就可以通过该域名的外部拨测来达到监控的目标，域名的访问耗时也可以通过不同的拨测点来监控。在我们腾讯内部QQ和Qzone两个海量业务对这三类监控都应用到了。

　　监控的类型

　　从大的对象范畴与层级关系来说，监控一般分为5种类型：

　　基础监控：这里的基础监控囊括范围比较广主要指IAAS层(服务器、系统、网络等)

　　服务端监控：一般指的是后台服务了，例如QQ的后台消息服务

　　客户端监控：一般指app了，手Q的客户端与微信的客户端。

　　WEB监控：一般指站网站了，例如对网站域名的拨测。

　　用户端监控：一般指用户舆情监控，例如某个APP的口碑好坏

　　监控的目标

　　一个好的监控体系应该要达到以下三点目标：

　　全：监控对象的广度，监控点的覆盖率，例如上文提到的5种对象类型是否都能覆盖到

　　快：监控的性能，数据流的处理能力

　　准：智能分析与收敛、监控对象收拢

　　监控的本质

　　在DevOps中，运维、开发、测试这三个角色应该视角统一，这里为什么说要视角统一，就是大家在监控这个层面关注的点应该是一致的，而不是你关注你的点，我关注我的点。例如所有的业务监控都可以抽象出三个核心指标：请求量、成功率、耗时。这三个关键指标来判断我们服务的可靠性，通过可靠性可以推算出可用性，并且可以间接反映用户使用我们产品的的体验。例如如果服务的可靠性不好，那么用户的产品体验肯定不会好。

　　监控的目的

　　通过对上文的一些概念介绍，其实我们已经可以推导出应用监控告警的目的，就是持续优化业务服务质量，并建设质量体系。同样织云监控也是为了打造质量体系的闭环路径。

　　监控告警的产品属性

　　监控告警是一款数据类属性的产品，既然是数据类产品，那么在产品设计的时候一定要注意这样的路径闭环 数据生产-> 数据增值–>数据消费，围绕着这样的路径我们就可以勾勒出很多的用户故事，用户故事就是针对具体的角色，会有什么具体的活动，这个活动所产生的价值。

　　这里举个简单的例子，来说明数据生产与数据消费。随着后面详细的讲述产品建设过程中会更加详细的阐述这个闭环的路径。

　　数据生产：例如一台服务器上报的各种基本的OS指标数据，例如CPU使用率，内存使用量等。这就产生了若干待消费的原始数据，那么我们能用这些数据干什么呢?

　　数据消费：对这些上报的原始数据整理可以用作视图展示，例如图形化展示该服务在最近一个小时的cpu使用率。 又或者对这些原始数据设定阈值，当超过某个阈值的时候，就产生告警通知。这些都是最直接的消费的场景。

　　我们在延伸一步对于这些消费场景产生的告警数据，是否可以在进一步消费呢?答案是可以的，例如对若干承载Cpu计算型业务的服务器所产生的cup使用率告警(生产)时间进行分析统计(消费)，是不是可以基本推导出该业务的服务高峰期是大概在那个时间范围呢?

　　这里想说明的是多数原子数据并无单一的消费或者生产的属性，而是要取决于在具体的场景与所处的数据链条中的角色。

　　并且监控告警的数据加上特定的流程(ITSM)也可以驱动监控告警+自动化的大的业务逻辑交互闭环，这个场景容我先买个关子，随着后面的叙述会再次提及到这部分。

　　监控体系