运维监控平台设计

Posted 2023-02-23

运维监控平台不是简单的下载一个开源工具，然后搭建起来就行了，它需要根据监控的环境和特点进行各种整合和二次开发，以达到与自己的需求完全吻合的程度。那么下面就谈谈运维监控平台的设计思路。

构建一个智能的运维监控平台，必须以运行监控和故障报警这两个方面为重点，将所有业务系统中所涉及的网络资源、硬件资源、软件资源、数据库资源等纳入统一的运维监控平台中，并通过消除管理软件的差别，数据采集手段的差别，对各种不同的数据来源实现统一管理、统一规范、统一处理、统一展现、统一用户登录、统一权限控制，最终实现运维规范化、自动化、智能化的大运维管理。

智能的运维监控平台，设计架构从低到高可以分为6层，三大模块，如下图：

• 数据收集层：位于最底层，主要收集网络数据、业务系统数据、数据库数据、操作系统数据等，然后将收集到的数据进行规范化并进行存储。
• 数据展示层：位于第二层，是一个Web展示界面，主要是将数据收集层获取到的数据进行统一展示，展示的方式可以是曲线图、柱状图、饼状态等，通过将数据图形化，可以帮助运维人员了解一段时间内主机或网络的运行状态和运行趋势，并作为运维人员排查问题或解决问题的依据。
• 数据提取层：位于第三层，主要是对从数据收集层获取到的数据进行规格化和过滤处理，提取需要的数据到监控报警模块，这个部分是监控和报警两个模块的衔接点。
• 报警规则配置层：位于第四层，主要是根据第三层获取到的数据进行报警规则设置、报警阀值设置、报警联系人设置和报警方式设置等。
• 报警事件生成层：位于第五层，主要是对报警事件进行实时记录，将报警结果存入数据库以备调用，并将报警结果形成分析报表，以统计一段时间内的故障率和故障发生趋势。

用户展示管理层：位于最顶层，是一个Web展示界面，主要是将监控统计结果、报警故障结果进行统一展示，并实现多用户、多权限管理，实现统一用户和统一权限控制。

在这6层中，从功能实现划分，又分为三个模块，分别是数据收集模块、数据提取模块和监控报警模块，每个模块完成的功能如下：

• 数据收集模块：此模块主要完成基础数据的收集与图形展示。数据收集的方式有很多种，可以通过SNMP实现，也可以通过代理模块实现，还可以通过自定义脚本实现。常用的数据收集工具有Cacti、Ganglia等。
• 数据提取模块：此模板主要完成数据的筛选过滤和采集，将需要的数据从数据收集模块提取到监控报警模块中。可以通过数据收集模块提供的接口或自定义脚本实现数据的提取。
• 监控报警模块：此模块主要完成监控脚本的设置、报警规则设置，报警阀值设置、报警联系人设置等，并将报警结果进行集中展现和历史记录。常见的监控报警工具有Nagios、Centreon等。

在了解了运维监控平台的一般设计思路之后，接下来详细介绍下如何通过软件实现这样一个智能运维监控系统。

下图是根据上图的设计思路形成的一个运维监控平台实现拓扑图，从图中可以看出，主要有三大部分组成，分别是数据收集模块、监控报警模块和数据提取模块。

其中，数据提取模块用于其他两个模块之间的数据通信，而数据收集模块可以有一台或多台数据收集服务器组成，每个数据收集服务器可以直接从服务器群组收集各种数据指标，经过规范数据格式，最终将数据存储到数据收集服务器中。

监控报警模块通过数据抽取模块从数据收集服务器获取需要的数据，然后设置报警阀值、报警联系人等，最终实现实时报警。报警方式支持手机短信报警、邮件报警等，另外，也可以通过插件或者自定义脚本来扩展报警方式。这样一整套监控报警平台就基本实现了。

监控系统的关键技术主要有如下5点：

采集器

采集器决定了监控数据的来源，采集器的好坏决定了监控数据的覆盖面、数据质量和及时性。一个好的监控系统应该配备大量针对常见技术场景的采集器，并提供方便的自定义数据接口。标准场景的监控数据占所有监控数据的 70% 左右，大量的标准采集器可以大大降低监控系统的持有成本；自定义监控数据占所有监控数据的 30% 左右，设计良好的自定义监控数据接口可以更好的调度、组织和收集自定义数据源，并为后续的二次开发工作夯实工程基础。

采集器负责采集监控数据，有两种典型的部署方式，一种是跟随监控对象部署，比如所有的机器上都部署一个采集器，采集机器的 CPU、内存、硬盘、IO、网络相关的指标；另一种是远程探针式，比如选取一个中心机器做探针，同时探测很多个机器的 PING 连通性，或者连到很多 mysql 实例上去，执行命令采集数据。

业界有多款开源采集器可供选择，下面我们做一个简要点评，便于你做选型。

Telegraf

Telegraf 是 InfluxData 公司的产品，开源协议是 MIT，非常开放，有很多外部贡献者，主要配合 InfluxDB 使用。当然，Telegraf 也可以把监控数据推给 Prometheus、Graphite、Datadog、OpenTSDB 等很多其他存储，但和 InfluxDB 的对接是最丝滑的。

InfluxDB 支持存储字符串，而 Telegraf 采集的很多数据都是字符串类型，但如果把这类数据推给 Prometheus 生态的时序库，比如 VictoriaMetrics、M3DB、Thanos 等，它就会报错。因为这些时序库只能存储数值型时序数据。另外，Telegraf 采集的很多数据在成功和失败的时候会打上不同的标签，比如成功的时候会打上 result=success 标签，失败的时候打上 result=failed 标签。

在 InfluxDB 中这种情况是可以的，但是在 Prometheus 生态里，标签变化就表示不同的指标，这种情况我叫它标签非稳态结构，使用 Prometheus 生态的时序库与 Telegraf 对接时需要把这类标签丢弃掉。Telegraf 是指标领域的 All-In-One 采集器，支持各种采集插件，只需要使用 Telegraf 这一个采集器，就能解决绝大部分采集需求。

Exporters

Exporter 是专门用于 Prometheus 生态的组件，Prometheus 生态的采集器比较零散，每个采集目标都有对应的 Exporter 组件，比如 MySQL 有 mysqld_exporter，Redis 有 redis_exporter，交换机有 snmp_exporter，JVM 有 jmx_exporter。

这些 Exporter 的核心逻辑，就是去这些监控对象里采集数据，然后暴露为 Prometheus 协议的监控数据。比如 mysqld_exporter，就是连上 MySQL，执行一些类似于 show global status 、show global variables 、show slave status 这样的命令，拿到输出，再转换为 Prometheus 协议的数据；还有 redis_exporter，它是连上 Redis，执行一些类似于 info 的命令，拿到输出，转换为 Prometheus 协议的数据。

随着 Prometheus 的影响越来越大，很多中间件都内置支持了 Prometheus，直接通过自身的 /metrics 接口暴露监控数据，不用再单独伴生 Exporter，简化了架构。比如 Kubernetes 中的各类组件：kube-apiserver、kube-proxy、kube-scheduler 等等，比如 etcd，还有新版本的 ZooKeeper、 RabbitMQ、HAProxy，都可以直接暴露 Prometheus 协议的监控数据，无需 Exporter。

不管是 Exporter 还是直接内置支持 Prometheus 协议的各类组件，都提供 HTTP 接口（通常是 /metrics ）来暴露监控数据，让监控系统来拉，这叫做 PULL 模型。而像 Telegraf 那种则是 PUSH 模型，采集了数据之后调用服务端的接口来推送数据。关于 PULL 模型和 PUSH 模型我们后面第 5 讲的时候还会再详细地讲一下，这里你先有个印象就可以了。

Telegraf 以及后面即将讲到的 Grafana-Agent，也可以直接抓取 Prometheus 协议的监控数据，然后统一推给时序库，这种架构比较清晰，总之跟数据采集相关的都由采集器来负责。

Grafana-Agent

Grafana-Agent 是 Grafana 公司推出的一款 All-In-One 采集器，不但可以采集指标数据，也可以采集日志数据和链路数据。开源协议是 Apache 2.0，比较开放。

Grafana-Agent 作为后来者，是如何快速集成各类采集能力的呢？Grafana-Agent 写了个框架，方便导入各类 Exporter，把各个 Exporter 当做 Lib 使用，常见的 Node-Exporter、Kafka-Exporter、Elasticsearch-Exporter、Mysqld-Exporter 等，都已经完成了集成。这样我们就不用到处去找各类 Exporter，只使用 Grafana-Agent 这一个二进制就可以搞定众多采集能力了。

Grafana-Agent 这种集成 Exporter 的方式，完全兼容 Exporter 的指标体系，比如 Node-Exporter。如果我们的场景不方便使用 PULL 的方式来抓取数据，就可以换成 Grafana-Agent，采用 PUSH 的方式推送监控数据，完全兼容 Node-Exporter 的指标。当然，Exporter 种类繁多，Grafana-Agent 不可能全部集成，对于默认没有集成进去的 Exporter，Grafana-Agent 也支持用 PULL 的方式去抓取其他 Exporter 的数据，然后再通过 Remote Write 的方式，将采集到的数据转发给服务端。

对于日志采集，Grafana-Agent 集成了 Loki 生态的日志采集器 Promtail。对于链路数据，Grafana-Agent 集成了 OpenTelemetry Collector。相当于把可观测性三大支柱的采集能力都建全了。一个 Agent 搞定所有采集能力有个显而易见的好处，就是便于附加一些通用标签，比如某个机器的所有可观测性数据，都统一打上机器名的标签，后面就可以使用这种统一的标签做关联查询，这个关联能力是这类 All-In-One 采集器带来的最大好处。

Categraf

Categraf 是快mao星云公司开源的一款监控采集器，开源协议是 MIT，非常开放。

你可能会想，已经有这么多采集器了，为何还要再造一个轮子呢？Categraf 的定位类似 Grafana-Agent，支持 metrics、logs、traces 的采集，未来也会支持事件的采集，对于同类监控目标的多个实例的场景，又希望做出 Telegraf 的体验。同时对于所有的采集插件，不但会提供采集能力，也会提供监控大盘、告警规则，让社区开箱即用。

Categraf 偏重 Prometheus 生态，标签是稳态结构，只采集数值型时序数据，通过 Remote Write 方式推送数据给后端存储，所有支持 Remote Write 协议的时序库都可以对接，比如 Prometheus、VictoriaMetrics、M3DB、Thanos 等等。

对于习惯使用 Prometheus 的用户，Categraf 也支持直接读取 prometheus.yml 中的 scrape 配置，对接各类服务发现机制，实现上就是把 Prometheus agent mode 的代码引入进来了。

除了上面介绍的采集器，业内还有很多其他方案，比如 Datadog-Agent、Metricsbeat 等，这里我就不一一介绍了。实际上在公司内部落地的时候，倒也不是非黑即白，一定要选择某一个。

机器层面的监控，我推荐 Telegraf 和 Categraf，内置了监控脚本、进程 / 端口监控，CPU、内存之类的也都很完备；探针类的监控自由度就很高了，不同的中间件、数据库监控，习惯用哪个采集器就可以用哪个。

针对上面我们介绍的这 4 种常见的采集器，我做了一个表格供你选型参考。采集器采集到数据之后，要推给服务端。通常有两种做法，一个是直接推给时序库，一个是先推给 Kafka，再经由 Kafka 写到时序库。当然，一些复杂的情况，可能会在 Kafka 和时序库之间加一个流式计算引擎，比如 Flink，做一些预聚合计算。但绝大部分公司都用不到，所以这里我们先不管复杂流式计算的问题，重点来看一下时序库。

时间序列存储技术

时间序列的管理、存储和处理是监控闭环中的核心环节，在设计或评估一个监控系统时应着重考察时间序列存储的技术方案。时间序列技术的关键点在于可用性、可靠性、压缩比、旧数据清理、指标项管理、多维度聚合等多个方面。

监控系统的架构中，最核心的就是时序库。老一些的监控系统直接复用关系型数据库，比如 Zabbix 直接使用 MySQL 存储时序数据，MySQL 擅长处理事务场景，没有针对时序场景做优化，容量上有明显的瓶颈。Open-Falcon 是用 RRDtool 攒了一个分布式存储组件 Falcon-Graph，但是 RRDTool 本身的设计就有问题，散文件很多，对硬盘的 IO 要求太高，性能较差。Falcon-Graph 是分布式的，可以通过堆机器来解决大规模的问题，但显然不是最优解。后来，各种专门解决时序存储问题的数据库横空出世，比较有代表性的有：OpenTSDB、InfluxDB、TDEngine、M3DB、VictoriaMetrics、TimescaleDB 等。下面我们逐一介绍一下。

OpenTSDB

OpenTSDB 出现得较早，2010 年左右就有了，OpenTSDB 的指标模型有别于老一代监控系统死板的模型设计，它非常灵活，给业界带来了非常好的引导。

OpenTSDB 是基于 HBase 封装的，后来持续发展，也有了基于 Cassandra 封装的版本。你可以看一下它的架构图。

由于底层存储是基于 HBase 的，一般小公司都玩不转，在国内的受众相对较少，当下再选型时序数据库时，就已经很少有人会选择 OpenTSDB 了。

InfluxDB

InfluxDB 来自 InfluxData，是一个创业公司做的项目，2019 年 D 轮融资 6000 万美金，所以开发人员不担心养家糊口的问题，做的产品还是非常不错的。

InfluxDB 针对时序存储场景专门设计了存储引擎、数据结构、存取接口，国内使用范围比较广泛，而且 InfluxDB 可以和 Grafana、Telegraf 等良好整合，生态是非常完备的。不过 InfluxDB 开源版本是单机的，没有开源集群版本。毕竟是商业公司，需要赚钱实现良性发展，这个点是需要我们斟酌的。

M3DB

M3DB 是来自 Uber 的时序数据库，M3 声称在 Uber 抗住了 66 亿监控指标，这个量非常庞大。而且 M3DB 是全开源的，包括集群版，不过架构原理比较复杂，CPU 和内存占用较高，在国内没有大规模推广起来。M3DB 的架构代码中包含很多分布式系统设计的知识，是个可以拿来学习的好项目。

VictoriaMetrics

VictoriaMetrics，简称 VM，架构非常简单清晰，采用 merge read 方式，避免了数据迁移问题，搞一批云上虚拟机，挂上云硬盘，部署 VM 集群，使用单副本，是非常轻量可靠的集群方式。你可以看一下我给出的 VM 架构图。

VM 实现了 Prometheus 的 Query 类接口，即  /api/v1/query、/api/v1/query_range、/api/v1/label//values 相关的接口，是 Prometheus 一个非常好的 Backend，甚至可以说是 Prometheus 的一个替代品。其实 VM 的初衷就是想要替换掉 Prometheus 的。

TimescaleDB

TimescaleDB 是  timescale.inc 开发的一款时序数据库，作为一个 PostgreSQL 的扩展提供服务。

它是基于 PostgreSQL 设计而成的，而 PostgreSQL 生态四十年的积累，就是巨人的肩膀，很多底层的工作 PostgreSQL 其实已经完成了。就拿保障数据安全来说吧，因为程序可能随时会崩溃，服务器可能会遇到电源问题或硬件故障，磁盘可能损坏或者夯住，这些极端场景都需要完善的解决方案来处理。PostgreSQL 社区已经有了现成的高可用特性，包括完善的流复制和只读副本、数据库快照功能、增量备份和任意时间点恢复、wal 支持、快速导入导出工具等。而其他时序库，这些问题都要从头解决。

但是传统数据库是基于 btree 做索引的，数据量到百亿或者千亿行，btree 会大到内存都存不下，产生频繁的磁盘交换，数据库性能会显著下降。另外，时序数据的写入量特别大，PostgreSQL 面对大量的插入，性能也不理想。TimescaleDB  就要解决这些问题。目前 Zabbix 社区在尝试对接到 TimescaleDB，不过国内应用案例还比较少。​

上面我们罗列了业界常用的几个时序库，你可以根据需求自行选择。数据一旦进入时序库，后面就可以对接告警引擎和可视化了。

查询语言接口对告警引擎和可视化非常重要，好的查询语言可以极大释放监控数据的价值，而不好的查询语言会限制对监控数据的进一步加工和使用（有些监控系统不支持通过语句方式查询数据，应该避免选择这样的方案）。数据的查询效率会影响监控系统的使用效率，尤其在告警计算、报表生成、数据统计等使用场景下，低下的查询效率会极大影响对数据使用方式的想象空间。

告警引擎

告警引擎的核心职责就是处理告警规则，生成告警事件。通常来讲，用户会配置数百甚至数千条告警规则，一些超大型的公司可能要配置数万条告警规则。每个规则里含有数据过滤条件、阈值、执行频率等，有一些配置丰富的监控系统，还支持配置规则生效时段、持续时长、留观时长等。

告警引擎通常有两种架构，一种是数据触发式，一种是周期轮询式。

数据触发式，是指服务端接收到监控数据之后，除了存储到时序库，还会转发一份数据给告警引擎，告警引擎每收到一条监控数据，就要判断是否关联了告警规则，做告警判断。因为监控数据量比较大，告警规则的量也可能比较大，所以告警引擎是会做分片部署的，即部署多个实例。这样的架构，即时性很好，但是想要做指标关联计算就很麻烦，因为不同的指标哈希后可能会落到不同的告警引擎实例。

周期轮询式，架构简单，通常是一个规则一个协程，按照用户配置的执行频率，周期性查询判断即可，因为是主动查询的，做指标关联计算就会很容易。像 Prometheus、Nightingale、Grafana 等，都是这样的架构。

生成事件之后，通常是交给一个单独的模块来做告警发送，这个模块负责事件聚合、收敛，根据不同的条件发送给不同的接收者和不同的通知媒介。告警事件的处理，是一个非常通用的需求，而且非常零碎、复杂，每个监控系统都去实现一套，通常不会做得很完备。于是就有了专门处理这类需求的产品，最典型的比如 PagerDuty，可以接收各类事件源的事件，用户就只需要在 PagerDuty 做 OnCall 响应即可，非常方便。

对告警策略配置方式的考量，应该以灵活性和可维护性为目标。混合架构、微服服等新技术催生了更现代化的业务系统技术栈，这对告警策略的灵活性提出更高要求，告警策略应该支持条件告警、组合条件告警、同比环比、回归、线性拟合等高级功能，最好能支持基于聚类算法的告警合并（基于聚类算法的告警合并是目前业界普遍认为最有效也是最可落地的告警合并方法）；云原生、容器带来高动态的服务端环境，这样的环境需要可维护性更强的告警策略配置方式，业务环境高频甚至自动变化，缺乏可维护性的告警策略配置方式会导致监控系统的配置无法跟上业务环境的变化，不但耗费大量人力，还容易导致漏配、错配。

数据展示

监控数据的可视化也是一个非常通用且重要的需求，业界做得最成功的当数 Grafana。Grafana 采用插件式架构，可以支持不同类型的数据源，图表非常丰富，基本可以看做是开源领域的事实标准。很多公司的商业化产品中，甚至直接内嵌了 Grafana，可见它是多么流行。当然，Grafana 新版本已经修改了开源协议，使用 AGPLv3，这就意味着如果某公司的产品基于 Grafana 做了二次开发，就必须公开代码，有些厂商想要 Fork Grafana，然后进行闭源商业分发，就行不通了。

监控数据可视化，通常有两类需求，一个是即时查询，一个是监控大盘（Dashboard）。即时查询是临时起意，比如线上有个问题，需要追查监控数据，还原现场排查问题，这就需要有个方便我们查看的指标浏览功能，快速找到想要的指标。监控大盘通常用于日常巡检和问题排查，由资深工程师创建，放置了一些特别值得重点关注的指标，一定程度上可以引发我们思考，具有很强的知识沉淀效果。如果想要了解某个组件的原理，这个组件的监控大盘通常可以带给你一些启发。

API 和二次开编程接口

基础设施可编程逐渐将运维工作软件化，这股软化趋势不断向运维技术栈的上部蔓延。监控系统作为运维系统的中枢需要具有强大的 API 和二次编程接口才能与 CMDB、虚拟化环境、部署系统（CI、CD）、运维自动化系统等其它运维子系统良好配合，协同工作；孤立的监控系统会形成数据孤岛，成为运维工作流中的瓶颈点，影响运维系统的整体规划与技术演进。