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

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

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」などの大文字小文字エラーがあることを意味する場合があります。
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 エラーの再試行

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

503 UNAVAILABLE: 問題が短期間しか継続しない条件または一過性の条件の場合に再試行が役立ちます。
429 RESOURCE_EXHAUSTED: t あたり n 回の呼び出しなど、時間単位の割り当てに従い長時間実行されるバックグラウンドジョブについて、一定の遅延後に、再試行が役立ちます。問題が短期間しか継続しない条件または一過性の条件の場合、またはボリュームベースの割り当てを使い果たした場合、再試行は役に立ちません。一過性の条件については、障害を許容することを検討してください。割り当てに関する問題については、割り当ての使用量を削減するか、割り当ての増加をリクエストすることを検討してください。

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

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

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

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

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

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

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

再試行中に待機できる時間、または試行回数を設定します。この制限を超過する場合は、サービスを利用できないことを考慮し、その条件を用途に合わせて適切に処理します。これにより、バックオフが切り捨てられ、どこかで再試行が停止します。
一時停止時間を徐々に長くしてリクエストを再試行し、再試行の頻度を減らします。リクエストが成功するか、指定した上限に達するまで、再試行してください。

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

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

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

最小遅延 = 1 秒 = 1,000 ミリ秒
初期バックオフ = 2 ミリ秒

再試行回数	延長遅延（ミリ秒）	再試行までの時間（ミリ秒）
0	2⁰ = 1	1001
1	2¹ = 2	1002
2	2² = 4	1004
3	2³ = 8	1008
4	2⁴ = 16	1016
…	…	…
n	2ⁿ	1000 + 2ⁿ

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

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

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