·2021-11-18 17:46

IT顾问·steven

系统融合之统一监控平台

字数 7937阅读 5142评论 0赞 2

最 近听了李老师的《业务流程重构 (BusinessProcess Reengineering) 》，感觉和我一直以来的一些体会和思路不谋而合。道理都是相通的，殊途同归。李老师强调 fundamental rethinking( 彻底的重新思考 ) 、 radicalredesign （根本的重新设计）、 dramatic improvement （显著的提升）。系统融合思路就是基于彻底的思考，重新的设计，以期获得显著的提升。

在容器云平台建设的时候，我们就考虑并提出过围绕容器云平台的监控方案。监控、日志等不应该是容器云平台的组件而应该独立于容器云平台并同时支撑容器云平台的独立组件或独立平台。每个系统都会涉及监控、日志等功能，所以这些功能就可以提取出来，实现复用，构建独立的统一监控中心、集中日志中心等，再基于这些统一监控、集中日志等平台构建可复用的监控、日志等服务，建设企业级技术中台（技术中台服务）。

围绕容器云、 DevOps 、微服务等的云原生讨论也很多，通常都是只重一个或几个点，很少有全局的和顶层的考虑，所以监控等也基本上没有全局的方案。监控能力散落于各个单体系统，从而导致了人为的部门墙。容器云、 DevOps 、微服务等技术相辅相成，非常适合从整体上来考虑，构建企业级的平台和中台，从而支撑企业敏捷变化的业务需求，支撑企业业务实践和转型。而监控是其中必不可少的部分。所以我们一直也在考虑如何和容器云平台、 DevOps 融合等来通过分布式微服务架构建设统一监控平台。

目前做监控厂商的产品基本上都是大杂烩，各种概念和名词很多，强调集成或加 agent 等加层的方式去实现，和软件工程、系统化的思想其实是相矛盾的。拔冗去繁，拨云见日，监控无非就是监控数据采集和监控数据接入、监控数据处理（包括监控实时数据处理和监控历史数据处理）、数据存储和查询显示。其他的功能都是基于监控的数据的进一步扩展，比如链路跟踪与拓扑展示、指标管理、探针管理、故障检测、异常处理、工单流程管理、知识库等（如 图  1 统一监控方案思路 ）。

![](/home/attachment/202111/18/1216527_163722872324776.png)
 图  1 统一监控方案设计思路

为了厘清统一监控平台方案的设计思路，简化设计实施的难度和复杂度，减少重复建设，我们今天详细讨论下统一监控平台的设计。**整体思路可以考虑纵向分层、横向分段、侧向管控的方法来设计实现**。 把应用涉及的整个软硬件环境当作一个整体、一个系统、一个体系来看待， 从而形成一个全局立体体系。

# 一、 纵向分层

目前实际的业务应用系统，至少是 C/S 、 B/S 两层架构，而分布式架构往往层次更多，从前端、中间服务层、数据库或数据存储层以及中间件组件、操作系统、基础设施资源服务器、网络设备等，任何一个节点出现异常都有可能影响到业务应用的运行。比如说服务器磁盘损坏，可能导致数据库或文件不可用，从而导致应用异常等等。既然每一层都有可能出现故障，那么每一层都需要进行监控，并且需要把各层之间的关系串接起来，形成链路。通过链路实时展示就可以知道哪一层有异常，快速的定位和处理问题。这就是监控分层的价值。

## 监控分层

分布式系统带来了运维的复杂性，特别容器化之后，灵活性更高，但层次更多，运维复杂化。如果有没良好的监控平台和工具，一旦容器达到一定量之后，就会超出人的管控能力，遇到异常问题就需要花费大量的时间排查问题。

监控纵向分层的思想就是把应用监控数据采集的问题简单化，也使应用调用处理过程的链路更清晰，更好的实现链路跟踪、链路拓扑展示，更好更快的定位问题，处理异常。当然这需要提前做整体规划、全局的设计。比如说日志为监控提供了很重要的支撑，日志的链路 ID 就需要全局定义。从打开前端页面到中台服务到后台资源等，这个链路能够通过全局 ID 关联起来。

监控分层可根据实际的业务链路进行划分，比如说前端渠道、前端应用（ Client ）、中台可复用服务、中间件、后端服务、服务部署运行平台、数据平台 / 数据库、软件基础设施、硬件基础设施等。分层目的是为了简化监控数据采集，便于实现链路跟踪、问题下钻定位等能力。

## 链路跟踪、拓扑展示

通过分层，才能更好的实现链路跟踪能力。其实我们需要考虑的不止是应用服务之间的调用关系，也需要考虑支撑这些应用服务的组件、工具、操作系统、基础设施资源等。这样才能形成多个相互关联的闭环。这也我们思考规划建设统一监控平台的原因。

当然业务应用的链路跟踪是核心。应用部署于支撑平台，支撑平台运行在容器、虚拟机、物理服务器等中，又涉及不同的操作系统、系统配置、CPU、内存、网络、磁盘、存储等众多的资源，在出现故障的时候需要抽丝剥茧，往往需要花费大量的时间和精力来定位故障，找到root cause。比如说节点磁盘空间满了导致某个中间件服务停掉，无法启动，但异常往往是从应用曝出，从应用、日志、中间件、节点、磁盘等过程定位，虽然最终可能会解决问题，但其代价却是很高昂的。因此，监控从端到端实现分层，这样可以明确每个层次所采集的指标和内容。通过统一的链路来快速定位故障，在系统融合阶段将变得越来越重要。

链路跟踪需要采集各个层次对象的指标，采集的指标根据监控对象的不同和监控指标的需求分别定义，每个应用从前端到后端往往经过若干个调用层次，可能涉及不同的对象和系统、平台、工具等，往往比较难用统一的标准去套这些对象，这也是统一监控落地比较难的地方，但这也是非常关键的。如果这些指标都能抽象并映射到不同的对象，那么统一监控平台的建设将非常容易。

有了标准化的指标，从前端到后端实现端到端的数据采集则可以实现链路跟踪，以拓扑形式展示服务 / 系统之间调用关系。在出现异常的情况下，可以快速下钻到根故障点，从而快速定位故障并解决故障。

# 二、 横向分段

## 监控数据采集

监控首先是监控数据的采集。要采集数据，需要知道从哪里采集，采集什么样的数据，怎么采集数据。这就是监控对象、监控指标、和监控数据采集方法。

###   1. 监控对象

监控对象就是我们监控采集数据的源端，包括众多的应用、系统、组件、平台、数据库、服务器、网络设备等等。由于这些应用和系统众多，需要监控的点（指标）也可能各不相同，这就可能导致我们在实施统一监控项目时有点无从下手。而厂商的监控产品是这些年的积累，五花八门，积累的时间越长，可能包含的东西就越多、越杂乱。国内大部分软件厂商的一个重要特点是基本上都是从做项目开始的，缺乏产品的顶层规划和设计，所以一个产品可能无所不包，什么都有但什么都不够精深，所以更像是大杂烩。这么说可能得罪很多厂商，但我们还是希望国内的软件厂商能真正静下心好好思考，真正的争口气，真正的强大起来，真正的把产品做好做强。由于目前各种应用系统架构、开发语言、接口方式等很多都不相同，这无疑增加了统一监控平台的实施难度。所以很多人直接去部署一个agent来采集数据。这也导致了可能很多agent在运行，使运维工作复杂化。所以在考虑统一监控平台的时候需要梳理监控对象，分层、分类进行梳理。硬件服务器的监控和软件应用的监控差别一定是很大的，所以首先要明确监控对象、监控目标才能确定监控指标和监控数据采集方式。

###   2. 监控指标和监控指标目标

每个存量应用或每套存量系统或多或少都会有相应的监控能力。首先需要梳理下这些监控对象的监控能力，确定监控采集的指标，比如请求到来时间、请求处理等待时间、 CPU 时间、响应时间计算、平均响应时间计算、最大响应时间记录、线程数、进程数、 CPU 、内存使用等等，这就是监控对象的监控采集指标的定义。每个监控层次监控指标有一些通用性的指标，但每个监控对象都有自身的一些特定指标。通用指标和特定指标的集合反映了监控对象的运行状况。对于新的应用和系统，要考虑通过标准化的监控采集方式采集标准化的监控指标，这在建设统一监控平台的时候需要明确定义。这样才能更好的基于监控数据首先更多的功能，比如链路跟踪、异常定位、智能运维等。

GoogleSRE 提出了在定义监控指标的同时要关注监控指标目标。所谓监控指标目标也就是服务质量目标，是指标的目标值或者目标范围。通过目标值可以确定采集到的指标值是否在合理范围内。通常确定一个合理的目标值并不容易，往往需要大量实践总结。

###   3. 监控采集方式

监控对象不一样，监控需求、监控指标和监控数据采集方式也可能会不一样的。数据采集，首要考虑是通过应用或系统本身来提供数据，通过接口对外提供监控数据，是publish分发方式，而不是pull拉取方式。通过publish方法，所有需要这些数据的对象（接收端）都可以接收，增加接收端而不需要额外付出代价。

存量系统往往不支持这样的方式，所以需要通过部署agent、daemonset等方式来采集数据。不管用agent或者探针、daemonset等方式，都相当于加了一层，是集成的方式，性能和效率都会受到影响，也会带来额外的管理复杂度。所以监控数据采集最好是监控对象直接吐出需要采集的监控指标数据，而不是通过集成方式。比如容器云平台的运行数据直接通过容器云平台把数据吐出，云管平台的虚拟机运行数据由云管平台来把数据吐出等。这样每个层次的数据就可以实现复用。降低对接、集成工作量，降低系统建设复杂度，也降低运维难度。

我们理解很多时候为了快速上线，直接对接监控工具，比如Prometheus、Zabbix等，但这些数据有时候跟我们期望的数据会有差别。我们在容器云平台运维的时候，就发现通过Prometheus的数据有时间会导致误告警，docker的运行数据和pod的运行数据以及Prometheus的监控数据会有差别，因此，最好的方式是直接由容器云平台提供docker和pod的运行数据，而不是再经过Prometheus等中间层。

## 监控数据处理

监控数据包括实时数据和历史数据。实时数据和历史数据的价值不一样，其处理方式也有不同。实际的业务处理往往需要基于历史数据经验并结合实时数据，实现更准备的一个预判。

###   1. 监控实时数据处理

实时数据往往价值最高，随着时间的推移，数据逐渐失去价值。监控的实施可以考虑分层来实现，从前端、中间服务（或中台服务）到基础设施平台、资源，每个层次每个组件每个对象都需要进行监控以跟踪其运行状态，分析其运行情况和可能趋势。通过实时的监控则可以实现实时风险管控和实时风险处理，避免后知后觉，造成额外的损失。

对于实时数据往往需要实现实时事件处理能力，可以建立复杂事件处理系统进行实时事件处理，结合历史数据学习所构建的态势感知、风险控制算法等提升实时业务处理能力。

###   2. 监控历史数据处理

历史数据则关注历史趋势和统计分析。比如我们提到的基于历史数据的态势感知分析预测能力、风险模型等。当然对具体的客户来说，其某个时点的历史数据为该客户提供了该时点的记录，也有意义，但也仅仅查看、对比等，可能就无法基于该数据做投资等决策。

###   3. 日志

日志是采集的一部分，由于日志量大，所以可以单独对日志进行处理，但日志的监控和数据处理结果要回归监控平台。也就是说，日志存储可以单独存储在文件、数据库、ES、或大数据平台等，不过需要考虑实现日志的查询搜索能力，支持快速日志数据查询和过滤，支持时间区间、关键字等查询或全文查询、模糊查询等能力。

这些能力可以和技术中台的搜索中台、消息中台等能力结合，实现日志的统一处理和管控。

## 数据存储

作为企业的重要资产和生产要素，数据是需要落地的，需要保存起来以被查询、统计、分析等之用。 所有的数据需要存储，可以根据实际选择存储的方式。并不一定存在一个地方。 按照微服务架构的思想，数据是可以分库存放的。监控数据量往往是很大的，但监控数据的价值随着时间快速衰减。比如说节点资源的使用情况监控，像证券每工作日周期性的高峰流量，会导致资源使用的周期性高峰，为了查看一段时间的资源趋势，就可以保存一个月、 3 个月等的数据。保存的数据和采集的数据的时间间隔往往也是不一样的。比如数据采集可能是每 2 秒一次，但 1 周之前的数据可能只保存 1 分钟一次的数据， 1 月之前可能保存 5 分钟一次的数据。具体的策略根据实际业务需求来定义。

数据可以存放在数据库、或者大数据平台，也可以是文件、  ES 等地方，通常要基于系统架构和技术能力进行决策。没有十全十美的方案，每种方案都会有优缺点，选择适合自己的方案就好。

## 查询展示

存储方式的选择很重要一点是为了便于查询和搜索。数据要用起来，流转起来，才能真正体现数据的价值。监控采集的数据要能便利的展示给不同的角色人员。每个角色的权限可能是不一样的，所以看到的数据也可能是不一样的。这和我们前面提到的分层思想一致，不同的人员负责不同的工作，其权限也是不一样的。通过授权等机制，在保障安全的前提下，可以实现故障数据的查询展示、定位处理等，那么数据就需要根据角色及其权限进行展示和过滤，以确保数据的安全。

# 三、 侧向管控

统一监控平台本身依然可以是一个独立的系统，同时又是企业融合系统中的一个模块或组件或子系统，所以实际应用过程依然中需要对这个子系统进行管控，比如访问权限的设置控制等。还有监控平台自身对象和属性的管理，比如指标的定义和管理、指标目标、服务协议的定义和管理、探针的管理、脚本的管理、通用配置的管理、日志、审计等功能。这些都是平台需要实现的能力。

## 认证权限、访问控制管理

登录认证、权限管理是每个系统都需要的基本功能，所以认证、权限等能力就可以提取出来以可复用服务的形式作为中台的能力，实现企业级共享，避免重复建设、降低成本提供效率。统一监控平台可以直接使用身份认证中台服务（基于认证平台提取沉淀）和权限管理中台的服务（基于权限平台）实现认证和权限管理就可以了，不需要再重复开发登录认证和权限管理能力。

## 指标定义和管理

对于每一次的每一个监控对象定义其监控指标。比如服务的响应时间、平均响应时间、最大响应时间、最小响应时间、请求到达时间、响应回复时间等。通过定义每个监控对象的监控指标，就可以把该对象的关注点都可以采集起来，进行后续的分析处理。比如一段时间内的响应时间就可以通过图形的方式展现出来，看下响应时间的分布，和我们期望的响应时间这个指标的目标是否匹配，差距有多大。这就给我们了一个优化和调整的参考。

## 探针管理

不同的对象可能需要不同的探针来采集数据。统一监控平台需要提供不同探针的统一管理、配置等能力。这是监控平台自我管理自我监控能力的体现。我们也提到，探针其实是一种加层集成方式，带来便利的同时也带来新的问题，比如说不同探针类型要管理起来不得不增加探针管理功能模块等，这也就带来了问题的复杂性。所以，如果能够最终都以某种标准化或规范化的方式来获取监控数据，则可以简化整个架构和监控处理逻辑。

## 自动化脚本管理

监控该平台往往需要管理一些自动化的脚本，比如一些自动化巡检任务的调度管理等。这些能力也和调度平台相关联，可以部署于调度平台来统一管理。这样就松耦合了平台架构，减少重复的建设。

## 配置设置

众多的组件和工具往往都有很多的配置参数需要调整，这些配置可以在配置中心统一来管理，这就和我们提出来的系统融合思路中“配置中心组件”融合起来，在配置中心进行配置的统一管理。

## 日志和审计

统一监控平台有自身的日志及操作审计需求。这些日志和审计信息也可以发送到日志中心统一管理起来。然后由日志中心提供查询接口集成到监控平台，这样监控平台的日志、审计数据不需要自己管理，按需从日志中心尽心查询。这就实现了系统之间的融合。

需要注意的是，系统融合采用的是分布式微服务架构思想，可以基于云原生容器技术实现弹性伸缩以支持需求的扩展和变化。它不是一个集中式的架构，但它是一个一体化可适用不同场景架构需求的分布式架构。

# 四、 监控功能扩展

基于采集到的数据可以实时或延时做故障检测、异常处理等。多指标复杂的数据处理可以通过 AI 算法平台来实现，也就是智能运维部分。可以和我们大数据平台、机器学习平台、数据智能中台等整合。在进行监控平台架构设计时，认识到并理解系统融合的趋势，将各个系统和模块进行无缝融合，则会在后期减少大量的重复建设工作量，从而提升效率。

###   1. 告警

通过规则实现自动告警和通知。如果需要人为介入，则通过自动化工单来记录并自动分发到相应的角色，处理完毕由利益关系人进行主观反馈评价。工单和评价反馈可以积累形成量化的工作业绩数据，可以考虑作为量化绩效考核的参考（这就是系统融合思想，不是单一的看待一个问题）。

###   2. 故障检测、异常处理到知识库

基于监控采集到的数据进行运行状况分析和预测、异常处理等。随着量的积累，可以逐步形成知识库，反过来支持故障检测和异常处理，使之相辅相成。

###   3. 工单处理

系统或应用出现异常时，需要人来介入才能解决，则需要分配工作给某个人。通常是谁负责谁来处理，不过多数时候会涉及多个系统之间、多个人员之间的协调配合。为了更好的激励员工，公平的记录每个人的工作，更公正的评价每个人的绩效，有必要通过高效的工单流程来达到这些目标。

###   4. 绩效统计

另外，目前提倡量化管理，每个人的工作量和工作效率可以通过相应的工单统计和成果反馈从定量和定性两个方面进行参考，特别对于外包人员的管理和评价将会更有合理依据。

###   5. DevOps

将持续监控、持续反馈置于 DevOps 闭环流程之中，持续改进业务应用的质量以及环境的可用性。 DevOps 是一种方法论，以闭环流程的方式实现落地。 DevOps 的目的就是为了协调开发人员和运维人员之间的关系，提升研发交付质量和交付效率，提升系统的稳定性、降低运维的工作量。处理好开发和运维之间的关切和利益分配问题则比较容易理顺彼此之间的矛盾，从而减少内耗，提升效率。这也和输出（工单）、评价（绩效）、故障率和故障处理效率密切相关。

# 五、 大屏展示

监控一个关键的能力是可视化展示，能够让用户一目了然看到核心关键应用、系统、组件、资源、资产、趋势等状况，通过在大屏上实时展示这些用户关心的核心信息，则能够帮助用户实时掌握系统运行状况和趋势，避免错失重要的异常问题等。

所有实时、历史、统计计算、分析结果可以作为输出在大屏上实时展示，并且可以通过下钻达到任何一层，以实现问题的快速定位和关联查询。

从系统融合的角度，统一监控平台的建设需要考虑各个层次和各个系统的关系，同时要构建可行的可适应的架构来为未来的扩展打好基础。无论数据、或者组件等，都需要提前考虑清楚、架构清晰。在设计建设统一监控平台之前，就需要考虑好平台之上的可复用中台能力、平台所支撑的应用能力等，这样，才能比较顺利的推进企业的系统逐步走向浑然一体，避免重复建设、推倒重来，才能在数字化转型过程中赢得先机，支持业务顺利转型。

系统融合统一监控平台系统监控

著作权归作者所有

如果觉得我的文章对您有用，请点赞。您的支持将鼓励我继续创作！

添加新评论0 条评论

Ctrl+Enter 发表

匿名评论

系统融合之统一监控平台

添加新评论0 条评论

作者其他文章

相关文章

相关问题

相关资料