Monitoring API のトラブル シューティング

このガイドでは、Monitoring API V3 を使用する際発生する可能性がある問題のいくつかを説明します。

Monitoring API は 一連の Cloud API の 1 つです。 これらの API は、共通のエラーコード群を共有します。Cloud API で定義されたエラーコードとそれらのエラーの処理に関する一般的な推奨事項については、エラーの処理をご覧ください。

API Explorer を使用してデバッグする

API Explorer は、API メソッドのリファレンス ページに組み込まれているウィジェットです。フィールドに入力することで、メソッドを呼び出すことができます。コードを記述する必要はありません。

メソッドの呼び出しで問題が発生した場合は、そのメソッドのリファレンス ページにある API Explorer(この API を試す)ウィジェットを使用して問題をデバッグしてください。詳細については、API Explorer をご覧ください。

一般的な API エラー

API 呼び出しで発生する可能性がある Monitoring API のエラーとメッセージの一部を次に示します。

  • 404 NOT_FOUND

    • 「リクエストされた URL はこのサーバーで見つかりませんでした」: URL の一部が正しくありません。メソッドのリファレンス ページに表示されている URL をメソッドのと URL を比較してください。 スペルミス(「projects」の代わりに「project」)と大文字にするルールの問題(「TimeSeries」の代わりに「timeSeries」)を確認してください。

    • 「projects/PROJECT_ID はワークスペースではありません」: これは、使用している Google Cloud プロジェクトが Cloud Monitoring ワークスペースに含まれていないことを意味します。ワークスペースは Google Cloud プロジェクトからのモニタリング情報を整理するために使用します。ほとんどの Monitoring API メソッドでは、プロジェクトがワークスペースの一部である必要があります。詳細については、ワークスペースをご覧ください。

  • 401 UNAUTHENTICATED「ユーザーには、プロジェクト(または指標)にアクセスする権限がありません」: これは許可の問題の可能性もありますが、単にプロジェクトの ID または指標タイプ名のスペルを間違えているだけの場合もあります。スペルと大文字にするルールを確認してください。

    API Explorer を使用していない場合は、お試しください。API Explorer で API 呼び出しが動作する場合は、API 呼び出しに使用している環境に承認の問題が存在する可能性があります。API マネージャ ページ内で Monitoring API v3 がプロジェクトで有効になっていることを確認します。

  • 400 INVALID_ARGUMENT「フィールド フィルタに無効な値が設定されていました」: モニタリング フィルタのスペルと書式をご確認ください。詳細については、モニタリング フィルタを参照してください。

  • 400 INVALID_ARGUMENT「リクエストには interval.endTime フィールドがありませんでした」: 終了時刻が存在しない場合、または存在しても適切にフォーマットされていない場合、このメッセージが表示されます。API Explorer を使用している場合は、時間フィールドの値を引用符で囲まないでください。

    ここで正しい時刻指定の例をいくつか示します。

    2016-05-11T01:23:45Z
    2016-05-11T01:23:45.678Z
    2016-05-11T01:23:45.678+05:00
    2016-05-11T01:23:45.678-04:30
    

不足している結果

API 呼び出しがステータス コード 200 と空の応答を返した場合、いくつか可能性があります。

  • 呼び出しがフィルタを使用している場合、フィルタに何も一致していない可能性があります。フィルタ一致では、大文字と小文字が区別されます。フィルタの問題を解決するには、metric.type など、1 つのフィルタのみのコンポーネントを指定してスタートし、結果を得られるかどうか確認します。他のフィルタ コンポーネントを 1 つずつ追加して、リクエストを作成します。

  • カスタム指標を使用している場合は、カスタム指標が定義されているプロジェクトを指定していない可能性があります。

timeSeries.list を使用して時系列データを取得していて、データポイントの一部が欠落しているように見える場合は、別途次の原因をご確認ください。

  • データが数週間以上前のものであれば、有効期限が切れている可能性があります。 詳細は、データ保持をご覧ください。

  • データが書き込まれたばかりの場合は、まだ Monitoring に入っていない可能性があります。 詳しくは、指標データのレイテンシをご覧ください。

  • 時間間隔を正しく指定したことを確認します。

    • 終了時刻が正しいことを確認します。
    • 開始時刻が正確で、終了時刻より前に設定されていることを確認します。 開始時刻が設定されていなかったり、形式が誤っていたりすると、開始時刻がデフォルトで終了時刻の値になり、時間間隔は、開始時刻と終了時刻が正確に時間間隔と一致する時点のみと一致します(これはある時点を測定する GAUGE 指標に対して有効ですが、時間間隔全体を測定する CUMULATIVE 指標または DELTA 指標に対しては有効ではありません)。詳細については、時間間隔をご覧ください。

API エラーの再試行

以下に示す Cloud API の 2 つのエラーコードは、リクエストの再試行に役立つ可能性のある状況を示します。

  • 503 UNAVAILABLE: 問題が短期間しか継続しない条件または一過性の条件の場合に再試行が役立ちます。
  • 429 RESOURCE_EXHAUSTED: たとえば t 秒あたり n 回しか呼び出しできない場合、時間単位での割り当てに従い長時間実行されるバックグラウンド ジョブについてのみ、一定の遅延時間後に再試行が役立ちます。ただし、容量単位の割り当てを使い果たした場合、再試行は役立ちません。割り当てを増やしてもらう必要があります。

リクエストを再試行できるコードを記述するときは、まずそのリクエストを安全に再試行できることを確認します。

このリクエストは再試行できますか?

リクエストがべき等である場合は、再試行しても安全です。べき等アクションは、状態の変化が現在の状態に依存しないアクションです。以下に例を示します。

  • x の読み取りがべき等です。値は変更されません。
  • x の 10 への設定がべき等です。値がまだ 10 でない場合は状態が変わる可能性がありますが、現在の値が何かは重要ではありません。また、その値の設定を何回試みるかも重要ではありません。
  • x の引き上げはべき等ではありません。新しい値は、現在の値に依存します。

指数バックオフを使用して再試行する

リクエストを再試行するコードを実装する場合、新しいリクエストを無期限に発行することはおすすめしません。システムに負荷が掛かりすぎると、問題が起こります。

代わりに、切り捨て型指数バックオフを実施してください。実施にシステムが稼働停止しているためではなく一時的な過負荷によりリクエストが失敗する場合は、負荷を軽減することで問題を解決できます。切り捨て型指数バックオフは、次の一般的なパターンに従って行われます。

  • 再試行中に待機できる時間、または試行回数を設定します。この制限を超過する場合は、サービスを利用できないことを考慮し、その条件を用途に合わせて適切に処理します。これにより、バックオフが切り捨てられ、どこかで再試行が停止します。

  • 一時停止時間を徐々に長くしてリクエストを再試行し、再試行の頻度を減らします。リクエストが成功するか、指定した上限に達するまで、再試行してください。

    間隔は、一般的に再試行回数のべき乗の関数により延長され、指数バックオフになります。

指数バックオフを実装する方法はさまざまです。以下に、最小遅延である 1,000 ミリ秒にバックオフ遅延の延長分を追加する簡単な例を示します。初期バックオフ遅延は 2 ミリ秒で、試行のたびに 2retry_count ミリ秒まで延長されます。

次の表に、初期値を使用した再試行間隔を示します。

  • 最小遅延 = 1 秒 = 1,000 ミリ秒
  • 初期バックオフ = 2 ミリ秒
再試行回数 延長遅延(ミリ秒) 再試行までの時間(ミリ秒)
0 20 = 1 1001
1 21 = 2 1002
2 22 = 4 1004
3 23 = 8 1008
4 24 = 16 1016
n 2n 1000 + 2n

再試行サイクルを短縮するには、n 回の試行の後、または実行時間が用途に適した値を超えた場合に停止します。

詳細については、Wikipedia の指数バックオフの記事をご覧ください。