- 监控的方式：主动、被动、旁路(比如舆情监控)
- 监控类型： 基础监控、服务端监控、客户端监控、 监控、用户端监控
- 监控的目标：全、块、准
- 核心指标：请求量、成功率、耗时
万丈高楼平地起
本章主要介绍一些关于监控的通用方法论，我们先理清一些基本概念。
-
监控的定义是什么？
-
监控的方式是什么？
-
监控的类型有哪些？
-
监控的目标是什么？
-
监控的本质是什么？
-
监控的目的是层面？
-
监控的产品属性如何理解？
监控的定义
通过技术手段发现服务异常，持续优化业务可用性与用户体验。这句话的关键词是 发现持续优化可用性与体验。
监控的方式
主动：程序内部埋点，服务主动上报自身的运行情况，一般都是具化为业务的各个属性或者指标，这种方式准、快，灵活性好，指标丰富。但是在非标准框架下会有一定的代码改造成本。
被动：无需埋点，从外部探测或获取服务的运行情况，例如ping探测、日志采集分析等等。
旁路：与程序逻辑无关，对服务质量与口碑的监控，例如舆情分析。
那么这三类有优劣之分吗？其实没有，这里的方式都是针对于不同场景的，例如对域名的监控，就可以通过该域名的外部拨测来达到监控的目标，域名的访问耗时也可以通过不同的拨测点来监控。在我们腾讯内部QQ和Qzone两个海量业务对这三类监控都应用到了。
监控的类型
从大的对象范畴与层级关系来说，监控一般分为五种类型
基础监控：这里的基础监控囊括范围比较广主要指IAAS层(服务器、系统、网络等)
服务端监控：一般指后台服务，例如QQ的后台消息服务
客户端监控：一般指app，手Q的客户端与微信的客户端。
WEB监控：一般指网站，例如对网站域名的拨测。
用户端监控：一般指用户舆情监控，例如某个APP的口碑好坏
监控的目标
监控的本质
在DevOps中，运维、开发、测试这三个角色应该视角统一，这里为什么说要视角统一，就是大家在监控这个层面关注的点应该是一致的，而不是你关注你的点，我关注我的点。例如所有的业务监控都可以抽象出三个核心指标：请求量、成功率、耗时。这三个关键指标来判断我们服务的可靠性，通过可靠性可以推算出可用性，并且可以间接反映用户使用我们产品的的体验。例如如果服务的可靠性不好，那么用户的产品体验肯定不会好。
-
全：监控对象的广度，监控点的覆盖率，例如上文提到的5种对象类型是否都能覆盖到
-
快：监控的性能，数据流的处理能力
-
准：智能分析与收敛、监控对象收拢
监控的目的
通过对上文的一些概念介绍，其实我们已经可以推导出应用监控告警的目的，就是持续优化业务服务质量，并建设质量体系。同样织云监控也是为了打造质量体系的闭环路径。
监控告警的产品属性
监控告警是一款数据类属性的产品，既然是数据类产品，那么在产品设计的时候一定要注意这样的路径闭环 数据生产→数据增值→数据消费，围绕着这样的路径我们就可以勾勒出很多的用户故事，用户故事就是针对具体的角色，会有什么具体的活动，这个活动所产生的价值。
数据生产：例如一台服务器上报的各种基本的 OS 指标数据，如 CPU 使用率，内存使用量等。这就产生了若干待消费的原始数据，那么我们能用这些数据干什么呢？
数据消费：对这些上报的原始数据整理可以用作视图展示，例如图形化展示该服务在最近一个小时的 CPU 使用率。 又或者对这些原始数据设定阈值，当超过某个阈值的时候，就产生告警通知。这些都是最直接的消费的场景。
我们再延伸一步对于这些消费场景产生的告警数据，是否可以再进一步消费呢？答案是可以的，例如对若干承载 CPU 计算型业务的服务器所产生的cup使用率告警(生产)时间进行分析统计(消费)，是不是可以基本推导出该业务的服务高峰期是大概在那个时间范围呢？
这里想说明的是多数原子数据并无单一的消费或者生产的属性，而是要取决于在具体的场景与所处的数据链条中的角色。
并且监控告警的数据加上特定的流程（ITSM）也可以驱动监控告警+自动化的大的业务逻辑交互闭环，这个场景容我先卖个关子，后面的叙述会再次提及到这部分。
体系，泛指一定范围内或同类的事物按照一定的秩序和内部联系组合而成的整体，是不同系统组成的系统。其实这个描述是有些抽象的，咱们用大白话套用监控体系来解读下。
对于一个有一定体量的公司，需要一些不同的监控系统，通过系统与系统间的内部交互来组成一个大的整体，从而完成对不同场景下的监控需求即监控体系。用我们内部来举例说，我们内部在现网上跑的监控系统也有快10套了，同样在构建体系时关键的部分也是要用动态的视角去看待这些系统所产生的数据，而不是每个系统都是一个孤立的数据孤岛。下图是织云整体的监控体系。