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

2022-12-21 00:00:00 数据 集群 架构 指标 告警

作者介绍：



王坤，2020年加入去哪儿网，系统运维工程师、去哪儿云原生SIG、基础设施SIG成员，目前主要负责Kubernetes、容器指标监控等系统的运维和云原生相关工作。

一、概述

在云原生的体系下，面对高弹性、拆分微服务以及应用动态生命周期等特点，传统监控体系如 cacti 、nagios 、Zabbix 等已经逐渐丧失了优势，难以适用和支撑，对应的新一代云原生监控体系应运而生，Prometheus 为核心的监控系统已成为云原生监控领域的事实标准。
之前公司有文章介绍过，Qunar 内部的一站式监控平台，后端存储是基于 Graphite+Whisper 做的二次开发，前端控制面是基于 Grafana 做的二次开发。而 Grafana 是支持多数据源的，其中就包含 Prometheus 数据源。所以在容器化落地期间初计划采用的监控方案也是 Prometheus ，其本身是个 All in One 的系统，拥有强大的 PromQL ，集采集、处理、存储、查询、rule检测于一身，非常易于部署和运维。但每个系统都不是完全能够契合使用需求的，Prometheus 也一样不是完美的。
该文章将以 Qunar 容器监控实践过程和经验为基础，讲述我们监控体系构建、遇到的挑战和相应对策，以及对 VictoriaMetrics 的简单介绍与 Qunar 在过渡至 VictoriaMetrics 后的效果。
二、使用Prometheus的相关问题
Prometheus 是个 All in One 的系统，集采集、处理、存储、查询、rule 检测于一身，这样做易于部署和运维，但也意味着丧失了拆分组件所具备的独立性和可扩展性。实践测试摘录的几个问题如下：

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

  • 不支持水平扩容；

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

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

  • 占用资源高；

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

如上例举的几项问题点，其实对于大多数公司来讲都不是问题，因为没有那么大的数据量和需求。但是对于我们或一些数据规模较大的公司来讲，每一项都在对我们的使用环境说 No...  我们也对这些问题尝试了以下解决方案：
使用分片，对 Prometheus 进行按服务维度分片进行分别采集存储。默认告警策略条件是针对所有 Targets 的，分片后因每实例处理的 Targets 不同，数据不统一，告警规则也需要随着拆分修改。
使用 HA ，也就是跑两个 Prometheus 采集同样的数据，外层通过负载均衡器进行代理对其实行高可用
使用Promscale作为其远程存储，保留长期数据注：Promscale是 TimescaleDB 近两年发布的一个基于 TimescaleDB 之上的 Prometheus 长期存储。
但做了这些处理后，其实还是留存问题，也有局限性和较大隐患：
例如 2 个实例，1、2 同时运行采集相同数据，他们之间是各自采集各自的没有数据同步机制，如果某台宕机一段时间恢复后，数据就是缺失的，那么负载均衡器轮训到宕机的这台数据就会有问题，这意味着使用类似 Nginx 负载均衡是不能够满足使用的。
各集群 2w+ Targets，拆分 Prometheus 后可以提升性能，但依然有限，对资源占用问题并未改善。
远程存储 Promscale 资源占用极大，40k samples/s，一天 30 亿，就用掉了将近16 cores/40G 内存/150GB 磁盘。而我们单集群1.50 Mil samples/s，一天就产生 1300 亿左右，而且需求数据双副本，这样的资源需求下如果上了线，仅磁盘单集群 1 天就要耗费 12TB 左右，这样的代价我们是表示有些抗拒的。。
三、接触 VictoriaMetrics
在为调整后面临到的这些难点，进行进一步调研，结合 Qunar 自身经验和需求参考各类相关文档以及各大厂商的架构分享时，我们注意到了 VictoriaMetrics ，并在其官网列出的诸多用户案例中，发现知乎使用 VictoriaMetrics 的数据分享与我们的数据规模量级几乎一致，而且性能与资源表现都相当优异，非常符合我们期望需求，便开始了 VictoriaMetrics 的尝鲜旅程，也归结出适合我们生产场景的云原生监控体系架构，并在后续工作中通过使用测试完全满足我们需求，进行了全面替换使用。
在此，先对 VictoriaMetrics 进行介绍，也推荐给大家对 VictoriaMetrics 进行了解和使用，后面也会贴出我们的使用架构和效果展示。
（一）VictoriaMetrics 介绍
VictoriaMetrics （后续简称 VM ）是一种快速、经济高效且可扩展的监控解决方案和时间序列数据库，它可以仅作为 Prometheus 的远程写入做长期存储，也可以用于完全替换 Prometheus 使用。
Prometheus 的 Config、API、PromQL，Exporter、Service discovery 等 VM 基本都能够兼容支持，如果作为替换方案，替换成本会非常低。
在 DB-Engines - TSDB 的排行中，VM 当前排名为 Top 15，并呈上升趋势，可见下图：

（二）VictoriaMetrics特点
可以作为 Prometheus 的长期数据存储库

  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. 集群版可水平扩展、可数据多副本、支持多租户
（三）VictoriaMetrics 架构
VM 有两类部署方式，都非常简单，如果对 Prometheus 有一定基础，整个替换过程会非常顺滑，这里就不对安装进行细述了。

  • 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
vmcluster 架构图
vm-single 特别简单不做赘述，这里说下 vm-cluster，vmcluster 由以下 3 个服务组成：

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

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

  • vmselect 负责数据查询，根据输入的查询条件从vmstorage 中查询数据。vmselece、vminsert为无状态服务，vmstorage是有状态的，每个服务都可以独立扩展。
vmstorage 使用的是 shared nothing 架构，节点之间各自独立互无感知、不需要通信和共享数据，由此也提升了集群的可用性，降低运维、扩容难度。
如下为官网提供的 vmcluster 的架构图

vmagent
vmagent 是一个轻量的指标收集器，可以收集不同来源处的指标，并将指标存储在vm或者其他支持 remote_write 协议的 Prometheus 兼容的存储系统。
建议通过VM Operate进行管理，它可以识别原Prometheus创建的  ServiceMonitor、PodMonitor 等资源对象，不需要做任何改动直接使用。
vmagent具备如下特点（摘要）：

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

  • 相较 prometheus 更少的资源占用

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

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

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

  • 支持从 Kafka 读写数据
vmalert
前面说到 vmagent 可用于替代 Prometheus 进行数据采集，那么 vmalert 即为用于替代 Prometheus 规则运算，之前我们都是在 prometheus 中配置报警规则评估后发送到 alertmanager，在 VM 中即可使用 vmalert 来处理报警。
vmalert 会针对 -datasource.url 地址执行配置的报警或记录规则，然后可以将报警发送给 -notifier.url 配置的 Alertmanager 地址，记录规则结果会通过远程写入的协议进行保存，所以需要配置 -remoteWrite.url 。
建议通过VM Operate进行管理，它可以识别原Prometheus创建的 PrometheusRule、Probe 资源对象，不需要做任何改动直接使用。
vmalert具备如下特点：

  • 与 VictoriaMetrics TSDB 集成

  • VictoriaMetrics MetricsQL 支持和表达式验证

  • Prometheus 告警规则格式支持

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

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

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

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

  • Qunar 的 VictoriaMetrics 架构
Qunar 的 VictoriaMetrics 架构
按照官网建议数据量低于 100w/s 采用 VM 单机版， 数据量高于 100w/s 采用 VM 集群版，根据 Qunar 的指标数据量级，以及对可扩展性的需求等，选择使用了 VM 集群版。

  • 采集方面使用 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 现有告警中心。

建议使用 vm-operate 进行部署和管理，它实现了如下几项 CRD 

  • VMCluster：定义 VM 集群

  • VMAgent：定义 vmagent 实例

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

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

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

  • VMProbe：使用 blackbox exporter 为目标定义探测配置
同时默认也可以识别 prometheus-perate 实现的 Servicemonitor 、 PodMonitor 、PrometheusRule 、Probe 这些 CRD ，开箱即用平滑接替 Prometheus 

完全替换后的表现

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

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

Active time series ~28 Million
Datapoints ~17 Trillion
Ingestion rate ~1.6 Million/s
Disk usage ~8 TB
Average query rate ~450/s
Query duration median is ~300ms, p99 ~200ms

后续准备做的几个优化

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

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

总结

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

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

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

相关文章