企业集中监控体系思路及架构 | 运维进阶

【作者】彭华盛，广发证券数字化运维研发团队负责人。超过10年的金融领域运维工作，期间负责参与企业运维组织、流程、工具的建设，包括各类重大业务系统项目与数据中心工程性项目的实施，数据中心标准化工作流程构建，运维工具体系的规划与研发、数字化转型研究与实施相关等工作，对金融领域的运维有较全面的理解。近年来专注数字化转型研究，探索推进数字化技术与业务转型双轮驱动的协同模式，推进业务数字化转型。平时喜欢研究新技术、新理念、思维模式、产品设计等等，乐于分享。腾讯TVP成员。个人公众号：运维之路

所谓“监控”，即包括“监” “控”，即应该具备对运维数字世界的运行情况进行感知、决策、应急处置的能力，是业务连续性保障能力的基础。因为要感知，所以监控需要具备实时的数据采集能力，而监控采集的性能、容量、运营等数据又为智能运维提供数据资产。由于生产系统运行涉及面极广，监控工具很多，企业很自然的会有合而为一的决策，像集中监控就是一个常见的项目。但是，需要关注的是，一方面市场上成熟的监控系统很多，不同层面的监控工具关注点又各不一样，通常很难选择一个包罗所有能力的监控系统；另一方面企业里的监控系统经过一段时间沉淀，原有监控系统最大的价值已经不是监控系统本身，而是上面的监控配置项，事实上很多技术架构及功能并不优秀的监控系统很难替换的原因就在于此。所以，本文讲的集中监控不是讲一个监控系统，而站在运维组织角度看监控体系。

（注：一些细化内容可以参见《监控体系建设》（点击标题可阅读））

1. 从飞机监控看运维监控

如果说运维行业工作特点是如履薄冰，那航空公司的运维是事关生死，借鉴航空公司的运维方案有助于持续提升业务连续性保障能力。以监控为例，一方面，如果机组人员遗漏或延迟响应监控报警，可能会产生灾难，要求监控系统的可靠性，报警的准确性；另一方面，影响飞行安全的因素很多，不仅包括飞机自身的设备可靠性，燃油，气候，航站楼安排等每一个环节都需要监控到位，要求监控系统覆盖面；同时，由于事关生死，监控报警响应、处理、复盘的管理得到严格落实。

本节内容源于早前看过一篇关于波音777-200LR飞机监控的贴子，为了实现一架飞机的监控管理，波音777-200LR飞机部署了超过3000个传感器，内容覆盖飞机内部设备、人员操作、外部环境、燃油等多个维度的监控。鉴于监控报警的优先级不同，对监控的信息触达与处置方式进行分级，以确保监控报警信息能够得到处理。飞机这种监控分级，报警处置要求，以及配套不同级别的提示对于运维监控体系有借鉴作用。以下摘录出一些有意思的内容。

1）报警分级

飞机监控系统对不同的监控报警划分了5个级别，每个级别有不同定义，并有多种不同的报警方式。通过报警分级，飞行员或飞机运营人员可以有主次的进行针对性处理与决策。5个级别包括：

备忘

备忘表示飞机的一种正常状态，但该状态需要机组知晓，类似于汽车上的大灯远光开启这样的指示信号。该级别信息通常为白色显示，无声音或首次出现时伴随单次提示音。

咨询

咨询表示飞机的一种异常状态，但该状态不会立即威胁飞行安全，条件允许时应予以关注。该级别信息通常为黄色显示，无声音或首次出现时伴随单次提示音。

警戒

警戒表示飞机出现故障或处于明显异常状态，该状态正在威胁飞行安全，应尽快予以关注。该级别信息通常为黄色显示，伴随连续谐音警告或嘟嘟声。

告警

告警表示飞机出现严重故障或处于危险状态，该状态已经严重威胁飞行安全，必须立即采取措施，否则极可能发生致命事故。该级别信息通常为红色显示，且故障排除前无法清除显示的内容，伴随不间断高分贝警告音或语音播报。

急迫告警

急迫告警表示飞机出现严重故障且持续恶化或处于即将发生致命事故的状态，必须立即采取措施，否则将不可避免的发生致命事故。该级别信息通常为红色显示，且故障排除前无法清除显示的内容，伴随不可关闭的不间断高分贝警告音或语音播报。

注：还有一个维护级别，但该级别信息主要展示给地勤，起飞后无需关注，该级别信息通常为白色显示，无声音，仅在地面显示或多功能显示器选择维护页面时显示。

2）报警触达手段

注意到上面不同的报警级别，会有一些不同的报警触达手段，以【急迫告警】级别为例：“……该级别信息通常为红色显示，且故障排除前无法清除显示的内容，伴随不可关闭的不间断高分贝警告音或语音播报。”

除了上述报警触达手段，飞机上还有其他触达手段，比如在不同面板，通过颜色、声音等方式进行设计，这些方法对于报警的响应处理是一个辅助手段。

* PFD显示：在主飞行仪表上显示

* ND显示：在导航仪表上显示

* EICAS显示：在综合信息仪表上显示

* 其他面板显示：在飞行管理计算机，备用仪表等其他面板上显示

* 主警报红：红色主警报灯亮起

* 主警报黄：黄色主警报灯亮起

* 专用警报灯：专用于该警报的灯光亮起

* 声音警报：各种声音效果警报

* 语音警报：语音播报的警报

* 其他警报：操作杆震动等其他警报方式

3）监控覆盖类型

飞机报警来源很多，比如设备故障、维修不当、设计失误、航管指挥、天气、鸟击、机员失误等因素，具体落地到飞机监控覆盖点包括：

* 引气系统监控：引气系统提供高压空气，与增压，除冰，气动液压泵，空调，引气启动等系统有关。

* 自动飞行系统监控：现代商业飞行全程95%以上的时间飞机由自动驾驶系统控制。

* 通信系统监控：检测数字通信方面的问题，主要是天地数据链。

* 电路有关监控：飞机电力系统十分完善，通常不可能意外断电，因此警报级别比较一般，所有电力系统的详细工作状态都可以在电力显示中查看。

* 引擎有关监控：发动机可以说是整个飞机中最重要最昂贵的设备。

* 火警有关监控：驾驶舱可见的火警警报，有些区域的烟雾和火警警报反应在乘务员面板上。

* 飞行操作有关监控：飞行操作系统包括多个扰流板，附翼，襟附翼，方向舵，安定面，升降舵等控制面，和一系列飞行计算机，由于飞行操作系统直接关乎飞行安全，所以拥有较高的警报级别。

* 飞行管理和导航系统监控：导航帮助飞机实现高级自动驾驶，和更高的自动化飞行管理，大幅度降低机组的工作量。

还有其他监控分类，比如燃油、液压、起落架、飞行保护系统、地形，姿态，风切等。我们可以看到飞机的监控包括外部环境、内部核心部件与关联性系统、飞行操作等监控，可以看到飞机监控是一个多种监控点组合而来。

4）监控报警信息

监控报警信息的准确性、关键信息有效传递也很重要，这样才能增加监控报警出现后，处置的高效。以下是两个咨询类报警的示例，值得运维监控报警信息的学习：

“警报名称：机组氧气压力低

警报级别：咨询

警报方式：EICAS显示：黄CREW OXYGEN LOW

触发逻辑：机组备用氧气钢瓶压力低

补充信息：可在维护信息显示中查看详细状况，备用氧气仅供失压或驾驶舱烟雾状态下使用”

“警报名称：自动驾驶失效

警报级别：告警，若在自动着陆系统工作时发生升级为急迫告警

警报方式：EICAS显示：红AUTOPILOT DISC，笛声，主警报红

触发逻辑：自动驾驶无法在指令的工作状态工作或飞行计算机正在放弃对飞行的控制权（包括人工断开自动驾驶）

补充信息：抓住操作杆并按下自动驾驶按钮可以解除警报转入人工控制（PFD将显示F/D模式）”

5）基于飞机传感器数据分析更好感知飞机状况

美国五角大楼根据数字孪生理论，从飞机传感器采集分析运行数据，构建一个数字孪生飞机模型，辅助飞机运维人员与飞行员进行决策。即从飞机设备运行数据采集起来，记录实体发动机的运营商、 飞行小时数、运营情况、维修情况等信息，为每台发动机生成数字孪生模型。采用这种数字孪生技术监控飞机发动机，运营人员可以更好分析发现飞机运行的潜在风险，并触发异常报警，帮助飞机运维人员更快的发现问题。

从上面飞机监控系统，我们可以看到飞机监控系统的设计，真正落实了监控系统的“不漏报、少误报、高响应”基本目标，并利用数字孪生这种上帝视角全面观察飞机运行状况。汇总一下有以下一些特点：

* 外部因素、飞机设备、人工操作、自动驾驶、燃油容量等多种因素都可能影响飞机的正常航行，需要实现多种监控策略与手段。

* 监控报警进行了统一汇总，对监控报警进行分级管理。

* 为了让监控报警得到有效处理，提供了多种不同类型的监控触达方式。

* 分析监控采集的性能指标数据，可提供运行感知、辅助决策的数据支撑。

* 飞机监控系统与自动化系统相结合，为飞行决策提供支撑。

2.关于集中监控总体思路

企业的生产系统要运行良好，需要保证一系列的软硬件设施的稳定运行，比如机房环控、网络设施、服务器设施、系统软件、数据库、中间件、应用服务，以及交易与客户体验层面等等因素都与稳定息息相关，经过多年的信息化建设，很多公司己针对上述软硬件设施配套了多种监控手段，但如同其它领域的信息化建设一样，运维监控的信息化建设中信息孤岛，烟囱建设的问题也比较突出，以下归纳了监控工具的一些常见问题：

* 缺乏持续优化监控体系的机制，既存在监控报警风暴、监控误报多的现象，也存在对一些个性化的业务缺少监控覆盖，监控漏报的情况；

* 缺乏统筹建设，监控工具重复建设情况突出，且工具与工具间缺乏互联互通，无法形成互补；

* 监控数据的报警事件、性能数据集中程度不够，没有有效的利用这些数据辅助运维优化工作；

由于运维涉及的领域越来越多，系统架构异构情况越来越明显，没有哪一个监控工具能够做到一篮子解决方案，往往硬件厂商擅长硬件监控，软件厂商擅长软件监控，DBA擅长数据库监控，业务运维擅长业务监控、性能分析团队擅长性能体验监控等，基于这个现状，建议传统企业的监控平台规划可以用以下几个思路作为切入点：

* 监控基本目标是“不漏报、少误报、高响应”；

* 站在整个运维组织看集中监控，源端监控工具关注“不漏报、少误报”，集中监控平台关注“少误报、高响应”；

* 源端监控工具采用分层方式，划分监控覆盖面能力要求；

* 集中监控平台整合源端监控工具产生的性能指标、报警数据，实现通用的平台能力；

* 基于数据驱动，量化“不漏报、少误报、高响应”指标，持续优化；

* 利用监控性能指标、报警数据，与日志、配置、操作、流程等数据，结合算法，进一步完善“不漏报、少误报、高响应”的目标；

基于上述的监控平台建设原则，抽象了监控能力的整体思路（如下图），建立以集中监控平台的思路，确保监控覆盖面，完善监控工具，丰富监控平台能力，并通过智能化不断提高监控手段.

2.1 从分层看源端监控工具

为了便于监控工具的管理，做好工具间的整合，需要对监控进行整合，划分好具体的监控工具所处的作用。但大部分运维组织在运维体系建设过程中，通过不断沉淀，往往有一些深度定制的指标，在实施运维过程中己起着重要作用，短期内比较难马上替换，这些监控指标分布在不同的监控工具。建议采用一种有序整合方式，制定好监控能力整合的原则与标准，处理好工具替换的过渡方案。要处理好保留哪个工具，引入什么新的工具，需要从监控体系上分析监控覆盖面的能力要求，做好分层与具体工具的对应关系。

1.监控分层架构

每一层监控的监控指标覆盖能力需要有所定义，这样就可以直观的清楚当前监控平台的监控能力覆盖面，才能不断完善以实现”不漏报“的基本目标。以下是每一层指标能力的简述：

1）基础设施

状态监控包括机房供电、空调、网络设备的软硬件状态，如设备状态等；

性能监控包括设备的性能情况，比如CPU、内存大小、session数量、端口流量包量、内存溢出监控、内存使用率等；

网络监控包括设备错包、丢包率，针对网络设备以及网络链路的探测延时、丢包率监控等；

容量监控包括设备负载使用率、专线带宽使用率、出口流量分布等；

由于基础设施硬件往往己有设备健康性的检测机制，建议向这类厂商提要求，将设备的运行事件主动送到监控平台整合。

2）服务器层

存储：包括存储设备，以及设备上的硬盘读写错误、读写超时、硬盘掉线、硬盘介质错误

服务器上的内存（内存缺失、内存配置错误、内存不可用、内存校验）、网卡（网卡速率；电源：电源电压、电源模块是否失效）、风扇（风扇转速等）、Raid卡（Raid卡电池状态、电池老化、电池和缓存是否在位、缓存策略）

虚拟机：vcenter状况等

存储、物理设备、虚拟机等建议参考基础设施层由厂商主动汇总事件到监控平台，由于容器方面的监控工具并不多，则需根据实际情况选择是否借鉴开源的工具进行自研。

3）平台服务层

平台服务层的数据主要包括操作系统、中间件、数据库，以及其它开源分布式中间件等工具，这方面包括很多，以操作系统和数据库为例：

操作系统的包括：CPU（CPU整体使用率、CPU各核使用率、CPU Load负载）、内存（应用内存、整体内存、Swap等）、磁盘IO（读写速率、IOPS、平均等待延时、平均服务延时等）、网络IO（流量、包量、错包、丢包）、连接（各种状态的TCP连接数等）、进程端口存活、文件句柄数、进程数、内网探测延时、丢包率等。

数据库的包括：数据库连接数、低效SQL、索引缺失、并行处理会话数、缓存命中率、主从延时、锁状态等。

容器：容器集群资源负载，集群基础组件健康情况，节点性能监控，以及微服务涉及TPS、QPS、请求熔断、限流、超时次数等。

另外，随着开源组件的不断涌现与应用，像分布式数据库中间件、web容器、负载均衡器、缓存、消息队列等组件的监控覆盖能力的挑战越来越大。

在分析平台服务层性能情况，需要客观衡量业务负载高低情况，并结合扩缩容调度，实现业务的负载和成本间的平衡。可以根据服务器所在业务层级（接入层、逻辑层还是数据层）的不同，设置不同的容量参考指标、指标参考基准、指标计算规则、高低负载判别规则，设置业务模块（由相同功能的多个服务器构成的业务集群）的扩缩容规则；由系统计算出服务器、业务模块的负载情况，决策出是否需要扩容或缩容，触发业务模块的扩缩容操作。

随着云原生架构的推进，平台之上的应用系统架构向微服务，容器化演进，面临各种不同的公有云/私有云的混合云环境，以及各种跨云/跨平台的操作。在以私有云为主的企业内，云原生架构以容器化为主要表现形式，涉及容器集群资源负载，集群基础组件健康情况，节点性能监控，以及微服务涉及TPS、QPS、请求熔断、限流、超时次数等常见微服务监控指标，链路追踪等数据。同时，建议平台服务层的监控工具主要采用引入更加主流的开源监控工具，一方面可以更好的整合外部成熟的监控指标覆盖能力，另一方面推动企业内PAAS平台、DBA、中间件管理员根据工作情况增加监控指标覆盖面。

4）应用服务层

架构的复杂性，对应用服务的可靠性、稳定性、业务连续性带来挑战，应用服务层监控能力建设是重中之重，包括：

服务可用性监控：如服务、端口是否存在，是否假死等

应用性能：应用处理能力，比如交易量、成功率、失败率、响应率、错误数、实时实例数、GC次数、GC耗时、各个内存区域的大小、当前线程数、死锁线程数等。

调用跟踪：请求量、耗时、超时量、拒绝量、URL存活、请求量、耗时、慢 SQL 次数、异常次数和慢调用次数等

应用交易：比如交易主动埋点、交易流水、订单量、委托量、访问日志、错误日志等

应用营业状态监控：指应用的状态是否满足业务开业状态

5）客户体验层

比如测速系统以及模拟用户访问的方式：以模拟用户访问为例，通过模拟用户访问业务并校验返回数据结果，监测业务是否可用、访问质量及性能、逻辑功能正确性的监控系统。不仅仅是接入层（网站类业务是否能访问，访问的速度是否快），业务逻辑的验证就涉及到登录鉴权、关系数据自动化获取等。

2.源端监控工具能力建设

源端监控工具来源很多，可以是主流的专业监控工具，或IAAS层或PAAS层提供的平台监控工具，或应用系统供应商提供的监控工具，或基于日志、NPM、APM，以及基于运维数据分析平台等提供的工具或监控能力。我个人观点，如果有人力最好选型更加主流的源端监控工具，比如zabbix、open-falcon等，没人力但有持续的资金投入则考虑采用成熟厂商的监控工具。

站在具体的监控工具角度看，主要涉及：监控性能指标数据采集、性能指标数据存储、报警策略计算、报警事件及应急操作行为。监控性能指标采集主流的方案利用代理在源端采集，这种方案对于监控服务端的管理更加友好，扩展性更好。但，由于当前系统架构越来越复杂，应用服务层与客户体验层监控越来越重要，基于日志与链路跟踪的数据的采集也显得尤为重要。性能指标数据的存储主要采用时序数据库、关系型数据库，以及ES这类用于日志数据的存储。报警策略上，工具已经从固定阀值的基础上增加动态基线的方法。在源端工具角度看报警事件，主要是监控报警是否能够及时按标准推送到统一的监控报警模块。

各专业条线对各条线的监控负责，他们是最清楚自己需要什么监控的团队，各专业条线对监控覆盖率负责，监控平台的建设方负责平台体系的建设，提供基础技术支撑。不同的专业条线、不同的分析技术可以有不同的监控工具，采用这种多点开花的建设方式更有助于监控“面“与”深度“的完善，所有的工具最终需要进行标准化工具的整合，主体现在下面的事件整合、性能数据整合。

2.2 统一事件/报警

Google SRE解密一书中提过（大体意思如下）：监控应该尽可能简单地把需要人介入或关注的信息展示给运维团队，能通过自动化自愈解决、分析定位过程则不在一级视图提供。当前，能实现自愈的企业还比较少，或还在摸索建设过程中，所以如何让每天产生上亿条流水，触发上万次告警条件（同一告警如未解除会持续不断触发告警条件），来自各种不同工具、不同格式的告警事件以尽可能简单的方式展示给一线监控团队是监控平台需要解决的重要问题。

事件整合主要包括以下几块：

事件汇总：汇总不同层次、不同专业条线、不同类型事件是监控集中管理的基础。

事件收敛：前面提到同一个故障会触发多类指标的告警，同一个指标在故障未解除前也会重复产生大量的告警事件，如果将全部事件都展示出来，那对于监控处理人员将是灾难性的，所以需要进行事件收敛。

事件分级：对于不同的事件需要有适当层次的事件分级，事件升级的策略。事件分级是将事件当前紧急程度进行标识显示，事件升级是对于低级的事件当达到一定的程度，比如处理时间过长，则需要进行升级。

事件分析：事件分析是建立事件的关联关系，关联分析可以从纵向和横向关系进行分析，纵向是指从底层的基础设施、网络、服务器硬件、虚拟机/容器、操作系统、中间件、应用域、应用、交易；横向是指从当前的应用节点、上游服务器节点、下游服务器节点的交易关系。事件分析是形成故障树，自愈的基础。

以下对事件整体解决方案的梳理，包括最底层的集成规则处理引擎，并在事件数据的基础之上构建事件展示、事件操作、事件策略管理、故障定位、故障应急、统计分析等场景，详见下图：

基于上述的事件整合思路，不仅是对各监控工具来源的事件进行汇总、处理、可视化，同时还需要基于监控事件与企业值班、监控响应、应急等场景整合起来。

以下我们对事件丰富、分级与分析做进一步介绍。

1.事件丰富

在建设监控过程中通常会花较多时间在监控数据采集、数据处理、指标覆盖面方面上，也就是“监”上面的投入，对于“控”方面的投入较少。“控”方面的的投入少往往会导致监控报警后，运维人员仍需花很大时间去判断影响、定位根源、应急处理等方面，延误了故障恢复的战机，直接影响应用可用性的提高。要做好“控”，事件丰富是关键，事件丰富的广度与深度则依赖于CMDB的建设。监控系统的事件丰富主要包括事件描述丰富（通过基本信息的丰富、拓扑丰富）、事件现场丰富（基础层、应用可用性、性能、业务运行指标信息丰富）、知识库丰富，提高运维人员分析问题的能力。

监控事件发生后，仅仅给出“什么时候，什么资源，出现什么问题”是不够的，因为运维人员还要其它的运行数据进行故障的处理，也就是事件丰富。需要注意的是，事件丰富不能为了丰富而丰富，而是要从事件处理过程中需要的信息进行丰富，比如判断故障影响、问题定位、故障恢复、故障协同处理等工作（见下图）。

由于监控系统很难覆盖所有的信息，需要整合其它工具的能力（见上图思维导图中的黄色小批注），这些数据则需要靠CMDB进行整合，关联到同一个事件上来。基于上述思路，对每一个事件进行了事件丰富，通过可视化的方式整合监控、变更、CMDB等信息，辅助应急管理。

2.事件分级及事件分析

为了规范化监控事件分级，解决每个监控工具不同分级方式的现状，考虑到原有监控工具改造的可行性与成功，我们没有让源系统进行改造，而是选择在事件集中后，由事件集中管理模块承担事件分级的标准化规范，比如制定“通知、预警、告警”三级，分别代表意义：

告警：属于已影响业务或可用性的异常事件，需要马上介入处理（非营业时间的告警可以是预警）。

预警：属于异常事件，这类事件暂时不会有业务影响，需要运维人员关注并处理（预警事件长时间不处理时，会升级为告警）。

通知：知会性的监控事件，这类监控事件通常不是报警，属于提醒性的消息，比如每天巡检前发布某个业务系统的登录量，业务量等；

有了分级，就要对事件的处理的方式制定策略：

微信或短信消息推送：不同级别的监控事件，推送人员可以不同；

电话拨打：紧急告警或告警事件N分钟未受理，工具调用拨打电话接口拨打给负责人，负责未接电话或N分钟仍未受理拨打群级经理；

可视化：通知采用单独一标签页，预警为字体红色，告警为橙色，紧急告警为红色；

监控报警处理时效性公示：对于监控事件处理不及时的报警，可以按级别推送到团队的IM群中进行公示；

另外，需要注意的是上述3级事件根据受理时间，解决时间将会有升级机制，不同的级别的事件有不同的事件处理机制，不同的业务期间或非业务时段的事件级别或升级机制可以不同。对于有计划解决的事件，可以设置挂起/维护期，期间如未发现该指标有更快级别事件（或手工设置挂起期间的升级报警阀值，比如80%的空间报警，设置在2天内95%内不报警），不进行升级。

2.3 统一性能指标数据

监控事件整合是利用不同监控工具已有的事件策略触发，并根据配置库的关联，来提高事件的处理效率。在实际运维过程中，可能还会遇到一些事件整合无法解决或解决起来费力的情况：

* 个别工具的性能指标、阀值、基线缺少或不合理导致的事件漏报或误报的情况；

* 个别工具因为工具本身的性能无法设置更高频繁的事件监测的情况；

* 从各个工具间的事件数据只能相对表层的关联出事件关系；

* 上层场景化的数据消费需要更丰富、更全局的数据进行整合分析获得；

* 仅有的事件数据无法有效的为后续数字化、智能化的监控平台提供数据基础；

针对上面几个问题，需要将多源头的性能原始数据进行数据整合，整合为一个事件完整的性能数据分布图，进而进行监控管理。具体来讲，性能数据整合可集成主流的监控数据源（如网络监控、硬件监控、存储监控、系统监控、应用监控等等），将各种监控数据（主动接收的时序数据，被动获取的关系数据库、日志ES数据等类型）关联结合，协助用户从业务角度、IT服务角度、资源角度等角度看待监控、保障业务、优化运维。

为了做到上述的目标，需有这一个监控性能数据整合的工具或数字化平台中的一个模块，并具备以下特征：

* 基于配置管理

* 具备高性能、高可用存储与计算能力的技术架构

* 具备简约式、可视化的数据汇总配置，支持快速落地

* 具备扩展性的数据消费场景能力

* 具备与事件整合关联能力

2.4 监控数据运营

在监控建设过程中，很多团队将绝大部份时间放在工具功能的完善上，而未针对监控工具使用的持续改进。前面己提到了监控平台建设基本目标是“不漏 报、少误报、高响应”，围绕这个基本目标，对于我们可以转化为完善“监”能力，增加“控”的能力，可以针对不同的阶段量化目标，比如60%告警即故障，80%故障来自监控。

1、不漏报

漏报可以从两个层面看，一个是监控工具不具备某一方面的监控能力；一个是监控工具具备监控能力，但因为使用者使用问题导致未覆盖监控。前者需要完善监控能力，比如针对生产故障举一反三式的优化，或由不同专业条线主动增加监控能力，为了支持通用性的监控覆盖能力，我们设计了一些可定制化的监控策略，比如以下这个支持动态配置SQL的方式，可以让DBA配置基于数据库层面的监控策略，也可以支持业务运维人员配置业务交易情况的策略。

对于监控使用的运维人员漏配置监控的问题，工具建设需要考虑几个问题：

* 管理上有没有要求指标的100%覆盖率

* 覆盖率的要求是否确实可以落地，或功能上是否设计极不友好

* 100%的覆盖率是否从技术默认设置，如果技术无法默认设置，能否从技术上主动发现。

前面两个问题需要从管理手段上解决，最后一个问题需要在监控系统中解决，即尽可能让需要覆盖的监控指标从技术上落地，减少对运维人员主动性上的依靠，同时监控系统要快速从技术上响应新的监控指标的落地。

2、少误报

误报带来的问题也很大，大量、反复的误报告警会让运维人员麻木，进而忽视监控报警，错过了真正的监控事件的处理，所以监控误报情况也需要重视。在减少误报过程中最好先对数据做统计，会发现有一些共性的特点，比如大部份报警来自同一类指标，比如磁盘报警，比如SSH无效的报警，那么对这类报警的阀值合理性评估、数据清理规范的落实则可能事半功倍；也可能某个组或某个人所负责的报警最多，又不愿意调优阀值的情况，如果对这类特点进行优化也可以效果明显；也可能增加监控的功能，比如端口异常进行自启动，变更维护期功能的设置，收敛机制等功能等方式都可以作为“少误报“的一些方法。

3、高响应

在故障处置过程中，我们通常关注一些指标，比如：MTBF（无故障时长）、MTTI（平均故障发现时长）、MTTK（故障定位时长）、MTTF（平均故障处理时长）、MTTR(平均故障响应时长)，MTTF(平均故障恢复时长)。在上述指标中，MTTR重点要关注监控报警时效性管理，即报警出现后多久被运维值班人员受理并介入处理，针对不及时处理的报警如何升级加快处置。数据运营中，可以考虑离线与实时分析两个角度。离线是定期的监控响应数据分析，通常采用报表，排名思路；实时是针对响应不及时的数据进行实时升级等操作。结合当前物联网设备的发展，可以考虑结合一个智能的穿戴设备提升响应效率。

2.5 上帝视角

面对不断复杂的系统架构，迭代速度越来越高，数据量越来越大，未知故障将越来越多，传统监控工具根据已知问题配置监控阀值的模式将受到挑战。借鉴前面提到的飞机运行维护数字孪生的思想，与AIOps方法，用数字化思维重塑运维数字世界的监控体系，建立全局式、全在线、可观察、可穿透、可预测的上帝视角将是下一代监控体系的建设方向。上帝视角的监控，一方面是对现有监控体系进行精准性、大数据量、大计算量、智能化的改造，同时围绕特定运维场景驱动源端监控的丰富，与传统监控工具的一些区别应该包括：报警更加精准，增强对未知异常的监控发现能力（减少手工配置监控阀值的占比），支持云化基础设施与云原生架构，提升业务及客户体验层监控覆盖面等。本节的内容暂时先引出“数据、算法、平台、场景”四个方向，具体内容有待下半年的探索。

原题：企业集中监控体系思路及架构