查看原文
其他

云原生监控--VictoriaMetrics 之基础篇

陈子榕 道客船长 2024-03-08




说到云原生监控方案,第一时间基本上都会想到 Prometheus+AlertManager+Grafana 的一套成熟解决方案。Prometheus 作为监控核心,具备强大的数据模型、高效率运作、丰富的监控能力、强大的查询语言 PromQL、简单易用、管理方便等特点。但是 Prometheus 目前在高可用层面上做得还并不完美。为此,在开源社区中,孕育出了许多替代、增强方案,VictoriaMetrics 属于其中较为优异的一个,是一个快速、经济高效且可扩展的监控解决方案和时间序列数据库。

01

七大特点

1. 它可以作为 Prometheus 的长期储存,且支持 Prometheus 查询 API,可以在 Grafana 中用作 Prometheus 的代替品;

2. 部署简单,无论是单节点版本还是集群版本,都只需要运行所需的组件可执行文件(每个组件都是一个可执行文件),运行前不需要安装任何依赖,易于设置和操作;

3. 使用 vmbackup/vmrestore 工具可以轻松快速地将即时快照备份到 S3 或 GCS;

4. 基于 PromQL 的查询语言实现 MetricsQL,对 PromSQL 进行改造;

5. 读写性能比 InfluxDB 和 TimescaleDB 高达 20 倍;百万时间序列数据下,内存使用比 InfluxDB 少 10 倍,比 Prometheus、Thanos 或 Cortex 少 7 倍;数据高压缩,与 Prometheus、Thanos 或 Cortex 相比,所需的存储空间最多可减少 7 倍;

6. 具有高延迟 IO 和低 IOPS;

7. 支持从第三方时序数据库获取数据源。

1.1. 快速接入 Prometheus 获取数据源

数据源接入层面,VictoriaMetrics 支持通过 Prometheus 的远程写入方式直接兼容 Prometheus 的数据写入,同时也支持搜集多个 Prometheus 数据汇总。

remote_write:
  - url: http://<victoriametrics-addr>:8428/api/v1/write
 
# 多个proemtheus的话,需要配置每个Prometheus的标识符
global:
  external_labels:
    datacenter: dc-123

VictoriaMetrics 还支持直接取代 Prometheus 进行 exporter 搜集。

使用-promscrape.config配置Prometheus的prometheus.yml

针对 Prometheus,VictoriaMetrics 进行了一些优化:

1. 增加了 “extra_label=<label_name>=<label_value>” 可选的查询支持,可用于基于额外标签进行查询过滤。例如“/api/v1/query_range?extra_label=user_id=123&extra_label=group_id=456&query=<query>”,会返回额外标签中包含“{user_id="123",group_id="456"}”的结果;

2. 增加了 “extra_filters[]=series_selector“ 可选的查询支持,可用于基于拓展标签进行规则匹配的查询过滤。例如 “/api/v1/query_range?extra_filters[]={env=~"prod|staging",user="xyz"}&query=<query>“,会返回额外标签中包含“{env=~"prod|staging",user="xyz"}“ 的结果;

3. 支持 “start“ 和 “end“,使用多种时间格式,如 1562529662.678、2022-03-29T01:02:03Z、2022-03、1h5m 等;

4. 在 “/api/v1/query“和“/api/v1/query_range“ 中增加了 round_digits 参数,它可用于将响应值四舍五入到小数点后给定的位数;

5. 在 “/api/v1/labels and /api/v1/label/<labelName>/values“ 中增加了 limit 参数,用于限制返回条目的数量;

6. 在 “/api/v1/series“ 中增加了 limit 参数,用于限制返回条目的数量;

7. 新增 “/api/v1/series/count“,返回数据库中时间序列的总数;

8. 新增 “/api/v1/status/active_queries“,返回当前正在运行的查询列表;

9. 新增 “/api/v1/status/top_queries“,返回“topByCount“最常执行的查询;返回“topByAvgDuration“平均执行持续时间最长的查询;返回“topBySumDuration“执行时间最长的查询。

除了支持 Prometheus 作为数据源外,VictoriaMetrics 还支持其他数据源:

1. DataDog agent

2. InfluxDB-compatible agents such as Telegraf

3. Graphite-compatible agents such as StatsD

4. OpenTSDB-compatible agents

02

架构

面对获取速率低于每秒一百万个数据点的场景下,官方建议使用单节点版本而不是群集版本。单节点版本可以根据 CPU 内核、RAM 和可用存储空间的数量完美扩展。与群集版本相比,单节点版本更易于配置和操作,因此在选择群集版本之前要三思。

图源:https://docs.victoriametrics.com/Cluster-VictoriaMetrics.html

VictoriaMetrics 集群由以下服务组成:

1. vmstorage,存储原始数据并返回给定标签过滤器的给定时间范围内的查询数据;

2. vminsert,接受接收的数据,并根据 “度量名称及其所有标签” 计算出的哈希值,在 vmstorage 节点之间传播数据;

3. vmselect,通过从所有配置的 vmstorage 节点获取所需数据来执行传入查询。

每个服务可以独立扩展,并且可以在最合适的硬件上运行。Vmstorage 节点不了解彼此,不相互通信,也不共享任何数据。这是一个无共享架构,它提高了群集可用性,简化了群集维护和群集扩展。

VictoriaMetrics 在开源层面,提供以下组件:

1. vmui:负责 vm 页面展示,提供数据查询、指标与基数查询、查询分析、链路分析、job 分析面板等功能;

2. vmagent:负责数据采集、重新标记和过滤收集,并通过 Prometheus 协议将数据存储到 VictoriaMetrics 或其他支持 Prometheus 协议的存储系统中。支持按时间和标签聚合样本后同时复制多个远程存储系统,且能在传输故障时缓存数据,等待恢复后继续传输;支持抓取暴露数百万时间序列的目标与写入多个租户中;支持 kafka 读写;

3. vminsert:负责数据插入,支持不同格式、不同租户的数据;

4. vmstorage:负责数据存储,具有高压缩率、低资源消耗、高性能的特点;

5. vmselect:负责数据查询,支持数据统一查询与多租户数据隔离查询;

6. vmalert:负责告警,和 Prometheus 一样支持纪录、告警两种规则配置与发送告警通知,允许在注解中使用 Go 模板来格式化数据、迭代或执行表达式,支持跨租户发送警报和记录规则

7. vmbackup:负责数据备份,支持增量备份和全量备份,可以做到每小时、每天、每周和每月备份,支持本地存储、GCS、Azure Blob 存储、S3 存储、任何与 S3 兼容的存储;

8. vmrestore:负责数据还原,支持随时中断与自动从断点恢复。

03

能力

3.1. 保存

VictoriaMetrics 使用 “-retentionPeriod”命令行标志进行配置,该标志采用一个数字,后跟一个时间单位字符 “-h(ours)、d(ays)、w(eeks)、y(ears)”。如果未指定时间单位,则假定为月。例如,“-retentionPeriod=3” 表示数据将存储 3 个月,然后删除。默认保留期为一个月。

3.2. 数据删除

VictoriaMetrics 除了支持配置定时过期外,还支持手动进行数据删除操作,使用 “http://<victoriametrics-addr>:8428/api/v1/admin/tsdb/delete_series?match[]=<timeseries_selector_for_delete>”。删除的时间序列的存储空间不会立即释放,而是在随后的数据文件后台合并过程中释放。请注意,对于前几个月的数据,后台合并可能永远不会发生,因此不会为历史数据释放存储空间。在这种情况下,强制合并可能有助于释放存储空间。

3.3. 强制合并

VictoriaMetrics 会在后台以每个月为一个分区的形式进行数据压缩,以保持良好的性能。可以使用 “http://victoriametrics:8428/internal/force_merge?partition_prefix=YYYY_MM” 进行强制数据压缩,会以异步的形式,立马返回请求结果,并在后台执行数据压缩任务。当需要立即删除数据的时候,可以使用强制合并触发数据删除。

3.4. 数据导入、导出

VictoriaMetrics 支持使用专属 Agent 接口导入数据:

1.Prometheus remote_write API

2.DataDog submit metrics API

3.Graphite plaintext protocol

4.OpenTSDB telnet put protocol

5.OpenTSDB http api/put protocol

支持使用 VictoriaMetrics 统一接口导入数据:

1./api/v1/import,导出 json 格式;

2./api/v1/import/csv,导出 csv 格式;

3./api/v1/import/native,导出二进制格式。

相对的,也可以使用导出接口导出数据:

1./api/v1/export,导出 json 格式;

2./api/v1/export/csv,导出 csv 格式;

3./api/v1/export/native,导出二进制格式。

VictoriaMetrics 接口侧,在导入、导出接口中,数据格式保持一致,可以直接使用导出的数据进行数据导入。

3.5. 消除重复数据

VictoriaMetrics 会根据 “-dedup.minScrapeInterval” 配置的值进行去重,只留下一个原始样本,保留配置周期中时间戳最大的数据。比如 “-dedup.minScrapeInterval=60s”,将会保留 60s 间隔中最大时间戳的单个原始样本。如果时间戳一致的情况下,随机保留数据。

多个相同配置的 vmagent 或 Prometheus 实例将数据写入同一 VictoriaMetrics 实例,则消除重复数据可减少磁盘空间的使用。

3.6. 存储

VictoriaMetrics 将以类似 MergeTree 的数据结构存储时间序列数据。插入时,VictoriaMetrics 累积最多 1s 的数据,并将其转储到磁盘上的 “←storageDataPath>/data/small/YYYY_MM/” 子目录,形成具有以下名称模式的 part:“rowsCount_blocksCount_minTimestamp_maxTimestamp”。每个 part 由两个 “列” 组成:值和时间戳。这些是经过排序和压缩的原始时间序列值。此外,part 包含索引文件,用于在值和时间戳文件中搜索特定 series。

part 会定期合并为较大的 part,生成的部分在 “<-storageDataPath>/data/{small,big}/YYYY_MM/tmp” 子目录下构造。当生成的 part 完成后,它将自动从 tmp 移动到自己的子目录,而源部分将自动删除。最终结果是,源部分被 ”<-storageDataPath>/data/{small,big}/YYYY_MM/“ 目录中的单个较大部分替换。

如果 part 的摘要大小超过可用磁盘空间,VictoriaMetrics 不会合并部件。这可以防止合并过程中出现潜在的磁盘空间不足错误。在可用磁盘空间不足的情况下,part 的数量可能会随着时间的推移而显著增加。这增加了数据查询期间的开销,因为 VictoriaMetrics 每次请求都需要从更多的部分读取数据。这就是为什么建议在 “-storageDataPath” 命令行标志指示的目录下至少有 20% 的可用磁盘空间。

有关合并过程的信息支持在 Grafana 仪表板中查看。

合并过程提高了压缩率,并使磁盘上的部件数量保持相对较低。执行合并过程的好处如下:

1. 它提高了查询性能,因为每次查询都会检查较少的部分;

2. 它减少了数据文件的数量,因为每个部分都包含固定数量的文件。

存储或是合并,都不会只保存部分 part,part 会以数据整体的形式,要么被全部保存成功,要么全部失败。part 是不可变的。

3.7. 监控

VictoriaMetrics 在 “/metrics” 页面以 Prometheus exposion 格式导出内部度量。这些指标可以通过 vmagent 或 Prometheus 获取。或者,当 “-selfScrapeInterval” 命令行标志设置为持续时间大于 0 时,单节点 VictoriaMetrics 可以自抓取度量。

VictoriaMetrics 在 “/api/v1/status/active_queries“ 页面上公开当前正在运行的查询及其执行时间。

VictoriaMetrics 在 ”/api/v1/status/top_queries” 页面上公开了执行时间最长的查询。

3.8. TSDB 状态

VictoriaMetrics 以类似于 Prometheus 的方式在 “/api/v1/status/TSDB“ 页面返回 TSDB 统计信息:

1. topN=N,其中 N 是响应数量。默认情况下,返回前 10 个;

2. date=YYYY-MM-DD,其中 YYYY-MM-DD 是收集统计数据的日期。默认情况下,收集当天的统计数据;

3. focusLabel=LABEL_NAME,返回 seriesCountByFocusLabelValue 列表中给定 LABEL_NAME 的时间序列数最多的标签值;

4. match[]=SELECTOR,其中 SELECTOR 是一个任意时间序列选择器,用于在统计计算期间考虑序列。默认情况下,将考虑所有系列;

5. extra_label=LABEL=VALUE,拓展标签筛选。

3.9. 推指标

当出现无法拉取指标的场景下,VictoriaMetrics 支持以 Prometheus 数据格式的方式,通过 push 模式进行指标推送:

1. -pushmetrics.url,推送地址,比如”-pushmetrics.url=http://victoria-metrics:8428/api/v1/import/prometheus“;

2. -pushmetrics.extraLabel,拓展标签,支持以 label="value" 的形式给 push 数据增加标签;

3. -pushmetrics.interval,push 周期,默认 10s。

3.10. 缓存

VictoriaMetrics 使用各种内部缓存。在正常关机期间(例如,当 VictoriaMetrics 通过发送 SIGINT 信号停止时),这些缓存存储到 “<-storageDataPath>/cache” 目录中。缓存将在下次 VictoriaMetrics 启动时读取。有时需要在下次启动时删除这些缓存。这可以通过在重启 VictoriaMetrics 之前将 reset_cache_on_startup 文件放置在“<-storageDataPath>/cache” 目录中来执行。

VictoriaMetrics 使用各种内存缓存来加快数据摄取和查询性能。每种类型缓存指标可以在 “/metrics” 页面导出:

1. vm_cache_size_bytes,实际缓存大小;

2. vm_cache_size_max_bytes,缓存大小限制;

3. vm_cache_requests_total,对缓存的请求数;

4. vm_cache_misses_total,缓存未命中数;

5. vm_cache_entries,缓存中的条目数。

支持在 Grafana 仪表板上查看缓存指标,面板显示了每种类型缓存的当前内存使用情况,以及缓存命中率。如果命中率接近 100%,则缓存效率已经很高,不需要任何调整。

3.11. 其他

支持众多 Prometheus 具备的功能,比如 Prometheus 的标签重写、联邦等功能。

04

与 Prometheus 对比

优势:

1. 性能优势。在相同配置、采集压力的情况下,相比使用 Prometheus,存储空间最多可减少 7 倍,磁盘读写峰值最多可减少 3-4 倍,内存使用最多减少 7 倍;

2. 更优秀的横向拓展、高可用方案。VictoriaMetrics 集群模式,通过组件化各个能力,进行功能层面的架构解耦。由于负责读写的 vmselect、vminsert 组件都是无状态组件,可以灵活根据读写压力,进行组件的横向扩缩容;负责存储的 vmstorage 组件虽然是有状态组件,但是当存储压力增加时,同样支持横向扩容,扩容后只需要更新上下游的 vmselect、vminsert 组件配置并重启,即可提升 VictoriaMetrics 集群存储能力;采集压力的时候,可以利用扩容 vmagent 与 vmagent 的采集分组能力,进行分散压力采集;

3. 数据多租户能力。VictoriaMetrics 支持把不同类型的数据分别放到不同的租户里,每个租户通过 accountID 或 accountID:projectID 的形式,在请求的 url 里做区分。租户的数量不影响性能,主要取决于所有租户的活跃总时间序列,每个租户的数据都均匀分布在后端 vmstorage 存储,但是不支持跨租户进行数据查询。

缺点:

1. 没有类似 Prometheus 的 WAL 日志,突然故障可能会丢失部分数据。Prometheus 在接收到数据的时候,会先把数据写入内存,定期再写入磁盘。为了防止写入磁盘前数据丢失,还会再写入内存的同时简单的写入 WAL 文件里,当出现故障时,就可以通过 WAL 快速恢复当前状态。而 VictoriaMetrics 则在写入过程中,使用 Go 的 chan 作为数据缓存队列,多协程实现数据处理、压缩、存储等操作,故障下存在缓存数据丢失的情况;

2. 为了更大程度优化存储,会选择丢失部分数据精度。Vmstorage 组件支持配置精度保存范围(1-64,64 表示不丢失),以此在数据读写过程中,提升速度。

05

安装

使用 helm 进行 VictoriaMetrics 集群模式的部署。

安装 helm,添加 chart helm 仓库:

helm repo add vm https://victoriametrics.github.io/helm-charts/
helm repo update

导出配置文件,并进行部署配置:

helm show values vm/victoria-metrics-cluster > values.yaml

可以使用以下命令进行配置检查:

helm install victoria-metrics vm/victoria-metrics-cluster -f values.yaml -n victoria-metrics --debug --dry-run

根据配置文件部署 victoria-metrics-cluster:

helm install victoria-metrics vm/victoria-metrics-cluster -f values.yaml -n victoria-metrics

稍等片刻 Helm 则会机提示安装成功,查询资源可以看到都已经部署起来了。

06

使用

调整 victoria-metrics-victoria-metrics-cluster-vminsert 的 service 与 victoria-metrics-victoria-metrics-cluster-vmselect 的 service,从 ClusterIP 模式改成 NodePort 模式,提供对外访问能力。修改现有 Prometheus 的配置,增加:

remote_write:
- url: http://IP:NodePort/insert/0/prometheus

把 Prometheus 的数据,写入 VictoriaMetrics,通过 VictoriaMetrics 的 UI 地址 ”http://IP:NodePort/select/0/vmui“,即可查看 Prometheus 采集到的数据了。


可以看出,两者数据基本一致。


参考资料:https://docs.victoriametrics.com/




 本文作者 



陈子榕

现任「DaoCloud 道客」后端开发工程师




热门推荐

            

访问以下网址,或点击文末【阅读原文】直接下载

新一代云原生操作系统底座--DCE 5.0 社区版:https://docs.daocloud.io/download/dce5/
任何组织、机构和个人,都能免费体验企业级云原生性能




DaoCloud 公司简介

「DaoCloud 道客」云原生领域的创新领导者,成立于 2014 年底,拥有自主知识产权的核心技术,致力于打造开放的云操作系统为企业数字化转型赋能。产品能力覆盖云原生应用的开发、交付、运维全生命周期,并提供公有云、私有云和混合云等多种交付方式。成立迄今,公司已在金融科技、先进制造、智能汽车、零售网点、城市大脑等多个领域深耕,标杆客户包括交通银行、浦发银行、上汽集团、东风汽车、海尔集团、屈臣氏、金拱门(麦当劳)等。目前,公司已完成了 D 轮超亿元融资,被誉为科技领域准独角兽企业。公司在北京、南京、武汉、深圳、成都设立多家分公司及合资公司,总员工人数超过 350 人,是上海市高新技术企业、上海市“科技小巨人”企业和上海市“专精特新”企业,并入选了科创板培育企业名单。


网址:www.daocloud.io

邮件:info@daocloud.io

电话:400 002 6898



继续滑动看下一个

云原生监控--VictoriaMetrics 之基础篇

陈子榕 道客船长
向上滑动看下一个

您可能也对以下帖子感兴趣

文章有问题?点此查看未经处理的缓存