Qunar容器集群监控系统架构实践

作者介绍：

一、概述

• 数据采集量大存在瓶颈，目前 Qunar 单集群容器指标量级每分钟将近 1 亿；

• 不支持水平扩容；

• 只支持 All in One 单机部署，不支持集群拆分部署；

• 其本身不适用于作为长期数据存储；

• 占用资源高；

• 查询效率低，Prometheus 加载数据是从磁盘到内存的，不合理查询或大范围查询都会加剧内存占用问题，范围较大的数据查询尤其明显，甚至触发 OOM 。

1. 兼容 PromQL 并提供改进增强的 MetricsQL ；

2. 可以直接使用 Grafana 的 Prometheus DataSource 进行配置，因为兼容 Prometheus API ；

3. 高性能 - 查询效率优于 Prometheus ；

4. 低内存 - 相较 Prometheus 低 5 倍，相较 Promscale 低 28 倍；

5. 高压缩 - 磁盘空间相较 Prometheus 低 7 倍，相较 Promscale 低 92 倍，详情可参见 Promscale VS VictoriaMetrics ；

6. 集群版可水平扩展、可数据多副本、支持多租户

• VM - Single server - All in One 单点方式，提供 Docker image ，单点 VM 可以支撑 100 万 Data Points/s。

• VM - Cluster - 集群版，拆分为了 vmselect、vminsert、vmstorage 3个服务，提供 Operate ，支持水平扩展；低于百万指标/s建议用单点方式，更易于安装使用和维护。

Qunar 单集群 Total Data points 17万亿，采用的是 VMCluster 方案。

另外对于指标采集和告警，需要单独以下组件

可选，可按自身需求选择是否使用如下组件替代现有方案。如果只是将 VM 作为 Prometheus 的远程存储来使用的话，这两个组件可忽略，仅部署 VM - Single 或 VM - Cluster ，并在 Prometheus 配置 remoteWrite 指向 VM 地址即可。

• VMagent
• VMalert

• vmstorage 负责提供数据存储服务;

• vminsert 是数据存储 vmstorage 的代理，使用一致性hash算法将数据写入分片；

• vmselect 负责数据查询，根据输入的查询条件从vmstorage 中查询数据。vmselece、vminsert为无状态服务，vmstorage是有状态的，每个服务都可以独立扩展。

• 可以直接替代 prometheus 从各种 exporter 进行指标抓取

• 相较 prometheus 更少的资源占用

• 当抓目标数量较大时，可以分布到多个 vmagent 实例中并设置多份抓取提供采集高可用性

• 支持不可靠远端存储，数据恢复方面相比 Prometheus 的 Wal ，VM 通过可配置 -remoteWrite.tmpDataPath 参数在远程存储不可用时将数据写入到磁盘，在远程存储恢复后，再将写入磁盘的指标发送到远程存储，在大规模指标采集场景下，该方式更友好。

• 支持基于 prometheus relabeling 的模式添加、移除、修改 labels，可以在数据发送到远端存储之前进行数据的过滤

• 支持从 Kafka 读写数据

• 与 VictoriaMetrics TSDB 集成

• VictoriaMetrics MetricsQL 支持和表达式验证

• Prometheus 告警规则格式支持

• 自 Alertmanager v0.16.0 开始与 Alertmanager 集成

• 在重启时可以保持报警状态

• 支持记录和报警规则重放

• 轻量级，且没有额外的依赖

• Qunar 的 VictoriaMetrics 架构

• 采集方面使用 vmagent 并按照服务维度划分采集目标分为多组，且每组双副本部署以保障高可用。各集群互不相关和影响，通过添加env、Cluster labels进行环境和集群标识

• 数据存储使用 VMcluster，每个集群部署一套，并通过 label 和 tolerations 与 podAntiAffinity 控制 VMcluster 的节点独立、vmstorage 同节点互斥。同一集群的 vmagent 均将数据 remoteWrite 到同集群 VM 中，并将 VM 配置为多副本存储，保障存储高可用。

• 部署 Promxy 添加所有集群，查询入口均通过 Promxy 进行查询

• Watcher 中的 Prometheus 数据源配置为 Promxy 地址，将 Promxy 作为数据源

• 告警方面使用了 vmalert，并在 Qunar 告警中心架构上，Watcher 团队自研添加了 Rule Manager、Prometheus Manager 两个模块。

· Rule Manager 表示的是 rule 同步模块，将规则同步至我们 Watcher Dashboard ，用于用户查看和自定义修改，便于一站式管理。同时也继续沿用原有告警实例信息同步 icinga daemon 逻辑。

· Prometheus Manager 模块主要是实现了 reciever 接口，接收 alertmanager 的 hook ，然后更改 icinga 的报警状态。

· 最后对于 vmalert 本身状态，则是采用拨测监控实现。于此以最小改动代价融入至 Qunar 现有告警中心。

• VMCluster：定义 VM 集群

• VMAgent：定义 vmagent 实例

• VMServiceScrape：定义从 Service 支持的 Pod 中抓取指标配置

• VMPodScrape：定义从 Pod 中抓取指标配置

• VMRule：定义报警和记录规则

• VMProbe：使用 blackbox exporter 为目标定义探测配置

完全替换后的表现

Qunar 容器化已将全环境集群的原 Prometheus 方案全部使用 VM 解决方案进行替换，所有的应用都是使用 VM-Operate 完成部署和管理的。

替换后其中某集群的数据表现如下：

后续准备做的几个优化

• VM 开源版本不支持 downsampling ，仅企业版中有。对于时间范围较大的查询，时序结果会特别多处理较慢，后续计划尝试使用 vmalert 通过 recordRule 来进行稀释，达到 downsampling 的效果。

• 其实很多应用如 Etcd、Node-exporter 暴露出来的指标里有些是我们并不关注的，后续也计划进行指标治理，排除无用指标来降低监控资源开销

总结

本文介绍了 Victoriametrics 的优势以及 Prometheus 不足之处，在 Qunar 替换掉的原因以及替换后的效果展示。也分享了 Qunar 对 VM 的使用方式和架构。

使用 VM 替代 Prometheus 是个很好的选择，其它有类似需求的场景或组织也可以尝试 VM 。如果要用最直接的话来形容 VM ，可以称其为 Prometheus 企业版，Prometheus Plus 。

最后，任何系统、架构都并非一劳永逸，都要随着场景、需求变化而变化；也并没有哪种系统、架构可以完全契合所有场景需求，都需要根据自身场景实际情况，本着实用至上的原则进行设计规划。