以下列出的是默认禁用的功能，因为它们属于破坏性变更或被认为是实验性的功能。 它们的行为可能会在未来的版本中发生变化，这将通过发布变更日志进行沟通。
您可以使用 --enable-feature 标志以及逗号分隔的功能列表来启用它们。 它们可能会在未来的版本中默认启用。
--enable-feature=exemplar-storage
OpenMetrics 引入了抓取目标向某些指标添加 exemplars 的能力。 Exemplars 是对 MetricSet 外部数据的引用。 一个常见的用例是程序跟踪的 ID。
Exemplar 存储实现为固定大小的循环缓冲区，用于在内存中存储所有序列的 exemplars。 启用此功能将启用 Prometheus 抓取的 exemplars 的存储。 配置文件块 存储/exemplars 可用于控制循环缓冲区的大小（以 exemplars 数量计）。 仅包含 trace_id=<jaeger-trace-id> 的 exemplar 通过内存中的 exemplar 存储大约使用 100 字节的内存。 如果启用了 exemplar 存储，我们还会将 exemplars 附加到 WAL 以进行本地持久化（用于 WAL 持续时间）。
--enable-feature=memory-snapshot-on-shutdown
这会在关闭时拍摄内存中 chunks 的快照以及序列信息，并将其存储在磁盘上。 这将减少启动时间，因为现在可以使用此快照和 m-mapped chunks 恢复内存状态，而只需要从磁盘重放 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 将忽略相应的经典直方图，但 exemplars 除外，exemplars 始终会被摄取。 要同时保留经典直方图，请在抓取作业中启用 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 将在内存中存储元数据，并按序列跟踪元数据更改作为 WAL 记录。
如果您想使用新的远程写入 2.0 发送元数据，则必须使用此功能。
--enable-feature=delayed-compaction
一个随机偏移量（最多为 chunk 范围的 10%）被添加到 Head 压缩开始时间。 这有助于 Prometheus 实例避免同时压缩，并减少共享资源的负载。
只有自动 Head 压缩和直接由此产生的操作才会受到此延迟的影响。
在可能进行多次连续 Head 压缩的情况下，只有第一次压缩会经历此延迟。
请注意，在此延迟期间，Head 继续其通常的操作，包括服务和附加序列。
尽管压缩存在延迟，但生成的块在时间上对齐的方式与未延迟时相同。
__name__ 标签移除--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 标志定义，默认为 30 秒。
配置重新加载是通过检测主配置文件或任何引用的文件（例如规则和抓取配置）的校验和更改来触发的。 为了确保重新加载期间的一致性并避免问题，建议原子性地更新这些文件。
--enable-feature=otlp-deltatocumulative
启用后，Prometheus 将 OTLP 指标从增量时序性转换为其累积等效项，而不是丢弃它们。
这使用了来自 OTel collector 的 deltatocumulative，使用其默认设置。
Delta 转换保持内存状态，以聚合每个序列随时间推移的增量更改。 当 Prometheus 重新启动时，此状态会丢失，并从零开始重新聚合。 这会导致累积序列中的计数器重置。
此状态会定期 (max_stale) 清除不活动的序列。
启用此功能可能会对性能产生负面影响，因为内存状态受到互斥锁保护。 仅累积 OTLP 请求不受影响。
本文档是开源的。 请通过提交 issue 或 pull request 来帮助改进它。