Managed Service for Prometheus のトラブルシューティング

このドキュメントでは、Managed Service for Prometheus を使用するときに発生する可能性のある問題ついて説明し、問題の診断と解決について情報を提供します。

Managed Service for Prometheus を構成しましたが、Grafana または Prometheus UI に指標データが表示されません。大まかに言えば、原因は次のいずれかである可能性があります。

• クエリ側の問題で、データを読み取ることができない。クエリ側の問題は、多くの場合、データを読み取るサービス アカウントに対する誤った権限または Grafana の構成の誤りが原因で発生します。

• 取り込み側の問題で、データが送信されない。取り込み側の問題は、サービス アカウント、コレクタ、ルール評価の構成の問題が原因で発生する可能性があります。

取り込み側とクエリ側のどちらにあるのかを判断するには、Google Cloud コンソールで Metrics Explorer の [PromQL] タブを使用して、データのクエリを実行します。このページが表示された場合、読み取り権限や Grafana の設定に問題はありません。

このページを表示するには、次のようにします。

1. Google Cloud コンソールのプロジェクト選択ツールを使用して、データが表示されないプロジェクトを選択します。

2. Google Cloud コンソールで、[leaderboardMetrics Explorer] ページに移動します。

   Metrics Explorer に移動

   検索バーを使用してこのページを検索する場合は、小見出しが [Monitoring] である結果を選択します。

3. クエリビルダー ペインのツールバーで、[codeMQL] または [codePROMQL] という名前のボタンを選択します。

4. [言語] で [PromQL] が選択されていることを確認します。言語切り替えボタンは、クエリの書式設定を行うのと同じツールバーにあります。

5. エディタに次のクエリを入力し、[クエリを実行] をクリックします。

   up
   

up 指標をクエリして結果が表示される場合は、クエリ側に問題があります。これらの問題の解決方法については、クエリ側の問題をご覧ください。

up 指標をクエリして結果が表示されない場合は、問題は取り込み側にあります。これらの問題の解決方法については、取り込み側の問題をご覧ください。

ファイアウォールでも、取り込みとクエリに関する問題が発生する場合があります。詳細については、ファイアウォールをご覧ください。

Cloud Monitoring の [指標の管理] ページでは、オブザーバビリティに影響を与えることなく、課金対象の指標に費やす金額を制御するために役立つ情報が提供されます。[指標の管理] ページには、次の情報が表示されます。

• 指標ドメイン全体と個々の指標での、バイトベースとサンプルベースの両方の課金に対する取り込み量。
• 指標のラベルとカーディナリティに関するデータ。
• 各指標の読み取り回数。
• アラート ポリシーとカスタム ダッシュボードでの指標の使用。
• 指標書き込みエラーの割合。

また、指標の管理を使用して不要な指標を除外し、取り込みのコストを削減することもできます。

[指標の管理] ページを表示するには、次の操作を行います。

1. Google Cloud コンソールで、 query_stats[指標の管理] ページに移動します。

   [指標の管理] に移動

   検索バーを使用してこのページを検索する場合は、小見出しが [Monitoring] である結果を選択します。

2. ツールバーで時間枠を選択します。デフォルトでは、[指標の管理] ページには、過去 1 日間に収集された指標に関する情報が表示されます。

[指標の管理] ページの詳細については、指標の使用状況の表示と管理をご覧ください。

クエリ側の問題

クエリ側の問題の原因の多くは、次のいずれかです。

• サービス アカウントの権限または認証情報が正しくない。
• GKE 用 Workload Identity 連携の構成ミス（クラスタでこの機能が有効になっている場合）。詳細については、Workload Identity Federation for GKE 用のサービス アカウントを構成するをご覧ください。

まず、次のようにします。

• 構成をクエリの設定手順に対して注意深く確認してください。

• Workload Identity Federation for GKE を使用している場合は、次のようにしてサービス アカウントに正しい権限があることを確認します。

  1. Google Cloud コンソールの [IAM] ページに移動します。

     [IAM] に移動

     検索バーを使用してこのページを検索する場合は、小見出しが [IAM と管理者] である結果を選択します。

  2. プリンシパルのリストでサービス アカウント名を確認します。サービス アカウントの名前が正しいことを確認します。次に [edit編集] をクリックします。

  3. [ロール] フィールドを選択し、[現在使用中] をクリックして、モニタリング閲覧者のロールを検索します。サービス アカウントにこのロールがない場合は、ここで追加します。

問題がまだ継続している場合は、次の可能性を検討します。

Secret の構成の不備または入力の誤り

次のいずれかが表示された場合は、Secret の欠落または入力の誤りの可能性があります。

• Grafana または Prometheus UI で次のいずれかの「禁止」エラーが表示される場合:

  • 「Warning: Unexpected response status when fetching server time: Forbidden」
  • 「警告: 指標リストの取得エラー: 指標名の取得時の予期しないレスポンス ステータス: 禁止」

• ログに次のようなメッセージが記録されている場合:
  「cannot read credentials file: open /gmp/key.json: no such file or directory」

データソース同期ツールを使用して Grafana の認証と構成を行っている場合は、これらのエラーを解決するために次の手順を試してください。

1. 選択した Grafana API エンドポイント、Grafana データソース UID、Grafana API トークンが正しいことを確認します。CronJob の変数を調べるには、kubectl describe cronjob datasource-syncer コマンドを実行します。

2. データソース同期ツールのプロジェクト ID が、サービス アカウントの認証情報と同じ指標スコープまたはプロジェクトに設定されていることを確認します。

3. Grafana サービス アカウントに「管理者」のロールがあり、API トークンの有効期限が切れていないことを確認します。

4. 選択したプロジェクト ID に対するモニタリング閲覧者のロールがサービス アカウントにあることを確認します。

5. kubectl logs job.batch/datasource-syncer-init を実行して、データソース同期ジョブのログにエラーがないことを確認します。このコマンドは、datasource-syncer.yaml ファイルを適用した直後に実行する必要があります。

6. Workload Identity Federation for GKE を使用している場合は、アカウントキーや認証情報を間違えて入力していないか確認し、正しい Namespace にバインドされていることを確認します。

以前のフロントエンド UI プロキシを使用している場合は、次の方法でエラーを解決してください。

1. フロントエンド UI のプロジェクト ID が、サービス アカウントの認証情報と同じ指標スコープまたはプロジェクトに設定されていることを確認します。

2. --query.project-id フラグで指定したプロジェクト ID を確認します。

3. 選択したプロジェクト ID に対するモニタリング閲覧者のロールがサービス アカウントにあることを確認します。

4. フロントエンド UI をデプロイするときに、正しいプロジェクト ID を設定していることと、リテラル文字列 PROJECT_ID に設定されていないことを確認します。

5. Workload Identity を使用している場合は、アカウントキーや認証情報を間違えて入力していないか確認し、正しい Namespace にバインドされていることを確認します。

6. 独自の Secret をマウントする場合は、その Secret が存在することを確認します。

   kubectl get secret gmp-test-sa -o json | jq '.data | keys'
   

7. Secret が正しくマウントされていることを確認します。

   kubectl get deploy frontend -o json | jq .spec.template.spec.volumes
   
   kubectl get deploy frontend -o json | jq .spec.template.spec.containers[].volumeMounts
   

8. Secret がコンテナに正しく渡されることを確認します。

   kubectl get deploy frontend -o json | jq .spec.template.spec.containers[].args
   

Grafana に対する HTTP メソッドが正しくない

Grafana で次の API エラーが表示された場合、GET リクエストの代わりに POST リクエストを送信するように Grafana が構成されています。

• "{"status":"error","errorType":"bad_data","error":"no match[] parameter provided"}%"

この問題を解決するには、データソースの構成の手順に沿って、GET リクエストを使用するように Grafana を構成します。

大規模クエリまたは長時間実行クエリのタイムアウト

Grafana で次のエラーが表示された場合は、デフォルトのクエリ タイムアウトが小さすぎます。

• "Post "http://frontend.NAMESPACE_NAME.svc:9090/api/v1/query_range": net/http:timeout awaiting response headers"

Prometheus 向けのマネージド サービスは、クエリが 120 秒を超えるまでタイムアウトしませんが、Grafana はデフォルトで 30 秒後にタイムアウトします。この問題を解決するには、データソースの構成の手順に沿って、Grafana のタイムアウトを 120 秒に引き上げます。

ラベル検証エラー

Grafana で次のいずれかのエラーが発生した場合、サポートされていないエンドポイントを使用している場合があります。

• 「検証: 名前以外のラベルはまだサポートされていません」
• 「[ジョブ] のテンプレート化: オプション更新のエラー: 名前以外のラベルはまだサポートされていません。」

Managed Service for Prometheus は、__name__ ラベルについてのみ /api/v1/$label/values エンドポイントをサポートします。この制限により、Grafana で label_values($label) 変数を使用するクエリは失敗します。

代わりに、label_values($metric, $label) の形式を使用してください。このクエリでは、返されるラベル値が指標によって制限されるため、ダッシュボードの内容に関係のない値は取得されないため、このクエリの使用をおすすめします。このクエリは、Prometheus でサポートされているエンドポイントを呼び出します。

サポートされているエンドポイントの詳細については、API の互換性をご覧ください。

割り当てを超過しました

次のエラーが表示された場合には、Cloud Monitoring API の取り込み割り当てを超えています。

• 「429: RESOURCE_EXHAUSTED: 「顧客の「project_number」用の「monitoring.googleapis.com」サービスの「時系列クエリ」割り当て指標と「1 分間あたりの時系列リクエスト」の上限の割り当てを超えました...」

この問題を解決するには、Monitoring API の読み取り割り当てを増やすリクエストを送信してください。サポートが必要な場合は、Google Cloud サポートにお問い合わせください。割り当ての詳細については、割り当ての操作をご覧ください。

複数のプロジェクトの指標

複数の Google Cloud プロジェクトの指標を表示する場合は、複数のデータソース同期ツールを構成したり、Grafana で複数のデータソースを作成する必要はありません。

代わりに、モニタリングするプロジェクトを含む 1 つの Google Cloud プロジェクト（スコープ対象プロジェクト）に Cloud Monitoring 指標スコープを作成します。スコープ対象プロジェクトで Grafana データソースを構成すると、指標スコープ内のすべてのプロジェクトのデータにアクセスできるようになります。詳細については、クエリと指標のスコープをご覧ください。

モニタリング対象リソースタイプが指定されていない

次のようなエラーが表示された場合は、PromQL を使用して Google Cloud システム指標をクエリするときに、モニタリング対象リソースタイプを指定する必要があります。

• 「複数のモニタリング対象リソースタイプで使用するように指標が構成されています。シリーズ セレクタは、モニタリング対象リソース名に対してラベルマッチャーを指定する必要があります」

モニタリング対象リソースタイプは、monitored_resource ラベルを使用してフィルタすることで指定できます。有効なモニタリング対象リソースタイプを特定して選択する方法については、モニタリング対象リソースタイプの指定をご覧ください。

コレクタ UI と Google Cloud コンソールでカウンタ、ヒストグラム、サマリーの未加工値が一致しない

カウンタ、ヒストグラム、サマリーなど、累積 Prometheus 指標の未加工値をクエリすると、ローカル コレクタ Prometheus UI と Google Cloud コンソールの値が異なる場合があります。この動作は予期されたものです。

Monarch には開始のタイムスタンプが必要ですが、Prometheus には開始のタイムスタンプがありません。Prometheus のマネージド サービスは、任意の時系列で最初に取り込まれたポイントをスキップして開始のタイムスタンプに変換することで、開始のタイムスタンプを生成します。その後のポイントの値から、最初にスキップしたポイントの値が減算され、レートが正確になります。その結果、これらのポイントの元の値に持続的な不足が生じます。

コレクタ UI の数値と Google Cloud コンソールの数値の差異は、コレクタ UI に最初に記録される値と等しくなります。これは、システムが最初の値をスキップし、後続のポイントから差し引くため、想定どおりの結果です。

本番環境では累積指標の未処理値に対するクエリを実行する必要がないため、問題ありません。すべての有効なクエリには rate() 関数などが必要です。この場合、対象期間にわたる差異は 2 つの UI 間で同じになります。累積指標は増加のみで、時系列がしきい値にヒットするのは 1 回だけです。このため、未処理のクエリにアラートは設定できません。有効なアラートとグラフはすべて、値の変化または変化の割合を示します。

コレクタがローカルに保持するデータは約 10 分のデータのみです。また、10 分間の期間より前に発生したリセットが原因で、未加工の累積値に差異が生じる場合もあります。この可能性を除外するには、コレクタ UI を Google Cloud コンソールと比較する際に、クエリ ルックバック期間を 10 分間のみに設定してみます。

アプリケーションに複数のワーカー スレッドがあり、それぞれに /metrics エンドポイントがある場合にも、差異が生じる可能性があります。アプリケーションが複数のスレッドをスピンアップする場合は、Prometheus クライアント ライブラリをマルチプロセス モードにする必要があります。詳細については、Prometheus の Python クライアント ライブラリにおけるマルチプロセス モードの使用に関するドキュメントをご覧ください。

カウンタデータが欠落しているか、ヒストグラムが破損している

この問題の最も一般的な兆候は、プレーン カウンタ指標（metric_name_foo の PromQL クエリなど）をクエリする際に、データが表示されなかったり、データギャップが表示されることです。この問題を確認するには、クエリに rate 関数（rate(metric_name_foo[5m]) など）を追加した後にデータが表示されるかどうかを調べます。

また、Cloud Monitoring で、取り込まれたサンプルが、スクレイピング ボリュームに大きな変化がなく急激に増加していたり、新しい指標が「unknown」や「unknown:counter」の接尾辞付きで作成されていることもあります。

また、quantile() 関数などのヒストグラム オペレーションが期待どおりに動作しない場合もあります。

これらの問題は、Prometheus 指標 TYPE なしで指標が収集された場合に発生します。Monarch は厳密に型指定されるため、Managed Service for Prometheus は末尾に「unknown」を付加した型指定のない指標を考慮し、これらをゲージとして 1 回、カウンタとして 2 回取り込みます。次に、クエリエンジンが、使用するクエリ関数に基づいて、基になるゲージまたはカウンタ指標のどちらをクエリするかを選択します。

通常、このヒューリスティックは非常にうまく機能しますが、生の「unknown:counter」指標をクエリすると、結果がおかしくなるなどの問題が発生する可能性があります。また、ヒストグラムは Monarch で特別に型指定されたオブジェクトであるため、必要な 3 つのヒストグラム指標を個別のカウンタ指標として取り込むと、ヒストグラム関数は機能しなくなります。「unknown」型の指標は 2 回取り込まれるため、TYPE を設定しないと、取り込まれるサンプルが 2 倍になります。

TYPE が設定されていない場合の一般的な理由は次のとおりです。

• Managed Service for Prometheus コレクタを連携サーバーとして誤って構成している。Managed Service for Prometheus を使用する場合、連携はサポートされません。連携は意図的に TYPE 情報を破棄するため、連携を実装すると「unknown」型の指標が発生します。
• 取り込みパイプラインの任意の時点で Prometheus Remote Write を使用する。また、このプロトコルは TYPE 情報を意図的に破棄します。
• 指標名を変更する再ラベル付けルールを使用する。これにより、名前が変更された指標は、元の指標名に関連付けられた TYPE 情報との関連付けが解除されます。
• エクスポータが各指標の TYPE を出力しない。
• コレクタの初回起動時に TYPE がドロップされる一時的な問題。

この問題を解決するには、次の操作を行います。

• Prometheus 用のマネージド サービスとの連携の使用を停止します。データを Monarch に送信する前にそれをロールアップすることでカーディナリティと費用を削減したい場合は、ローカル集約の構成をご覧ください。
• コレクション パスでの Prometheus Remote Write の使用を停止します。
• /metrics エンドポイントにアクセスして、各指標に # TYPE フィールドが存在することを確認します。
• 指標の名前を変更するラベル変更ルールをすべて削除します。
• DeleteMetricDescriptor の呼び出しによって、接尾辞「unknown」または「unknown:counter」で競合する指標を削除します。
• または、常に rate または他のカウンタ処理関数を使用してカウンタをクエリします。

Pod の再起動後に Grafana データが保持されない

Pod の再起動後にデータが Grafana から消えるように見え、Cloud Monitoring では表示される場合は、Prometheus 向けのマネージド サービスの代わりにローカル Prometheus インスタンスをクエリするために Grafana を使用しています。

マネージド サービスをデータソースとして使用するように Grafana を構成する方法については、Grafana をご覧ください。

Grafana ダッシュボードのインポート

ダッシュボード インポータの使用方法とトラブルシューティングについては、Grafana ダッシュボードを Cloud Monitoring にインポートするをご覧ください。

ダッシュボード コンテンツの変換に関する問題については、インポータの README ファイルをご覧ください。

取り込み側の問題

取り込み側の問題は、収集またはルールの評価に関連することがあります。まず、マネージド コレクションのエラーログを確認します。次のコマンドを実行できます。

kubectl logs -f -n gmp-system -lapp.kubernetes.io/part-of=gmp

kubectl logs -f -n gmp-system -lapp.kubernetes.io/name=collector -c prometheus

GKE Autopilot クラスタでは、次のコマンドを実行できます。

kubectl logs -f -n gke-gmp-system -lapp.kubernetes.io/part-of=gmp

kubectl logs -f -n gke-gmp-system -lapp.kubernetes.io/name=collector -c prometheus

ターゲット ステータス機能は、スクレイピング ターゲットのデバッグに役立ちます。詳細については、ターゲットのステータス情報をご覧ください。

エンドポイントのステータスが欠落しているか、古すぎる

ターゲット ステータス機能を有効にしているが、1 つ以上の PodMonitoring または ClusterPodMonitoring リソースに Status.Endpoint Statuses フィールドまたは値がない場合は、次のいずれかの問題が発生している可能性があります。

• Managed Service for Prometheus がエンドポイントの 1 つと同じノード上のコレクタに到達できなかった。
• 1 つ以上の PodMonitoring または ClusterPodMonitoring 構成で有効なターゲットがない。

同様の問題により、Status.Endpoint Statuses.Last Update Time フィールドの値がスクレイピング間隔より数分以上長くなることがあります。

この問題を解決するには、まず、スクレイピング エンドポイントに関連付けられている Kubernetes Pod が実行中であることを確認してください。Kubernetes Pod が実行中であり、ラベルセレクタが一致している場合、スクレイピング エンドポイントに手動でアクセスできるのであれば（通常は /metrics エンドポイントにアクセス）、Managed Service for Prometheus コレクタが実行中かどうかを確認できます。

Collectors Fraction が 1 になっていない

ターゲット ステータス機能を有効にしている場合は、リソースに関するステータス情報を取得できます。PodMonitoring リソースまたは ClusterPodMonitoring リソースの Status.Endpoint Statuses.Collectors Fraction 値は、到達可能なコレクタの割合を 0～1 の値で表します。たとえば、値 0.5 はコレクタの 50% が到達可能であることを示し、値 1 はコレクタの 100% が到達可能であることを示します。

Collectors Fraction フィールドの値が 1 以外の場合、1 つ以上のコレクタに到達できず、これらのノードのいずれかの指標がスクレイピングされていない可能性があります。すべてのコレクタが実行中で、クラスタ ネットワーク経由で到達可能であることを確認してください。次のコマンドを使用して、コレクタ Pod のステータスを表示できます。

kubectl -n gmp-system get pods --selector="app.kubernetes.io/name=collector"

GKE Autopilot クラスタでは、このコマンドは少し異なります。

kubectl -n gke-gmp-system get pods --selector="app.kubernetes.io/name=collector"

個々のコレクタ Pod（たとえば、collector-12345 という名前のコレクタ Pod）を調査するには、次のコマンドを使用します。

kubectl -n gmp-system describe pods/collector-12345

GKE Autopilot クラスタでは、次のコマンドを実行します。

kubectl -n gke-gmp-system describe pods/collector-12345

コレクタが正常でない場合は、GKE ワークロードのトラブルシューティングをご覧ください。

コレクタが正常な場合は、オペレーター ログを確認してください。オペレーター ログを確認するには、最初に以下のコマンドを実行してオペレーターの Pod 名を確認します。

kubectl -n gmp-system get pods --selector="app.kubernetes.io/name=gmp-collector"

GKE Autopilot クラスタでは、以下のコマンドを実行します。

kubectl -n gke-gmp-system get pods --selector="app.kubernetes.io/name=gmp-collector"

次に、以下のコマンドを使用してオペレーター ログを確認します（たとえば、オペレータ Pod の名前が gmp-operator-12345 だとします）。

kubectl -n gmp-system logs pods/gmp-operator-12345

GKE Autopilot クラスタでは、以下のコマンドを実行します。

kubectl -n gke-gmp-system logs pods/gmp-operator-12345

異常なターゲット

ターゲット ステータス機能を有効にしているが、1 つ以上の PodMonitoring または ClusterPodMonitoring リソースに、0 以外の値を持つ Status.Endpoint Statuses.Unhealthy Targets フィールドがある場合、コレクタが 1 つ以上のターゲットをスクレイピングできません。

エラー メッセージごとにターゲットをグループ化する Sample Groups フィールドを表示し、Last Error フィールドを見つけます。Last Error フィールドには Prometheus から返された値が含まれており、ターゲットをスクレイピングできなかった理由を示します。この問題を解決するには、サンプル ターゲットを参照として使用して、スクレイピング エンドポイントが実行中かどうかを確認します。

許可されていないスクレイピング エンドポイント

次のいずれかのエラーが表示され、スクレイピング ターゲットに認証が必要な場合、コレクタが正しい認証タイプを使用するように設定されていないか、正しくない認証ペイロードを使用しています。

• server returned HTTP status 401 Unauthorized
• x509: certificate signed by unknown authority

この問題を解決するには、承認済みのスクレイピング エンドポイントの構成をご覧ください。

割り当てを超過した

次のエラーが表示された場合には、Cloud Monitoring API の取り込み割り当てを超えています。

• 「429: コンシューマ「project_number:PROJECT_NUMBER」に対するサービス「monitoring.googleapis.com'」の割り当て指標「時系列取り込みリクエスト」と上限「1 分間あたりの時系列取り込みリクエスト」に対する割り当てを超えました」、rateLimitExceeded」

このエラーは、マネージド サービスを初めて起動したときに多く一般的に発生します。デフォルトの割り当ては 1 秒間に 100,000 サンプルの取り込みで尽きます。

この問題を解決するには、Monitoring API の取り込み割り当てを増やすリクエストを送信してください。サポートが必要な場合は、Google Cloud サポートにお問い合わせください。割り当ての詳細については、割り当ての操作をご覧ください。

ノードのデフォルトのサービス アカウントでの権限の欠落

次のいずれかのエラーが発生した場合は、そのノード上のデフォルトのサービス アカウントに権限がない場合があります。

• 「クエリの実行: Prometheus のクエリのエラー: client_error: クライアント エラー: 403」
• 「Readiness プローブが失敗しました: ステータスコード: 503 で HTTP プローブが失敗しました」
• 「Prometheus インスタンスのクエリのエラー」

Managed Service for Prometheus のマネージド コレクションとマネージド ルール エバリュエータの両方が、ノード上のデフォルトのサービス アカウントを使用します。このアカウントは必要なすべての権限付きで作成されますが、顧客が手動で モニタリング権限を削除することがあります。この削除により、コレクションとルールの評価が失敗します。

サービス アカウントの権限を確認するには、次のいずれかを行います。

• 基盤となる Compute Engine ノード名を特定してから、次のコマンドを実行します。

  gcloud compute instances describe NODE_NAME --format="json" | jq .serviceAccounts
  

  文字列 https://www.googleapis.com/auth/monitoring を探します。 必要に応じて、構成に不備があるサービス アカウントの説明に従ってモニタリングを追加します。

• クラスタ内の基盤となる VM に移動し、ノードのサービス アカウントの構成を確認します。

  1. Google Cloud コンソールで、[Kubernetes クラスタ] ページに移動します。

     [Kubernetes クラスタ] に移動

     検索バーを使用してこのページを検索した場合は、小見出しが [Kubernetes Engine] の結果を選択します。

  2. [ノード] を選択してから、[ノード] テーブルでノードの名前をクリックします。

  3. [詳細] をクリックします。

  4. [VM インスタンス] リンクをクリックします。

  5. [API と ID の管理] ペインに移動して、[詳細を表示] をクリックします。

  6. 完全アクセス権のある Stackdriver Monitoring API を探します。

また、データソース同期ツールまたは Prometheus UI が誤ったプロジェクトを参照するように構成されている可能性もあります。意図した指標スコープをクエリしていることを確認する方法については、クエリされたプロジェクトを変更するをご覧ください。

構成に不備があるサービス アカウント

次のいずれかのエラー メッセージが表示される場合は、コレクタで使用されるサービス アカウントに正しい権限がありません。

• 「コード = Permissiondeny 説明 = monitoring.timeSeries.create 権限の拒否（またはリソースが存在しない場合があります）」
• 「google: could not find default credentials. See https://developers.google.com/accounts/docs/application-default-credentials for more information.」

サービス アカウントに正しい権限が付与されていることを確認するには、次のようにします。

1. Google Cloud コンソールの [IAM] ページに移動します。

   [IAM] に移動

   検索バーを使用してこのページを検索する場合は、小見出しが [IAM と管理者] である結果を選択します。

2. プリンシパルのリストでサービス アカウント名を確認します。サービス アカウントの名前が正しいことを確認します。次に [edit編集] をクリックします。

3. [ロール] フィールドを選択してから、[現在使用中] をクリックして、モニタリング指標の書き込みまたはモニタリング編集者のロールを検索します。サービス アカウントにこれらのロールのいずれかがない場合は、サービス アカウントにモニタリング指標の書き込み（roles/monitoring.metricWriter）ロールを付与します。

GKE 以外の Kubernetes で実行する場合は、コレクタとルール エバリュエータの両方に明示的に認証情報を渡す必要があります。rules セクションと collection セクションの両方で認証情報を繰り返す必要があります。詳細については、認証情報を明示的に指定する（収集の場合）または認証情報を明示的に指定する（ルールの場合）をご覧ください。

サービス アカウントは、たいてい単一の Google Cloud プロジェクトによってスコープされます。1 つのサービス アカウントを使用して複数のプロジェクトの指標データを書き込むと（たとえば、1 つのマネージド ルール エバリュエータがマルチプロジェクトの指標スコープをクエリしている場合）、この権限エラーを引き起こす可能性があります。デフォルトのサービス アカウントを使用している場合は、いくつかのプロジェクトの monitoring.timeSeries.create 権限を安全に追加できるように、専用のサービス アカウントを構成することを検討してください。この権限を付与できない場合には、指標のラベル付けをやり直し、project_id ラベルを別の名前に書き換えます。プロジェクト ID はその後、デフォルトで、Prometheus サーバーまたはルール エバリュエータが実行されている Google Cloud プロジェクトになります。

スクレイピングの構成が無効

次のエラーが表示された場合、PodMonitoring または ClusterPodMonitoring の形式が正しくありません。

• 「Internal error occurred: failed calling webhook "validate.podmonitorings.gmp-operator.gmp-system.monitoring.googleapis.com": Post "https://gmp-operator.gmp-system.svc:443/validate/monitoring.googleapis.com/v1/podmonitorings?timeout=10s": EOF"」

この問題を解決するには、カスタム リソースの形式が仕様に従った形式であることを確認してください。

アドミッション Webhook が解析できない、または無効な HTTP クライアント構成

Managed Service for Prometheus のバージョンが 0.12 より前の場合、デフォルト以外の Namespace でのシークレット挿入に関連する次のようなエラーが表示されることがあります。

• 「admission webhook "validate.podmonitorings.gmp-operator.gmp-system.monitoring.googleapis.com" denied the request: invalid definition for endpoint with index 0: unable to parse or invalid Prometheus HTTP client config: must use namespace "my-custom-namespace", got: "default""

この問題を解決するには、バージョン 0.12 以降にアップグレードしてください。

収集間隔とタイムアウトに関する問題

Managed Service for Prometheus を使用する場合、スクレイピングのタイムアウトがスクレイピングの間隔より長くなることはありません。この問題のログを確認するには、次のコマンドを実行します。

kubectl -n gmp-system logs ds/collector prometheus

GKE Autopilot クラスタでは、次のコマンドを実行します。

kubectl -n gke-gmp-system logs ds/collector prometheus

次のメッセージを探します。

• 「収集タイムアウトが、ジョブ名が「PodMonitoring/gmp-system/example-app/go-metrics」の収集構成の収集間隔を超えています。」

この問題を解決するには、収集間隔の値を収集タイムアウトの値以上に設定します。

指標にタイプがありません

次のエラーが表示された場合には、指標にタイプ情報が欠落しています。

• 「指標名「{metric_name}」に関するメタデータが見つかりません」

タイプ情報の欠落が問題かどうかを確認するには、エクスポート アプリケーションの /metrics 出力を確認します。次のような行がない場合、タイプ情報が欠落しています。

# TYPE {metric_name} <type>

特定のライブラリ（バージョン 1.28.0 より前の VictoriaMetrics のライブラリなど）は、意図的にタイプ情報を破棄します。これらのライブラリは、Managed Service for Prometheus ではサポートされていません。

時系列の競合

次のエラーのいずれかが表示された場合、複数のコレクタが同じ時系列に書き込もうとしている場合があります。

• 「1 つ以上の TimeSeries に書き込めませんでした: 1 つ以上のポイントが、指標に対して構成されている最大サンプリング期間よりも頻繁に書き込まれました。」
• 「1 つ以上の TimeSeries に書き込めませんでした: ポイントを順番に書き込む必要があります。指定された 1 つ以上のポイントで、直近のポイントより古い終了時刻があります。」

一般的な原因と解決策は次のとおりです。

• 高可用性ペアの使用。Managed Service for Prometheus は、従来の高可用性コレクションをサポートしていません。この構成を使用すると、同じ時系列にデータの書き込みを試みる複数のコレクタが作成できるため、このエラーが発生します。

  この問題を解決するには、レプリカ カウントを 1 に減らして重複するコレクタを無効にするか、サポートされている高可用性メソッドを使用します。

• 再ラベル付けルール（特にジョブやインスタンスで動作するルール）の使用。Managed Service for Prometheus は、{project_id, location, cluster, namespace, job, instance} の組み合わせによって一意の時系列を部分的に識別します。再ラベル付けルールを使用してこれらのラベル（特に job ラベルと instance ラベル）を破棄すると、競合を頻繁に発生させる可能性があります。これらのラベルの書き換えは推奨されません。

  この問題を解決するには、原因となっているルールを削除します。多くの場合、この処理は labeldrop アクションを使用する metricRelabeling ルールで行います。すべての再ラベル付けルールをコメントアウトしてから、エラーが発生するまで 1 回に 1 つずつ復元することで、問題のあるルールを特定できます。

あまり一般的ではない時系列の競合の原因は、5 秒未満の収集間隔の使用です。Managed Service for Prometheus でサポートされる最小収集間隔は 5 秒です。

ラベル数の上限超過

次のエラーが発生した場合は、いずれかの指標に定義されているラベルが多すぎる可能性があります。

• 「One or more TimeSeries could not be written: The new labels would cause the metric prometheus.googleapis.com/METRIC_NAME to have over PER_PROJECT_LIMIT labels.」

このエラーは通常、指標の定義が頻繁に変更され、指標の存続期間全体で同じ指標名に対して独立したラベルキーのセットが複数存在する場合に発生します。Cloud Monitoring では各指標のラベル数に上限があります。詳細については、ユーザー定義の指標の制限をご覧ください。

この問題を解決するには、次の 3 つの操作を行います。

1. 特定の指標のラベルが多すぎる理由、または頻繁に変化する理由を特定する。

   • metricDescriptors.list ページで API Explorer ウィジェットを使用して、メソッドを呼び出します。詳細については、API Explorer をご覧ください。例については、指標とリソースタイプを一覧表示するをご覧ください。

2. 問題の原因を特定する。たとえば、PodMonitoring のラベル変更ルールの調整、エクスポータの変更、計測の修正などが原因として考えられます。

3. この指標の指標記述子を削除する（これによりデータが消失します）。これにより、サイズの小さい安定したラベルのセットで再作成できるようになります。この操作を行うには、metricDescriptors.delete メソッドを使用します。

この問題の最も一般的な原因は次のとおりです。

• 指標に動的ラベルを適用するエクスポータまたはアプリケーションから指標を収集している。たとえば、追加のコンテナラベルと環境変数を使用したセルフデプロイの cAdvisor や、動的アノテーションを挿入する DataDog エージェントなど。

  この問題を解決するには、PodMonitoring の metricRelabeling セクションを使用して、ラベルを保持または削除します。一部のアプリケーションとエクスポータでは、エクスポートされた指標を変更する構成も許可されています。たとえば、cAdvisor の場合は、ラベルを動的に追加できる高度なランタイム設定が数多く用意されています。マネージド コレクションを使用する場合は、組み込みの自動 kubelet コレクションを使用することをおすすめします。

• 再ラベル付けルール（特にラベル名を動的に付けるルール）を使用すると、予期しないラベル数が発生する可能性があります。

  この問題を解決するには、その原因となっているルールのエントリを削除します。

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

次のようなエラーが表示された場合は、新しい指標の作成と既存の指標への新しい指標ラベルの追加で 1 分あたりのレート制限に達しています。

• 「リクエストはスロットリングされています。1 分あたりの指標定義またはラベル定義の変更に関して、プロジェクトごとの上限に達しています。」

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

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

指標記述子の数の制限

次のエラーが表示された場合は、1 つの Google Cloud プロジェクト内の指標記述子の数の割り当て上限に達しています。

• 「Your metric descriptor quota has been exhausted.」

デフォルトでは、この上限は 25,000 に設定されています。この割り当ては、指標の形式が正しければリクエストによって解除できますが、不正な形式の指標名がシステムに取り込まれるため、この上限に達する可能性が高くなります。

Prometheus にはディメンション データモデルがあり、クラスタ名や Namespace 名などの情報をラベル値としてエンコードする必要があります。ディメンション情報が指標名自体に埋め込まれている場合、指標記述子の数は無限に増加します。さらに、このシナリオではラベルが適切に使用されないため、クラスタ、Namespace、サービス間でデータをクエリして集計することがはるかに難しくなります。

Cloud Monitoring と Managed Service for Prometheus はどちらも、StatsD や Graphite などのディメンション以外の指標をサポートしていません。ほとんどの Prometheus エクスポータは最初から正しく構成されていますが、StatsD エクスポータ、Vault エクスポータ、Istio に付属の Envoy プロキシなどの特定のエクスポータは、ラベルを使用するように明示的に構成する必要があります。不適切な形式の指標名の例は次のとおりです。

• request_path_____path_to_a_resource____istio_request_duration_milliseconds
• envoy_cluster_grpc_method_name_failure
• envoy_cluster_clustername_upstream_cx_connect_ms_bucket
• vault_rollback_attempt_path_name_1700683024
• service__________________________________________latency_bucket

この問題を確認するには、次の操作を行います。

1. Google Cloud コンソールで、エラーにリンクされている Google Cloud プロジェクトを選択します。

2. Google Cloud コンソールで、 query_stats[指標の管理] ページに移動します。

   [指標の管理] に移動

   検索バーを使用してこのページを検索する場合は、小見出しが [Monitoring] である結果を選択します。

3. 「有効」と「無効」の指標の合計が 25,000 を超えていることを確認します。ほとんどの場合、多くの「有効」指標が表示されます。
4. [クイック フィルタ] パネルで [無効] を選択し、リストをページ送りしてパターンを探します。
5. [クイック フィルタ] パネルで [アクティブ] を選択し、請求対象ボリュームのサンプルを降順で並べ替えて、リストをページごとに確認し、パターンを探します。
6. 請求対象ボリュームのサンプルを昇順で並べ替えて、リストをページごとに確認し、パターンを探します。

また、Metrics Explorer を使用してこの問題を確認することもできます。

1. Google Cloud コンソールで、エラーにリンクされている Google Cloud プロジェクトを選択します。

2. Google Cloud コンソールで、[leaderboardMetrics Explorer] ページに移動します。

   Metrics Explorer に移動

   検索バーを使用してこのページを検索する場合は、小見出しが [Monitoring] である結果を選択します。

3. クエリビルダーで、指標をクリックして選択し、[有効] チェックボックスをオフにします。
4. 検索バーに「prometheus」と入力します。
5. 指標の名前にパターンがないか探します。

不正な形式の指標を示すパターンを特定したら、ソースでエクスポータを修正し、問題のある指標記述子を削除することで、問題を軽減できます。

この問題の再発を防ぐには、まず、関連するエクスポータを構成して、不正な形式の指標が出力されないようにする必要があります。エクスポータのドキュメントを参照することをおすすめします。問題が修正されたことを確認するには、/metrics エンドポイントに手動でアクセスし、エクスポートされた指標名を調べます。

その後、projects.metricDescriptors.delete メソッドを使用して不正な形式の指標を削除することで、割り当てを解放できます。不正な形式の指標のリストをより簡単に反復処理できるように、使用可能な Golang スクリプトが用意されています。このスクリプトは、不正な形式の指標を識別できる正規表現を受け入れ、パターンに一致する指標記述子をすべて削除します。指標の削除は元に戻せないため、最初にドライラン モードでスクリプトを実行することを強くおすすめします。

エラーも指標もない

マネージド コレクションを使用している場合、エラーは表示されませんが、Cloud Monitoring にデータが表示されない場合、最も可能性が高い原因は、指標のエクスポータやスクレイピングが正しく構成されていないことです。最初に有効なスクレイピング構成を適用しない限り、Managed Service for Prometheus は時系列データを送信しません。

これが原因かどうかを特定するには、サンプル アプリケーションとサンプル PodMonitoring リソースのデプロイを試してください。up 指標が表示される場合は（数分かかる場合があります）、スクレイピングの構成またはエクスポータに問題があります。

根本原因にはさまざまなものがあります。以下を確認することをおすすめします。

• PodMonitoring が有効なポートを参照している。

• エクスポータの Deployment 仕様に適切な名前のポートがある。

• セレクタ（最も一般的には app）が Deployment と PodMonitoring のリソースに一致する。

• 手動でアクセスすることで、想定されるエンドポイントとポートでデータを確認する。

• スクレイピングするアプリケーションと同じ名前空間に PodMonitoring リソースがインストールされている。gmp-system 名前空間または gke-gmp-system 名前空間にカスタム リソースやカスタムアプリをインストールしないでください。

• 指標とラベル名が Prometheus の正規表現の検証と一致する。Managed Service for Prometheus は、_ で始まるラベル名をサポートしていません。

• すべてのデータがフィルタで除外されるようなフィルタセットを使用していない。OperatorConfig リソースで collection フィルタを使用する場合は、競合するフィルタがないことに注意してください。

• Google Cloud の外部で実行されている場合は、project または project-id が有効な Google Cloud プロジェクトに設定され、location が有効な Google Cloud リージョンに設定されます。location の値として global を使用することはできません。

• 指標は、4 つの Prometheus 指標タイプのいずれかです。Kube State Metrics などの一部のライブラリでは、Info、Stateet、GaugeHistogram などの OpenMetrics 指標タイプが公開されていますが、これらの指標タイプは Prometheus のマネージド サービスではサポートされておらず、通知なく破棄されます。

短時間実行ターゲットの一部の指標がない

Google Cloud Managed Service for Prometheus がデプロイされ、構成エラーはありませんが、一部の指標がありません。

部分的に欠落している指標を生成するデプロイメントを特定します。デプロイが Google Kubernetes Engine の CronJob の場合は、ジョブの通常の実行時間を特定します。

1. cron ジョブのデプロイ yaml ファイルを見つけて、ファイルの末尾にリストされているステータスを確認します。この例のステータスは、ジョブが 1 分間実行されたことを示しています。

     status:
       lastScheduleTime: "2024-04-03T16:20:00Z"
       lastSuccessfulTime: "2024-04-03T16:21:07Z"
   

2. 実行時間が 5 分未満の場合、指標データが継続的にスクレイピングされるほどジョブが実行されていません。

   この状況を解決するには、次のことを試してください。

   • ジョブの開始から 5 分以上経過するまでジョブが終了しないようにジョブを構成します。

   • 終了前に指標がスクレイピングされたかどうかを検出するようにジョブを構成します。この機能を使用するには、ライブラリのサポートが必要です。

   • 指標データを収集する代わりに、ログベースの分布値指標の作成を検討してください。このアプローチは、データが低い頻度で公開される場合に推奨されます。詳細については、ログベースの指標をご覧ください。

3. 実行時間が 5 分を超える場合や、実行時間が一定でない場合は、このドキュメントの異常なターゲットのセクションをご覧ください。

エクスポータからの収集に関する問題

エクスポータからの指標が取り込まれていない場合は、次の点を確認してください。

• kubectl port-forward コマンドを使用して、エクスポータが動作しており、指標をエクスポートしていることを確認します。

  たとえば、名前空間 test のセレクタ app.kubernetes.io/name=redis を持つ Pod がポート 9121 のエンドポイント /metrics で指標を出力していることを確認するには、次のようにポート転送します。

  kubectl port-forward "$(kubectl get pods -l app.kubernetes.io/name=redis -n test -o jsonpath='{.items[0].metadata.name}')" 9121
  

  別のターミナル セッションでブラウザまたは curl を使用してエンドポイント localhost:9121/metrics にアクセスし、指標がスクレイピング用にエクスポータによって公開されていることを確認します。

• Google Cloud コンソールで指標をクエリできても、Grafana はクエリできないかどうかを確認します。その場合、問題は指標の収集ではなく、Grafana にあります。

• コレクタが公開する Prometheus ウェブ インターフェースを検査して、マネージド コレクタがエクスポータを取得できることを確認します。

  1. エクスポータを実行している同じノードで実行されているマネージド コレクタを特定します。たとえば、エクスポータが名前空間 test の Pod で実行されており、Pod に app.kubernetes.io/name=redis のラベルが付いている場合、同じノードで実行されているマネージド コレクタを特定するには次のコマンドを使用します。

     kubectl get pods -l app=managed-prometheus-collector --field-selector="spec.nodeName=$(kubectl get pods -l app.kubernetes.io/name=redis -n test -o jsonpath='{.items[0].spec.nodeName}')" -n gmp-system -o jsonpath='{.items[0].metadata.name}'
     

  2. マネージド コレクタのポート 19090 からのポート転送を設定します。

     kubectl port-forward POD_NAME -n gmp-system 19090
     

  3. URL localhost:19090/targets に移動してウェブ インターフェースにアクセスします。エクスポータがターゲットの 1 つとして表示されている場合は、マネージド コレクタがエクスポータを正常に取得しています。

コレクタのメモリ不足（OOM）エラー

マネージド コレクションを使用していて、コレクタでメモリ不足（OOM）エラーが発生する場合は、垂直 Pod 自動スケーリングを有効にすることを検討してください。

オペレーターにメモリ不足（OOM）エラーがある

マネージド コレクションを使用していて、オペレータでメモリ不足（OOM）エラーが発生する場合は、ターゲット ステータス機能を無効にすることを検討してください。ターゲット ステータス機能を使用すると、大規模なクラスタでオペレーターのパフォーマンスの問題が発生する可能性があります。

ファイアウォール

ファイアウォールは、取り込みとクエリの両方の問題の原因である可能性があります。Monitoring API サービス monitoring.googleapis.com に対する POST リクエストと GET リクエストの両方が取り込みとクエリを許可するように、ファイアウォールを構成する必要があります。

同時編集に関するエラー

「Too many concurrent edits to the project configuration」というエラー メッセージは通常、一時的なものであり、数分後に消えます。これは通常、さまざまな指標に影響するラベル変更ルールを削除したことが原因で発生します。削除により、プロジェクト内の指標記述子の更新キューが形成されます。キューが処理されると、エラーが表示されなくなります。

詳細については、指標とラベルの作成と更新に関する制限をご覧ください。

Monarch によってブロックおよびキャンセルされたクエリ

次のエラーが表示された場合は、特定のプロジェクトに対して実行できる同時実行クエリ数の内部上限に達しています。

• 「internal: expanding series: generic::aborted: invalid status monarch::220: メモリを待機している評価がブロックされているクエリの数は 501 で、上限の 500 以上であるため、キャンセルされました。」

不正使用を防ぐため、Monarch 内で同時に実行できる 1 つのプロジェクトのクエリ数にはハード制限が適用されます。一般的な Prometheus の使用では、クエリは迅速に行われ、この上限に達することはありません。

予想よりも長い時間実行される同時クエリを大量に発行している場合は、この上限に達する可能性があります。通常、25 時間を超えるデータをリクエストするクエリは、25 時間未満のデータをリクエストするクエリよりも実行に時間がかかります。クエリのルックバックが長くなるほど、クエリの実行時間は長くなることが予想されます。

通常、この問題は、長いルックバック ルールを非効率的に大量に実行することで発生します。たとえば、1 分ごとに実行され、4 週間のレートのリクエストを行うルールが多数ある場合などです。これらのルールの実行に時間がかかると、プロジェクトの実行を待機しているクエリのバックアップが発生し、Monarch がクエリをスロットリングする可能性があります。

この問題を解決するには、長いルックバック ルールの評価間隔を長くして、1 分ごとに実行されないようにする必要があります。4 週間のレートに対して 1 分ごとにクエリを実行する必要はありません。4 週間には 40,320 分あるため、1 分ごとに追加のシグナルがほとんど得られません（データは最大で 1/40,320 倍変化します）。4 週間の料金をリクエストするクエリには、1 時間の評価間隔で十分です。

長時間実行クエリの実行頻度が高すぎるために発生するボトルネックを解決すると、この問題は解決します。

互換性のない値の型

取り込みまたはクエリ時に次のエラーが表示された場合は、指標に値の型の不整合があります。

• 「指標 prometheus.googleapis.com/metric_name/gauge の値の型は INT64 である必要がありますが、DOUBLE です」
• 「指標 prometheus.googleapis.com/metric_name/gauge の値の型は DOUBLE である必要がありますが、INT64 です」
• 「One or more TimeSeries could not be written: Value type for metric prometheus.googleapis.com/target_info/gauge conflicts with the existing value type (INT64)」

Monarch は DOUBLE 型のデータの INT64 型の指標への書き込みも、INT64 型のデータの DOUBLE 型の指標への書き込みもサポートしていないため、取り込み時にこのエラーが表示されることがあります。また、マルチプロジェクト指標スコープを使用してクエリを実行するときに、このエラーが表示されることもあります。これは、Monarch が 1 つのプロジェクトの DOUBLE 型の指標と別のプロジェクトの INT64 型の指標を結合できないためです。

このエラーは、OpenTelemetry コレクタがデータを報告している場合にのみ発生します。また、target_info 指標でよく発生するように、OpenTelemetry（googlemanagedprometheus エクスポータを使用）と Prometheus の両方が同じ指標のデータを報告している場合に発生する可能性が高くなります。

原因は次のいずれかである可能性があります。

• OTLP 指標を収集していて、OTLP 指標ライブラリの値の型が DOUBLE から INT64 に変更された（OpenTelemetry の Java 指標で発生したように）。新しいバージョンの指標ライブラリは、古いバージョンの指標ライブラリによって作成された指標値の型と互換性がなくなりました。
• Prometheus と OpenTelemetry の両方を使用して target_info 指標を収集しています。Prometheus は、この指標を DOUBLE として収集しますが、OpenTelemetry は INT64 として収集します。コレクタは、同じプロジェクトの同じ指標に 2 つの値の型を書き込み、指標記述子を最初に作成したコレクタのみが成功します。
• あるプロジェクトでは OpenTelemetry を使用して target_info を INT64 として収集し、別のプロジェクトでは Prometheus を使用して target_info を DOUBLE として収集しています。両方の指標を同じ指標スコープに追加し、その指標スコープでその指標をクエリすると、互換性のない指標値の型の間で無効な結合が発生します。

この問題は、次の手順ですべての指標値の型を DOUBLE に強制的に設定することで解決できます。

1. 機能ゲート exporter.googlemanagedprometheus.intToDouble フラグを有効にして、すべての指標を DOUBLE に強制的に設定するように OpenTelemetry コレクタを再構成します。
2. すべての INT64 指標記述子を削除し、DOUBLE として再作成します。delete_metric_descriptors.go スクリプトを使用して、この処理を自動化できます。

この手順を行うと、INT64 指標として保存されているすべてのデータが削除されます。この問題を完全に解決するには、INT64 指標を削除する以外に方法はありません。