背景

中原银行自 2018 年开始从传统集中式应用架构向分布式微服务应用架构转型，2020 年开始拥抱云原生体系，实现应用、平台上云。随着架构转型的不断深入，对监控体系的要求也不断提高，本文回顾中原银行微服务平台基于 Prometheus 对微服务监控体系的一些探索和实践。

Prometheus 是 CNCF 基金会管理的第二个毕业项目（第一个是 Kubernetes），由于其良好的架构设计和完善的生态，迅速成为了监控领域的主流解决方案，尤其是在云原生领域。

随着深入地了解 Prometheus，会发现一些非常好的功能：

·生态丰富，社区活跃，开源社区建立了数百个 exporter，同时提供开箱即用的 Grafana dashboard。基本上涵盖了所有基础设施和主流中间件；

·基本上主流开发语言都有对应的工具库，工具库可从应用程序获取自定义指标；

·服务发现使配置更加容易。Prometheus 支持 consul，etcd，kubernetes 以及各家公有云厂商自动发现。对于监控目标动态发现，这点特别契合 Cloud 时代，应用动态扩缩的特点；

·Pushgateway，Alermanager 等组件，基本上涵盖了一个完整的监控生命周期。

同样 Prometheus 存在一些问题：

·Prometheus 性能不足：原生 Prometheus 并不支持高可用，也不能做横向扩缩容，当集群规模较大时，单一 Prometheus 会出现性能瓶颈，无法正常采集数据；

·运维难度大：Prometheus 监控和告警均在配置文件配置，且每个 Prometheus 都是单独管理的，缺乏全局管理工具；

·告警能力不足：缺乏 oncall 机制，告警信息持久化存储等能力。

中原银行的探索和实践

中原银行微服务团队在充分利用 Prometheus 的优势功能基础上，经过各项实践研究和分析，针对原生 Prometheus 存在的问题，增强了其集群能力，降低其运维难度，提升其告警能力，配合中原银行微服务平台提供的基础服务治理体系，逐步将 Prometheus 打造为云原生领域的监控利器，构建出中原银行企业级监控体系。

一、Prometheus 集群能力增强

Prometheus 自身的时序数据库 TSDB 是一个单机数据库，不支持分布式是其天生的劣势。当保存 metrics 数量足够多的时候，单机 Prometheus 就显得捉襟见肘。Prometheus 中的内存使用量与存储的时间序列数量成正比，并且随着时间序列数量的增加，Prometheus 会 OOM。具有数百万个指标的 Prometheus 可以使用超过 100GB 的 RAM，但是受限于主机本身的大小，无法不断的通过纵向调整机器大小来解决这个问题。因此解决 Prometheus 的扩展性，是打造企业分布式监控平台的关键。

Prometheus 官方的解决方案是联邦，主要提供了分层联邦和跨服务联邦（联邦官方文档）。本质上就是采集级联，说白了就是 a 从 b,c,d 那里再采集数据过来，其实有很大的问题，本质上 Prometheus 的单机能力依旧没有得到解决。

在实践探索过程中，团队最初的方案是利用 remote_read 功能，将 Prometheus 分为查询节点和采集节点，来解决高可用和全局查询的问题。采集节点按模采集监控指标并触发告警，查询节点从各个采集节点查询并 merge 数据，不存储数据。

这种架构同样有一些不可避免的缺点：

·并发查询必须要等最慢的那个返回才返回，所以如果有个慢的节点会导致查询速度下降。

·应对重查询时可能会把 query 打挂，但也正是这个特点，会很好的保护后端存储分片，重查询的基数分散给多个采集器了。

·由于是无差别的并发 query，也就是说所有的 query 都会打向所有的采集器，会导致一些采集器总是查询不存在他这里的数据。

随着监控节点的不断增加，开始遇到了性能瓶颈，在做一些重查询，比如 api 网关接口耗时 topN 时，查询速度缓慢，甚至 qurey 节点 OOM。所以微服务团队继续进行架构调整以适应不断提升的监控需求。

针对 Prometheus 的集群扩展问题，业内主要有远端存储和开源监控套件两类解决方案：

1. 远端存储：借助 prometheus remote_write API 将监控数据写入远端存储（通常是分布式时序数据库如 influxDB、M3DB、VictoraMetrics 等），prometheus 负责采集和告警，存储和查询使用远端存储。

2. 监控套件：业内为了解决 prometheus 集群功能欠缺的问题，开发了 Thanos 、Cortex 等监控套件（依赖于对象存储），与原生 Prometheus 结合，满足了长期存储 + 无限拓展 + 全局视图 + 无侵入性的需求。

微服务团队重点调研测试了 VictoriaMetrics 和 Thanos 两个解决方案。

Thanos

Thanos 也是一个 CNCF 基金会下管理的项目。Thanos 利用 Prometheus 2.0 存储格式以经济高效的方式将历史指标数据存储在任何对象存储中，Thanos 整体架构图如下：

从架构图就可看出其组件比较复杂，这里就不在一一赘述，有兴趣的同学可以到其官网了解。Thanos 解决了 Prometheus 的集群缺失问题，与原生 Prometheus 结合，满足了长期存储 + 无限拓展 + 全局视图 + 无侵入性的需求，但维护成本比较高，如果你在一些非云的环境中，需要自己提供一套对象存储。

VictoriaMetrics

VictoriaMetrics 是一种快速，经济高效且可扩展的时间序列数据库，可用作 Prometheus 的长期远程存储。

VictoriaMetrics 包括了如下的组件：

·vmstorage -- 存储数据。

·vminsert -- 通过 remote_write API 接收来自 Prometheus 的数据并将其分布在可用的 vmstorage 节点上。

·vmselect -- 通过从 vmstorage 节点获取并合并所需数据，通过 Prometheus 查询 API 执行传入查询。

VictoriaMetrics 是一种无共享架构（Shared-nothing_architecture），每个组件可以使用最合适的硬件配置独立扩展到多个节点。

整体架构图如下：

该系统的优势是架构简单，提供单节点和集群两种部署模式，无需额外组件，启动二进制文件即可完成部署。扩展性好，集群模式下，各个组件可独立扩容。性能优异，借鉴 clickhouse 的思想的列式存储，官方测试相较 Prometheus 和 Thanos 数据压测 7 倍，在写入和查询性能上相比 InfluxDB 和 TimescaleDB 有 20 倍的性能优势；在处理百万级别时间序列时，内存使用比 InfluxDB 小十倍，比 Prometheus、 Thanos 小七倍。

项目组在测试环境虚拟机（8C32G）搭建 VictoriaMetrics 单节点应用，秒增 5 万数据点的压力下，CPU 平均使用率 5%，峰值 15%，内存平均 6.75G，峰值 8.5G；预铺 30 天数据，查询耗时 99%峰值 3s。

总的来说，Thanos 和 Victoriametrics 均对 Prometheus 生态有较好的兼容性，支持 promtheus 查询 api，支持全局查询视图，支持 prometheus HA 去重。Thanos 组件比较复杂，维护成本比较高，如果公司已有对象存储，或在公有云部署可以省去对象存储的运维工作。VictoriaMetrics 架构简单，性能优异，也有较好的可扩展性和高可用性。

团队最终选择 VictoriaMetrics 作为 Prometheus 数据的持久化存储和查询数据库。逻辑架构如下图所示：

项目组在生产环境中使用四台中配虚机（4C16G）部署 insert 和 select 节点，三台高配虚机（8C32G）部署 storage 节点，单副本存储，搭建 VM 集群。另外仅需在 Prometheus 配置中增加远程写，Grafana 中修改数据源，即可完成整体架构升级。升级之后，在秒增 10 万数据点压力下，长期运行稳定无异常。最终以较小的投入，实现了业务目标。

二、通过服务发现简化运维

Prometheus 提供多种客户端配置方式，包括服务发现，静态文件等。在目前云原生环境下，应用具备高度弹性，通过静态配置监控目标的行为是多么的低效。所以需要尽可能的通过服务发现来管理客户端列表。

借助于架构转型，全行使用统一的 springcloud 技术栈，注册中心为 Eureka，为了兼容 Prometheus 服务发现，微服务团队对 Eureka 进行二次开发使其能够模拟 Consul 的服务注册发现 API（2.21.0 版本后以支持 Eureka SD），简化 server 端配置。

微服务监控主要分为资源监控和应用监控，资源监控指服务所在主机、虚机或容器的运行状态如 cpu、内存、网络等，应用监控指标是应用的运行状态如接口响应时长，线程池情况，jvm 运行情况等。

资源监控方面，微服务团队对社区的 NodeExporter 进行定制化开发，使其可以通过 Eureka 进行服务发现。

应用监控方面，除了利用社区 JmxExproter，微服务团队又提供了一套标准化的应用监控 SDK，即插即用，提供了丰富的应用状态监控指标，包括节点运行情况，接口运行情况，线程池运行情况，JVM 运行情况，队列监控，信号量监控和熔断监控。

在此基础上，微服务团队这提供标准的容器镜像，内置所需的各种 agent 或 exporter，使业务应用无需关注基础监控功能。

三、统一告警管理

Prometheus 官方提供了告警组件 AlterManager 进行告警管理，AlertManager 用于处理客户端应用程序（如 Prometheus）的警报。AlterManager 支持分组，抑制，静默等特性，它还负责将其发送给下游处理（例如电子邮件，Slack，Pager Duty）。

Alertmanager 虽然已经比较优秀了，但是在落地的过程中，存在以下问题：

·缺失个性推送。做为企业级应用，不同应用的告警信息需要推送到对应的 oncall 人员。

·告警规则变更需要逐个修改 Prometheus 配置文件，告警配置繁琐，运维压力大。

·Alertmanager 虽然支持许多通知方式，但企业会有自身的告警通知方式，如：不支持中原银行的统一告警平台和员工 APP。

·此外，一个完善的报警系统，势必要支持报警分析，针对过去时间维度的报警，做一些比如 topK 的分析，有助于指导运维方向。目前 Alertmanager 没有将历史报警做持久化处理。

为了解决以上问题，需要对 Prometheus 监控体系进行扩展。一种方案是 fork 源码，扩展功能，另一种是增加自有组件来扩展功能。考虑到社区的快速迭代，产品后续的持续更新，以及技术栈的差异，中原银行选择了增加自有组件来扩展功能。

中原银行微服务平台提供了功能完善的服务治理体系，构建了注册中心、配置中心、认证中心等基础组件，借助这些组件可以方便的对 Prometheus 告警体系进行增强。微服务团队开发了 Prometheus-agent 和 MspAlter 来增强告警功能，达到企业级要求，架构如下如所示。

同时在管理平台抽象出了告警应用、告警模板、告警函数、告警规则等概念，屏蔽了 Prometheus 的 rule 表达式，实现了告警规则的可视化流程化设置。如下图所示，选择一个微服务和模板即可生成告警规则。

管理平台进一步将翻译后的告警规则下发至 apollo 配置中心，Prometheus-agent 监听配置变化，实时修改 Prometheus 配置文件，做到告警配置的自动化下发、实时生效。

MspAlter 组件对 AlterManager 推送的告警做进一步的处理，包括告警过滤，定时开启告警，告警持久化存储，告警信息格式转换以适配统一告警平台和员工 APP，以及根据告警来源推送至对应人员等功能。下图为员工 APP 中收到的告警信息。

总结与展望

未来 Prometheus 生态体系仍将是云原生监控的主流解决方案，团队将继续拥抱开源社区，持续改进优化产品功能。架构的演进不是一蹴而就的，随着业务的增长，当时合理的一些决策，在当前的场景下会变得不再适用，企业级的落地要根据自身场景，做出适当的扩展和选型。未来随着 target 数量的增长以及种类的增多，Prometheus 节点的动态扩容和 target 的动态调度是目前面临的一个痛点，也是后续需要重点解决的问题。

在应对复杂系统及其构成的复杂系统集合的故障排查需求时，单独的监控数据难以满足系统故障快速定位的要求，无法达到系统整体的可观测性，亟需打通 Metrics、Logs、Traces 壁垒，整合各方能力，提升系统可观测性，实现生产问题的快速精确的定位。

参考文献

[1]https://github.com/tkestack/kvass/blob/master/README_CN.md；

[2]https://prometheus.io;

[3]https://www.zhihu.com/people/iyacontrol;

[4]https://docs.victoriametrics.com

本文转载自原银科技微信公众号

原文链接：基于Prometheus的企业级监控体系探索与实践