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

コレクションでコンテンツを整理 必要に応じて、コンテンツの保存と分類を行います。

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

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

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

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

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

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

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

  2. Google Cloud コンソールで、[Monitoring] に移動するか、次のボタンを使用します。

    [Monitoring] に移動

  3. [Monitoring] のナビゲーション パネルで、[Metrics Explorer] をクリックします。

  4. [PromQL] タブを選択します。

  5. 次のクエリを入力します。

    up

  6. [クエリを実行] をクリックします。

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

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

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

クエリ側の問題

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

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

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

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

    1. Google Cloud Console で、[IAM と管理] に移動するか、次のボタンを使用します。

      [IAM と管理] に移動

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

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

問題が解決しない場合は、次の可能性を検討します。

Secret の構成ミスまたは入力の誤り

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

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

    • 「Warning: Unexpected response status when fetching server time: Forbidden」
    • 「Warning: Error fetching metrics list: Unexpected response status when fetching metric names: Forbidden」

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

これらのエラーを解決するには、次の手順を試してください。

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

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

  3. サービス アカウントにモニタリング閲覧者のロールがあることを確認します。

  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.gmp-test.svc:9090/api/v1/query_range": net/http: timeout awaiting response headers」

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

ラベル検証エラー

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

  • 「Validation: labels other than name are not supported yet」
  • 「Templating [job]: Error updating options: labels other than name are not supported yet.」

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: Quota exceeded for quota metric 'Time series queries ' and limit 'Time series queries per minute' of service 'monitoring.googleapis.com' for consumer 'project_number:...'.」

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

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

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

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

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

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

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

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

コレクタ UI と Google Cloud コンソールでカウンタの合計が一致しない

未処理のカウンタまたはカウンタの合計をクエリすると、ローカル コレクタ Prometheus UI と Google Cloud コンソールの値が異なる場合があります。この動作は予期されたものです。

Monarch には開始のタイムスタンプが必要ですが、Prometheus には開始のタイムスタンプがありません。Managed Service for Prometheus は、任意の時系列で最初に取り込まれたポイントをスキップして開始のタイムスタンプに変換することで、開始のタイムスタンプを生成します。その結果、カウンタの合計で過不足が持続的に発生します。

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

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

取り込み側の問題

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

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

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

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

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

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

割り当てを超過している

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

  • 「429: Quota exceeded for quota metric 'Time series ingestion requests' and limit 'Time series ingestion requests per minute' of service 'monitoring.googleapis.com' for consumer 'project_number:PROJECT_NUMBER'., rateLimitExceeded」

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

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

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

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

  • 「execute query: Error querying Prometheus: client_error: client error: 403」
  • 「Readiness probe failed: HTTP probe failed with statuscode: 503」
  • 「Error querying Prometheus instance」

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 Engine] を選択するか、次のボタンを使用します。

      [Kubernetes Engine] ページに移動

    2. [クラスタ] を選択してから、クラスタの名前をクリックします。

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

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

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

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

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

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

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

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

  • 「code = PermissionDenied desc = Permission monitoring.timeSeries.create denied (or the resource may not exist)」
  • 「google: could not find default credentials. See https://developers.google.com/accounts/docs/application-default-credentials for more information.」

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

  1. Google Cloud Console で、[IAM と管理] に移動するか、次のボタンを使用します。

    [IAM と管理] に移動

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

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

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

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

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

スクレイピングの間隔とタイムアウトに関する問題

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

kubectl -n gmp-system logs ds/collector prometheus

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

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

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

  • 「scrape timeout greater than scrape interval for scrape config with job name "PodMonitoring/gmp-system/example-app/go-metrics"」

この問題を解決するには、スクレイピング間隔の値をタイムアウトの値以上に設定します。

指標にタイプがない

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

  • 「no metadata found for metric name "{metric_name}"」

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

# TYPE {metric_name} <type>

特定の VictoriaMetrics のライブラリは、意図的にタイプ情報を破棄します。これらのライブラリは、Managed Service for Prometheus ではサポートされていません。

不明な型または二重書き込みの指標

次のエラーが表示された場合、指標が 2 回取り込まれている可能性があります。

  • 「invalid parameter "query": substitute queries failed: convert vector selector failed: mismatching label sets between matching metric types prometheus.googleapis.com/metric_name_foo/gauge and prometheus.googleapis.com/metric_name_foo/unknown」

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

プレーン カウンタ指標（たとえば、metric_name_foo の PromQL クエリ）のクエリの際に、データが表示されなかったり、データギャップが表示されることがある場合も、この問題が発生している可能性があります。これは、クエリに rate 関数（たとえば、rate(metric_name_foo[5m])）を追加した後に上記のエラーが表示された場合に確認できます。

これは通常、Managed Service for Prometheus コレクタを連携サーバーとして誤って構成することによって発生します。Managed Service for Prometheus を使用する場合、連携はサポートされません。連携で TYPE 情報が意図的に破棄されるため、連携を実装すると「不明」タイプの指標が生成されます。システムがすべての「不明」型の指標を 2 回送信する（ゲージとして 1 回、カウンタとして 1 回）ため、取り込まれたサンプルが 2 倍になります。

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

  • Managed Service for Prometheus との連携の使用を停止します。データを Monarch に送信する前にそれをロールアップすることでカーディナリティと費用を削減したい場合は、ローカル集約の構成をご覧ください。
  • DeleteMetricDescriptor の呼び出しによって、接尾辞「unknown」または「unknown:counter」で競合する指標を削除します。

時系列の競合

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

  • 「One or more TimeSeries could not be written: One or more points were written more frequently than the maximum sampling period configured for the metric.」
  • 「One or more TimeSeries could not be written: Points must be written in order. One or more of the points specified had an older end time than the most recent point.」

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

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

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

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

    この問題を解決するには、その原因となっているルールを削除します（labeldrop アクションを使用する指標の再ラベル付け構成が原因であることがよくあります）。すべての再ラベル付けルールをコメントアウトしてから、エラーが発生するまで 1 回に 1 つずつ復元することで、問題のあるルールを特定できます。

あまり一般的ではありませんが、5 秒未満のスクレイピング間隔が原因で時系列の競合が発生することもあります。Managed Service for Prometheus でサポートされる最小収集間隔は 5 秒です。

エラーも指標もない

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

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

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

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

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

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

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

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

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

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

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

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

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

  • 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 つとして表示されている場合は、マネージド コレクタがエクスポータを正常に取得しています。

ファイアウォール

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

同時編集に関するエラー

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