以下是默认禁用的功能列表，因为它们属于破坏性变更或被认为是实验性的。它们的行为可能会在未来的版本中发生变化，相关变更将通过发布变更日志进行通知。
你可以使用 --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
此功能在关机时对内存中的 chunk 以及序列信息进行快照并存储到磁盘。这将减少启动时间，因为内存状态现在可以通过此快照和内存映射的 chunk 来恢复，而 WAL 重放仅需要处理快照中未包含的 WAL 部分。
额外的抓取指标
--enable-feature=extra-scrape-metrics
注意： 此功能开关已被弃用。请改用
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。
未在引擎或查询中启用时，不会计算每步统计信息。
实验性 PromQL 函数
--enable-feature=promql-experimental-functions
启用被视为实验性的 PromQL 函数。这些函数的名称、语法或语义可能会发生变化，也可能被完全移除。
起始（创建）时间戳零值注入
--enable-feature=created-timestamp-zero-ingestion
注意：CreatedTimestamp 功能已重命名为 StartTimestamp 以保持一致性。上述标志为了稳定性使用旧名称。
启用起始时间戳的摄入。起始时间戳在适当时以 0 值样本注入。详情请参阅 PromCon 演讲。
目前，Prometheus 在以下格式上支持起始时间戳：
PrometheusProtoOpenMetrics1.0.0
其中，Prometheus 推荐使用 PrometheusProto。这是因为 OpenMetrics 1.0 的起始时间戳信息以 <metric>_created 指标的形式共享，解析这些信息容易出错且开销较大（因此增加了额外负担）。你还需要注意不要让额外的 _created 指标污染你的 Prometheus。
因此，当启用 created-timestamp-zero-ingestion 时，Prometheus 会将全局 scrape_protocols 默认配置选项更改为 [ PrometheusProto, OpenMetricsText1.0.0, OpenMetricsText0.0.1, PrometheusText0.0.4 ]，从而优先协商 Prometheus Protobuf 协议（除非 scrape_protocols 选项被显式设置为其他值）。
除了在 Prometheus 中启用此功能外，被抓取的应用程序也需要暴露起始时间戳。
起始时间戳 (ST) 原生存储
--enable-feature=st-storage
启用每个样本的起始时间戳 (ST) 存储，通过 WAL、TSDB/Agent 和 Remote-Write 2.0 实现。此选项允许保留从抓取和接收协议中获得的确切 ST 值。未来此功能旨在替代通过注入合成 0 值样本的 created-timestamp-zero-ingestion。
目前，Prometheus 在以下格式上支持起始时间戳：
PrometheusProtoOpenMetrics1.0.0
推荐使用 PrometheusProto，因为 ST 传递效率更高。
除了在 Prometheus 中启用此功能外，被抓取的应用程序也需要暴露起始时间戳。
注意：这是一个实验性功能，在完全实现之前存在已知限制。
- 它引入了新的 WAL 记录类型（SamplesV2），只能由 Prometheus 3.11 或更高版本重放。
- 对于持久化存储支持（TSDB 块），你需要手动选择启用 XOR2 chunk 格式（
xor2-encoding标志）。
这可能会在我们完成 XOR2 实验阶段后发生变化。- 原生直方图和 NHCB 的 ST 尚未实现（参见 #18315）。
- PromQL 对 ST 的使用不在此功能的范围内。
独立规则的并发评估
--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 记录进行跟踪。
如果你想使用新的 Remote Write 2.0 发送元数据，则必须使用此功能。
延迟压缩开始时间
--enable-feature=delayed-compaction
在 Head 压缩开始时间上添加一个随机偏移量（最多为 chunk 范围的 10%）。这有助于 Prometheus 实例避免同时进行压缩，并减少共享资源上的负载。
只有自动 Head 压缩及由其直接产生的操作受此延迟影响。
如果可以进行多次连续的 Head 压缩，只有第一次压缩会经历此延迟。
请注意，在此延迟期间，Head 继续其正常操作，包括提供和追加序列。
尽管压缩存在延迟，但生成的块的时间对齐方式与没有延迟时完全相同。
延迟 PromQL 引擎的 `__name__` 标签移除
--enable-feature=promql-delayed-name-removal
启用后，Prometheus 将改变从 PromQL 查询结果中移除 __name__ 标签的方式（对于需要移除的函数和表达式）。具体来说，它将延迟移除到查询评估的最后一步，而不是每次评估创建派生指标的表达式或函数时都移除。
这允许通过 label_replace 和 label_join 函数可选地保留 __name__ 标签，并有助于防止 "vector cannot contain metrics with the same labelset" 错误，该错误可能在对 __name__ 标签应用正则匹配器时发生。
请注意，单独评估查询的部分仍然会触发标签集冲突。这通常发生在手动分析查询的中间结果或使用 PromLens 等工具时。
如果查询引用了已被移除的 __name__ 标签，其行为可能会在设置此功能开关时发生变化。（示例：sum by (__name__) (rate({foo="bar"}[5m]))，参见 GitHub 上的详情。）这类查询很少出现且容易修复。（在上述示例中，移除 by (__name__) 在没有功能开关时不会改变任何内容，并修复了使用功能开关时的潜在问题。）
可能会构造出一个按 __name__ 聚合的查询，将具有和不具有延迟名称移除的样本放入同一组中。在这种情况下，名称将从受影响的组中移除。请注意，这种情况几乎不会出现在具有实际用途的查询中。
自动重新加载配置
--enable-feature=auto-reload-config
启用后，Prometheus 将按指定的间隔自动重新加载其配置文件。该间隔由 --config.auto-reload-interval 标志定义，默认值为 30s。
配置重新加载通过检测主配置文件或任何引用文件（如规则和抓取配置）的校验和变化来触发。为确保一致性并避免重新加载过程中的问题，建议以原子方式更新这些文件。
OTLP Delta 转换
--enable-feature=otlp-deltatocumulative
启用后，Prometheus 将把 OTLP 指标从 delta 时间性转换为其累积等价形式，而不是丢弃它们。此功能不能与 otlp-native-delta-ingestion 同时启用。
此功能使用 OTel collector 的 deltatocumulative 处理器，采用其默认设置。
Delta 转换在内存中保持状态，以便随时间按序列聚合 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
在使用带有持续时间表达式的 offset 时，必须将表达式包裹在括号中。如果没有括号，offset 计算中只会使用第一个持续时间值。
step() 可以在持续时间表达式中使用。对于范围查询，它解析为范围查询的步长宽度。对于即时查询，它解析为 0s。
range() 可以在持续时间表达式中使用。对于范围查询，它解析为查询的完整范围（结束时间 - 开始时间）。对于即时查询，它解析为 0s。这在与 @end() 组合使用时特别有用，可以回顾整个查询范围，例如 max_over_time(metric[range()] @ end())。
min(<duration>, <duration>) 和 max(<duration>, <duration>) 可用于查找两个持续时间表达式的最小值或最大值。
注意：持续时间表达式不支持在 @ 时间戳运算符中使用。
支持以下运算符：
+- 加法-- 减法*- 乘法/- 除法%- 取模^- 幂运算
等价持续时间示例：
5m * 2等价于10m或600s10m - 1m等价于9m或540s(5+2) * 1m等价于7m或420s1h / 2等价于30m或1800s4h % 3h等价于1h或3600s(2 ^ 3) * 1m等价于8m或480sstep() + 1等价于查询步长宽度加 1 秒。max(step(), 5s)等价于查询步长宽度和5s中较大的值。min(2 * step() + 5s, 5m)等价于查询步长的两倍加5s和5m中较小的值。
OTLP 原生 Delta 支持
--enable-feature=otlp-native-delta-ingestion
启用后，允许原生摄入 delta OTLP 指标，存储原始样本值而不进行转换。此功能不能与 otlp-deltatocumulative 同时启用。
目前，StartTimeUnixNano 字段被忽略，delta 指标被赋予未知的指标元数据类型。
Delta 支持处于非常早期的开发阶段，摄入和查询过程可能会随时间变化。有关开放提案，请参阅 prometheus/proposals#48。
查询
我们鼓励用户尝试使用 delta 指标和现有的 PromQL 函数；我们将收集反馈并可能构建新功能以改善 delta 指标的查询体验。
请注意，标准的 PromQL 计数器函数如 rate() 和 increase() 是为累积指标设计的，用于 delta 指标时会产生不正确的结果。这在未来可能会改变，但目前，要获得 delta 指标的类似结果，你需要使用 sum_over_time()：
sum_over_time(delta_metric[<range>])：计算指定时间范围内 delta 值的总和。sum_over_time(delta_metric[<range>]) / <range>：计算 delta 指标的每秒速率。
如果 <range> 不是指标采集间隔的倍数，这些查询可能效果不佳。例如，如果你执行 sum_over_time(delta_metric[1m]) / 1m 范围查询（步长为 1m），但指标的采集间隔为 10m，图表将每 10 分钟显示一个具有较高速率值的单点，而不是 10 个具有较低且恒定速率值的点。
当前注意事项
如果 delta 指标通过联邦暴露，当摄入间隔与联邦端点的抓取间隔不同时，数据可能会被错误收集。
很难判断一个指标是 delta 还是累积时间性的，因为指标名称或标签中没有时间性的指示。目前，如果你同时摄入 delta 和累积指标，我们建议你显式添加自己的标签来区分它们。未来，我们计划引入类型标签来一致地区分指标类型，并可能使 PromQL 函数具有类型感知能力（例如，当累积专用函数用于 delta 指标时提供警告）。
如果在同一时间戳有多个样本被摄入，只保留其中一个点 - 样本不会被求和（这是 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 用户体验（当错误的类型用于错误的函数时提供帮助）、自动重命名、delta 类型等。
与元数据记录的行为
当此功能启用且存在元数据 WAL 记录时，在类型或单位不一致的罕见情况下，Prometheus 输出将优先使用 __type__ 和 __unit__ 标签值。例如在 Remote Write 2.0 中，如果元数据记录由于某种原因（例如 bug）显示为 "counter"，但 __type__="gauge"，则远程时间序列将被设置为 gauge。
使用非缓存 IO
--enable-feature=use-uncached-io
实验性功能，仅在 Linux 上可用。
启用后，chunk 写入将绕过页面缓存。其主要目标是减少围绕页面缓存行为的困惑，并防止因误导性缓存增长而导致的内存过度分配。
目前使用直接 I/O 实现。
更多详情请参阅提案。
XOR2 chunk 编码
--enable-feature=xor2-encoding
警告：这是一个高度实验性且有风险的设置：
- 使用 XOR2 编码的 chunk 无法被不支持该编码的旧版 Prometheus 读取。一旦启用并写入数据，你需要手动从磁盘删除块，否则 Prometheus 将在所有查询中返回错误。
- 我们仍在对最终编码进行实验。目前此编码可能在任何 Prometheus 版本中发生变化。你的所有持久化块数据将在版本之间丢失。
- 这是新的编码，意味着下游工具和长期存储系统可能尚不支持它（例如 Thanos sidecar 上传的块）。
此设置启用新的 XOR2 chunk 编码用于浮点样本，对于典型的 Prometheus 工作负载，它提供比默认 XOR 编码更好的磁盘压缩。此格式还允许存储起始时间戳 (ST)。
扩展范围选择器
--enable-feature=promql-extended-range-selectors
启用实验性的 anchored 和 smoothed 修饰符，用于 PromQL 范围和即时选择器。这些修饰符提供了对范围边界处理方式的更多控制，特别是在 rate 和 increase 等函数中处理缺失或不规则数据时。
原生直方图尚不支持扩展范围选择器。
`anchored`
使用范围开始处的最近样本（在 lookback delta 内），如果在 lookback delta 内没有样本，则使用范围内的第一个样本。范围末尾也使用范围内的最后一个样本。不应用外推或内插，因此这对于获取样本值之间的直接差异非常有用。
Anchored 范围选择器适用于：resets、changes、rate、increase 和 delta。
示例查询：increase(http_requests_total[5m] anchored)
注意：当使用 anchored 修饰符与 increase 函数时，返回的结果是整数。
`smoothed`
在范围选择器中，在范围边界处进行线性内插，使用边界前后的样本值进行改进的估计，对于不规则抓取和缺失样本具有更好的鲁棒性。然而，它需要评估区间之后的样本才能正常工作，请参阅下面的注意事项。
对于即时选择器，使用评估时间戳前后的样本在评估时间戳处进行线性内插。
Smoothed 范围选择器适用于：rate、increase 和 delta。
示例查询：rate(http_requests_total[step()] smoothed)
告警和记录规则的注意事项：
smoothed修饰符需要评估区间之后的样本，因此在告警或记录规则中直接使用通常会低估结果，因为在评估时未来的样本不可用。
要在规则中安全使用smoothed，你必须对规则组应用query_offset（参见文档）以确保计算窗口完全在过去，并且所有需要的样本都可用。
对于关键告警，将偏移量设置为至少一个抓取间隔；对于不太关键或更具弹性的用例，考虑更大的偏移量（多个抓取间隔）以容忍错过的抓取。
更多详情请参阅设计文档。
注意：扩展范围选择器不支持子查询。
二元运算符填充修饰符
--enable-feature=promql-binop-fill-modifiers
启用实验性的 fill()、fill_left() 和 fill_right() 修饰符，用于 PromQL 二元运算符。这些修饰符允许在二元操作的任意一侧使用提供的默认样本值填充缺失的匹配项。
示例查询：
rate(successful_requests[5m])
+ fill(0)
rate(failed_requests[5m])
更多详情和示例请参阅填充修饰符文档。