特性标志
以下列出的功能列表，因为是破坏性更改或被认为是实验性的，在默认情况下被禁用。在未来的版本中，它们的行为可能会改变。具体的变更将在发布日志中进行通知。
你可以通过使用--enable-feature标志并以逗号分隔的列表来启用它们。在未来版本中，这些功能可能会被默认启用。
在外部标签中扩展环境变量
--enable-feature=expand-external-labels
根据当前环境变量的值替换 external_labels 值中的${var}或$var。引用未定义的变量将被替换为空字符串。要使用$字符可以通过$$进行转义。
Remote Write 接收器
--enable-feature=remote-write-receiver
Remote write 接收器允许 Prometheus 接受来自其他 Prometheus 服务器的远程写入请求。更多详细信息可以在这里找到。
通过该特性标志激活 remote write 接收器的功能已被弃用。应使用--web.enable-remote-write-receiver代替。此特性标志在未来版本的 Prometheus 中将被忽略。
示例存储
--enable-feature=exemplar-storage
OpenMetrics 引入了 Target 向某些指标添加示例的能力。示例是对指标集外数据的引用。常见的用途是链路追踪的 ID。
示例存储的实现为在内存中为所有序列存储示例的固定大小循环缓冲区。启用此功能将使 Prometheus 抓取的示例存储启用。配置文件块 storage/exemplars 可用于通过#个示例控制循环缓冲区的大小。仅包含trace_id=<jaeger-trace-id>的示例大约会使用100字节的示例存储内存。如果启用了示例存储，我们还将附加示例到 WAL 以实现本地持久化。
关机时内存快照
--enable-feature=memory-snapshot-on-shutdown
在关机时捕获内存状态的快照以及与系列信息，然后将其存储在磁盘上。因为在没有需要重做的 WAL 的情况下，可以使用此快照和映射块来恢复内存状态，该功能可以减少启动时间。
额外抓取指标
--enable-feature=extra-scrape-metrics
当启用时，对于每个实例抓取，Prometheus 会在以下额外的时间序列中存储样本：
scrape_timeout_seconds。Target 配置的scrape_timeout。这允许你通过scrape_duration_seconds / scrape_timeout_seconds测量每个 Target 进行采集时，与采集超时的接近程度。scrape_sample_limit。Target 的配置sample_limit。这允许你测量每个 Target 以了解它们接近限制的程度（scrape_samples_post_metric_relabeling / scrape_sample_limit）。请注意，scrape_sample_limit可以为零，如果没有配置限制，则上述查询将会返回+Inf。如果你只想查询具有样本限制的 Target，请使用此查询：scrape_samples_post_metric_relabeling / (scrape_sample_limit > 0)。scrape_body_size_bytes。成功抓取响应的未压缩大小。由于超出body_size_limit限制而导致抓取失败的报告为-1，其他抓取失败报告为0。
新服务发现管理器
--enable-feature=new-service-discovery-manager
当启用时，Prometheus 使用一个新的服务发现管理器，它不会在重新加载时重新启动没有变化的服务发现。这将使重新加载更快，而且能减轻对服务发现来源的负担。
鼓励用户测试新服务发现管理器并向上游报告使用过程中的任何问题。
在未来的版本中，这个新的服务发现管理器将成为默认选项，而这个特性标志将被忽略。
Prometheus 代理
--enable-feature=agent
当启用时，Prometheus 运行在代理模式下。代理模式仅限于发现、抓取和 remote write。
当你不需要从本地查询 Prometheus 数据，而是只从中央远程端点查询时，这很有用。
单步统计信息
--enable-feature=promql-per-step-stats
当启用时，通过查询请求传递stats=all会返回每一步的统计信息。当前该功能仅限于totalQueryableSamples。
在引擎或查询中禁用此功能时，每步的统计信息完全不会被统计。
自动 GOMAXPROCS
--enable-feature=auto-gomaxprocs
当启用时，自动设置 GOMAXPROCS 变量以匹配 Linux 容器的 CPU 配额。
自动 GOMEMLIMIT
--enable-feature=auto-gomemlimit
当启用时，自动设置 GOMEMLIMIT 变量以匹配 Linux 容器的内存限制。如果没有容器限制，或者进程正在容器外运行，则使用系统内存总量。
还有一个额外的标志--auto-gomemlimit.ratio，可用于控制使用的内存量。剩余的内存保留给进程之外的内存。例如，内核页面缓存。页面缓存对于 Prometheus TSDB 查询性能很重要。默认值为0.9，意味着将使用90%的内存限制供 Prometheus 使用。
默认抓取端口
--enable-feature=no-default-scrape-port
当启用时，HTTP（:80）或 HTTPS（:443）的默认端口将不会添加到用于抓取 Target 的地址（__address_标签的值），与默认行为相反。此外，如果已经通过静态配置或服务发现机制添加了默认 HTTP 或 HTTPS 端口，并且指定了相应的方案(http或https)，则该端口将被删除。
原生 Histogram
--enable-feature=native-histograms
当启用时，Prometheus 将消费原生 Histogram（native histogram，以前也被称为稀疏 Histogram 或高分辨率 Histogram）。原生 Histogram 仍然处于实验阶段。预计会发生包括使 TSDB 不可读在内的破坏性更改。
原生 Histogram 目前仅支持传统 Prometheus protobuf 暴露格式。因此，此特性标志还启用了一个新的（也是实验性的）protobuf 解析器，通过它可以消费所有指标（而不仅仅是原生 Histogram）。Prometheus 将尝试优先协商 protobuf 格式。被监控的 Target 也需要支持 protobuf 格式，并且需要暴露原生 histogram。protobuf 格式允许同时暴露经典和原生 Histogram。禁用此标志时，Prometheus 将继续通过文本格式解析经典 Histogram（classic histogram）。启用此标志时，Prometheus 将仍然消费没有对应原生 Histogram 的经典 Histogram。但是，如果存在原生 Histogram，则 Prometheus 将忽略相应的经典 Histogram，值得注意的是，无论如何，样本始终都会被消费。如果要保持经典 Histogram，请在采集作业中启用scrape_classic_histograms。
关于le和quantile标签值的格式：
在某些情况下，protobuf 解析会改变经典 Histogram 的le标签和总结的quantile标签的数字格式。通常，这种情况发生在使用 client_golang 的抓取 Target 中，其中promhttp.HandlerOpts.EnableOpenMetrics设置为false。在这种情况下，整数标签值在文本格式中表示如quantile="1"或le="2"。然而，protobuf 解析会将这些格式化为类似于浮点数的格式（遵循 OpenMetrics 规范），因此在 Prometheus 中被消费后，上面的例子变成了quantile="1.0"和le="2.0"，这改变了指标标签。
这种变化的影响是直接引用作为整数的le和quantile标签值的告警、记录规则和仪表板将停止工作。
在过渡期间，向量中包含不同格式的le和quantile标签的聚合会导致意外的结果，过渡期间的向量跨越不同格式之间的范围将包含额外的序列。这两种最常见的用例是通过histogram_quantile函数计算的分位数，例如histogram_quantile(0.95, sum by (le) (rate(histogram_bucket[10m])))。histogram_quantile函数已经尝试在某种程度上缓解这种影响，但仅覆盖少量样本时，较短的范围依然会有不准确的结果。
处理这种变化的方法：
- 修复对整数
le、quantile标签值的引用。否则的话你就得接受，在过渡期间一些查询可能会产生不准确或意外结果的事实。为了获得一致的标准化标签值，这是推荐的解决方案。Prometheus 3.0 也预计会强制规范化这些标签值。 - 使用
metric_relabel_config在抓取 Target 时保留旧的标签。这应该仅应用于当前产生此类标签的指标。
metric_relabel_configs: - source_labels: - quantile target_label: quantile regex: (\d+)\.0+ - source_labels: - le - __name__ target_label: le regex: (\d+)\.0+;.*_bucketOTLP 接收器
--enable-feature=otlp-write-receiver
OTLP 接收器允许 Prometheus 接受来自 OpenTelemetry 的指标值写入。Prometheus 最好作为基于 pull 的系统使用。在推送 OTLP 指标值时，staleness、up指标值和其他基于 pull 的功能无法正常工作。
实验性 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。
元数据 WAL 记录
--enable-feature=metadata-wal-records
启用后，Prometheus 将在内存中存储元数据，并在每个系列的基础上跟踪元数据的更改作为 WAL 记录。
如果同时使用 remote write 2.0，则必须使用此特性，因为它仅从 WAL 收集元数据。
延迟启动压缩开始时间
--enable-feature=delayed-compaction
向头部（Head）压缩开始时间添加一个随机偏移量，最多可达10%的块范围。这有助于 Prometheus 实例避免同时压缩从而减少共享资源的负载。
只有自动头部压缩和直接导致它们的操作受到此延迟的影响。
如果有多个连续的头部压缩，则只有第一个压缩受到这个延迟的影响。
请注意，在延迟期间，头部仍然执行其常规操作，包括服务和附加序列。
尽管存在延迟，但产生的块仍以与延迟不存在时相同的方式对齐时间。
延迟__name__标签删除功能
--enable-feature=promql-delayed-name-removal
启用后，Prometheus 将改变 PromQL 查询结果中__name__标签的删除方式（对于需要此操作的函数和表达式）。具体来说，它将延迟到查询被计算的最后一步删除，而不是每次评估创建衍生指标值的表达式或函数时都删除。
这允许通过label_replace和label_join函数选择性地保留__name__标签，并帮助防止“vector cannot contain metrics with the same labelset”错误（当在__name__标签上应用正则匹配器时，可能会发生这种情况）。
UTF-8 名称支持
--enable-feature=utf8-names
启用后，Prometheus 内部的指标值和标签名称验证方案将允许使用完整的 UTF-8 字符集。仅启用此标志本身并不启用通过内容协商请求 UTF-8 名称的功能。
用户还必须在抓取配置中设置metric_name_validation_scheme，以便在全局配置或单个抓取配置基础上启用该功能。
该文档基于 Prometheus 官方文档翻译而成。