このガイドでは、Monitoring API を使用する際発生する可能性がある問題のいくつかを説明します。
Monitoring API は 一連の Cloud APIs の 1 つです。これらの API は、共通のエラーコード群を共有します。Cloud APIs で定義されたエラーコードとそれらのエラーの処理に関する一般的な推奨事項については、エラーの処理をご覧ください。
デバッギング用の 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」）があることを意味します。401 UNAUTHENTICATED（ユーザーには、プロジェクト（または指標）にアクセスする権限がありません）: このエラーコードは通常、承認の問題を示していますが、プロジェクト ID または指標タイプ名にエラーがあることを意味します。スペルと大文字アルファベットの使用方法を確認します。API Explorer を使用していない場合は、それを使ってみてください。API 呼び出しが API Explorer で動作する場合、API 呼び出しを行っている環境で承認の問題が発生している可能性があります。API マネージャー ページに移動して、Monitoring API がプロジェクトで有効になっていることを確認します。
400 INVALID_ARGUMENT（フィールド フィルターが無効な値でした）: モニタリング フィルタのスペルと書式設定を確認します。詳細については、モニタリング フィルタをご覧ください。400 INVALID_ARGUMENT（リクエストにフィールド interval.endTime が欠落していました）: 終了時間が存在しない場合、または存在しても適切にフォーマットされていない場合、このメッセージが表示されます。API Explorer を使用している場合は、時間フィールドの値を引用しないでください。有効な時間仕様の例を次に示します。
2024-05-11T01:23:45Z 2024-05-11T01:23:45.678Z 2024-05-11T01:23:45.678+05:00 2024-05-11T01:23:45.678-04:30
不足している結果
API 呼び出しがステータス コード 200 と空のレスポンスを返した場合は、次の点を確認してください。
- 呼び出しにフィルタを使用している場合、フィルタに一致するものがない可能性があります。フィルタ一致では、大文字と小文字が区別されます。フィルタの問題を解決するには、
metric.typeなど、1 つのみのフィルタ コンポーネントを指定してスタートし、結果を得られることを確認します。他のフィルタ コンポーネントを 1 つずつ追加して、リクエストを作成します。
- カスタム指標を使用する場合は、指標を定義するプロジェクトが指定されていることを確認します。
timeSeries.list メソッドを使用すると、データポイントが欠落する理由がいくつかあります。
データが古くなっている可能性があります。詳細については、データの保持をご覧ください。
データがまだ Monitoring に伝播されていない可能性があります。詳細については、指標データのレイテンシをご覧ください。
間隔が無効です。
- 終了時間が正しいことを確認します。
- 開始時間が正しく、終了時間より前に設定されていることを確認します。開始時間が設定されていない場合や、形式が誤っている場合は、API によって開始時刻が終了時刻に設定されます。
GAUGE指標の場合、この時間間隔は開始時刻と終了時刻が間隔の終了時刻と完全に一致するポイントのみに一致します。期間全体を測定するCUMULATIVE指標やDELTA指標の場合、ポイントは一致しません。詳細については、時間間隔をご覧ください。
API エラーの再試行
以下の 2 つ Cloud APIs のエラーコードは、リクエストの再試行が有用な状況であることを示します。
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 の指数バックオフの記事をご覧ください。