VictoriaMetrics 核心概念与实战数据模型、写入/查询模型与 MetricsQL 深度解析【免费下载链接】VictoriaMetricsVictoriaMetrics: fast, cost-effective monitoring solution and time series database项目地址: https://gitcode.com/GitHub_Trending/vi/VictoriaMetrics本篇技术指南以 VictoriaMetrics 官方核心概念文档为骨架系统讲解监控时序数据库的数据模型metric、时间序列、基数、样本分辨率、四种指标类型Counter/Gauge/Histogram/Summary、Push 与 Pull 两种写入模型、Instant Query 与 Range Query 两种查询模型以及MetricsQL 查询语言的核心操作。读完本文你将掌握在单机版与集群版 VictoriaMetrics 中正确地设计指标、埋点、采集、查询与可视化数据流并理解-search.latencyOffset、-maxLabelsPerTimeseries等关键参数背后的实现原理。数据模型Data model什么是 metric指标通俗地说metric指标是对某个事物的数值化度量或观测。指标最常见的应用场景包括检查系统在特定时间段内的行为表现将行为变化与其他测量指标进行关联观察或预测趋势当指标超过阈值时触发事件告警。metric 的结构以一个例子开始为了跟踪应用处理了多少请求我们定义一个名为requests_total的指标。你也可以定义得更具体例如requests_success_total仅统计成功请求或request_errors_total统计失败请求。指标名的选择非常重要它应当向每个阅读者阐明实际测量对象——就像编程中的变量名一样。标签Labels每个指标都可以通过label-value标签-值对的形式携带额外的元信息requests_total{path/, code200} requests_total{path/, code403}花括号中的元信息——一组labels——为我们提供了该请求是在哪个path、以什么code被服务的上下文。标签值对永远是string类型。VictoriaMetrics 的数据模型是无模式schemaless的这意味着无需预先定义指标名或标签用户可以随时自由地添加或更改摄入的指标。实际上指标名本身也是一个标签其特殊名称为__name__。从 v1.111.0 起为了简洁__name__键可以省略。因此以下三条序列是完全相同的requests_total{path/, code200} {__name__requests_total, path/, code200} {requests_total, path/, code200}标签可以通过 vmagent 或 Prometheus 自动附加到写入的时间序列上。VictoriaMetrics 支持在 查询 API 上强制标签过滤以模拟数据隔离而真正意义上的数据隔离可以通过 多租户multi-tenancy实现。时间序列Time series指标名与其标签的组合定义了一条时间序列time series。例如requests_total{path/, code200}与requests_total{path/, code403}因为code标签取值不同是两条不同的时间序列。唯一时间序列的数量会影响数据库的资源占用。详见 什么是活跃时间序列 与 什么是高流失率churn rate。基数Cardinality唯一 时间序列 的数量被称为基数cardinality。拥有过多唯一时间序列被称为高基数high cardinality。高基数 会导致 VictoriaMetrics 资源占用上升。可进一步参考Cardinality Explorer——用于在 VMUI 中探查基数构成的可视化工具。原始样本Raw samples每条唯一时间序列可以由任意数量的(value, timestamp)数据点即原始样本raw samples组成并按timestamp排序。VictoriaMetrics 将所有value以 float64 存储并施加额外压缩。这允许精确存储最多 12 位十进制数字的整数以及最多 12 位有效十进制数字的浮点数。如果值超过 12 位有效十进制数字存入 VictoriaMetrics 时较低的有效位可能丢失。timestamp是毫秒精度的 Unix 时间戳。下面是一个 Prometheus 文本暴露格式 下的单个原始样本示例requests_total{path/, code200} 123 4567890requests_total{path/, code200}标识该样本所属的时间序列123是样本值4567890是该样本的可选时间戳如果缺失则在存入 VictoriaMetrics 时使用当前时间戳。时间序列的分辨率Resolution分辨率是同一时间序列相邻 原始样本 之间的最小间隔。看下面的例子---------------------------------------------------------------------- | time series | value | timestamp | | requests_total{path/health, code200} | 1 | 1676297640 | | requests_total{path/health, code200} | 2 | 1676297670 | | requests_total{path/health, code200} | 3 | 1676297700 | | requests_total{path/health, code200} | 4 | 1676297730 | ....这里时间序列requests_total{path/health, code200}每30s更新一次值因此其分辨率也是30s。在 Pull 模型 下分辨率等于scrape_interval由监控系统服务端控制在 Push 模型 下分辨率是样本时间戳之间的间隔由客户端指标采集器控制。尽量保持时间序列分辨率一致因为部分 MetricsQL 函数会依赖这一点。指标的类型Types of metrics从内部实现看VictoriaMetrics 并没有指标类型的概念。指标类型这一概念存在的意义是帮助用户理解指标“如何被测量”。常见的指标类型共有 4 种。Counter计数器Counter 是统计事件的指标。其值随时间递增或保持不变一般不会下降。唯一的例外是counter reset计数器重置例如服务重启导致计数器归零。因此counter指标展示的是自服务启动以来观测到的事件总数。在编程中counter就是每次事件发生时执行increment自增的变量。vm_http_requests_total是典型的 counter 示例。上图中vm_http_requests_total{instancelocalhost:8428, jobvictoriametrics, pathapi/v1/query_range}时间序列在 13:38 至 13:39 之间快速攀升之后直到 13:41 都没有变化。Counter 用于度量事件数量例如请求数、错误数、日志条数、消息数等。与 counter 搭配最常用的 MetricsQL 函数是rate计算指标变化的每秒平均速率。例如rate(requests_total)展示每秒平均处理多少个请求increase计算指标在方括号指定时间区间内的增长量。例如increase(requests_total[1h])展示过去一小时处理了多少请求。Counter 允许是小数。例如request_duration_seconds_sum这个 counter 累加所有请求的耗时而每个耗时可能以秒为单位出现0.5这样的小数因此所有请求耗时的累计和也可能是小数。建议给counter指标名加上_total、_sum或_count后缀便于人类快速将其与其他类型区分开。Gauge仪表Gauge 用于度量可以上下波动的值上图process_resident_memory_anon_bytes指标展示应用在任意时刻的内存占用它频繁上下变化反映进程如何分配与释放内存。在编程中gauge就是随值变化而设置set特定值的变量。Gauge 的典型使用场景度量温度、内存占用、磁盘占用等存储某个进程的状态。例如config_reloaded_successful在配置重载成功时设为1失败时设为0存储事件发生的时间戳。例如config_last_reload_success_timestamp_seconds存储最近一次配置重载成功的时间戳。Gauge 最常用的 MetricsQL 函数是聚合函数与 rollup 函数。Histogram直方图Histogram 是一组带不同vmrange或le标签的 counter 指标。vmrange/le标签定义某个桶bucket的测量边界当观测值命中某个桶时对应的 counter 就自增。直方图桶名通常带_bucket后缀。例如 VictoriaMetrics 用vm_rows_read_per_query直方图跟踪每次查询处理的行数分布其暴露格式如下vm_rows_read_per_query_bucket{vmrange4.084e02...4.642e02} 2 vm_rows_read_per_query_bucket{vmrange5.275e02...5.995e02} 1 vm_rows_read_per_query_bucket{vmrange8.799e02...1.000e03} 1 vm_rows_read_per_query_bucket{vmrange1.468e03...1.668e03} 3 vm_rows_read_per_query_bucket{vmrange1.896e03...2.154e03} 4 vm_rows_read_per_query_sum 15582 vm_rows_read_per_query_count 11vm_rows_read_per_query_bucket{vmrange4.084e02...4.642e02} 2表示自上次 VictoriaMetrics 启动以来行数落在区间(408.4 - 464.2]内的查询有 2 次。带_bucket后缀的 counter 允许借助 histogram_quantile 函数估算观测值的任意分位数。例如下面的查询返回过去一小时见方括号中的1h每次查询读取行数的 99 分位估计值histogram_quantile(0.99, sum(increase(vm_rows_read_per_query_bucket[1h])) by (vmrange))该查询的工作流程increase(vm_rows_read_per_query_bucket[1h])计算过去一小时每个实例每个桶的事件数sum(...) by (vmrange)将vmrange相同的各实例桶事件数求和histogram_quantile(0.99, ...)基于第 2 步得到的vmrange桶计算 99 分位。Histogram 还暴露两个额外的 counter分别以_sum与_count结尾vm_rows_read_per_query_sum是所有观测值的总和例如自启动以来所有查询处理的行数之和vm_rows_read_per_query_count是观测事件的总数例如自启动以来观测到的查询总数。这两个 counter 允许计算特定回看窗口lookbehind window内的平均值。例如下面的查询计算过去 5 分钟见方括号中的5m每次查询平均读取的行数increase(vm_rows_read_per_query_sum[5m]) / increase(vm_rows_read_per_query_count[5m])在 Go 应用中可以通过 github.com/VictoriaMetrics/metrics 包以如下方式使用vm_rows_read_per_query直方图// 定义直方图 rowsReadPerQuery : metrics.NewHistogram(vm_rows_read_per_query) // 在业务处理中使用直方图 for _, query : range queries { rowsReadPerQuery.Update(float64(len(query.Rows))) }每次调用rowsReadPerQuery.Update时countervm_rows_read_per_query_sum增加len(query.Rows)表达式的值countervm_rows_read_per_query_count增加 1countervm_rows_read_per_query_bucket仅在观测值落在vmrange定义的桶区间内时自增。这样的 counter 组合允许在 Grafana 中绘制 Heatmaps热力图 并计算 分位数quantilesGrafana 无法直接理解带vmrange标签的桶因此在 Grafana 中构建热力图前必须使用 prometheus_buckets 函数将vmrange标签的桶转换为le标签的桶。直方图通常用于度量延迟分布、元素大小例如批大小分布等。VictoriaMetrics 支持两种直方图实现Prometheus histogram经典直方图实现被大多数指标埋点客户端库支持需要用户静态定义桶边界VictoriaMetrics histogram由 VictoriaMetrics/metrics 埋点库支持自动处理桶边界用户无需关心。使用直方图前建议先阅读以下资料Prometheus histogramHistograms and summariesHow does a Prometheus Histogram work?Improving histogram usability for Prometheus and GrafanaSummary摘要Summary 与 Histogram 很相似也用于分位数计算。主要区别在于Summary 的分位计算在客户端完成因此指标暴露格式中已经包含预定义的分位数go_gc_duration_seconds{quantile0} 0 go_gc_duration_seconds{quantile0.25} 0 go_gc_duration_seconds{quantile0.5} 0 go_gc_duration_seconds{quantile0.75} 8.0696e-05 go_gc_duration_seconds{quantile1} 0.001222168 go_gc_duration_seconds_sum 0.015077078 go_gc_duration_seconds_count 83Summary 的可视化非常直接这种做法的优点是易于使用但也带来了相对 Histogram 的显著限制无法跨多个 summary 计算分位数。例如sum(go_gc_duration_seconds{quantile0.75})、avg(go_gc_duration_seconds{quantile0.75})或max(go_gc_duration_seconds{quantile0.75})都无法返回从应用多个实例收集的go_gc_duration_seconds的预期 75 分位无法计算除预计算分位数之外的其他分位数无法为任意时间范围收集的测量值计算分位数。通常 Summary 分位数是在固定时间范围如最近 5 分钟内计算的。Summary 通常用于跟踪延迟、元素大小例如批大小等的预定义百分位。使用指标埋点应用Instrumenting application with metrics正如 指标的类型 一节开头所述指标类型定义的是“如何被测量”VictoriaMetrics TSDB 本身并不知道指标类型——它只看到指标名、标签、值和时间戳。指标是什么、测量什么、如何测量完全取决于发出它们的应用。推荐使用 github.com/VictoriaMetrics/metrics 包为应用接入与 VictoriaMetrics 兼容的指标埋点。VictoriaMetrics 同时兼容 Prometheus 客户端埋点库。命名规范建议遵循 Prometheus 指标命名规范。虽然 VictoriaMetrics 没有严格限制任何指标名和标签都会被接受但遵循该规范有助于让命名对他人而言更有意义、更清晰、更具描述性。标签规范每个测量可以携带任意数量的keyvalue标签。好的实践是控制标签数量否则处理包含大量标签的测量将变得困难。默认情况下VictoriaMetrics 将每条测量的标签数量限制为 40超出部分将被丢弃。如有必要但不推荐可以通过-maxLabelsPerTimeseries命令行标志修改该限制。在仓库源码 lib/timeserieslimits/timeseries_limits.go 中可以确认这些默认值与底层行为maxLabelsPerTimeseries 40每条时间序列的最大标签数maxLabelValueLen 4 * 10244KiB标签值的最大长度maxLabelNameLen 256标签名的最大长度。当样本超出限制时对应时间序列会被忽略不写入并累加vm_rows_ignored_total{reasontoo_many_labels}、vm_rows_ignored_total{reasontoo_long_label_value}等指标见 timeseries_limits.go同时以节流方式输出 WARN 日志提示增大对应的-maxLabelsPerTimeseries/-maxLabelValueLen标志值。每个标签值可以是任意字符串。好的实践是使用简短且有意义的标签值描述指标属性而不是“讲故事”。例如environmentprod可以接受而log_messagelong log message with a lot of details...则不可取。默认情况下 VictoriaMetrics 将标签值限制为 4KiB可通过-maxLabelValueLen命令行标志修改。控制唯一标签值的数量至关重要——每一个唯一的标签值都会产生一条新的时间序列。尽量避免使用会话 ID、查询 ID 这类易变的标签值以免造成资源过度占用和数据库变慢。多租户Multi-tenancyVictoriaMetrics 的集群版本支持多租户实现数据隔离。对于单机版可以通过在写入路径添加标签、并在读取路径强制标签过滤来模拟多租户。写数据Write dataVictoriaMetrics 同时支持现代监控应用使用的两种模型Push 与 Pull。Push 模型在 Push 模型中客户端定期将收集到的指标发送给服务端由客户端应用决定何时、向何处发送指标。VictoriaMetrics 支持多种数据摄入协议即push protocols完整列表见 单机版文档。所有协议都与 VictoriaMetrics 的数据模型完全兼容可以用于生产环境。推荐使用 github.com/VictoriaMetrics/metrics 包向 VictoriaMetrics 推送应用指标也可以使用上述协议已有的客户端例如通过 InfluxDB line protocol 接入的 Telegraf。创建自定义客户端或为应用埋点写指标简单到只需发送一个 POST 请求curl -d {metric:{__name__:foo,job:node_exporter},values:[0,1,2],timestamps:[1549891472010,1549891487724,1549891503438]} -X POST http://localhost:8428/api/v1/import指标可以被推送到单节点 VictoriaMetrics、集群版组件 vminsert 以及 vmagent。Push 模型的优点VictoriaMetrics 侧配置更简单——无需配置 VictoriaMetrics 去发现被监控应用的位置也无需复杂的服务发现方案安全设置更简单——无需设置 VictoriaMetrics 到每个被监控应用的访问通道。Push 协议的缺点被监控应用的配置复杂度上升——每个应用都需要单独配置监控系统地址、推送间隔以及推送失败时的策略向多个监控系统投递指标时配置复杂难以区分应用是宕机了还是因其他原因停止发送指标应用可能以过短的推送间隔压垮监控系统。Pull 模型Pull 模型是由 Prometheus 推广的方法监控系统决定何时、从哪里拉取指标在 Pull 模型中监控系统需要感知所有需要监控的应用。指标按固定周期即scrape_interval通过 HTTP 协议从已知应用即scrape targets抓取scrape/pull。VictoriaMetrics 支持以与 Prometheus 相同的方式发现 Prometheus 兼容的目标并抓取其指标详见相关文档。指标抓取由单节点 VictoriaMetrics 和 vmagent 支持。Pull 模型的优点更容易排查——VictoriaMetrics 知道所有被监控应用即scrape targets。up 0查询能立刻显示不可用的抓取目标抓取目标的实时信息可在http://victoriametrics:8428/targets与http://vmagent:8429/targets查看监控系统控制抓取频率因此更容易控制自身负载应用不感知监控系统的存在无需实现指标投递逻辑。Pull 模型的缺点安全设置更复杂——监控系统需要能够访问被监控的应用需要非平凡的服务发现方案。常见的数据采集方式VictoriaMetrics 同时支持 Push 与 Pull 两种数据采集模型。许多部署只使用其中一种或者同时使用两者。最常见的采集方式就是同时使用两种模型在这种方案中引入了额外的组件——vmagent。vmagent 是一个轻量级代理核心职责是采集、过滤、relabel 并将指标投递给 VictoriaMetrics。它支持上文提到的所有 Push 和 Pull 协议。VictoriaMetrics 与 vmagent 的基本监控部署见示例 docker-compose 清单。在该示例中vmagent 抓取一组目标并将采集到的数据转发给 VictoriaMetrics随后 VictoriaMetrics 被用作 Grafana 的数据源来查询采集到的数据。VictoriaMetrics 组件还允许构建更复杂的拓扑。例如多个 vmagents 可以将指标从不同数据中心推送到中心化的 VictoriaMetrics此场景中的 VictoriaMetrics 既可以是单节点版也可以是 VictoriaMetrics Cluster。vmagent 还支持将同一份数据复制到多个目标实现复制与高可用。查询数据Query dataVictoriaMetrics 提供 HTTP API 服务读查询。该 API 被 Grafana 等各种集成使用也被 VMUI——查询与可视化指标的原生图形界面所使用。API 主要由两个处理器组成分别服务即时查询与范围查询。即时查询Instant query即时查询在给定的time时刻执行query表达式GET | POST /api/v1/query?query...time...step...timeout...参数说明query要执行的 MetricsQL 表达式。time可选。计算query所用时刻的时间戳毫秒精度。省略时取now()当前时间。该参数支持多种允许的格式。step可选。执行query时在过去的时间间隔内查找原始样本当指定time处样本缺失时使用。例如请求/api/v1/query?queryupstep1m会在(now()-1m, now()]区间内不包含第一毫秒为up指标查找最近写入的原始样本。省略时step默认为5m5 分钟。timeout可选的查询超时。例如timeout5s超时后查询被取消。默认值为传递给单节点 VictoriaMetrics 或集群版vmselect组件的-search.maxQueryDuration命令行标志值。在仓库源码 app/vmselect/searchutil/searchutil.go 中可以确认-search.maxQueryDuration的默认值为 30 秒且可以通过timeout查询参数在单次查询上覆盖为更小的值timeout不能超过-search.maxQueryDuration。即时查询的结果是匹配query表达式中过滤条件的时间序列列表。每条返回的序列恰好包含一个(timestamp, value)条目其中timestamp等于time查询参数value是query在请求时刻的结果。为理解即时查询的工作方式先看一组数据样本foo_bar 1.00 1652169600000 # 2022-05-10T08:00:00Z foo_bar 2.00 1652169660000 # 2022-05-10T08:01:00Z foo_bar 3.00 1652169720000 # 2022-05-10T08:02:00Z foo_bar 5.00 1652169840000 # 2022-05-10T08:04:00Z, one point missed foo_bar 5.50 1652169960000 # 2022-05-10T08:06:00Z, one point missed foo_bar 5.50 1652170020000 # 2022-05-10T08:07:00Z foo_bar 4.00 1652170080000 # 2022-05-10T08:08:00Z foo_bar 3.50 1652170260000 # 2022-05-10T08:11:00Z, two points missed foo_bar 3.25 1652170320000 # 2022-05-10T08:12:00Z foo_bar 3.00 1652170380000 # 2022-05-10T08:13:00Z foo_bar 2.00 1652170440000 # 2022-05-10T08:14:00Z foo_bar 1.00 1652170500000 # 2022-05-10T08:15:00Z foo_bar 4.00 1652170560000 # 2022-05-10T08:16:00Z以上数据包含foo_bar时间序列的样本列表样本间隔从 1m 到 3m 不等。若将其绘制成图形态如下要获取foo_bar序列在某个具体时刻例如2022-05-10T08:03:00Z的值需要发起一次即时查询curl http://victoria-metrics-addr/api/v1/query?queryfoo_bartime2022-05-10T08:03:00.000Z{ status: success, data: { resultType: vector, result: [ { metric: { __name__: foo_bar }, value: [ 1652169780, // 2022-05-10T08:03:00Z 3 ] } ] } }响应中VictoriaMetrics 返回foo_bar序列在2022-05-10T08:03:00Z时刻的单个样本-时间戳对值为3。但回看原始数据2022-05-10T08:03:00Z处并没有原始样本。当请求时间戳处没有原始样本时VictoriaMetrics 会尝试定位请求时间戳之前最近的样本VictoriaMetrics 为缺失数据样本寻找替代样本的时间范围默认为5m可通过step参数覆盖。即时查询可以返回多条时间序列但每条序列始终只返回一个数据样本。即时查询适用于以下场景获取最后记录的值配合 rollup 函数如count_over_time使用告警与录制规则recording rules的评估在 Grafana 中绘制 Stat 或 Table 面板。范围查询Range query范围查询在给定的[start...end]时间范围内、以给定step执行query表达式GET | POST /api/v1/query_range?query...start...end...step...timeout...参数说明query要执行的 MetricsQL 表达式。startquery求值时间范围的起始时间戳。endquery求值时间范围的结束时间戳。未设置时自动取当前时间。step范围查询必须返回的数据点之间的间隔。query将在start、startstep、start2*step、……、startN*step这些时间戳上执行其中N是start与end之间能容纳的完整步数。只有当end恰好等于startN*step时end才被包含。未设置时step默认为5m5 分钟。timeout可选的查询超时。例如timeout5s超时后查询被取消。默认值为传递给单节点 VictoriaMetrics 或集群版vmselect组件的-search.maxQueryDuration命令行标志值。范围查询的结果是匹配query过滤条件的时间序列列表。每条返回的序列包含在start、startstep、……、startN*step时刻执行query得到的(timestamp, value)结果。换句话说范围查询就是在start、startstep、……、startN*step时刻独立执行的即时查询唯一区别是范围查询不返回ephemeral临时样本见下文当数据库在请求的时间与步长上没有任何样本时它直接返回空结果。例如要获取foo_bar在2022-05-10T07:59:00Z至2022-05-10T08:17:00Z时间段内的值需要发起范围查询curl http://victoria-metrics-addr/api/v1/query_range?queryfoo_barstep1mstart2022-05-10T07:59:00.000Zend2022-05-10T08:17:00.000Z{ status: success, data: { resultType: matrix, result: [ { metric: { __name__: foo_bar }, values: [ [ 1652169600, 1 ], [ 1652169660, 2 ], [ 1652169720, 3 ], [ 1652169780, 3 ], [ 1652169840, 5 ], [ 1652169900, 5 ], [ 1652169960, 5.5 ], [ 1652170020, 5.5 ], [ 1652170080, 4 ], [ 1652170140, 4 ], [ 1652170260, 3.5 ], [ 1652170320, 3.25 ], [ 1652170380, 3 ], [ 1652170440, 2 ], [ 1652170500, 1 ], [ 1652170560, 4 ], [ 1652170620, 4 ] ] } ] } }响应中VictoriaMetrics 返回foo_bar序列在2022-05-10T07:59:00Z至2022-05-10T08:17:00Z时间段内的 17 个样本-时间戳对。但回看原始数据它只有 13 个原始样本。这里发生的是范围查询实际上是即时查询在start到end范围内执行了1 (start-end)/step次。如果把这个请求绘制出来图形如下图中蓝色虚线是即时查询执行的时刻。由于即时查询保留了为缺失点返回替代样本的能力图中包含两类数据点real真实与ephemeral临时。ephemeral数据点总是重复其之前最近的一个原始样本见图中红色箭头。产生这种临时数据点填充行为源于 Pull 模型 的特性指标按固定间隔抓取监控系统过载时可能跳过某次抓取抓取可能因网络问题失败。基于这些特性范围查询假设如果某个原始样本缺失很可能是一次漏抓因此用前一个原始样本填充。当step小于样本实际间隔时也同样有效——事实上如果对同一请求设置step1s将得到约 1000 个数据点其中大部分是ephemeral。有时回看窗口不够大图上就会出现缺口。对于范围查询回看窗口并不等于step参数而是按请求时间范围内最后 20 个原始样本之间间隔的中位数计算。这样 VictoriaMetrics 会自动调整回看窗口在填补缺口的同时也能检测出陈旧stale序列。范围查询主要用于在指定时间范围内绘制时序数据曲线在以下场景中非常有用跟踪指标在给定时间区间内的状态关联时间区间内多个指标之间的变化观察指标变化的趋势与动态。如果需要从 VictoriaMetrics 导出原始样本请参考导出 API。查询延迟Query latency默认情况下VictoriaMetrics 不会立即返回最近写入的样本而是检索由-search.latencyOffset命令行标志指定时间之前写入的最后结果该标志的默认偏移量为 30 秒。这对query和query_range都成立因此可能给人“数据写入 VM 有 30 秒延迟”的印象。该标志用于防止因最后一个抓取间隔内只有部分值被抓取而导致的查询结果不一致。该标志在源码 app/vmselect/prometheus/prometheus.go 中定义默认值为 30 秒可通过latency_offset查询参数按查询覆盖如果取值过小查询结果可能包含不完整的最后几个数据点。下面是-search.latencyOffset设置为 0 时可能出现的潜在问题示意设置该标志后VictoriaMetrics 会在整个-search.latencyOffset时长内返回该时长之前收集到的最后一个指标值该行为可以通过latency_offset查询参数按单次查询覆盖。VictoriaMetrics 会将最近摄入的样本在内存中缓冲数秒然后定期将这些样本刷写flush到磁盘。这种缓冲提升了数据摄入性能。即使-search.latencyOffset设置为 0或latency_offset查询参数设置为 0缓冲中的样本在查询结果中也是不可见的。可以向单节点 VictoriaMetrics 或集群版的vmstorage发送 GET 请求到/internal/force_flushHTTP 处理器强制将缓冲样本刷写到磁盘使其对查询可见。该处理器在源码 app/vmstorage/main.go 中实现并受forceFlushAuthKey会覆盖-httpAuth.*保护。/internal/force_flush仅用于调试与测试生产环境请勿调用否则会显著拖慢数据摄入性能并增加资源占用。MetricsQLVictoriaMetrics 提供专门的读查询语言——MetricsQL。它是类似 PromQL 的查询语言带有专门面向时序数据的强大函数与特性集合。MetricsQL 与 PromQL 向后兼容因此共享大部分查询概念。过滤Filtering在即时查询与范围查询小节中我们已经用 MetricsQL 获取foo_bar指标的数据——简单到只写一个指标名foo_bar单个指标名可能对应多条标签集不同的时间序列。例如requests_total{path/, code200} requests_total{path/, code403}要只选择具有特定标签值的时间序列在花括号中指定匹配过滤条件requests_total{code200}上述查询返回所有名为requests_total且标签code200的时间序列。使用运算符匹配标签值负向匹配使用!。过滤条件还支持正向正则匹配~与负向正则匹配!~requests_total{code~2.*}过滤条件可以组合requests_total{code~200, path/home}上述查询返回所有名为requests_total、同时满足标签code200与path/home的时间序列。按名称过滤有时需要返回多个指标名的全部时间序列。正如数据模型一节所述指标名只是名为__name__的特殊标签。因此按多个指标名过滤可以借助对指标名应用正则表达式{__name__~requests_(error|success)_total}上述查询返回两个指标的时间序列requests_error_total与requests_success_total。多个 “or” 过滤器MetricsQL 支持选择至少匹配多个 or 过滤条件之一的时间序列。这类过滤条件在花括号内用or分隔。例如下面的查询选择带{jobapp1,envprod}或{jobapp2,envdev}标签的时间序列{jobapp1,envprod or jobapp2,envdev}or分组数量可以是任意的每个or分组内用,分隔的标签过滤条件数量也可以是任意的。每个分组内的过滤条件以and逻辑应用即选择同时匹配该组所有过滤条件的时间序列。该功能允许将选中的序列直接传给 rollup 函数如 rate()而无需使用子查询rate({jobapp1,envprod or jobapp2,envdev}[5m])如果需要为同一个标签选择匹配多个过滤条件的序列从性能角度考虑使用正则过滤{label~value1|...|valueN}优于{labelvalue1 or ... or labelvalueN}。算术运算MetricsQL 支持所有基本算术运算加法 -减法 --乘法 -*除法 -/取模 -%幂 -^这允许跨多个指标执行各种计算。例如下面的查询计算错误请求的百分比(requests_error_total / (requests_error_total requests_success_total)) * 100组合多条序列用算术运算组合多条时间序列需要理解匹配规则否则查询可能出错或产生错误结果。匹配规则的基础很简单MetricsQL 引擎会剥掉算术运算左右两侧所有时间序列的指标名但保留标签对左侧每条时间序列MetricsQL 引擎在右侧查找具有相同标签集的对应时间序列对每个数据点执行运算并返回带有相同标签集的结果序列若无匹配该序列将从结果中剔除匹配规则可以通过ignoring、on、group_left、group_right修饰符增强详见 vector matching 文档。比较运算MetricsQL 支持以下比较运算符等于 -不等于 -!大于 -大于等于 -小于 -小于等于 -这些运算符与算术运算符一样可以应用于任意 MetricsQL 表达式。比较运算的结果是只保留匹配数据点的时间序列。例如下面的查询只返回内存占用超过 100MB 的进程对应序列process_resident_memory_bytes 100*1024*1024聚合与分组函数MetricsQL 支持对时间序列进行聚合与分组。时间序列按给定标签集分组然后对每个组分别应用给定的聚合函数。例如下面的查询返回每个job的内存使用汇总sum(process_resident_memory_bytes) by (job)更多内容参见 MetricsQL 聚合函数文档。计算速率针对 Counter 使用最广泛的函数之一是 rate。它逐条为匹配的时间序列计算每秒平均增长速率。例如下面的查询展示每个暴露了node_network_receive_bytes_total指标的受监控node_exporter实例的每秒平均数据接收速度rate(node_network_receive_bytes_total)默认情况下VictoriaMetrics 在 即时查询 或 范围查询 传入的step参数指定的回看窗口内基于原始样本计算rate。也可以用方括号中的时长显式指定rate的计算区间rate(node_network_receive_bytes_total[5m])这种情况下VictoriaMetrics 使用指定的回看窗口5m5 分钟计算每秒平均增长速率。更大的回看窗口通常产生更平滑的曲线。rate会剥掉内部时间序列的指标名但保留所有标签。如果需要保留指标名可以在rate(..)后添加 keep_metric_names 修饰符。例如下面的查询在计算rate()后保留指标名rate(node_network_receive_bytes_total) keep_metric_namesrate()只能应用于 Counter。对 Gauge 应用rate()的结果是未定义的。可视化时间序列VictoriaMetrics 内置了查询与可视化指标的原生图形界面——VMUI。打开http://victoriametrics:8428/vmui页面输入查询并查看结果VictoriaMetrics 支持 Prometheus HTTP API因此可以像 Grafana 查询 Prometheus 一样用 Grafana 查询它。修改数据Modify dataVictoriaMetrics 使用类似 MergeTree 的数据结构存储时序数据。这种结构对写密集数据库非常高效但对数据更新施加了一些限制。简而言之修改已写入的时间序列需要重写其所在的整个数据块。由于这一限制VictoriaMetrics 不支持直接修改数据。删除Deletion参见 如何删除时间序列。重打标签RelabelingRelabeling 是一种强大的机制用于在时间序列写入数据库之前对其进行修改。Relabeling 可以同时应用于 Push 与 Pull 两种模型详见相关文档。去重DeduplicationVictoriaMetrics 支持数据去重参见相关文档。降采样DownsamplingVictoriaMetrics 支持数据降采样参见相关文档。总结本文围绕 VictoriaMetrics 的核心概念展开从无模式的 schemaless 数据模型出发厘清了 metric、labels、__name__、时间序列、基数、原始样本与分辨率等基础术语随后详细对比了 Counter、Gauge、Histogram、Summary 四种指标类型及其适用场景与 MetricsQL 配套函数接着梳理了 Push/Pull 两种写入模型及以 vmagent 为中心的混合采集架构再以foo_bar完整示例剖析了 Instant Query 与 Range Query 的执行语义、回看窗口与ephemeral临时样本机制并结合源码解释了-search.latencyOffset、-search.maxQueryDuration、/internal/force_flush等查询相关参数最后覆盖了 MetricsQL 的过滤、运算、聚合与rate等核心操作以及删除、relabeling、去重、降采样等数据修改能力。掌握这些概念是正确使用单机版与集群版 VictoriaMetrics 构建可靠监控体系的基础。【免费下载链接】VictoriaMetricsVictoriaMetrics: fast, cost-effective monitoring solution and time series database项目地址: https://gitcode.com/GitHub_Trending/vi/VictoriaMetrics创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考