什么是商城网站建设,中小企业网站提供了什么,想在网上做外卖 上什么网站好,动漫做视频在线观看网站一、概述
在云原生的体系下#xff0c;面对高弹性、拆分微服务以及应用动态生命周期等特点#xff0c;传统监控体系如 cacti 、nagios 、Zabbix 等已经逐渐丧失了优势#xff0c;难以适用和支撑#xff0c;对应的新一代云原生监控体系应运而生#xff0c;Prometheus 为核…一、概述
在云原生的体系下面对高弹性、拆分微服务以及应用动态生命周期等特点传统监控体系如 cacti 、nagios 、Zabbix 等已经逐渐丧失了优势难以适用和支撑对应的新一代云原生监控体系应运而生Prometheus 为核心的监控系统已成为云原生监控领域的事实标准。
之前公司有文章介绍过Qunar 内部的一站式监控平台后端存储是基于 GraphiteWhisper 做的二次开发前端控制面是基于 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、PromQLExporter、Service discovery 等 VM 基本都能够兼容支持如果作为替换方案替换成本会非常低。
在 DB-Engines - TSDB 的排行中VM 当前排名为 Top 15并呈上升趋势可见下图
二VictoriaMetrics特点
可以作为 Prometheus 的长期数据存储库 兼容 PromQL 并提供改进增强的 MetricsQL 可以直接使用 Grafana 的 Prometheus DataSource 进行配置因为兼容 Prometheus API 高性能 - 查询效率优于 Prometheus 低内存 - 相较 Prometheus 低 5 倍相较 Promscale 低 28 倍 高压缩 - 磁盘空间相较 Prometheus 低 7 倍相较 Promscale 低 92 倍详情可参见 Promscale VS VictoriaMetrics 集群版可水平扩展、可数据多副本、支持多租户
三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-clustervmcluster 由以下 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 MillionDatapoints~17 TrillionIngestion rate~1.6 Million/sDisk usage~8 TBAverage query rate~450/sQuery durationmedian is ~300ms, p99 ~200ms
后续准备做的几个优化 VM 开源版本不支持 downsampling 仅企业版中有。对于时间范围较大的查询时序结果会特别多处理较慢后续计划尝试使用 vmalert 通过 recordRule 来进行稀释达到 downsampling 的效果。 其实很多应用如 Etcd、Node-exporter 暴露出来的指标里有些是我们并不关注的后续也计划进行指标治理排除无用指标来降低监控资源开销
总结
本文介绍了 Victoriametrics 的优势以及 Prometheus 不足之处在 Qunar 替换掉的原因以及替换后的效果展示。也分享了 Qunar 对 VM 的使用方式和架构。
使用 VM 替代 Prometheus 是个很好的选择其它有类似需求的场景或组织也可以尝试 VM 。如果要用直接的话来形容 VM 可以称其为 Prometheus 企业版Prometheus Plus 。
后任何系统、架构都并非一劳永逸都要随着场景、需求变化而变化也并没有哪种系统、架构可以完全契合所有场景需求都需要根据自身场景实际情况本着实用至上的原则进行设计规划。
