在大型分布式微服务场景下如何设计一个监控平台

作者 |慕枫Java
来源 | 慕枫技术笔记(ID：lulideguang)

在大型分布式微服务场景下，各个服务版本快速迭代，各类业务规模不断膨胀，同时监控的场景也在不断的发生变化，线上故障随时可能发生，各个平台错综复杂，如何保证线上服务稳定运行，同时提升运维效率，降低运维成本成了监控平台的挑战。

一、什么是监控

在设计监控平台之前，我们首先来探讨下监控到底是什么。首先从字面进行理解。我们把监控两个字拆开来看，“监”即为“监”视，需要对平台所涉及的硬件资源以及软件资源进行7*24小时的无间断监视，获取其运行信息，不断进行异常检测。“控”即为管“控”，在检测到异常时可以进行及时处理，采取对应的控制措施，如发出告警叫醒运维人员进行解决或者是执行预定义的自愈措施，进行快速恢复等。

因此“监”是手段，而“控”则是结果。监控平台的建立其实就是在不断的丰富“监”视的方式以及手段，以便于更加快准狠的管“控”线上业务平台，保障线上各平台以及各业务稳定健康的运行。

这里将监控平台的核心业务流程抽象为七大步骤，如下图所示：

当故障发生时，监控平台需要及时感知，及时检测到异常。当检测到异常后，平台需要将检测结果进行通知，无论是通知给研发或者运维人员进行人工解决，还是中枢决策平台判断是否可以进行自动恢复处理，都需要进行及时的故障止损。平台或者研发人员需要根据检测的问题进行故障根因定位，根据实际情况进行恢复或者升级。最后在进行故障的复盘，研发以及运维等相关人员复盘问题产生的原因以及预防措施，避免相同问题再次发生。如果平台的AI智能化水平比较高的话，可以根据新的故障以及场景，训练出新的处理策略来更新策略库。

二、数据采集

数据采集是监控平台的基础，后续各个服务都需要采集到的监控数据来处理对应的业务流程。大致采集的数据如下表所示，当然真实环境中的指标数据远比下表中多的多。

关于采集器，开源的监控方案中已经有比较成熟的数据采集器了，如TICK技术体系中的Telegraf采集器，或者Prometheus技术体系中exporter采集器。基本覆盖了常见的机器、应用服务数据采集，包括中间件等，同时也可以根据自身的业务特性进行定制开发。

三、CMDB

在业务平台发展初期，少量的的服务器以及运维人员也许就可以满足生产需要。但是随着业务规模的不断扩大，监控对象类别不断扩充以及监控场景不断复杂化，如何应对大规模基础设施以及应用服务的监控以及运维，成了我们不得不面对以及需要解决的问题。如何对各类监控以及运维资源进行高效组织，并将其作为监控平台的数据基座来提升监控运维效率是CMDB的核心价值。

那么CMDB到底是什么呢?CMDB(Configuration Management Database)即配置管理数据库。可以按照场景分为面向应用型或者面向业务型。简单来说，CMDB管理着各类资源模型以及基础数据，使得监控平台各类应用可以方便的使用资源以及模型数据进行业务处理以及数据同步。

要想构建CMDB，首先便需要对资源模型进行高度的抽象。由于监控运维的对象主要涉及机房、机器、各类设备以及应用服务等多种资源对象，因此需要通用性的资源模型来应对不同的使用场景。

一个资源对象从购买、使用、监控到替换整个生命周期会涉及到多个子系统之间的资源数据同步，因此需要保证各个子系统之间的数据一致性以及准确性。

有了前面两个阶段的支撑之后，就到了发挥CMDB数据价值的最终阶段。它必须在数据可视化、自动化监控运维、智能监控以及数据运营方面提供强有力的支撑。

我们可以将监控对象分为两大类对象，一类为基础设施，即机房、机架、服务器、网络设备、前端设备、电源等设施对象。而另外一类则是以基础设施为基础构建在其上的应用服务、中间件等应用对象。这两类监控对象的关联关系可以通过下图进行展示。

无论是监控对象是设施对象还是应用对象，它都是一种资源信息。需要通过抽象的资源模型进行支撑以及扩展。根据上述监控对象的关联管理，我们可以得到以下的资源模型。

在实际场景下，都会有资源隔离的需求。一个租户可能会申请一批服务器，其中按照开发环境、测试环境、预发布环境以及生产环境来对资源进行分配。因此我们需要以业务为主轴线，针对机器资源管理以及应用业务场景来对资源进行组织管理。

五、根因追溯

故障发生是“果”，比如服务崩溃，但是导致故障发生的“因”可能有很多，可能是服务自身Bug导致的内存溢出，可能是服务器CPU被打满，可能是依赖的服务有问题。因此故障根因追溯是辅助研发以及运维人员进行故障定位的重要手段和措施。只有快速而准确的进行故障根因定位，才能将故障造成的损失降到最低。

我们可将故障根因追溯分为趋势图表辅助分析以及系统自主分析两类。

1、趋势图表辅助分析

监控平台都需要有个信息丰满、覆盖全面的平台全景监控大盘。 用户可以更具自身业务需要进行自定义。另外对于机房、机架、服务器、集群、服务实例、中间件都应该有对应的运行趋势数据展示。当故障发生时，必定会导致某些数据的变化，而这些数据的变化在运行趋势图中必定会有所体现。研发人员以及运维人员可以结合对应的趋势图来判断异常的可能原因。

2、系统自主分析

以上的全景图表以及细维度的图表，需要研发以及运维人员参与，属于一种事后分析的手段。但是监控平台本身就是为了减少人力维护投入以及故障快速定位而存在的。因此系统自主分析，挖掘故障根因，才是监控平台真正发挥价值的地方，也是业务与技术的难点。

在进行故障原因定位时，可以通过故障区域筛选以及多维度关联分析找到关键事件来进行系统自主故障定位。当然，如果可以结合AI技术，不断训练对应的分析模型，可以最终实现无需人工介入的故障定位效果。

(1)故障区域筛选

当故障发生时，首先需要筛选出来具体故障的机房以及机器。如检测出来某个业务的接口响应超时，那么该业务涉及到的各个应用有哪些，这些应用对应的服务实例有哪些，这些实例部署在哪个机房以及机器上?依赖的中间件有哪些，中间件又部署在哪里?通过第一步的筛选可以确定哪些机房的哪些机器以及哪些服务可能出现问题。再在此基础上分析这些机房是否服务器是否存在高负载的情况，各个服务是否正常，依赖的中间件是否正常运行，再结合有无持续的错误日志以等信息进行进一步的筛选，缩小故障范围。

(2)多维度关联分析

在缩小了故障区域后，就需要进行故障下探，挖掘真正平台出血点位置。除了上述的，需要关联平台的事件信息，比如故障发生前是不是进行了发布升级，是不是发生配置变更等等?通过锁定的故障区域以及对应的事件流信息，综合判断后给出故障点根因列表，同时计算对应的故障比例值。

六、数据存储

在监控平台中数据主要分为分为两类，一类为时序类数据、另一类为事件类数据。时序数据主要为CPU、内存、磁盘、网络以及流量数据等。我们需要根据不同的数据特征选择适合的存储平台，最终形成监控平台的数据混合存储架构。

监控平台内的事件数据主要包括告警事件、故障自愈事件、日志数据等。其中需要说明的是日志数据也属于事件数据的一种，因为对于程序来说，输出日志一定是程序有标志性的事件发生，比如catch到了异常、比如重要的逻辑判断等。因此我们认为日志数据也是一种事件数据。

整个事件数据存储平台主要分为数据接入层以及存储分析层。其大致的架构如下所示：

数据接入层主要负责统一的流量接入、接口鉴权、流量统计以及流量切换的功能。

存储分析层主要负责平台事件数据的存储、全文检索、数据聚合计算以及分析。因此需要满足以下的重点特性：

(1)支持海量事件数据高性能存储;

(2)支持基于事件描述的模糊搜索;

(3)能够方便的实现数据存储节点的水平扩容;

(4)支持数据节点的副本冗余存储以达到数据高可用的目的。

考虑到事件数据存储的重要性，需要设计互为主备的双ES集群，以达到最大程度的保证事件数据存储平台的可用性。如果有条件的话，建议进行双机房部署双集群，避免单机房故障导致的平台不可用问题。数据接入层向存储分析层进行数据双写，数据查询搜索从ES主集群中获取。

平台可以根据平均响应时间、错误等指标综合分析主集群可用性，在经过几个决策周期分析后，如果发现异常则将流量切换到备集群，实现平台高可用。

七、总结

本文作为如何设计监控平台的上篇，大致描述了平台建立需要做的事情。主要涉及数据采集、CMDB、故障定位、数据存储等方面的内容。一个完整的监控平台远不止于此，还会涉及到异常检测、故障自恢复、告警通知、监控大脑(中枢决策中心)等内容，这些将在下篇文章中进行阐述。

随着AI技术的出现，使得我们有机会将人工智能技术应用到监控平台中，它为我们打开了更多的应用场景想象。监控平台逐渐由自动化监控运维迈向AI智能监控运维。让故障感知、分析决策以及任务调度执行最终由机器自主完成，以达到无人值守的目的，高效维护线上环境。