以下是默认禁用的功能列表，因为它们是破坏性变更或被认为是实验性的。它们的行为在未来版本中可能会改变，这将通过版本变更日志进行沟通。
您可以使用带有逗号分隔的功能列表的 --enable-feature 标志来启用它们。它们在未来版本中可能会默认启用。
--enable-feature=exemplar-storage
OpenMetrics 引入了抓取目标向特定指标添加 exemplar 的能力。Exemplar 是 MetricSet 外部数据的引用。一个常见的用例是程序跟踪的 ID。
Exemplar 存储实现为一个固定大小的循环缓冲区，用于在内存中存储所有 series 的 exemplar。启用此功能将启用 Prometheus 抓取的 exemplar 的存储。配置文件的 storage/exemplars 块可用于通过 exemplar 数量控制循环缓冲区的大小。一个仅包含 trace_id=<jaeger-trace-id> 的 exemplar 通过内存中的 exemplar 存储大约占用 100 字节的内存。如果 exemplar 存储启用，我们还会将 exemplar 追加到 WAL 以进行本地持久化（在 WAL 持续时间内）。
--enable-feature=memory-snapshot-on-shutdown
这会在关机时对内存中的块以及 series 信息进行快照，并将其存储到磁盘。这将减少启动时间，因为内存状态现在可以通过此快照和内存映射块进行恢复，而 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。
--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 2.x) web UI，而不是新的 UI。作为 Prometheus 3.0 的一部分发布的新 UI 是一个完全重写，旨在更简洁、更清爽、底层更现代化。然而，它尚未完全实现功能并经过实战检验，因此一些用户可能仍然喜欢使用旧的 UI。
--enable-feature=old-ui
--enable-feature=metadata-wal-records
启用后，Prometheus 将在内存中存储元数据，并按 series 跟踪元数据变更作为 WAL 记录。
如果您想使用新的远程写 2.0 发送元数据，则必须启用此功能。
--enable-feature=delayed-compaction
一个随机偏移量（最多为块范围的 10%）将被添加到 Head 合并的开始时间。这有助于 Prometheus 实例避免同时合并，并减少共享资源的负载。
只有自动 Head 合并以及直接由此产生的操作才会受到此延迟的影响。
如果可能发生多次连续的 Head 合并，则只有第一次合并会受到此延迟的影响。
请注意，在此延迟期间，Head 继续执行其常规操作，包括提供服务和追加 series。
尽管合并存在延迟，但生成的块的时间对齐方式与没有延迟时相同。
__name__ 标签移除用于 PromQL 引擎--enable-feature=promql-delayed-name-removal
启用后，Prometheus 将改变从 PromQL 查询结果中移除 __name__ 标签的方式（对于需要这样做的函数和表达式）。具体来说，它会将移除操作延迟到查询评估的最后一步，而不是每次评估创建派生指标的表达式或函数时都移除。
这允许通过 label_replace 和 label_join 函数选择性地保留 __name__ 标签，并有助于防止在将正则表达式匹配器应用于 __name__ 标签时可能发生的“向量不能包含具有相同标签集的指标”错误。
请注意，单独评估查询的部分内容仍会触发标签集冲突。这通常发生在手动分析查询中间结果或使用 PromLens 等工具时。
如果查询引用了已经移除的 __name__ 标签，当此功能标志设置时，其行为可能会改变。（示例：sum by (__name__) (rate({foo="bar"}[5m]))，详见 GitHub。）这些查询很少出现且易于修复。（在上述示例中，移除 by (__name__) 在没有功能标志的情况下不会改变任何内容，并且解决了使用功能标志时可能出现的问题。）
--enable-feature=auto-reload-config
启用后，Prometheus 将按指定的间隔自动重新加载其配置文件。该间隔由 --config.auto-reload-interval 标志定义，默认为 30s。
配置重新加载由检测主配置文件或任何引用文件（如规则和抓取配置）的校验和变化触发。为了确保一致性并避免重新加载期间出现问题，建议以原子方式更新这些文件。
--enable-feature=otlp-deltatocumulative
启用后，Prometheus 会将具有 delta 暂时性的 OTLP 指标转换为其累积等效项，而不是丢弃它们。此功能不能与 otlp-native-delta-ingestion 一起启用。
这使用了来自 OTel collector 的 deltatocumulative，采用其默认设置。
Delta 转换会保留内存状态，以随时间聚合每个 series 的 delta 变化。当 Prometheus 重启时，此状态会丢失，聚合会重新从零开始。这会导致累积 series 中出现计数器重置。
此状态会定期（max_stale）清除不活动的 series。
启用此功能可能对性能产生负面影响，因为内存状态受到 mutex 保护。仅累积的 OTLP 请求不受影响。
--enable-feature=promql-duration-expr
使用此标志，可以在范围查询和 offset 时长的时间段中使用算术表达式。例如
在范围查询中：rate(http_requests_total[5m * 2]) # 10 分钟范围 rate(http_requests_total[(5+2) * 1m]) # 7 分钟范围
在 offset 时长中：http_requests_total offset (1h / 2) # 30 分钟 offset http_requests_total offset ((2 ^ 3) * 1m) # 8 分钟 offset
注意：@ 时间戳运算符不支持时长表达式。
支持以下运算符
+ - 加法- - 减法* - 乘法/ - 除法% - 模数^ - 幂运算等效时长的示例
5m * 2 等效于 10m 或 600s10m - 1m 等效于 9m 或 540s(5+2) * 1m 等效于 7m 或 420s1h / 2 等效于 30m 或 1800s4h % 3h 等效于 1h 或 3600s(2 ^ 3) * 1m 等效于 8m 或 480s--enable-feature=otlp-native-delta-ingestion
启用后，允许原生摄入 delta OTLP 指标，存储原始样本值而不进行转换。此功能不能与 otlp-deltatocumulative 一起启用。
目前，StartTimeUnixNano 字段被忽略，delta 被赋予未知指标元数据类型。
Delta 支持尚处于非常早期的开发阶段，摄入和查询过程可能会随时间变化。有关开放提案，请参阅 prometheus/proposals#48。
我们鼓励用户试验 delta 和现有的 PromQL 函数；我们将收集反馈并可能构建功能来改善 delta 查询体验。
请注意，像 rate() 和 increase() 这样的标准 PromQL 计数器函数是为累积指标设计的，与 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 范围查询（步长为 1 分钟），但指标的采集间隔是 10 分钟，则图表每隔 10 分钟会显示一个高速率值点，而不是 10 个较低的恒定值点。
如果通过联合暴露 delta 指标，当摄入间隔与联合端点的抓取间隔不同时，可能会错误地采集数据。
很难判断指标是 delta 还是 cumulative 暂时性，因为指标名称或标签中没有暂时性的指示。目前，如果您正在摄入 delta 和 cumulative 指标的混合数据，我们建议您明确添加自己的标签来区分它们。未来，我们计划引入类型标签以一致地区分指标类型，并可能使 PromQL 函数具有类型感知能力（例如，当仅累积函数与 delta 指标一起使用时提供警告）。
如果在同一时间戳有多个样本被摄入，只会保留其中一个点 - 样本不会被累加在一起（这是 Prometheus 的通常工作方式 - 重复的时间戳样本会被拒绝）。任何聚合都必须在将样本发送到 Prometheus 之前完成。
本文档是开源的。请通过提交问题或拉取请求来帮助改进它。