作者介绍

王坤，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，并呈上升趋势，可见下图：

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

（二）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 的架构图：

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

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 集群版。

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

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

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。

最终，任何体系、架构都并非一劳永逸，都要跟着场景、需求改变而改变；也并没有哪种体系、架构能够彻底符合一切场景需求，都需求依据本身场景实际情况，本着有用至上的原则进行设计规划。