Prometheus 2.0移行ガイド

当社の安定性に関する約束に沿って、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 Prometheus 2.0では、ログは標準エラーにのみストリーミングできます。

  • -query.staleness-delta--query.lookback-deltaに名前が変更されました。 Prometheus 2.0では、stalenessを処理するための新しいメカニズムが導入されています。stalenessを参照してください。

  • -storage.local.* Prometheus 2.0では、新しいストレージエンジンが導入されています。そのため、古いエンジンに関連するすべてのフラグが削除されました。新しいエンジンの詳細については、ストレージを参照してください。

  • -storage.remote.* Prometheus 2.0では、非推奨のリモートストレージフラグが削除され、指定された場合、起動に失敗します。 InfluxDB、Graphite、またはOpenTSDBに書き込むには、関連するストレージアダプターを使用してください。

Alertmanagerサービスディスカバリ

AlertmanagerサービスディスカバリはPrometheus 1.4で導入され、Prometheusはスクレイプターゲットと同じメカニズムを使用してAlertmanagerレプリカを動的に検出できるようになりました。 Prometheus 2.0では、静的Alertmanager設定のコマンドラインフラグが削除されたため、次のコマンドラインフラグ

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

は、prometheus.yml設定ファイルで次のように置き換えられます。

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

Alertmanager設定で、通常のPrometheusサービスディスカバリ統合と再ラベル付けをすべて使用することもできます。 このスニペットは、Prometheusに、default名前空間で、ラベルname: alertmanagerと空でないポートを持つKubernetesポッドを検索するように指示します。

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 by (le, job) (rate(request_duration_seconds_bucket[1m])))

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 by (le, job) (rate(request_duration_seconds_bucket[1m])))
  - 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

以降のバージョンには上記サブコマンドが含まれていないため、Prometheus 2.5からpromtoolを使用する必要があります.

ストレージ

Prometheus 2.0のデータ形式は完全に変更されており、1.8以前のバージョンとは後方互換性がありません。 過去の監視データへのアクセスを維持するには、Prometheus 2.0インスタンスと並行して少なくともバージョン1.8.1を実行している非スクレイピングPrometheusインスタンスを実行し、新しいサーバーがリモート読み取りプロトコルを介して古いサーバーから既存のデータを読み取ることをお勧めします。

Prometheus 1.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()または操作におけるラベルの正しい伝播によってより適切に処理されます。

詳細については、issue #3060を参照してください。

その他

Prometheus非rootユーザー

Prometheus Dockerイメージは、Prometheusを非rootユーザーとして実行するように構築されるようになりました。 Prometheus UI / APIに低いポート番号(たとえば、ポート80)でリッスンさせる場合は、オーバーライドする必要があります。 Kubernetesの場合、次のYAMLを使用します。

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

詳細については、ポッドまたはコンテナのセキュリティコンテキストを設定するを参照してください。

Dockerを使用している場合は、次のスニペットを使用します。

docker run -p 9090:9090 prom/prometheus:latest

Prometheusライフサイクル

Prometheus /-/reload HTTPエンドポイントを使用して、Prometheus設定が変更されたときに自動的にリロードする場合、これらのエンドポイントはPrometheus 2.0ではセキュリティ上の理由からデフォルトで無効になっています。 有効にするには、--web.enable-lifecycleフラグを設定します。

このドキュメントはオープンソースです。 問題の報告またはプルリクエストを送信して、改善にご協力ください。