Prometheus 是什么？

时序数据库 Prometheus 可以说是云原生趋势下广为使用的成熟开源产品。依靠 Kubernetes 丰富的生态支持、广泛的云厂商的产品兼容与集成、深厚的运维管控经验沉淀、灵活多样的现有中间件的指标采集插件等功能，Prometheus 日益成为各厂在应用监控（APM--Application Performance Monitoring）领域的标准解决方案。

Prometheus 的简要架构如下所示。其中，应用程序引入 Prometheus Client SDK 进行业务埋点暴露指标上报接口（第三方组件可使用 Exporter 暴露内部指标）。Prometheus 根据配置的 Client 接口地址或基于服务发现去拉取应用的指标，再写入到本机的存储中。其中，我们可配置指标的重写（relabel）规则进行指标增强，也可以配置远程写入（remote write）将数据写入其他存储系统。

Prometheus 同样支持报警。用户可通过灵活强大的 PromQL 配置报警规则，触发后通过 AlertManager 组件将报警推送到用户配置的接收渠道。

数据持久化方案

在官方设计之初，Prometheus 并未定位成指标数据的长期存储，其单实例的容量受限于部署节点的硬件容量。因此，业界有众多成熟的指标持久化的解决方案，例如：Cortex、InfluxDB、M3、Thanos、VictoriaMetrics 等。这里简要介绍下 VictoriaMetrics。

VictoriaMetrics 其中将指标采集、指标查询、指标存储、报警等划分成独立的组件，分别兼容 Prometheus 的功能与 API，并在众多实现细节上比 Prometheus 更精巧。在内存用量、CPU 用量、磁盘 IOPS 等性能指标上，VictoriaMetrics 都显著优于 Prometheus（Promscale vs VictoriaMetrics: measuring resource usage in production）。

并且，相对于其他持久化方案，VictoriaMetrics 不需要部署 Sidecar，没有特殊的一致性协议、没有额外的第三方依赖。基于这些考虑，在指标长期存储选型上 VictoriaMetrics 优于其他方案。

Prometheus 在货拉拉使用情况

货拉拉的选择

作为一家货运物流行业的独角兽企业，货拉拉同样选择基于 Prometheus 来构建相关应用监控的底层数据基座。在数据持久性和扩展性方案上，我们选择使用 VictoriaMetrics 作为持久化存储，此时的指标监控系统的的逻辑架构如下所示：

由于货拉拉有着多样化的开发技术栈，我们基于开发语言划分到多个 Prometheus 去采集指标（既有机器内存用量的考虑，也能针对性进行采集配置），另还有多套 Prometheus 供独立业务部门（如，风控、安全、端上应用等）专用。

这些 Prometheus 统一通过“Remote Write”机制写入到 VictoriaMetrics 集群。应用监控系统查询指标是通过 vm-select 组件获取数据。

其中的问题

Prometheus 配置难管且难迁移

如前文，货拉拉仅生产环境，就部署着十多套 Prometheus 集群（共计上百核上千 G 内存的资源）。由于业务飞速增长，Prometheus 配置变更与升级、机器迁移的场景经常发生，都需要人工进行配置校对和验证。集群划分调整时，对应的采集规则也要调整，也是费时费力，极易出错。

因此，亟需一个集中化的、白屏化的、用户友好的 Prometheus 配置管理系统，解决 Prometheus 的日常运维和管理难题。

异常查询经常拖垮存储

即使已经将查询的压力转移到 VictoriaMetrics 的 vm-select 上，仍会因为异常埋点（如 Label 过多、结果集太大）的大时间跨度查询造成 VictoriaMetrics 抖动。在 VictoriaMetrics 紧急故障需要降级时，我们同样束手无策，只能简单粗暴的停止写入或停止查询。vm-select 的地址暴露出去后，各种“民间”的 Grafana 就可以配置查询，偶尔会造成系统异常抖动。

因此，亟需针对 Prometheus 和 VictoriaMetrics 的查询增强、查询限流、查询降级等功能，提升监控系统的稳定性。

居高不下的内存压力、计算压力

由于历史原因，大量使用老版本的中间件会上报多余的（如已废弃不用的）、复杂的(如，SQL）的 指标和 Labels，给 Prometheus 带来巨大的计算压力、内存压力。

其次由于多语言版本的 SDK 的实现偶有差异，应用集成 SDK 进行升级迭代周期不尽相同，往往兼容几个“钉子户”需要保留众多遗留的指标采集配置，Prometheus 的 relabel 配置也带来巨大的维护压力。

因此，亟需一个 Prometheus 的采集代理，让这个代理屏蔽多版本、多语言的埋点差异，并将 relabel 的维护工作抽离出来。

我们提出的解法 ：SHANGFU

所以，为了解决日常使用与运维 Prometheus 集群中的多个痛点，我们自主设计实现了一套 Prometheus 集群配置管理、采集管理、查询增强的系统--SHANGFU，中文名为 "尚付"。

“尚付”源自《山海经·南山经》：有鸟焉，其状如鸡而三首、六目、六足、三翼，其名曰尚付，食之无卧。

尚付有三头，正好对应该系统的三大模块：采集代理模块、查询代理模块、Prometheus 集群管理模块。虽然神话中说尚付能令人不睡觉，但我们希望 SHANGFU 这套系统能让人安心睡觉，不再因为 Prometheus 的运维和治理工作夜不能寐。

逻辑架构设计

SHANGFU 由一个 Server 服务提供查询代理、采集代理、Prometheus 集群管理的功能，另一个为 UI 服务提供可视化界面供用户查看集群和调整 Prometheus 配置。它们都部署于 Kubernetes 中，通过预先配置的域名对外提供服务。

物理部署架构设计

SHANGFU Server 和 SHANGFU UI 都是无状态的。极端情况下，某台 SHANGFU Server 如果挂掉，因我们已配置了“双份 Prometheus 同时采集指标机制”，即使该失联的 SHANGFU Server 导致采集失败，另外存活的 SHANGFU Server  会补上，保证采集的数据不丢。并且，依赖 Kubernetes 的健康检查与恢复机制，SHANGFU 整体服务可快速恢复。其次，基于 Kubernetes 的架构，SHANGFU 能根据请求与负载实现快速扩容，快速启动，快速服务。

高可用性设计

如果单机故障，基于域名（SLB）的探活机制，新请求自动会切换到存活的节点上。但如果所有实例均服务不可用，确实会造成监控数据查询失败或监控数据丢失。如果SHANGFU 服务长时间无法恢复，那么紧急方案是手动调整 Prometheus 或上游查询服务的配置，降级回原始的架构。大多数成熟企业有着健全的灰度发布机制以及监控应急手段，这样所有实例均不可用的情况极端情况基本不会发生。

SHANGFU 各模块详细说明

采集代理模块

使用 Prometheus 提供的"relabel_config"配置将采集目标改写，SHANGFU 能够代理数据采集过程，并添加自定义的逻辑后再返回给 Prometheus。

如下图所示的处理流程，应用上报的指标在 SHANGFU 中解析处理成增强过的新指标：（1）移除不再使用的 Labels；（2）将 LabelValue 统一化，消除不同版本、不同语言 SDK 在埋点实现时的差异；（3）将数值进行聚合计算。

这样，SHANGFA 同时将新指标与原始指标一并转发给 Prometheus。在货拉拉监控系统中，用户实际使用的是这些新指标，原始指标保留仅供遗留系统查询。

采集代理模块的另一重作用是突破 Prometheus 原生的采集限制（如，body_size_limit

参数可以保护 Prometheus 内存使用，但限制了从 Agent 端采集的数据大小）。采集代理模块可以过滤废弃指标，并精简上报数据。

查询代理模块

在货拉拉的使用场景，SHANGFU 主要针对 VictoriaMetrics 进行了查询定制和查询函数扩展，在也能兼容 Prometheus 原生的查询函数。我们实现了如下功能：

• 查询管理上：

• 多样化的限流和封禁手段：可根据查询 IP、指标名、请求头Header 等手动封禁恶意查询来源，保护整体服务可用。

• 提供代理后的数据域名，隐藏真实的 Prometheus 或 VictoriaMetrics 的服务地址。

• 查询降级：可依场景（如查询时间范围、指标类型）进行精细化降级，直接返回空结果集。降级范围的查询不受影响。

• 查询优化上：

• 元数据预加载：针对已知的指标（如超大的中间件指标），直接返回已加载好的元数据（LabelName)，避免频繁和缓慢的查询。

• Label Value 默认限制：同样如超大的中间件指标，进行 Label Value 过滤选择时，查询自动添加查询上限，避免全量数据返回。

• Series 默认限制：在以“Group by”查询时，如果不加限制，可能动辄返回几百上千条数据曲线，用户也难以查看。因此这类查询会默认添加“topk_max”函数。

• 查询模版：监控系统的前端上常有固定但复杂的中间件指标查询场景，而在采集模块中，中间件的指标又被 SHANGFU 增强改写成了新指标。为了解耦前端与采集模块的强依赖，前端仅使用定制的简化查询 QL 模版语句，由查询代理模块将起解释成具体的查询语句。

• 查询加速：

• 查询缓存：解析查询语句并哈希后，转发到固定的 vm-select 集群的实例上，利用其自身的缓存机制，加速查询。

• 查询聚合：针对某些特殊查询的重复请求，并非立刻全部执行查询，而是在较短的时间窗口内，只执行第一次查询，其余请求等待并复制其结果再返回。在几百人同时访问监控大屏的场景中，这个机制能显著减少对 VictoriaMetrics 的查询请求量。

• 指标自动转换：将中间件的指标自动转成采集代理模块生成的对应指标，能大幅加速查询，下文将做详述。

• 自身管理

• 健康检查：SHANGFU Server 之间互相探活。

• 内部管理页面：展示目前 SHANGFU Server 集群状态、工作负载等信息，集成降级开关等便捷操作页面。

这里以查询指标的自动转换为例，展示经过采集代理模块的指标增强和查询代理模块自动的查询指标转换后，扫描的数据点数减少 83%，查询时间从 3.8 秒减少到 203 毫秒，快了95%。

Prometheus 集群管理模块

在 Prometheus 集群管理模块中，SHANGFU 提供了一个便利易用的用户界面。用户通过 SSO 登录后可以查看各 Prometheus 集群概览、具体规则配置的管理。Prometheus 的配置文件（conf.yaml）包括：采集、服务发现、认证方式、远程读写等等数十个配置项。

SHANGFU 将常用配置项抽离成单个条目，反向关联到实际的 Prometheus 上，再由 SHANGFU 生成完整的配置文件，写到机器上制定目录下。如此，某些通用的配置，只用在 SHANGFU 上修改一遍，就能手动同步到所有相关 Prometheus 令其生效。下图为某个 Prometheus 关联子配置项的页面。

下面 4 张图为采集任务、规则转换、远程写入、认证方式等配置的编辑和查看页面。

此外，配置导入和导出、配置在不同 Prometheus 上迁移、配置回滚等操作，用户只需在白屏化的界面中就能执行，省去了依次登陆机器直接修改文件的繁琐，也避免了可能的手工操作失误。下图为操作日志的审计页面。

总结

综上，SHANGFU 通过功能丰富的采集代理、查询代理、Prometheus 集群管理三个模块，解决了我们日常在指标监控使用和日常集群运维上的痛点，为监控系统的稳定性和效率提供了巨大帮助。

展望

目前 SHANGFU 这套系统，已经在货拉拉落地使用了 1 年。它可兼容现有 Promehteus 生态，解决日常 Prometheus 集群运维的难点、指标查询又慢又不稳定的问题、采集数据杂乱导致 Prometheus 不稳定的症结，提升了整体监控指标底层的管控能力，增加了指标系统的稳定性。

当然，我们仍有一些规划中未来得及实现的特性，希望日后能继续增强 SHANGFU 系统。例如：

• 与 CMDB 深度集成，根据应用特性与实时负载，将采集元数据动态分组，增强采集自适应能力；

• 根据应用归属进行指标租户化管理，提供差异化的可靠性服务；

• 引入流式计算层，进行查询、告警加速；

• 进一步将指标标准化，简化 PromQL 使用难度

• ……

想做的太多，精力却有限。接下来，我们将继续打磨和开发  SHANGFU 系统，争取将它从货拉拉开源出来，贡献到整个社区，为每位 Prometheus 的使用者提供些许帮助。