现如今，越来越多的企业想要建设统一监控平台，但不知道从哪里开始着手。比如：
◇ 有些企业会直接将监控系统页面集成到统一监控的门户里，当作统一的监控平台。
◇ 有些企业把所有告警事件集中到统一系统里进行处理和流转。
◇ 还有些企业把所有数据比如性能数据、日志数据、事件数据接入大数据的平台，企图应用大数据平台的计算能力来完成统一监控。
如果没有明确的目标，缺少体系化的思考，这些做法会在后续使用的过程中面临各式各样的问题。
因此，我们邀请到嘉为蓝鲸产品总监苏文老师，为我们讲解建设基于数据的统一平台思路，希望能给有想建设统一监控平台的企业带来一些启发。
一、监控系统的六大核心模块
统一监控平台，说到底本质上也是一个监控系统，监控的基本能力是必不可少的，回归到监控的本质，先梳理下整个监控体系。
监控系统的本质是通过发现故障、解决故障、预防故障，从而保障业务的稳定。
监控体系一般来说包括数据采集、数据检测、告警管理、故障管理、视图管理和监控管理6大模块。
而数据采集、数据检测和告警处理是监控的最小闭环，但如果想要真正把监控系统做好，那故障管理闭环、视图管理、监控管理的模块也缺一不可。
1.数据采集
1）采集方式
数据采集一般分为Agent模式和非Agent模式。
- Agent模式包括插件采集、脚本采集、日志采集、进程采集、APM探针等。
- 非Agent模式包括通用协议采集、Web拨测、API接口等。
2）数据类型
监控的数据类型有指标、日志、跟踪数据三种类型。
◇ 指标数据是数值型的监控项，主要是通过维度来做标识。
◇ 日志数据是字符型的数据，主要是从中找一些关键字来做监控。
◇ 跟踪型数据反馈的是跟踪链路一个数据流转的过程，观察过程中的耗时是否正常。
由于数据类型不同，也衍生出三类不同的监控系统。
◇ 指标类型的监控，典型代表比如Zabbix、普罗米修斯。
◇ 日志类常见的监控系统有日志易、Splunk等，主要关注日志类数据的分析和监控。
◇ 跟踪型的系统是通过trace ID请求的过程来进行监控，即APM（应用性能监控）类型的监控，例如Dynatrace、Skywalking等。
由于三种数据互不兼容，导致数据存储分散，不利于集中分析，而近两年兴起的OpenTelemetry，将三种数据格式的输入和消费实现了统一，但并没有解决存储和分析的问题。
目前主流解决方案还是将三类数据存储到不同的库中，再封装一层统一的查询层，屏蔽数据存储层的差异，实现集中的分析查询。
3）采集频率
采集频率分秒级、分钟级、随机三种类型。常用的采集频率为分钟级。
- 关于分钟级与秒级
越来越多的客户开始对秒级有一种执念，觉得越快越好，认为越快就能更快发现问题。但是秒级的采集频率的增加，这对目标机器性能的影响也会增加，若因为数据采集导致业务性能本身出现问题，这就本末倒置了。
而且，随着数据量加倍，存储成倍增加，计算量级指数型增长，带来的成本损耗可能远超秒级监控带来的好处。在真实的应用场景中，大家需要思考使用秒级频率是否值得。这提前十几秒的告警发现，运维人员是否能够在这十几秒的时间内把问题解决掉，如果解决不掉，那秒级监控并没有太大的意义。比如腾讯游戏的业务是以秒来赚钱，所以需要针对关键指标需要做到秒级监控，配合自动伸缩替换故障节点，可以实现秒级恢复。这种情况下的秒级监控必不可少。
秒级监控是监控系统的一种必备的能力，但并不是所有的指标数据都需要秒级监控，需要挖掘真正的场景需求来判断是否需要这个秒级监控，而不是为了秒级而秒级，白白浪费资源，徒增维护成本。
- 随机采集
随机适用于增量采集或触发式采集，采集频率不定。主要场景是日志采集、应用系统异常事件上报。
4）采集传输
采集传输可按传输发起分类，也可按传输链路分类。
◇ 按传输发起分类有主动采集Pull（拉）、被动接收Push（推）。
◇ 按传输链路分类有直连模式、Proxy传输。
其中，Proxy传输不仅能解决监控数据跨网传输的问题，还可以缓解监控节点数量过多导致出现的数据传输的瓶颈，用Proxy实现数据分流。
5）数据存储
对于监控系统来说，主要有以下三种存储供选择：
- 关系型数据库
由于数据库本身的限制，很难搞定海量监控的场景，有性能瓶颈，只在传统监控系统常用。
例如MySQL、MSSQL、DB2；典型监控系统代表：Zabbix、SCOM、Tivoli。
- 时序数据库
为监控这种场景设计的数据库，擅长于指标数据存储和计算。
例如InfluxDB、OpenTSDB（基于Hbase）、Prometheus等；典型监控系统代表：TICK监控框架、 Open-falcon、Prometheus。
- 全文检索数据库
这类型数据库主要用于日志型存储，对数据检索非常友好，例如Elasticsearch。
2. 数据检测
1）数据加工
- 数据清洗
数据清洗比如日志数据的清洗，因为日志数据是非结构化的数据，信息密度较低，因此需要从中提取有用的数据。
- 数据计算
很多原始数据不能直接用来判断数据是否产生异常。比如采集的数据是磁盘总量和磁盘使用量，如果要检测磁盘使用率，就需要对现有指标进行一个简单的四则运算，才能得到磁盘使用率。
- 数据丰富
数据丰富就是给数据打上一些tags标签，比如打上主机、机房的标签，方便进行聚合计算。
- 指标派生
指标派生指的是通过已有的指标，通过计算得出新的指标。
2）检测算法
有固定规则和机器学习算法。
◇ 固定算法是较为常见的算法，静态阈值、同比环比、自定义规则
◇ 机器学习主要有动态基线、毛刺检测、指标预测、多指标关联检测等算法。
无论是固定规则还是机器学习，都会有相应的判断规则，即常见的< > >=和and/or的组合判断等。
2. 告警管理
1）告警丰富
告警丰富是为了后续告警事件分析做准备，需要辅助信息去判断该怎么处理、分析和通知。
告警丰富一般是通过规则，联动CMDB、知识库、作业历史记录等数据源，实现告警字段、关联信息的丰富。
通过人工打Tags也是一种丰富方式，不过实际场景下由于人工成本高导致难以落地。
2）告警收敛
告警收敛有三种思路：抑制、屏蔽和聚合。
- 抑制
即抑制同样的问题，避免重复告警。常见的抑制方案有防抖抑制、依赖抑制、时间抑制、组合条件抑制、高可用抑制等。
- 屏蔽
屏蔽可预知的情况，比如变更维护期、固定的周期任务这些已经知道会发生的事件，心里已经有预期。
- 聚合
聚合是把类似或相同的告警进行合并，因为可能反馈的是同一个现象。
比如业务访问量升高，其他性能也飙升，这样把这些性能都聚合到一块，那承载业务的主机的CPU、内存、磁盘IO、网络IO等各项性能都会飙升，这样把这些性能指标都聚合到一块，更加便于告警的分析处理。
3）告警通知
- 通知到人
通过一些重要的渠道，能够触达到人。
这样在没有人盯屏的时候，可以通过微信、短信、邮件触发到工作人员。
- 通知到系统
一般通过API推送给第三方系统，便于进行后续的事件处理。另外还需要支持自定义渠道扩展（比如企业里有自己的IM系统，可以自行接入）
3. 故障管理
告警事件必须要处理有闭环，否则监控是没有意义的。
- 人工处理
这是最常见的方式，值班、工单、故障升级等。
- 经验积累
可以把人工处理的故障积累到知识库里面，为自动化处理做准备。
- 自动处理
通过提取一些特定告警的固化处理流程，实现特定场景的故障自愈，比如磁盘空间告警时把一些无用日志清掉。
- 智能分析
主要是通过故障的关联分析、定位、预测等AI算法，进一步提升故障定位和处理的效率。
4. 视图管理
视图管理也属于增值性功能，主要是满足人的心理述求，做到心中有底，面向的角色很多（领导、管理员、值班员等）。
- 大屏
面向领导，提供全局概览。
- 拓扑
面向运维人员，提供告警关联关系和影响面视图。
- 仪表盘
面向运维人员，提供自定义的关注指标的视图。
- 报表
面向运维人员、领导，提供一些统计汇总报表信息，例如周报、日报等。
- 检索
面向运维人员，用于故障分析场景下的各类数据检索。
5. 监控管理
监控管理是企业监控落地过程中的最大挑战。
前5个模块都是监控系统对外提供的服务功能，而监控管理才是面向监控系统自身的管理和控制，关注真正落地的过程的功能呈现。主要有以下几个方面：
◇ 配置：简单、批量、自动
◇ 覆盖率：监控水平的衡量指标
◇ 指标库：监控指标的规范
◇ 移动端：随时随地处理问题
◇ 权限：使用控制
◇ 审计：管理合规
◇ API：运维数据最大的来源，用于数据消费
◇ 自监控：自身稳定的保障
二、监控平台建设的现状和传统建设模式的挑战
1. 监控建设的现状
一般来说，企业监控建设的现状主要分成四个阶段：监控工具建设阶段、统一监控建设阶段、智能分析建设阶段、主动防御建设阶段，目前大部分企业都处在第一和第二阶段之间挣扎。
◇ 第一阶段的主要目标是全覆盖，能够全面监控对象，全面感知告警。
◇ 第二个阶段的核心重点在于管理，需要有统一的指标体系和统一的事件管理流程，同时也是为第三个阶段做数据的准备。
◇ 第三阶段重点关注的是效率提升，之前要配很多阈值的算法，有了智能检测算法就不需要再每个每个指标配置阈值了。而关联影响分析能够利用机器学习帮助机械能问题定位分析，减少人工定位分析的时间消耗。
◇ 第四阶段的核心是预防，提前预测来采取一些措施，去预防相关问题的发生。比如根据磁盘损耗的速率变化趋势，预测1个月后磁盘可能会坏掉，这样提前更换磁盘，将事故消灭在萌芽中。
2. 传统监控系统建设所面临的挑战
由于大部分传统监控系统在建设之初并没有考虑到统一监控，定位都是做一个监控的工具，在建设统一系统时，会面临以下困难和挑战：
◇ 技术演进快，监控复杂度日益升高；
◇ 监控工具多，统一治理无从下手；
◇ 工具互相隔离，无法联动协同，效率低下；
◇ 升级扩展慢，无法响应快速发展的业务要求；
◇ 系统复杂度高，故障分析定位难，业务损失大。
以上种种挑战都导致了企业亟待建设一个统一监控平台。
三、从两个层面建设统一监控平台
1. 产品能力上
除了需要有灵活的扩展能力，能够广泛适配各种对象的监控数据接入外，还得有统一采集、统一检测、统一告警、统一展示四个基本能力。
2. 产品架构上
主要为三层：接入层、能力层、功能层.
1）接入层
主要考虑各种数据的接入，除了本身Agent和插件的采集接入，还需要支持第三方监控源的数据接入，才能算一个完整的统一监控平台。
2）能力层
主要考虑监控的基础通用能力，包含数据采集模块、数据存储模块、数据加工模块、数据检测模块、AI分析模块。
3）功能层
功能层需要贴近用户使用场景，主要有管理、展示两类功能，在建设的过程中可以不断丰富功能场景。
另外，考虑到数据的关联关系，为未来的数据分析打下基础，监控和CMDB也需要紧密联动，所有的监控对象都应该用CMDB进行管理。
还可以配置驱动监控为指导理念，实现监控的自动上下线，告警通知自动识别负责人等场景，简化监控的维护管理。
嘉为蓝鲸统一监控平台的功能界面
1.基于CMDB的指标管理
联动CMDB，把CMBD的对象纳入到统一监控平台，并对监控对象的指标进行统一管理。至于如何去梳理构建整个监控指标体系，是接下来第4部分要讲解的内容。
2. 配置驱动监控
通过动态分组来实现，利用CMDB已知的属性来作为判断条件，去创建动态分组。
整个分组的实例是动态变化的，只有满足条件的的实例才会纳入分组，不满足时会自动剔除分组。
监控如果识别到实例数的动态变化，实现监控的自动上下线操作。
3. 插件式采集扩展
监控平台需要接受各种各样的数据，不仅支持监控对象的数据采集。还支持将第三方监控源的数据接入到平台，进行统一管理。
整个插件的设计可以直接在页面进行编辑或上传，这样扩展性会比较强，扩展也非常简单方便。
4. 模板化策略配置
强调模板化配置，根据不同的场景设置不同的模板。
比如说对测试环境，做一个主机测试环境的模板， 对生产环境做主机生产环境的策略模板，这样就减少监控配置量。
5. 集中事件中心
将前面产生的策略和告警事件在事件中心呈现，给出一些辅助信息比如指标、数据流转信息、字段等，帮助进行故障排查。
6. 动态菜单视图功能
第一个视角是资源视角，以动态菜单的形式去做，菜单根据添加的监控对象来自动生成。
第二个视角是应用视角，形式是应用监控视图。是为了在应用层面来看监控对象是否正常，应用的拓扑哪些节点发生了问题等。
四、构建指标体系的理念和规范
1. 核心理念
◇ 监控的指标体系是以CMDB为骨架，以监控指标为经脉，将整个统一监控平台的数据有机结合起来。
◇ 贯穿指标的生命周期管理，辅以指标的管理规范，保障监控平台长久有序的运行。
2. 指标管理规范
1）设计原则示例
最重要的是可度量、可采集、可理解、可消费。
落到监控指标，还有两个辅助原则，即构建统一监控指标体系规范；明确监控目标和消费场景。
2）指标分层的示例
从企业业务应用的视角出发，一般将企业监控的对象分为6层：基础设施层、硬件设备层、操作系统层、组件服务层、应用性能层、业务运营层。也可以根据企业自己的情况进行调整。
3. 指标分级规范
一般分三级，按重要程度区分：核心指标、关键指标和常规指标。
◇ 核心指标一般不会定太多，主要反映这个监控对象是活着还是死了，1到2个即可。
◇ 关键指标是看核心性能是否正常，参考谷歌定义的SRE四大常规指标。
◇ 常规指标可以根据实际的业务场景去考虑。
通过不同指标的分级、权重，可以建设模型，衡量整个业务的健康情况。
4. 命名规范示例
没有绝对的标准，可读就行，可根据企业情况自行设定。
5. 指标管理流程
目的是让整个指标的生命周期管理顺利运行下去，可以根据企业实际情况来设计相关流程。
本次直播主要讲述了四个部分，第一部分讲解了监控体系（采集-检测-告警-故障-视图-管理），第二部分讲解了现状和挑战，第三部分介绍了统一监控平台的产品设计（产品能力和产品架构两个角度），第四部分梳理了指标体系的建设管理（核心是以CMDB为骨架、以监控指标为经脉），保障统一监控平台的顺利落地。
精选互动问答
问：告警丰富阶段的处理时间，是否会影响到告警发送的及时性呢？
答：告警丰富是需要一定的时间损耗的，会影响告警发送及时性，但是相对于后期去找这些信息的时间来看，告警丰富所花时间几乎可以忽略不计，另外告警丰富之后，带来的更多信息除了可以辅助排错，还可以根据丰富的新的字段进行收敛、聚合等。
问：监控模板也是放置在CMDB吗，还是放在监控平台呢？
答：监控模板肯定放在监控平台，只不过监控模板应用的对象范围可以和CMDB联动，效果更佳
问：统一监控里包含网络性能监控吗？
答：统一监控平台是可以接入第三方网络监控系统数据的，例如Zabbix。
问：统一监控初期建设的时候，需要对接很多已有监控平台，比如Zabbix、Prometheus、听云、网管neteagle等，这个阶段应该如何对现有监控的纳管呢？
答：可以考虑分阶段建设：
1、建设CMDB，将所有的监控系统的监控对象和CMDB的对象对齐，为统一监控建设打下基础
2、将所有的监控系统的告警事件进行统一管理，联动CMDB进行告警的收敛和影响分析，提升告警处理效率，节省告警处理的时间，释放人力进行后期建设
3、梳理企业内部的指标管理体系，建立监控的管理规范和流程，将所有的监控系统的性能数据按指标体系接入统一监控平台，注意联动CMDB，实现统一管理和视图
4、引入AI平台，基于统一监控平台的数据进行智能检测和分析，进一步提升人效
问：监控系统和告警系统是两个团队去开发的么? 两者会有一些耦合的部分么? 比如对于CMDB 的依赖。
答：监控系统和告警系统是分开开发的，但是产品设计是统一设计的，两套系统可以直接联动，监控系统的告警事件可以直接推送到告警系统中，并且可以关闭监控系统中原有的告警通知功能，让两边的联动更加友好。且监控系统中和CMDB建立的关联关系，推送到告警系统中之后，CMDB关联关系依旧会保存下来，不必要重复建设关联关系。