背景

云原生监控

近几年的架构演进中，越来越多的新架构思想都是倾向于微服务、无状态、容器化的方向，支撑整个运维和运营质量的监控系统也随之发生着变化，过去一些传统的监控系统也在自我迭代中增加了许多对监控云生态的功能支持，总体适配上也算颇有成效。但考虑更加土生土长的监控方案的情况，诞生于云原生技术展的 Prometheus 绝对是一个不可忽视的选择，甚至在其发展过程中，相关功能都是与其他云原生架构相伴而生的，例如非常适合监控同为 CNCF 门下的 Kubernetes。

Prometheus 提供强大的 relabeling、PromQL、ServiceDiscovery 等能力，结合 Grafana、AlertManager 等平台可以使用丰富的图形展示、告警收敛、告警通知等，但 Prometheus 的时序存储能力和高可用方案也一直是需要人们考虑的点。时序存储可以通过冷热分离来规划，但这种行为除了增加大量的维护成本外，随着单节点的规模扩大，热数据依旧会暴露出性能瓶颈。仅使用 Prometheus 自身的方案，可以选择联邦方式来灵活拆分监控负载，再依赖一定程度的重复采集来满足高可用要求，可最上层汇聚查询的节点依旧会出现巨大的压力，而且整体的架构维护异常艰辛。

Thanos 监控

原生的 Prometheus 在高负载、高可用场景下没能提供一个令人非常满意的答卷，为此人们另辟蹊径，在基于 Prometheus 技术栈开发了 Thanos 的监控体系来弥补上述的缺点，Thanos 主要是通过 Sidecar 的模式来衔接 Promethues，将单个 Prometheus 视为独立的采集单元，把采集的时序传入到如 S3、GCS、Ceph 等接口的远程存储中保存，当需要查询时则统一调用 Query 模块来获取 PromQL 的结果，而 Query 则会通过 Storage Gateway 模块进一步的解耦对存储的操作，相关的查询数据会由网关来检索对应的 Bucket 获取，再汇聚到上层。

VictoriaMetrics 监控

Thanos 监控体系可以解决了 Prometheus 的大部分痛点，也在不少公司里落地成熟，可是实际使用中可能会发现整个架构过于复杂，即便是容器化部署也不会轻松，组件链路较长不利于故障定位，对远程存储和 Prometheus 都有外部依赖挂钩，采集端没有摒弃 Prometheus 而且需要其设置一些参数来完成 Sidecar 的适配。为此，一些社区也在尝试寻求其他更满足的监控方案，VictoriaMetrics 则是其中的佼佼者，其提供了组件可以替代 Prometheus 的采集能力，并且提供了优秀的远程存储方案，相比于 Thanos 更加的一站式。采集、上传、告警和查询的链路也比较清晰，集群版的各个组件也功能明确，对于部署和维护都比较方便。

介绍

单机版

单机版是没有扩展能力的，类似单节点 Prometheus 的模式，不过没有可视化页面，可以使用 victoria-metrics 容器镜像来快速部署，通过暴露 /victoria-metrics-data 持久化时序存储以及 promscrape.config 参数指定采集的配置文件，不支持告警功能，使用范围非常受限。根据官方给出的性能数据，单机模式可以满足如下的性能需求：

vmagent

vmagent 是集群模式下的指标采集和接收上报的组件，支持 Prometheus 的采集配置语法，并且同样支持所有的 sd 模块，可以无缝地从原生的 Prometheus 迁移采集配置到 vmagent。vmagent 支持 remotewrite 方式写入到远程存储，把收到的时序整合后发送到 vminsert 组件，当收到成功报文则会操作完成，如果响应异常就会持续发送，并把未发送成功的数据堆积到本地存储保存，直至发送写入请求成功后会将堆积消耗完毕，亦或者达到堆积上限就讲 drop 掉堆积时序。
另外，vmagent 集成了 prometheus-gateway 的接收上报功能，并提供了更加丰富的上报协议，如 promremotewrite 来作为 Prometheus 的下游中继时序存储，influx 写入 InfluxDB 的协议格式，prometheus 支持 Prometheus metric 文本上报协议等等。
vmagent 也提供了比 Prometheus 更高的性能和功能，如更低的内存消耗和丰富的 relabeling 语法等，另外可以提供多租户的形式来完成集群模式的监控采集，加上自身的无状态性，可以满足非常有效的高可用性，但同样也需要牺牲存储和性能来支撑。

vminsert

vminsert 主要的作用是接收 vmagent 的写入请求，并将其处理后序列化为 vmstorage 的协议，把时序数据推送到真正提供存储能力的远程存储里。仅仅是功能上看，在整个体系中略显单一且多余，但其通过设置 -storageNode 参数可以配置多组存储节点，通过动态摘流和一致性哈希的方式实现快速的扩容，并且自身仅依赖于 -storageNode 配置，也是无状态的一种，将此类组件挂载到 LB 下可以实现负载均衡，提升写入请求链路的吞吐。

vmstorage

vmstorage 是 VictoriaMetrics 真正的时序存储组件，将接收到的写入时序保存到本地存储，并响应由 vmselect 发起的时序查询。vmstorage 使用了 LSM 的存储架构，对于时序数据流而言非常的友好，减少磁盘的随机 IO，并且将热数据保留在内存中来提高告警查询时的响应。vmstorage 会对每个租户独立于不同目录下存储， 同样使用了倒排索引对每个租户的标签做索引，提升标签检索的性能。

vmselect

vmselect 是负责提供 PromQL 语法查询存储时序的组件，同样是多租户形式下暴露特定的 HTTP URL 来支持类似 Prometheus 语法的查询，一般是提供给 Grafana 这类监控可视化平台使用，或者是 vmalert 等告警规则执行的组件查询。组件自身只需要 -storageNode 参数来声明接入的存储节点，因而也能够在 LB 下快速扩容来满足弹性扩容。

vmalert

vmalert 是负责计算 recording-rules 和告警规则触发的组件，其定期执行配置文件里说明的规则，计算生成新的指标或者判断是否满足告警条件，因此需要同时配置写入时序的 vminsert 接口和查询时序的 vmselect 接口，并且同样支持多租户模式。其可以将告警通知渠道配置到 -notifier.* 参数中，来推送 firing 和 resolved 的告警。

集群版部署

单机版的 VictoriaMetrics 比较简单，通过部署单个容器即可体验，因此下面来部署一个简单的集群版架构，不过考虑到资源受限，因此只使用一台 64C256G 56TB 的物理服务器来部署单机多进程，模拟分布式架构。操作系统是 Ubuntu 16.04.6 LTS，VictoriaMetrics 集群的版本选用最新的 v1.65.0，工作目录为 ~/Acwork。
节点的组件端口规划如下：

首先部署存储层，先根据规划部署 vmstorage 和 vminsert 节点。设置保存时序的存储时间为1个月，限制单个查询时序的最大数量以避免繁重查询，设置好使用的内存缓存大小。

紧接着部署 vmselect 和 vmagent，设置好查询的最大超时间隔和最大并发请求数，避免 API 需要处理过大的查询。

vmagent 使用的租户 ID 是 10001，是一个可随意设置的整型，并且制定了堆积数据落盘的本地存储路径 -remoteWrite.tmpDataPath。
至此，检查组件日志无报错则表示运行正常，可以尝试采集本机的 node-exporter 来验证整个链路的可用性。对 vmagent 的配置文件添加一个 node 的静态配置：

后续将 vminsert 拉起，vmagent 堆积的数据会被快速消费掉，并且堆积指标也恢复为0，验证了 vmagent 堆积机制的有效性，这种特性可以很好的保证在空间容忍范围内存储链路的问题不会导致数据丢失。
对于 vmstorage 的高可用同样可以将单个节点 kill 来测试。

集群扩容

这里模拟存储节点出现性能或容量瓶颈而需要扩容的场景，请注意，此操作仅为实验步骤，不能用于生产环境，生产环境需要考虑上层 LB 的摘流与分流的动作，减少 vminset/vmselect 的启动时间，避免堆积过大。

然后把 vminser 和 vmselect 重启，启动时添加新的 vmstorage 节点：

后续可以继续看到新的 vmstorage 也创建了时序存储，并将数据写入到新节点中，集群总体负载降低。

高可用架构设计

以上通过架构部署、链路测试、堆积处理和高可用测试等实验，体验了 VictoriaMetrics 的集群版功能，还有很多功能需要结合组件参数配置来实现，总体来讲实用性还是非常高的。接下来继续思考一下架构的设计，如何基于 VictoriaMetrics 设计一套满足云原生、高可用、可扩展的监控系统架构呢？写入组件、查询组件和存储组件都是可以通过多节点来支持负载均衡和高可用的，通过一层 LB 就能够轻松实现，采集层的 vmagent 可以通过双采集来满足高可用，但其实 VictoriaMetrics 提供了一个特别出色的租户能力，但没有开放一个智能管理的决策系统，可以开发一个管理程序保证就可以实现不需要多采集下的 vmagent 高可用，这里可以依赖于 etcd 的分布式锁服务，而 vmalert 也亦是如此，毕竟多份的采集-会膨胀存储，多份的告警则会影响使用体验。

综合上面的设计思路，可以规划出如下的一套集群方案。

这里加入两组单机版的模块也是为了独立存储来监控下游的组件，来保证高可用节点宕机后可以及时响应，或者整体不可用时还有两组独立的监控模块可以发送告警通知。Notifier 可以编写简单的程序实现，保证锁的一致性，处理当前主机中的服务租户的关停，就可以在采集高可用时也能减少重复采集，毕竟默认的查询步长为15秒，多余的数据并没有很实际的作用。

总结

在逐步解除云生态的系统架构时，逐渐思考传统监控平台的适用性，尝试学习和使用新的监控架构，从云原生的视角出发，来发现痛点并将各个方案横纵向对比，可以快速增加对监控体系的认识。在选定一个产品后，在快速部署中实验测试产品功能，也是在身体力行中增深了对产品的熟悉，并且直观的了解此产品的优劣。同时，不断思考一个架构方案的规划，力求更高的可用性与扩展性，锻炼架构设计思维，也是非常有趣。

总的来看，VictoriaMetrics 的方案确实非常优秀，不过目前文档较少，为其背书的大公司也并不多，但社区的迭代速度还是很快的，期待后续这个产品的方案，逐渐替代 Prometheus/Thanos，也许有一天能够用在线上环境。

来源 http://mp.weixin.qq.com/s?__biz=Mzg3NTIwODE3MA==&mid=2247483815&idx=1&sn=1e5fce621510fe8e958c72c418675394&chksm=cec44d22f9b3c434cb64be769871200d425f820150c62d161a268e9ac59e5f35bcabf640bf03&mpshare=1&scene=1&srcid=0324eF85ROCPdCN0XV8Eg99Y&sharer_sharetime=1648104287008&sharer_shareid=b37f669367a61860107a8412c2f3cc74#rd