このページは Cloud Translation API によって翻訳されました。

セルフデプロイコレクションを使ってみる

このドキュメントでは、セルフデプロイコレクションを使用して Google Cloud Managed Service for Prometheus を設定する方法について説明します。サンプルアプリケーションは Kubernetes クラスタにデプロイされ、収集した指標を Monarch に保存する Prometheus サーバーによってモニタリングされます。

このドキュメントでは、次の方法について説明します。

環境とコマンドラインツールを設定する。
Workload Identity Federation for GKE 対応クラスタのサービスアカウントを構成する。
Kubernetes でドロップインの Prometheus バイナリを実行する。
Managed Service for Prometheus に取り込む指標を制御します。
Managed Service for Prometheus を prometheus-operator の設定と統合します。
Prometheus バイナリを手動でコンパイルして実行する。

セルフデプロイデータ収集では、Prometheus のインストールを通常どおり管理します。唯一の違いは、Managed Service for Prometheus のドロップイン代替バイナリである gke.gcr.io/prometheus-engine/prometheus:v2.45.3-gmp.9-gke.0 を、アップストリームの Prometheus バイナリの代わりに実行することです。

このドロップインバイナリは、--export.* フラグを使用した追加の構成オプションを提供します。詳細については、--help オプションの出力をご覧ください。このドキュメントでは、最も重要なオプションについて説明します。

Prometheus のマネージドサービスでは、連携サーバーや、リモート書き込みレシーバーとして使用するサーバーからの指標のエクスポートをサポートしていません。フィルタとローカル集計を使用すると、Monarch に送信する前にデータを集約して取り込み量を減らすなど、すべての連携サーバー機能をレプリケートできます。

Managed Service for Prometheus にデータをストリーミングすると、追加のリソースが消費されます。コレクタを自分でデプロイする場合は、CPU とメモリの上限を 5 倍に増やし、実際の使用量に基づいて調整することをおすすめします。

マネージドデプロイとセルフデプロイによるデータ収集の詳細については、Managed Service for Prometheus を使用したデータ収集をご覧ください。

始める前に

このセクションでは、このドキュメントで説明するタスクに必要な構成について説明します。

プロジェクトとツールを設定する

Google Cloud Managed Service for Prometheus を使用するには、次のリソースが必要です。

Cloud Monitoring API が有効になっている Google Cloud プロジェクト。
- Google Cloud プロジェクトが存在しない場合は、以下の操作を行います。
  1. Google Cloud コンソールで [新しいプロジェクト] に移動します。
    
    新しいプロジェクトを作成
  2. [プロジェクト名] フィールドにプロジェクトの名前を入力して、[作成] をクリックします。
  3. [お支払い] に移動します。
    
    [お支払い] に移動
  4. ページ上部で、作成したプロジェクトをまだ選択していない場合は選択します。
  5. 既存のお支払いプロファイルを選択するか、新しいお支払いプロファイルを作成するように求められます。
  新しいプロジェクトでは、Monitoring API がデフォルトで有効になっています。
- Google Cloud プロジェクトがすでに存在する場合は、Monitoring API が有効になっていることを確認します。
  1. [API とサービス] に移動します。
    
    [API とサービス] に移動
  2. プロジェクトを選択します。
  3. [API とサービスの有効化] をクリックします。
  4. 「Monitoring」を検索します。
  5. 検索結果で、[Cloud Monitoring API] をクリックします。
  6. [API が有効です] と表示されていない場合は、[有効にする] をクリックします。
Kubernetes クラスタ。Kubernetes クラスタがない場合は、GKE のクイックスタートの手順を行います。

また、次のコマンドラインツールも必要です。

gcloud
kubectl

gcloud ツールと kubectl ツールは Google Cloud CLI に含まれています。インストールの詳細については、Google Cloud CLI コンポーネントの管理をご覧ください。インストールされている gcloud CLI コンポーネントを確認するには、次のコマンドを実行します。

gcloud components list

環境を構成する

プロジェクト ID またはクラスタ名を繰り返し入力しないようにするには、次の構成を行います。

コマンドラインツールを次のように構成します。
- Google Cloud プロジェクトの ID を参照するように gcloud CLI を構成します。
```
gcloud config set project PROJECT_ID
```
- クラスタを使用するように kubectl CLI を構成します。
```
kubectl config set-cluster CLUSTER_NAME
```
これらのツールの詳細については、以下をご覧ください。
- gcloud CLI の概要
- kubectl コマンド

名前空間を設定する

サンプルアプリケーションの一部として作成するリソースに NAMESPACE_NAME Kubernetes Namespace を作成します。

kubectl create ns NAMESPACE_NAME

サービスアカウントの認証情報を確認する

Kubernetes クラスタで Workload Identity Federation for GKE が有効になっている場合は、このセクションをスキップできます。

GKE で実行すると、Managed Service for Prometheus は Compute Engine のデフォルトのサービスアカウントに基づいて環境から認証情報を自動的に取得します。デフォルトのサービスアカウントには、必要な権限である monitoring.metricWriter と monitoring.viewer がデフォルトで付与されています。Workload Identity Federation for GKE を使用しておらず、以前にいずれかのロールをデフォルトのノードサービスアカウントから削除している場合は、続行する前に、不足している権限を再度追加する必要があります。

GKE で実行していない場合は、認証情報を明示的に提供するをご覧ください。

Workload Identity Federation for GKE 用のサービスアカウントを構成する

Kubernetes クラスタで Workload Identity Federation for GKE が有効になっていない場合は、このセクションをスキップできます。

Managed Service for Prometheus は、Cloud Monitoring API を使用して指標データをキャプチャします。クラスタで Workload Identity Federation for GKE を使用している場合は、Kubernetes サービスアカウントに Monitoring API の権限を付与する必要があります。このセクションでは、次のことを説明します。

専用の Google Cloud サービスアカウント gmp-test-sa を作成する。
テスト名前空間 NAMESPACE_NAME のデフォルトの Kubernetes サービスアカウントに Google Cloud サービスアカウントをバインドする。
Google Cloud サービスアカウントに必要な権限を付与する。

サービスアカウントを作成してバインドする

この手順は、Managed Service for Prometheus のドキュメントの複数の場所で説明されています。前のタスクですでに行っている場合は、この手順を繰り返す必要はありません。サービスアカウントを承認するに進んでください。

次のコマンドシーケンスでは、gmp-test-sa サービスアカウントを作成し、NAMESPACE_NAME 名前空間でデフォルトの Kubernetes サービスアカウントにバインドします。

gcloud config set project PROJECT_ID \
&&
gcloud iam service-accounts create gmp-test-sa \
&&
gcloud iam service-accounts add-iam-policy-binding \
  --role roles/iam.workloadIdentityUser \
  --member "serviceAccount:PROJECT_ID.svc.id.goog[NAMESPACE_NAME/default]" \
  gmp-test-sa@PROJECT_ID.iam.gserviceaccount.com \
&&
kubectl annotate serviceaccount \
  --namespace NAMESPACE_NAME \
  default \
  iam.gke.io/gcp-service-account=gmp-test-sa@PROJECT_ID.iam.gserviceaccount.com

別の GKE 名前空間またはサービスアカウントを使用している場合は、コマンドを適宜調整してください。

サービスアカウントを承認する

ロールには関連する権限がまとめられています。このロールをプリンシパル（この例では Google Cloud サービスアカウント）に付与します。Monitoring のロールの詳細については、アクセス制御をご覧ください。

次のコマンドは、Google Cloud サービスアカウント gmp-test-sa に、指標データの書き込みに必要な Monitoring API のロールを付与します。

前のタスクで Google Cloud サービスアカウントに特定のロールを付与している場合は、再度付与する必要はありません。

gcloud projects add-iam-policy-binding PROJECT_ID\
  --member=serviceAccount:gmp-test-sa@PROJECT_ID.iam.gserviceaccount.com \
  --role=roles/monitoring.metricWriter

Workload Identity Federation for GKE の構成をデバッグする

Workload Identity Federation for GKE の動作に問題がある場合は、Workload Identity Federation for GKE の設定の確認と Workload Identity Federation for GKE のトラブルシューティングガイドをご覧ください。

Workload Identity Federation for GKE の構成で最も一般的なエラーの原因は入力ミスや、部分的なコピー / 貼り付けです。これらの手順のコードサンプルに埋め込まれた編集可能な変数と、クリック可能なコピー / 貼り付けアイコンを使用することを強くおすすめします。

本番環境での Workload Identity Federation for GKE

このドキュメントの例では、Google Cloud サービスアカウントをデフォルトの Kubernetes サービスアカウントにバインドし、Monitoring API を使用するために必要なすべての権限を Google Cloud サービスアカウントに付与しています。

本番環境では、各コンポーネントのサービスアカウントを最小権限で使用し、よりきめ細かいアプローチを使用する必要があります。Workload Identity 管理のサービスアカウントを構成する方法の詳細については、Workload Identity Federation for GKE の使用をご覧ください。

セルフデプロイコレクションを設定する

このセクションでは、セルフデプロイコレクションを使用するサンプルアプリケーションを設定して実行する方法について説明します。

サンプルアプリケーションをデプロイする

このサンプルアプリケーションでは、metrics ポートに example_requests_total カウンタ指標と example_random_numbers ヒストグラム指標が出力されます。アプリケーションのマニフェストでは 3 つのレプリカを定義しています。

サンプルアプリケーションをデプロイするには、次のコマンドを実行します。

kubectl -n NAMESPACE_NAME apply -f https://raw.githubusercontent.com/GoogleCloudPlatform/prometheus-engine/v0.13.0/examples/example-app.yaml

置換 Prometheus バイナリを実行する

サンプルアプリケーションから出力された指標データを取り込むには、Google のフォークされたバージョンの Prometheus サーバーをデプロイします。これは、ワークロードの指標と独自の指標エンドポイントを取得するように構成されています。

次のコマンドを実行して、フォークされたサーバーをデプロイします。
```
kubectl -n NAMESPACE_NAME apply -f https://raw.githubusercontent.com/GoogleCloudPlatform/prometheus-engine/v0.13.0/examples/prometheus.yaml
```
デプロイされた Prometheus サーバーは、アップストリームの Prometheus バイナリの thin fork です。これは標準的な Prometheus サーバーと同様に動作しますが、Managed Service for Prometheus にデータを取り込むこともできます。

上記のマニフェストは、データをグローバルデータストアである Monarch に送信する基本的な動作例を示しています。データのローカルコピーは永続的に保存されません。事前定義の構成の機能と拡張方法については、オープンソースの Prometheus 構成のドキュメントをご覧ください。

ビルド済みイメージは Linux ノードでのみ動作します。Windows ノードで実行されているターゲットを取得するには、サーバーを Linux ノードにデプロイして、Windows ノードでエンドポイントを取得するように構成するか、Windows 自体のバイナリをビルドします。

Prometheus サーバーの Pod とサンプルアプリケーションの Pod が正常にデプロイされたことを確認します。

kubectl -n NAMESPACE_NAME get pod

デプロイに成功すると、次のような出力が表示されます。

NAME                            READY   STATUS    RESTARTS   AGE
prom-example-84c6f547f5-fglbr   1/1     Running   0          5m
prom-example-84c6f547f5-jnjp4   1/1     Running   0          5m
prom-example-84c6f547f5-sqdww   1/1     Running   0          5m
prometheus-test-0               2/2     Running   1          3m

GKE で実行している場合は、次の操作を行います。

サンプルアプリケーションによって取り込まれた指標をクエリするには、Cloud Monitoring を使用したクエリまたは Grafana を使用したクエリをご覧ください。
セルフデプロイコレクションで prometheus-operator と kube-prometheus を使用する方法と、マネージドサービスのバイナリをビルドして実行する方法については、セルフデプロイコレクションに関する追加トピックをご覧ください。

GKE の外部で実行する場合は、次のセクションで説明するように、サービスアカウントを作成して指標データの書き込みを承認する必要があります。

認証情報を明示的に提供する

GKE で実行する場合、情報を収集する Prometheus サーバーは、ノードのサービスアカウントまたは Workload Identity Federation for GKE の設定に基づいて、環境から認証情報を自動的に取得します。GKE 以外の Kubernetes クラスタでは、フラグまたは GOOGLE_APPLICATION_CREDENTIALS 環境変数を使用して、認証情報を収集する Prometheus サーバーに明示的に提供する必要があります。

コンテキストをターゲットプロジェクトに設定します。
```
gcloud config set project PROJECT_ID
```
サービスアカウントの作成:
```
gcloud iam service-accounts create gmp-test-sa
```
この手順では、Workload Identity Federation for GKE の手順ですでに作成したサービスアカウントを作成します。

サービスアカウントに必要な権限を付与します。

gcloud projects add-iam-policy-binding PROJECT_ID\
  --member=serviceAccount:gmp-test-sa@PROJECT_ID.iam.gserviceaccount.com \
  --role=roles/monitoring.metricWriter

サービスアカウントのキーを作成してダウンロードます。

gcloud iam service-accounts keys create gmp-test-sa-key.json \
  --iam-account=gmp-test-sa@PROJECT_ID.iam.gserviceaccount.com

キーファイルを Secret として GKE 以外のクラスタに追加します。

kubectl -n NAMESPACE_NAME create secret generic gmp-test-sa \
  --from-file=key.json=gmp-test-sa-key.json

Prometheus StatefulSet リソースを開いて編集します。
```
kubectl -n NAMESPACE_NAME edit statefulset prometheus-test
```
1. 太字で示されているテキストをリソースに追加します。
```
apiVersion: apps/v1
kind: StatefulSet
metadata:
  namespace: NAMESPACE_NAME
  name: example
spec:
  template
    containers:
    - name: prometheus
      args:
      - --export.credentials-file=/gmp/key.json
...
      volumeMounts:
      - name: gmp-sa
        mountPath: /gmp
        readOnly: true
...
    volumes:
    - name: gmp-sa
      secret:
        secretName: gmp-test-sa
...
```
2. ファイルを保存して、エディタを閉じます。変更が適用されると、Pod が再作成され、指定されたサービスアカウントで指標のバックエンドに対する認証が開始します。
また、この例で設定されたフラグを使用する代わりに、GOOGLE_APPLICATION_CREDENTIALS 環境変数を使用してキーファイルパスを設定することもできます。
セルフデプロイコレクションに関する追加トピック

このセクションでは、次の操作を行う方法について説明します。
- マネージドサービスにエクスポートするデータをフィルタします。
- 既存のデプロイ構成を変換します。
- 高可用性モードで Prometheus バイナリを実行します。
- 代替 Prometheus バイナリをビルドして実行します。
- Google Cloud の外部で Managed Service for Prometheus を実行します。
エクスポートした指標をフィルタする

大量のデータを収集する場合は、費用を抑えるために、一部の時系列が Managed Service for Prometheus に送信されないようにする必要があります。

Prometheus スクレイピング構成で通常の指標の再ラベル付け構成を使用できます。再ラベル付け構成により、取り込み時にラベルの一致に基づいて指標をドロップできます。

Managed Service for Prometheus にエクスポートせずに、ローカルでのデータの取り込みが必要になることもあります。エクスポートされた指標をフィルタリングするには、--export.match フラグを使用します。

このフラグには 1 つ以上の PromQL シリーズセレクタを指定します。このフラグは複数回使用できます。時系列が少なくとも 1 つのフラグのセレクタをすべて満たしている場合、その時系列は Managed Service for Prometheus にエクスポートされます。つまり、適格性を判断する際、1 つのフラグ内の条件は AND で結合され、別のフラグ内の条件は OR で結合されます。次の例では、2 つのフラグインスタンスを使用します。
```
./prometheus \
  --export.match='{job="prometheus"}' \
  --export.match='{__name__=~"job:.+"}' \
  ...
```
この変更により、「prometheus」ジョブの指標と、ジョブレベルに集約された記録ルールによって生成された指標（命名のベストプラクティスに従っている場合）のみがエクスポートされます。他のすべての時系列のサンプルは除外されます。デフォルトでは、セレクタは指定されず、すべての時系列がエクスポートされます。

--export.match フラグのセマンティクスは、Prometheus フェデレーションの match[] パラメータと同じです。そのため、フェデレーションサーバーからセレクタを、フェデレーション Prometheus サーバーでスクレイピングした Prometheus サーバーのフラグとして直接使用することで、フェデレーション設定を Managed Service for Prometheus に移行できます。連携サーバーからマネージドサービスへの指標のエクスポートはサポートされていません。

フィルタに histogram タイプの指標を含めるには、_count、_sum、_bucket 指標を指定する必要があります。また、セレクタ {__name__=~"histogram_metric_.+"} のように、ワイルドカードマッチャーを使用してこれの操作を行うこともできます。

prometheus-operator ライブラリを使用している場合は、コンテナの EXTRA_ARGS 環境変数を使用して --export.match フラグを設定します。詳細については、prometheus-operator と一緒に使用するをご覧ください。

フィルタフラグをローカルで実行される記録ルールと組み合わせると、Monarch に送信する前にデータを「ロールアップ」して、カーディナリティと費用を削減できます。詳しくは、費用管理とアトリビューションをご覧ください。

Cloud Monitoring の [指標の管理] ページでは、オブザーバビリティに影響を与えることなく、課金対象の指標に費やす金額を制御するために役立つ情報が提供されます。[指標の管理] ページには、次の情報が表示されます。
- 指標ドメイン全体と個々の指標での、バイトベースとサンプルベースの両方の課金に対する取り込み量。
- 指標のラベルとカーディナリティに関するデータ。
- 各指標の読み取り回数。
- アラートポリシーとカスタムダッシュボードでの指標の使用。
- 指標書き込みエラーの割合。
また、指標の管理を使用して不要な指標を除外し、取り込みのコストを削減することもできます。[指標の管理] ページの詳細については、指標の使用状況の表示と管理をご覧ください。

prometheus-operator と一緒に使用する

Managed Service for Prometheus の Prometheus バイナリは、prometheus-operator によって管理される既存の GKE Prometheus デプロイでも使用できます。

マネージドサービスのバイナリを使用するには、Prometheus リソースのイメージ仕様を置き換えます。
```
  apiVersion: monitoring.coreos.com/v1
  kind: Prometheus
  metadata:
    name: NAMESPACE_NAME
    namespace: gmp-system
  spec:
    image: gke.gcr.io/prometheus-engine/prometheus:v2.45.3-gmp.9-gke.0
    ...
    replicas: 1
    serviceAccountName: default
    version: v2.35.0
    ...
```
Workload Identity Federation for GKE クラスタ内にいて、リソースの名前空間またはサービスアカウントが異なる場合は、追加の名前空間と Kubernetes サービスアカウントのペアに対して Workload Identity Federation for GKE の手順を繰り返します。

GKE 以外の Kubernetes クラスタで実行する場合は、認証情報を手動で指定する必要があります。認証情報を提供するには、次の手順を行います。
1. 認証情報を明示的に指定するの説明に従って、適切なサービスアカウントキーファイルを Secret として追加します。
2. Prometheus リソースを変更して、太字で示されているテキストを追加します。
```
  apiVersion: monitoring.coreos.com/v1
  kind: Prometheus
  metadata:
    namespace: gmp-test
    name: example
  spec:
    ...
    secrets:
    - gmp-test-sa
    containers:
    - name: prometheus
      env:
      - name: GOOGLE_APPLICATION_CREDENTIALS
        value: /gmp/key.json
      volumeMounts:
      - name: secret-gmp-test-sa
        mountPath: /gmp
        readOnly: true
```
コンテナの EXTRA_ARGS 環境変数を設定して、指標フィルタリングフラグなどのフラグを追加できます。コンテナ仕様の args セクションは Prometheus Operator によって管理されるため、これは環境変数を介して行われます。

kube-prometheus と一緒に使用する

広く使用されている kube-prometheus ライブラリを使用して作成されたデプロイメントを、Managed Service for Prometheus を使用するように構成できます。

kube-prometheus には、デフォルトの名前空間とサービスアカウントに対して内部的に緊密な依存関係があるため、Prometheus 用のマネージドサービスにデータを送信するのに必要な最小限のフィールドのみ変更することをおすすめします。

manifests/prometheus-prometheus.yaml 内で、イメージ仕様を置き換え、replicas を 1 に減らして高可用性収集をオフにします。
```
    apiVersion: monitoring.coreos.com/v1
    kind: Prometheus
    ...
    spec:
      image: gke.gcr.io/prometheus-engine/prometheus:v2.45.3-gmp.9-gke.0
      ...
      replicas: 1
      version: v2.35.0
      ...
  
```
GKE 上で実行していて、ノード上のデフォルトのサービスアカウントを変更していない場合は、変更したマニフェストを適用すると、Prometheus 用のマネージドサービスへのデータ送信がすぐに開始されます。それ以外の場合は、サービスアカウントを構成して適用する必要がある場合があります。GKE 上で実行していて、Workload Identity を使用する場合は、monitoring 名前空間内で prometheus-k8s サービスアカウントを作成して承認する必要がある場合があります。GKE 以外の Kubernetes クラスタで実行する場合は、prometheus-operator セクションの手順に従ってください。

kube-prometheus はデフォルトで多くの指標を収集します。それらのほとんどは、GKE などのマネージド Kubernetes 環境では不要な場合が数多くあります。取り込みコストを節約するために、kube-prometheus をカスタマイズして、関心のある指標だけを収集するようにしたり、エクスポートされた指標を積極的にフィルタリングしたりできます。

その他の提案については、費用管理とアトリビューションをご覧ください。

高可用性デプロイメント

代替 Prometheus バイナリには、リーダー選出を使用した高可用性コレクションのサポートが組み込まれています。高可用性モードのレプリケートされた Prometheus サーバーは、通常どおり指標の収集とルールの評価を行いますが、Google Cloud Managed Service for Prometheus にデータを送信するのはいずれか 1 つだけです。

同じ Prometheus サーバーのレプリカには、同じ external_labels を含め、常に同じ構成にする必要があります。この要件は、レプリカを明示的に区別するために __replica__ などの特別な外部ラベルに依存する他のシステムとは異なります。

Kubernetes API サーバーは、サポートされているリーダー選出バックエンドであり、次のフラグを設定することで有効にできます。
```
./prometheus
  ...
  --export.ha.backend=kube \
  --export.ha.kube.namespace=LEASE_NAMESPACE \
  --export.ha.kube.name=LEASE_NAME
```
LEASE_NAMESPACE と LEASE_NAME の値は、リーダー選出が行われるリースリソースを識別します。同じリソースを参照する Prometheus サーバーはすべて同じレプリカセットに属します。Prometheus デプロイメントの Kubernetes サービスアカウントには、対応するリースリソースの読み取りと書き込みを行うための権限が必要です。Kubernetes クラスタの外部で Prometheus サーバーを実行する場合は、--export.ha.kube.config フラグを使用して明示的な構成を指定します。

この設定を行った後、replicas に 2 以上の値を設定できるようになります。

予約済みラベル

Managed Service for Prometheus は、6 つの予約済みラベルを使用して、Monarch のリソースを一意に識別します。
- project_id: 指標に関連付けられた Google Cloud プロジェクトの ID。必須。
- location: データが保存される物理的な場所（Google Cloud リージョン）。通常、この値は GKE クラスタのリージョンです。AWS またはオンプレミスデプロイメントからデータが収集される場合、値は最も近い Google Cloud のリージョンになります。必須。
- cluster: 指標に関連付けられた Kubernetes クラスタの名前。Kubernetes で実行されていない場合は、インスタンスグループなどの任意の階層レベルとして使用できます。オプションですが、使用を強くおすすめします。
- namespace: 指標に関連付けられた Kubernetes Namespace の名前。 Kubernetes で実行されていない場合は、インスタンスのサブグループなど、任意の階層レベルとして使用できます。オプションですが、使用を強くおすすめします。
- job: Prometheus ターゲットのジョブラベル（既知の場合）。ルール評価の結果で空の場合もあります。必須。通常は Prometheus によって自動的に追加されます。
- instance: Prometheus ターゲットのインスタンスラベル（既知の場合）。ルール評価の結果で空の場合もあります。必須。通常は Prometheus によって自動的に追加されます。手動で設定またはラベルを変更する場合は、localhost などのハードコードされた値を使用しないでください。これにより、時系列の競合が発生します。
Google Cloud で実行する場合、project_id、location、cluster の各ラベルがすべての指標に自動的に追加されます。

Google Cloud で実行する場合は推奨されませんが、Prometheus 構成の global.external_labels セクションを使用して、project_id、location、cluster、namespace の各ラベルをオーバーライドできます。詳細については、Google Cloud の外部でセルフデプロイコレクションを実行するをご覧ください。

予約済みラベルを指標ラベルとして使用する場合、セルフデプロイコレクションは、予約済みラベルの値として指標ラベルを使用します。これにより柔軟性が向上しますが、たとえば、ラベル location を使用して Google Cloud リージョン以外のものを参照すると、エラーが発生する可能性があります。

バイナリデプロイ

コンテナ化されていない環境で実行する場合は、置換 Prometheus バイナリを直接ビルドできます。

ソースのビルド

Prometheus をコンパイルする既存のプロセスがある場合は、GitHub リポジトリをそのプロセスに透過的に置き換えることができます。Managed Service for Prometheus には独自のバージョンタグ拡張機能があり、リリースとアップストリームリリースを区別できます。

プレーンバイナリをビルドするには、Go ツールチェーンと最新バージョンの NPM / Yarn をマシンにインストールする必要があります。詳細については、アップストリームビルドの手順をご覧ください。
1. リポジトリのクローンを作成します。
```
git clone https://github.com/GoogleCloudPlatform/prometheus &&
cd prometheus
```
2. 目的のバージョンタグをチェックアウトします。
```
git checkout v2.45.3-gmp.9
```
3. Managed Service for Prometheus tarball を作成するには、次のコマンドを実行します。
```
make build && make tarball
```
作成された tarball とバイナリには、ディレクトリ構造と機能の点で、アップストリームバリアントと完全な互換性があります。

指標とラベルの作成と更新に関する制限

Prometheus 向けのマネージドサービスでは、新しい指標の作成と既存の指標への新しい指標ラベルの追加に、1 分あたりのレート制限が適用されます。通常、このレート制限は、Prometheus 向けのマネージドサービスと初めて統合するときにのみ発生します（たとえば、既存の成熟した Prometheus デプロイをセルフデプロイ済みのコレクションを使用する方式に移行する場合）。これは、データポイントを取り込む場合のレート制限ではありません。このレート制限は、未知の指標を作成する場合、または既存の指標に新しいラベルを追加する場合にのみ適用されます。

この割り当ては固定されていますが、新しい指標と指標ラベルを作成するときのレートが 1 分あたりの制限以下になると、問題は自動的に解決されます。

詳細については、トラブルシューティングをご覧ください。

Google Cloud の外部でセルフデプロイコレクションを実行する

Compute Engine 環境、GKE 環境、または適切な権限を持つアカウントで gcloud login を実行したマシンでは、追加構成なしでセルフデプロイコレクションを実行できます。Google Cloud の外部では、認証情報を明示的に指定するか、指標を格納する project_id と指標を保存する location（Google Cloud リージョン）を明示的に指定する必要があります。また、cluster ラベルと namespace ラベルを設定する必要があります。これは Kubernetes 以外の環境で実行する場合でも同様です。

サービスアカウントキーを指定するには、認証情報を明示的に指定するで説明しているように、--export.credentials-file フラグまたは GOOGLE_APPLICATION_CREDENTIALS 環境変数を使用します。

読み取り用に計画されたテナンシーモデルに基づいて project_id を選択することをおすすめします。後で指標スコープを使用して読み取りを整理する方法に基づいて、指標を保存するプロジェクトを選択します。問題がなければ、すべてを 1 つのプロジェクトにまとめても構いません。

location については、デプロイに最も近い Google Cloud リージョンを選択することをおすすめします。選択した Google Cloud リージョンがデプロイから遠くなるほど、書き込みレイテンシが大きくなり、より多くのネットワーク問題が発生する可能性があります。複数のクラウドにまたがるリージョンのリストをご覧ください。問題がなければ、すべてを 1 つの Google Cloud リージョンにまとめることができます。 global をロケーションとして使用することはできません。

Kubernetes 環境で実行する場合は、cluster と namespace の値をローカルクラスタと名前空間に設定します。Kubernetes の外部で実行する場合は、階層的に意味のある値に設定します。たとえば、AWS 上で実行される VM ベースの環境では、cluster の値を __aws__ に、namespace の値をインスタンス ID に設定します。ローカルメタデータサーバーを呼び出すラベル変更ルールを使用して、インスタンス ID を動的に入力できます。

最小の例では、次のコマンドを使用して、ローカルのセルフモニタリング Prometheus バイナリを実行できます。
```
./prometheus \
  --config.file=documentation/examples/prometheus.yaml \
  --export.label.project-id=PROJECT_ID \
  --export.label.location=REGION \
  --export.label.cluster=CLUSTER_NAME \
```
この例では、REGION 変数が us-central1 などの値に設定されていることを前提としています。

ただし、Prometheus 構成の global.external_labels セクションでマネージドサービスの export ターゲットラベルを設定することをおすすめします。たとえば、Kubernetes 環境では次の構成を使用できます。
```
global:
  external_labels:
    project_id: PROJECT_ID
    location: REGION
    cluster: CLUSTER_NAME
    namespace: local-testing

scrape_configs:
  ...
```
Google Cloud の外部で Managed Service for Prometheus を実行すると、データ転送料金が発生します。Google Cloud へのデータ転送には料金がかかります。また、別のクラウドからのデータ移転にも料金が発生する場合があります。--export.compression=gzip フラグを使用して圧縮を有効にすると、このコストを最小限に抑えることができます。

次のステップ
- Cloud Monitoring で PromQL を使用して Prometheus 指標をクエリする。
- Grafana を使用して Prometheus 指標をクエリする。
- Cloud Monitoring で PromQL アラートを使用する。
- マネージドルールの評価を設定する。
- セルフデプロイルールの評価を設定する。
- ローカル集計を構成することで、カーディナリティと費用を削減します。

セルフデプロイ コレクションを使ってみる

始める前に

プロジェクトとツールを設定する

環境を構成する

名前空間を設定する

サービス アカウントの認証情報を確認する

Workload Identity Federation for GKE 用のサービス アカウントを構成する

サービス アカウントを作成してバインドする

サービス アカウントを承認する

Workload Identity Federation for GKE の構成をデバッグする

本番環境での Workload Identity Federation for GKE

セルフデプロイ コレクションを設定する

サンプル アプリケーションをデプロイする

置換 Prometheus バイナリを実行する

認証情報を明示的に提供する

セルフデプロイ コレクションに関する追加トピック

エクスポートした指標をフィルタする

prometheus-operator と一緒に使用する

kube-prometheus と一緒に使用する

高可用性デプロイメント

予約済みラベル

バイナリ デプロイ

ソースのビルド

指標とラベルの作成と更新に関する制限

Google Cloud の外部でセルフデプロイ コレクションを実行する

次のステップ