Prometheus 联邦、迁移

FEDERATION 允许Prometheus服务器从另一台Prometheus服务器抓取选定的时间序列。

一，用例

联盟有不同的用例。通常，它用于实现可扩展的Prometheus监控设置或将相关指标从一个服务的Prometheus拉到另一个服务。

1.1 分层联盟

分层联盟使Prometheus可以扩展到具有数十个数据中心和数百万个节点的环境。在此用例中，联合拓扑就像一棵树，更高级别的Prometheus服务器从大量从属服务器收集聚合的时间序列数据。

例如，设置可能包含许多高度详细收集数据的每个数据中心Prometheus服务器（实例级深入分析），以及一组仅收集和存储聚合数据的全局Prometheus服务器（作业级向下钻取））来自那些本地服务器。这提供了聚合全局视图和详细的本地视图。

1.2 跨服务联盟

在跨服务联盟中，将一项服务的Prometheus服务器配置为从另一项服务的Prometheus服务器抓取所选数据，以针对单个服务器内的两个数据集启用警报和查询。
例如，运行多个服务的集群调度程序可能会公开有关集群上运行的服务实例的资源使用情况信息（例如内存和CPU使用情况）。另一方面，在该群集上运行的服务将仅公开特定于应用程序的服务指标。通常，这两组指标是由单独的Prometheus服务器抓取的。使用联盟，包含服务级别指标的Prometheus服务器可以从群集Prometheus中获取有关其特定服务的群集资源使用指标，以便可以在该服务器中使用这两组指标。

二、联邦配置

在任何给定的Prometheus服务器上，/federate端点允许检索该服务器中所选时间序列集的当前值。必须至少指定一个match[] URL参数才能选择要公开的时间序列。每个match[]参数都需要指定一个瞬时向量选择器，如up或{job=\”api-server\”}。如果提供了多个match[]参数，则选择所有匹配系列的并集。
要将指标从一个服务器联合到另一个服务器，请将目标Prometheus服务器配置为从源服务器的/federate端点进行采集，同时还启用honor_labels scrape选项（以不覆盖源服务器公开的任何标签）并传入所需的 match[]参数。
例如，以下scrape_config将任何带有标签job=\”prometheus\”的系列或以job开头的度量标准名称联合起来：source-prometheus-{1,2,3}:9090的Prometheus服务器进入抓取Prometheus：

scrape_configs:
  - job_name: \'federate\'
    scrape_interval: 15s
    honor_labels: true
    metrics_path: \'/federate\'
    params:
      \'match[]\':
        - \'{job=\"prometheus\"}\'
        - \'{__name__=~\"job:.*\"}\'
    static_configs:
      - targets:
        - \'source-prometheus-1:9090\'
        - \'source-prometheus-2:9090\'
        - \'source-prometheus-3:9090\'

三、迁移指南

Prometheus 2.0版本包含了许多向后不兼容的更改。本文档提供了从Prometheus 1.8迁移到Prometheus 2.0的指导。

参数

选项

Prometheus命令行选项的格式已经改变。所有的选项现在都使用双破折号，而不是单破折号。常见的选项（–config.file，–web.listen-address 和 –web.external-url）仍然相同，但除此之外，几乎所有与存储相关的选项都被删除了。
一些值得注意的选项已被删除：

-alertmanager.url：在Prometheus 2.0中，用于配置静态Alertmanager URL的命令行选项已经被移除。现在必须通过服务发现来发现Alertmanager，请参阅Alertmanager服务发现。
-log.format：在Prometheus2.0日志只能定向至标准错误输出。
-query.staleness-delta：已经被重命名为 –query.lookback-delta；Prometheus2.0引入了一种新的机制来处理陈旧，参见陈旧。
-storage.local.*：Prometheus2.0引入了一个新的存储引擎，所有与旧引擎相关的选项都被移除。有关新引擎的信息，请参阅存储。
-storage.remote.*：Prometheus2.0已经删除了已经废弃的远程存储选项，如果提供这些选项，将无法启动。要写入到InfluxDB、Graphite或OpenTSDB，请使用相关的存储适配器。

Alertmanager服务发现

在Prometheus 1.4中引入了Alertmanager服务发现，允许Prometheus使用与抓取目标相同的机制动态发现Alertmanager副本。在Prometheus 2.0中，已经删除了用于静态Alertmanager配置的命令行选项，因此如下命令行选项：

./prometheus -alertmanager.url=http://alertmanager:9093/

在Prometheus中将被以下 prometheus.yml配置文件内容所取代：

alerting:
  alertmanagers:
  - static_configs:
    - targets:
      - alertmanager:9093

你还可以在Alertmanager配置中使用所有常见的Prometheus服务发现集成和重新标记。如下代码指示Prometheus搜索在default 命名空间中，具有标签 name: alertmanager ，端口非空的Kubernetes pod。

alerting:
  alertmanagers:
  - kubernetes_sd_configs:
      - role: pod
    tls_config:
      ca_file: /var/run/secrets/kubernetes.io/serviceaccount/ca.crt
    bearer_token_file: /var/run/secrets/kubernetes.io/serviceaccount/token
    relabel_configs:
    - source_labels: [__meta_kubernetes_pod_label_name]
      regex: alertmanager
      action: keep
    - source_labels: [__meta_kubernetes_namespace]
      regex: default
      action: keep
    - source_labels: [__meta_kubernetes_pod_container_port_number]
      regex:
      action: drop

记录规则和告警

配置告警和记录规则的格式已更改为YAML。旧格式的记录规则和告警示例下如：

job:request_duration_seconds:histogram_quantile99 =

histogram_quantile(0.99, sum(rate(request_duration_seconds_bucket[1m])) by (le, job))

ALERT FrontendRequestLatency

IF job:request_duration_seconds:histogram_quantile99{job=\”frontend\”} > 0.1

FOR 5m

ANNOTATIONS {

summary = \”High frontend request latency\”,

}

新格式如下：

groups:
- name: example.rules
  rules:
  - record: job:request_duration_seconds:histogram_quantile99
    expr: histogram_quantile(0.99, sum(rate(request_duration_seconds_bucket[1m]))
      BY (le, job))
  - alert: FrontendRequestLatency
    expr: job:request_duration_seconds:histogram_quantile99{job=\"frontend\"} > 0.1
    for: 5m
    annotations:
      summary: High frontend request latency

为了帮助进行更改，promtool工具有一个自动转换规则的模式。给定一个.rules文件，它将以新格式输出一个.rules.yml文件。例如：

$ promtool update rules example.rules

请注意，你需要从2.0开始使用promtool，而不是1.8。

存储

Prometheus 2.0中的数据格式已经完全改变，不再向后兼容1.8。为了保留对你的历史监控数据的访问，我们建议你运行一个最低1.8.1版本（与Prometheus 2.0实例并行运行）的非抓取Prometheus实例，并让新服务器通过远程读取协议从旧服务器读取现有数据。
你的Prometheus v1.8实例应该使用以下选项和配置文件来启动，配置文件只包含external_labels设置（如果有的话）：

$ ./prometheus-1.8.1.linux-amd64/prometheus -web.listen-address \":9094\" -config.file old.yml

Prometheus 2.0可以（在同一台机器上）使用以下选项启动：

$ ./prometheus-2.0.0.linux-amd64/prometheus --config.file prometheus.yml

其中prometheus.yml 除了包含现有的完整配置，还有：

remote_read:
  - url: \"http://localhost:9094/api/v1/read\"

PromQL

以下特性已从PromQL中删除：

drop_common_labels 函数，应该使用without聚合修饰符。
keep_common 聚合修饰符，应该使用by修饰词。
count_scalar 函数，在操作中使用 absent()或正确的标签传播可以更好地处理使用场景。

更多细节见#3060号问题。

杂项

Prometheus非root用户

PrometheusDocker镜像现在以非root用户的身份运行Prometheus。如果希望Prometheus UI/API监听较低的端口号（比如端口80），就需要覆盖它。对于Kubernetes，你将使用以下YAML：

apiVersion: v1
kind: Pod
metadata:
  name: security-context-demo-2
spec:
  securityContext:
    runAsUser: 0
...

有关详细信息，请参见为Pod或容器配置安全上下文。
如果你正在使用Docker，那么将使用以下代码片段：

docker run -u root -p 80:80 prom/prometheus:v2.0.0-rc.2  --web.listen-address :80

Prometheus生命周期

如果你使用Prometheus /-/reload HTTP 端点来在Prometheus配置发生变化时自动重新加载配置，那么出于安全考虑，Prometheus 2.0将默认禁用这些端点。要启用它们，请设置–web.enable-lifecycle 选项。