功能标志

这里列出了一些默认禁用的功能,因为它们是重大变更或被认为是实验性的。它们的行为可能会在未来的版本中发生变化,相关信息将通过发布变更日志进行传达。

您可以使用 --enable-feature 标志并提供一个逗号分隔的功能列表来启用它们。它们可能会在未来的版本中默认启用。

Exemplar 存储

--enable-feature=exemplar-storage

OpenMetrics 引入了抓取目标向某些指标添加 exemplar 的能力。Exemplar 是对 MetricSet 外部数据的引用。一个常见的用例是程序跟踪的 ID。

Exemplar 存储被实现为一个固定大小的循环缓冲区,用于在内存中存储所有序列的 exemplar。启用此功能将开启对 Prometheus 抓取的 exemplar 的存储。配置文件块 storage/exemplars 可用于按 exemplar 数量控制循环缓冲区的大小。一个仅包含 trace_id=<jaeger-trace-id> 的 exemplar 通过内存中的 exemplar 存储大约使用 100 字节的内存。如果启用了 exemplar 存储,我们还将 exemplar 附加到 WAL 以实现本地持久性(在 WAL 持续时间内)。

关闭时进行内存快照

--enable-feature=memory-snapshot-on-shutdown

这会在关闭时为内存中的块和序列信息创建快照,并将其存储在磁盘上。这将减少启动时间,因为现在可以使用此快照和 m-mapped 块来恢复内存状态,而只需对 WAL 中不属于快照的部分进行 WAL 重放。

额外的抓取指标

--enable-feature=extra-scrape-metrics

启用后,对于每个实例抓取,Prometheus 会在以下额外的时间序列中存储一个样本:

  • scrape_timeout_seconds。为目标配置的 scrape_timeout。这允许您测量每个目标,通过 scrape_duration_seconds / scrape_timeout_seconds 来了解它们离超时有多近。
  • scrape_sample_limit。为目标配置的 sample_limit。这允许您测量每个目标,通过 scrape_samples_post_metric_relabeling / scrape_sample_limit 来了解它们离达到限制有多近。请注意,如果没有配置限制,scrape_sample_limit 可以为零,这意味着对于没有限制的目标,上述查询可能返回 +Inf(因为我们除以零)。如果您只想查询有样本限制的目标,请使用此查询:scrape_samples_post_metric_relabeling / (scrape_sample_limit > 0)
  • scrape_body_size_bytes。如果成功,最近一次抓取响应的未压缩大小。因超过 body_size_limit 而失败的抓取报告 -1,其他抓取失败报告 0

每步统计信息

--enable-feature=promql-per-step-stats

启用后,在查询请求中传递 stats=all 会返回每步的统计信息。目前这仅限于 totalQueryableSamples。

如果在引擎或查询中禁用,则根本不会计算每步的统计信息。

原生直方图

--enable-feature=native-histograms

启用后,Prometheus 将摄取原生直方图(以前也称为稀疏直方图或高分辨率直方图)。原生直方图仍处于高度实验阶段。预计会发生重大变更(包括那些会使 TSDB 不可读的变更)。

原生直方图目前仅在传统的 Prometheus protobuf 公开格式中受支持。因此,此功能标志还会启用一个新的(也是实验性的)protobuf 解析器,通过它来摄取*所有*指标(即不仅仅是原生直方图)。Prometheus 将首先尝试协商 protobuf 格式。被插桩的目标也需要支持 protobuf 格式,*并且*需要公开原生直方图。protobuf 格式允许并排公开经典直方图和原生直方图。如果禁用此功能标志,Prometheus 将继续解析经典直方图(尽管是通过文本格式)。如果启用此标志,Prometheus 仍然会摄取那些没有相应原生直方图的经典直方图。但是,如果存在原生直方图,Prometheus 将忽略相应的经典直方图,但 exemplar 是个明显的例外,它总是会被摄取。要同时保留经典直方图,请在抓取作业中启用 always_scrape_classic_histograms

实验性 PromQL 函数

--enable-feature=promql-experimental-functions

启用被认为是实验性的 PromQL 函数。这些函数的名称、语法或语义可能会发生变化。它们也可能被完全删除。

创建时间戳零值注入

--enable-feature=created-timestamp-zero-ingestion

启用创建时间戳的摄取。在适当的时候,创建时间戳会作为值为 0 的样本注入。详情请见 PromCon 演讲

目前 Prometheus 仅在传统的 Prometheus Protobuf 协议上支持创建时间戳(其他协议正在开发中)。因此,启用此功能时,将优先使用 Prometheus protobuf 抓取协议(更多详情请参见 scrape_config.scrape_protocols 设置)。

除了在 Prometheus 中启用此功能外,被抓取的应用程序也需要公开创建时间戳。

独立规则的并发评估

--enable-feature=concurrent-rule-eval

默认情况下,规则组是并发执行的,但一个组内的规则是顺序执行的;这是因为规则可以使用前面规则的输出作为其输入。然而,如果规则之间没有可检测到的关系,就没有理由顺序运行它们。当启用 concurrent-rule-eval 功能标志时,规则组内不依赖于其他规则的规则将被并发评估。这有可能提高规则组评估的延迟和资源利用率,但代价是增加更多的并发查询负载。

并发规则评估的数量可以通过 --rules.max-concurrent-rule-evals 进行配置,默认设置为 4

提供旧版 Prometheus UI

回退到提供旧的(Prometheus 2.x)Web UI,而不是新的 UI。作为 Prometheus 3.0 的一部分发布的新 UI 是一次完全重写,旨在变得更简洁、不那么杂乱,并且底层更现代化。然而,它尚未完全功能完备且经过实战检验,所以一些用户可能仍偏好使用旧版 UI。

--enable-feature=old-ui

元数据 WAL 记录

--enable-feature=metadata-wal-records

启用后,Prometheus 将在内存中存储元数据,并以 WAL 记录的形式跟踪每个序列的元数据变化。

如果您想使用新的远程写入 2.0 发送元数据,则必须使用此功能。

延迟压缩开始时间

--enable-feature=delayed-compaction

一个随机偏移量,最多为块范围的 10%,被添加到 Head 压缩的开始时间。这有助于 Prometheus 实例避免同时进行压缩,并减少对共享资源的负载。

只有自动 Head 压缩和直接由其产生的操作会受到此延迟的影响。

如果可能连续进行多次 Head 压缩,则只有第一次压缩会经历此延迟。

请注意,在此延迟期间,Head 会继续其常规操作,包括提供和附加序列。

尽管压缩存在延迟,但生成的块与没有延迟时的时间对齐方式相同。

为 PromQL 引擎延迟移除 __name__ 标签

--enable-feature=promql-delayed-name-removal

启用后,Prometheus 将改变从 PromQL 查询结果中移除 __name__ 标签的方式(对于需要此操作的函数和表达式)。具体来说,它会将移除操作延迟到查询评估的最后一步,而不是每次评估创建派生指标的表达式或函数时都进行移除。

这允许通过 label_replacelabel_join 函数选择性地保留 __name__ 标签,并有助于防止“vector cannot contain metrics with the same labelset”错误,该错误可能在对 __name__ 标签应用正则表达式匹配器时发生。

请注意,单独评估查询的各个部分仍会触发标签集冲突。这种情况通常在使用 PromLens 等工具手动分析查询的中间结果时发生。

如果查询引用了已经被移除的 __name__ 标签,其行为可能会在设置此功能标志时发生变化。(例如:sum by (__name__) (rate({foo="bar"}[5m])),详情请参见 GitHub 上的详细信息。)这类查询很少出现,并且很容易修复。(在上面的例子中,移除 by (__name__) 在没有功能标志的情况下不会改变任何东西,而在有功能标志的情况下可以修复可能的问题。)

自动重载配置

--enable-feature=auto-reload-config

启用后,Prometheus 将按指定的时间间隔自动重载其配置文件。该间隔由 --config.auto-reload-interval 标志定义,默认为 30s

配置重载是通过检测主配置文件或任何引用的文件(如规则和抓取配置)的校验和变化来触发的。为确保重载期间的一致性并避免问题,建议以原子方式更新这些文件。

OTLP Delta 转换

--enable-feature=otlp-deltatocumulative

启用后,Prometheus 会将 OTLP 指标从增量(delta)时序性转换为其等效的累积(cumulative)时序性,而不是丢弃它们。此功能不能与 otlp-native-delta-ingestion 同时启用。

这使用了 OTel collector 中的 deltatocumulative 处理器,并采用其默认设置。

Delta 转换会维护内存中的状态,以随时间聚合每个序列的增量变化。当 Prometheus 重启时,此状态会丢失,聚合会从零重新开始。这会导致累积序列中的计数器重置。

此状态会定期(max_stale)清除不活跃的序列。

启用此功能*可能*会对性能产生负面影响,因为内存中的状态受到互斥锁保护。仅累积的 OTLP 请求不受影响。

PromQL 时间持续期中的算术表达式

--enable-feature=promql-duration-expr

启用此标志后,可以在范围查询和偏移持续期的时间持续期中使用算术表达式。

在范围查询中

rate(http_requests_total[5m * 2])  # 10 minute range
rate(http_requests_total[(5+2) * 1m])  # 7 minute range

在偏移持续期中

http_requests_total offset (1h / 2)  # 30 minute offset
http_requests_total offset ((2 ^ 3) * 1m)  # 8 minute offset

当使用带有持续期表达式的偏移时,您必须将表达式用括号括起来。不使用括号,只有第一个持续期值将用于偏移计算。

step() 可以在持续期表达式中使用。对于**范围查询**,它解析为范围查询的步长。对于**即时查询**,它解析为 0s

min(<duration>, <duration>)max(<duration>, <duration>) 可用于查找两个持续期表达式的最小值或最大值。

注意:@ 时间戳操作符不支持持续期表达式。

支持以下操作符:

  • + - 加法
  • - - 减法
  • * - 乘法
  • / - 除法
  • % - 模运算
  • ^ - 幂运算

等效持续期示例:

  • 5m * 2 等效于 10m600s
  • 10m - 1m 等效于 9m540s
  • (5+2) * 1m 等效于 7m420s
  • 1h / 2 等效于 30m1800s
  • 4h % 3h 等效于 1h3600s
  • (2 ^ 3) * 1m 等效于 8m480s
  • step() + 1 等效于查询步长增加 1 秒。
  • max(step(), 5s) 等效于查询步长和 5s 中较大的那个。
  • min(2 * step() + 5s, 5m) 等效于查询步长的两倍加上 5s5m 中较小的那个。

OTLP 原生 Delta 支持

--enable-feature=otlp-native-delta-ingestion

启用后,允许原生摄取增量(delta)OTLP 指标,存储原始样本值而不进行转换。此功能不能与 otlp-deltatocumulative 同时启用。

目前,StartTimeUnixNano 字段被忽略,并且增量被赋予未知的指标元数据类型。

Delta 支持处于非常早期的开发阶段,摄取和查询过程可能会随着时间而改变。有关开放提案,请参见 prometheus/proposals#48

查询

我们鼓励用户试验 delta 和现有的 PromQL 函数;我们将收集反馈,并可能构建功能以改善查询 delta 的体验。

请注意,标准的 PromQL 计数器函数,如 rate()increase(),是为累积指标设计的,当用于增量指标时会产生不正确的结果。这种情况将来可能会改变,但目前要获得增量指标的类似结果,您需要使用 sum_over_time()

  • sum_over_time(delta_metric[<range>]):计算指定时间范围内增量值的总和。
  • sum_over_time(delta_metric[<range>]) / <range>:计算增量指标的每秒速率。

如果 <range> 不是指标收集间隔的倍数,这些函数可能无法正常工作。例如,如果您执行一个 sum_over_time(delta_metric[1m]) / 1m 范围查询(步长为 1m),但指标的收集间隔是 10m,那么图表将每 10 分钟显示一个高率值的点,而不是 10 个具有较低恒定值的点。

当前的注意事项

  • 如果通过联邦公开增量指标,如果摄取间隔与联邦端点的抓取间隔不同,则可能导致数据收集不正确。

  • 很难判断一个指标是增量时序性还是累积时序性,因为指标名称或标签中没有时序性的指示。目前,如果您正在摄取增量和累积指标的混合体,我们建议您明确添加自己的标签来区分它们。未来,我们计划引入类型标签,以一致地区分指标类型,并可能使 PromQL 函数能够感知类型(例如,当累积型函数用于增量指标时提供警告)。

  • 如果同一时间戳有多个样本被摄取,则只保留其中一个点 - 样本**不会**被加在一起(这是 Prometheus 的通用工作方式 - 重复时间戳的样本会被拒绝)。任何聚合都必须在将样本发送到 Prometheus 之前完成。

类型和单位标签

--enable-feature=type-and-unit-labels

启用后,Prometheus 将开始注入额外的、保留的 __type____unit__ 标签,这是根据 PROM-39 提案 设计的。

这些标签来源于现有抓取和摄取格式(如 OpenMetrics Text、Prometheus Text、Prometheus Proto、Remote Write 2 和 OTLP)的元数据结构。所有用户提供的带有 __type____unit__ 的标签都将被覆盖。

PromQL 层将像处理 name 一样处理这些标签,例如在某些操作(如 -+)中被丢弃,并受 promql-delayed-name-removal 功能的影响。

此功能使得重要的元数据信息可以直接与样本和 PromQL 层一起访问。

对于以下用户来说,这尤其有用:

  • 希望能够根据类型或单位选择指标。
  • 希望处理具有相同指标名称但不同类型和单位的序列的情况。例如,原生直方图迁移或来自 OTLP 端点的 OpenTelemetry 指标,无需翻译。

未来计划进行更多工作,这些工作将依赖于此,例如,丰富的 PromQL 用户体验,有助于在错误类型用于错误函数时提供帮助,自动重命名,增量类型等。

使用非缓存 IO

--enable-feature=use-uncached-io

实验性功能,仅在 Linux 上可用。

启用后,它会使块(chunk)写入绕过页面缓存。其主要目标是减少围绕页面缓存行为的困惑,并防止因误导性的缓存增长而导致内存过度分配。

目前这是使用直接 I/O 实现的。

更多详情,请参阅提案

扩展范围选择器

--enable-feature=promql-extended-range-selectors

启用 PromQL 范围选择器和瞬时选择器的实验性 anchoredsmoothed 修饰符。这些修饰符可以更好地控制 rateincrease 等函数中范围边界的处理方式,尤其是在数据缺失或不规律的情况下。

扩展范围选择器尚不支持原生直方图。

anchored

在范围的开始处,使用最近的样本(在回溯窗口内),或者如果没有在回溯窗口内的样本,则使用范围内的第一个样本。范围内的最后一个样本也用于范围的末尾。不应用外插或内插,因此这对于获取样本值之间的直接差异非常有用。

锚定范围选择器可用于:resetschangesrateincreasedelta

查询示例:increase(http_requests_total[5m] anchored)

注意:当将 anchored 修饰符与 increase 函数一起使用时,返回的结果是整数。

smoothed

对于范围选择器,它会使用边界前后的样本值在范围边界处进行线性插值,以得到更优的估算,这种方法对于不规律的抓取和样本缺失具有鲁棒性。但是,它需要评估区间之后有一个样本才能正常工作,请参阅下面的说明。

对于瞬时选择器,它会使用评估时间点前后的样本在该时间点进行线性插值。

平滑范围选择器可用于:rateincreasedelta

查询示例:rate(http_requests_total[step()] smoothed)

关于告警和记录规则的注意:smoothed 修饰符需要在评估区间之后有样本,因此直接在告警或记录规则中使用它通常会低估结果,因为在评估时未来的样本是不可用的。为了在规则中安全地使用 smoothed,你必须为规则组应用一个 query_offset(请参阅文档),以确保计算窗口完全位于过去,并且所有需要的样本都可用。
对于关键告警,请将偏移量设置为至少一个抓取间隔;对于不那么关键或更具弹性的用例,可以考虑设置一个更大的偏移量(多个抓取间隔)以容忍抓取失败。

更多详情,请参阅设计文档

注意:子查询不支持扩展范围选择器。

本页内容