基于系统融合的统一监控平台设计.docx

?

?

基于系统融合的统一监控平台设计

?

?

【导读】目前做监控厂商的产品基本上都是大杂烩，各种概念和名词很多，强调集成或加agent等加层的方式去实现，和软件工程、系统化的思想其实是相矛盾的。为了厘清统一监控平台方案的设计思路，简化设计实施的难度和复杂度，减少重复建设，本文将详细讨论统一监控平台的设计。

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

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

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

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

图1统一监控方案设计思路

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

一、纵向分层

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

监控分层

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

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

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

链路跟踪、拓扑展示

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

当然业务应用的链路跟踪是核心。应用部署于支撑平台，支撑平台运行在容器、虚拟机、物理服务器等中，