监控系统的本质是通过发现故障、解决故障、预防故障来为了保障业务的稳定。而要想在企业内实现监控系统的体系化建设落地，需要从以下三个方面着手建设，分别是监控技术体系、监控指标体系、监控管理体系。
01. 监控技术体系
一般来说，一个完整的监控系统，可以抽象为采集+数据+算子+告警四个基本模块，缺一不可。
1）采集
① 采集方式
数据采集方式一般分为Agent模式（Agent-based）和非Agent模式（Agentless）；
Agent模式包括各种插件采集、各种格式的脚本采集、主机日志采集、主机进程采集、APM探针和SDK等；
非Agent模式包括SNMP、IPMI/Redfish、SSH、JMX、ODBC/JDBC、Syslog、ICMP、HTTP(s)、TCP/UDP、SMTP等各种通用协议的数据采集。
② 采集频率
采集频率一般有分秒级、分钟级之分，常用的采集频率为分钟级；同时也有基于条件触发式的随机采集或上报。
关于分钟级与秒级也有不少争论，常有人认为越快越好，认为越快就能更快发现问题。但是秒级的采集频率的增加，这对目标机器性能的影响也会增加，若因为数据采集导致业务性能本身出现问题，这就本末倒置了。而且，随着数据量加倍，存储成倍增加，计算量级指数型增长，带来的成本损耗可能远超秒级监控带来的好处。
在实际的应用场景中，需要思考使用秒级频率是否真的值得，是否能带来对应的业务价值。秒级监控是监控系统的一种必备的能力，但并不是所有的指标都需要秒级监控，需要挖掘真正的价值场景，而不是为了秒级而秒级，白白浪费资源，徒增维护成本。
③ 采集传输
采集传输按传输发起模式分类有主动采集Pull（拉）、被动接收Push（推）；按传输链路分类有直连模式、Proxy传输。其中Proxy传输不仅能解决监控数据跨网传输的问题，还可以缓解监控节点数量过多导致出现的数据传输的瓶颈，用Proxy机制实现数据传输负载分流。
2）数据
① 数据类型
监控的数据类型有指标（Metrics）、日志（Logs）、调用链（Traces）三种类型。指标数据是数值型的监控项，主要是通过维度来做标识；日志数据是字符型的数据，主要是从中找一些关键字信息来做监控；调用链数据反馈的是跟踪链路一个数据流转的过程，观察过程中的耗时性能是否正常。
由于数据类型不同，也衍生出了三类不同的监控系统。指标类型的监控，典型代表比如Zabbix、普罗米修斯。日志类常见的监控系统有ELK、Splunk等，主要关注日志类数据的分析和监控。调用链是通过TraceID来追踪请求的过程来进行监控，即APM（应用性能监控），例如Dynatrace、Skywalking等。
② 数据存储
对于监控系统来说，主要有以下三种存储供选择：
- 关系型数据库：例如MySQL、MSSQL、DB2；典型监控系统代表：Zabbix、SCOM、Tivoli；但由于数据库本身的限制，很难搞定海量监控的场景，有性能瓶颈，只在传统监控系统常用，逐渐被淘汰。
- 时序数据库：几乎可以说是为监控这种场景设计的数据库，擅长于指标数据存储和计算；例如InfluxDB、OpenTSDB（基于Hbase）、Prometheus等；典型监控系统代表：TICK监控、 Open-falcon、Prometheus。
- 全文检索数据库：这类型数据库主要用于日志型存储，Traces数据也可以存储，对数据检索非常友好，例如Elasticsearch。
③ 数据视图
数据视图主要是将监控的数据以一种人类便于理解的方式呈现出来，面向不同的角色会有不同的呈现方式，例如领导、管理员、值班员等关注的点都不一样。常见的数据视图模式有以下几种：
- 大屏：面向领导，提供全局概览；也可以面向值班员，提供盯屏视图；
- 拓扑：面向运维人员，提供告警关联关系和影响面视图；
- 仪表盘：面向运维人员，提供自定义的关注指标的视图；
- 报表：面向运维人员、领导，提供一些统计汇总报表信息，例如周报、日报等；
- 检索：面向运维人员，用于故障分析场景下的各类数据的快速查找和定位。
3）算子
① 数据加工
数据加工一般分为：数据清洗、数据计算、数据丰富、指标派生。
- 数据清洗：比如日志数据的清洗，因为日志数据是非结构化的数据，信息密度较低，因此需要从中提取有用的数据。
- 数据计算：很多原始性能数据不能直接用来判断数据是否产生异常。比如采集的数据是磁盘总量和磁盘使用量，如果要检测磁盘使用率，就需要对现有指标进行一个简单的四则运算，才能得到磁盘使用率。
- 数据丰富：就是给数据打上一些tags标签，比如打上主机、机房的标签，方便进行聚合计算。
- 指标派生：指的是通过已有的指标，通过各种公式计算得出新的指标，在一些统计指标的场景中比较常用。
② 数据检测
有固定规则和AI算法。固定算法是较为常见的算法，静态阈值、同比环比、自定义规则，而机器学习主要有动态基线、毛刺检测、指标预测、多指标关联检测等算法。无论是固定规则还是机器学习，都会有相应的判断规则，即常见的< > >=和and/or的组合判断等。
4）告警
① 告警收敛
告警收敛有三种思路：抑制、屏蔽和聚合。
- 抑制：即抑制同样的问题，避免重复告警。常见的抑制方案有防抖抑制、依赖抑制、时间抑制、组合条件抑制、高可用抑制等。
- 屏蔽：屏蔽可预知的情况，比如变更维护期、固定的周期任务这些已经知道会发生的事件，心里已经有预期。
- 聚合：聚合是把类似或相同的告警进行合并，因为可能反馈的是同一个现象。比如业务访问量升高，那承载业务的主机的CPU、内存、磁盘IO、网络IO等各项性能都会飙升，这样把这些性能指标都聚合到一块，更加便于告警的分析处理。
② 告警通知
- 通知到人：通过一些常规的通知渠道，能够触达到人。这样在没有人盯屏的时候，可以通过微信、短信、邮件触发到工作人员。
- 通知到系统：一般通过API推送给第三方系统，便于进行后续的事件处理。
对于一个成熟的监控，还需要支持自定义通知渠道扩展（比如企业里有自己的IM系统，可以自行接入）
关于上述4个方面便是一个站在技术的角度对监控系统的一个抽象，但是要落地监控系统，仅仅依靠一个技术强大的工具是远远不够的；接下来介绍的将是监控系统的核心数据管理—监控指标体系。
02. 监控指标体系
为什么要搭建指标体系？通过指标体系监测应用运行的状况，最大的价值就是高效利用时间，把时间花在解决问题上，而不是寻找问题上，从而提高整体的人效。指标体系的输出结果应当是一份指标字典，需要至少满足以下要求：
- 成体系化的指标，能够从多维度了解应用运行的现状
- 在应用运行出现问题时能够快速定位问题所在
- 高效地为运维团队提供数据支持
1）核心理念
- 监控的指标体系是以监控对象为骨架，以监控指标为经脉，将整个监控系统的数据有机整合起来。
- 指标体系的设计原则最重要的是可度量、可采集、可理解、可消费。
- 贯穿指标的生命周期管理，辅以指标的管理规范，才能保障监控平台长久有序的运行。
2）体系设计
从企业业务应用的视角出发，一般将企业监控的对象分为6层：基础设施层、硬件设备层、操作系统层、组件服务层、应用性能层、业务运营层；也可以根据企业自己的情况进行调整。
① 基础设施层
- 基础设施层，一般指机房的基础设施配备，用于保证机房的正常运转，包含动力、环境、安防等设备。即机房动环监控的核心关注点。
- 动力主要包含供电系统、发电机、UPS电源等电力供应设备，核心关注电力的状态、容量、电压、电流、稳定性、频率等指标。
- 环境主要包含温湿度计、空调、通风等环境监测和调节设备，核心关注环境设备的运行状态、环境温度、湿度等指标。
- 安防主要包含视频摄像头、门禁、烟雾探测器、消防设备等安全防护设备，核心关注设备的运行状态、视频稳定性、门禁状态等指标。
② 硬件设备层
- 硬件设备层，一般指服务器、存储、网络、安全四类常见硬件设备对象，用于提供应用运行所需的硬件资源。即基础硬件监控的核心关注点。
- 服务器设备主要包含X86服务器、小机、大机等计算资源设备，随着分布式计算技术的普及，小机、大机这种性能超强的专用机器逐渐淘汰，X86服务器成为当下主流；核心关注服务器的电源、CPU、内存、磁盘、风扇等配件的工作状态和性能指标。
- 存储设备主要包含磁盘整列、磁带库、存储交换机等存储资源设备，随着虚拟存储的技术的出现，专用而昂贵的存储设备逐渐减少，取而代之的是廉价的服务器设备配合大量的硬盘通过虚拟化技术提供的存储资源；核心关注存储设备的容量、IOPS、运行状态、读写速率等指标。
- 网络设备主要包含交换机、路由器、负载均衡等网络资源设备；核心关注网络设备的运行状态、端口状态、端口流量、吞吐量、错误包、丢包率等指标。
- 安全设备主要包含防火墙、入侵检测设备、防病毒设备、加密机等；核心关注安全设备的运行状态、接口状态、速率、丢包数、网络攻击数等指标。
③ 操作系统层
- 操作系统层，除了包含传统意义上的各类操作系统之外，还把虚拟化、容器也纳入该层，主要是考虑到虚拟化、容器本质上也是由操作系统驱动而提供的一种资源服务，如有需要，单独划分管理也未尝不可。
- 操作系统主要包含Windows Server、Linux系的CentOS、RHEL、Suse、Ubuntu、AIX、HP-Unix等服务器操作系统；核心关注CPU使用率、内存使用率、磁盘使用率、磁盘IO速率、网卡流量等指标。
- 虚拟化主要包含VMware、OpenStack、KVM、Citrix等虚拟化平台；核心关注平台主机、集群、存储的状态和资源容量、资源数、配额等指标。
- 当前的容器监控主要指K8s容器管理平台的监控；核心关注Cluster、Namespace、Service、Pod、Workload、Node等资源的状态、CPU负载、内存使用、磁盘使用、网络流量等指标。
④ 组件服务层
- 组件服务层，一般指数据库、中间件及其运行进程等软件资源对象，部分监控系统经常将进程归属于操作系统监控，或者独立进行监控，反应的都是进程本身的状态，但是进程本质是各种数据库、中间件软件资源服务化的表现形式，应当隶属于资源实例监控的一部分。
- 数据库主要包含企业常用的各种关系型数据库MySQL、Oracle、MSSQL等，以及非关系型数据库MongoDB、Redis、InfluxDB等；核心关注的是数据库的连接数、读写速率、锁、索引命中率、连接数等指标。
- 中间件主要包含Web中间件、消息中间件两种，例如WebLogic、Was、Tomcat、kafka、RabbitMQ等，其它的还有配置中间件、分布式事务、任务调度中间件等；核心关注的是中间件的吞吐量、连接数、JVM性能等指标。
- 一般只有数据库、中间件或者应用本身的进程才会进行监控，进程监控核心关注进程状态、端口状态、进程的性能使用率等指标。
⑤ 应用性能层
- 应用性能层，一般包含应用系统服务端和客户端两个方面，其中服务端主要指调用链，客户端主要包含移动端APP、PC端Web页面。
- 对于服务端的调用链，核心关注可用率、错误率、响应时间、吞吐率等关键性能指标。
- 对于客户的移动端APP和PC端的Web页面，核心关注浏览量、请求数、首屏时间、渲染时间、可用率、响应时间等关键性能指标。
- 另外，对于应用和服务的基础探活，也可以采用协议拨测的方式来实现，此时主要关注网站或接口的拨测可用率、拨测响应时间。
⑥ 业务运营层
- 业务运营层，主要指业务系统中的业务数据的监控，一般需要根据业务系统的特点来进行梳理，常见的业务系统主要关注交易量、交易耗时、库存量、用户数、活跃用户数、在线用户数等业务核心指标
⑦ 指标分级管理
根据上述梳理的指标清单，对于指标本身也建议能够做一个分级管理。一般分三级，按重要程度区分：核心指标、关键指标和常规指标。
- 核心指标一般不会定太多，主要反映这个监控对象是活着还是死了，1到2个即可。
- 关键指标是看核心性能是否正常，参考谷歌定义的SRE四大黄金指标。
- 常规指标可以根据实际的业务场景去考虑。
核心指标一定要配置告警基线，关键指标建议配置，而常规指标可以按业务场景考虑是否配置。后续通过不同指标的分级、权重，便可以很容易地建设起企业内地应用健康评估模型，衡量整个应用的健康情况。
通过上述分层分类的指标体系设计，可以对企业内的指标进行一个清晰的归纳和管理，再结合一套优秀的监控工具，便可实现企业IT资源应用的无死角监控，但要想监控系统在企业内实现长治久安，甚至不断进化，还得搭配下面即将介绍的监控管理体系。
03. 监控管理体系
监控的管理最重要的便是告警闭环管理，很多企业建设了很多套监控系统，都能产生告警，但是告警之后呢？没有然后了。对于监控体系的落地，运营管理比系统建设更加重要。只有将监控系统产生的告警治理起来，监控系统才能发挥其应有的价值，监控体系化建设过程才能出现正向的进化，而不是用着用着就没用了。
1）告警闭环管理
告警事件的闭环管理可以分为三个大的阶段，事前、事中、事后。事前核心关注发现问题的发现和预防，提示告警处理的效率；事中核心关注快速发现和解决问题，快速恢复业务，保障业务连续性，降低损失；事后核心关注问题的根因复盘，优化告警预防的方案和下次告警处理的效率。
① 告警预防管理（事前）
告警预防阶段，主要是针对可能出现的问题进行规避，核心是评估、调优、监测和预案。
- 评估：可以通过性能压测、人员测试等方式，评估系统的可用性和性能瓶颈，作为提前扩容调优的依据。
- 调优：根据测试评估的结论以及历史问题的反馈建议，对应用系统进行架构、容量、性能等方面的优化，以防事故发生。
- 监测：提前建设一些监控、巡检等工具，即前两部分中的监控系统建设，对应用系统的一些关键指标进行实时或定期检测，便于及时发现问题，提前解决问题，降低问题的影响时间。
- 预案：对于一些可能发生的问题，组织团队一起做出对应的方案，以便在事故真实发生时能够快速处理，最大可能性降低损失；例如灾备、降级、限流等方案。
② 告警处理管理（事中）
告警处理阶段流程最为复杂，又可以分为告警感知、告警响应、告警定位、告警恢复4个过程。
在具体谈告警处理之前，先说说告警分级，只有对告警提前进行分级，才能在告警发生时有条不紊，采取不同的应对策略。告警一般分为三级，致命、警告、提醒。致命告警一般代表服务已经异常，需要马上进行处理；警告告警一般代表如果不进行及时处理，服务即将异常；提醒告警一般代表一些潜在问题，需要开始关注或提前采取行动，避免异常产生。另外，告警分级的设定的影响因子也有很多，一般来说对象等级、指标等级、所属环境（生产/测试/准生产等）、业务重要性等为核心考虑因子。
- 告警感知：发现并感知到告警，有两种方式。一种是通过系统检测并通知到人，例如监控检测、主动拨测、舆情监测、健康巡检等；另一种是通过人工发现并反馈，例如关键应用盯屏机制、用户报障、服务台上报、测试人员上报等。
- 告警响应：接收并响应告警，也有两个过程。首先是处理人接收到自己负责的告警，主要是通过多种渠道（例如邮件、短信、电话、微信等）的通知，告警系统/服务台的分派，零线/一线无法处理告警的升级，值班室/值班群的通报机制等；然后是处理人响应告警，根据不同告警的处理策略，会有服务台响应、值班组响应、运维组响应、专家组响应等不同级别的响应模式。
- 告警定位：快速定位告警的问题，一般都是以人员经验为主，工具为辅进行快速定位。可以从各种数据着手，对指标、日志、链路数据进行快速分析；也可以从周边关联入手，是否是关联问题影响或者影响到了其它系统；还可以从变更历史记录中寻找可能的问题；目标是快速找到问题的原点，便于快速决策解决方案，特别注意，此时最关键的是问题解决的速率，而不是问题的根因分析，尤其是技术人员千万不要陷入问题根因定位中。
- 告警恢复：通过一系列行之有效的方案快速恢复应用系统的功能，可以通过问题节点隔离、负载限流、服务降级、资源扩容、应用重启、切换灾备、问题系统重装上线等方式，快速恢复核心业务服务，尽可能减少损失。
③ 复盘改进机制（事后）
告警复盘改进也可以分3个部分，分别是问题复盘、经验积累、改进优化。
- 问题复盘：核心目的是找出问题的根因，彻底解决问题，并且需要留下问题复盘报告，以防下次类似问题。
- 经验积累：经验积累最重要的便是知识库建设，据了解很多企业都有知识库，但是并没有真正用起来。建设知识库要注重3个点；一是以终为始，消费驱动，而不是为了沉淀而建设，一定要保障知识库的易用性，具备强大的检索能力，便于快速找到想要的知识；二是工具承载，基于知识消费场景丰富知识库，打通联动各个系统，自动汇聚知识经验；三是流程保证，设立专门的知识管理组织，保障知识库的落地和持续运营。
- 改进优化：回归本质，监控体系的建设不仅仅是为了出现问题后解决问题，而是为了不出或少出问题，故除了监控系统本身的使用优化之外，反推业务应用的优化才是根本。
- 告警关闭分析：统计直接关闭告警数、自动恢复数，分析原因，判断该项是否需要持续监控，是否可以优化告警策略？
- 误告警分析：通过打标签的方式标记误告警，可进一步优化告警策略，精准告警。
- 告警排行分析：业务告警数排行、资源对象告警数排行、指标告警数排行、跨区业务的区域告警数排行等，对于高频告警业务、对象、指标、区域等进行重点整治，优化业务应用系统。
- 自愈告警分析：自愈告警数、自愈告警成功率，自愈是否有误？自愈流程是否可以进一步优化？
为了更好的落地监控体系，还得有建设成果的衡量指标，主要可以从监控覆盖广度和告警处理效率两方面来看。
2）运营管理指标
① 监控覆盖率
主要是监控对象采集覆盖率、监控指标覆盖率两个指标，主要衡量监控的推广使用情况。监控对象采集覆盖率一般通过监控任务覆盖的对象实例数和CMDB中该对象的实例总数进行对比得出；监控指标覆盖率，一般是某个实例的规划指标总数和该实例的采集指标数进行对比得出。
② 告警处理指标
从告警生命周期的过程来看，会有告警发生时间、发现时间、响应时间、诊断时间、告警处理开始时间到告警恢复时间等关键时间节点，衡量告警管理会有如下几个关键指标。
- MTTI（平均告警发现时间）=发现时间-发生时间（一般可忽略）
- MTTA （平均告警响应时间）=响应时间-发现时间
- MTTR（平均告警恢复时间） =恢复时间-发生时间
- MTBF（平均无故障告警时间）=运行时间-故障时间
告警管理的根本目标便是降低MTTA，缩短MTTR，提升MTBF。即：快速发现并响应故障；快速定位并解决故障；减少故障发生，提升业务连续性。
其中的MTTA、MTTR便是运维团队工作的告警处理的最好衡量指标，直接反馈了团队的告警处理效率和告警处理能力。
