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「Field filter had an invalid value」: モニタリングフィルタのスペルと書式設定を確認します。詳細については、モニタリングフィルタを参照してください。
400 INVALID_ARGUMENT「Request was missing field 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 回の呼び出しなど、時間単位の割り当てに従い長時間実行されるバックグラウンドジョブについて、一定の遅延後に、再試行が役立ちます。問題が短期間しか継続しない条件または一過性の条件の場合、またはボリュームベースの割り当てを使い果たした場合、再試行は役に立ちません。一過性の条件については、障害を許容することを検討してください。割り当て関連の問題については、割り当て使用量を減らすか、割り当ての増加をリクエストすることを検討してください。

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

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

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

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

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

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

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

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

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

指数バックオフを実装する方法はさまざまです。以下に、最小遅延である 1,000 ミリ秒にバックオフ遅延の延長分を追加する例を示します。初期バックオフ遅延は 2 ミリ秒で、試行のたびに 2^retry_count ミリ秒まで延長されます。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ⁿn	1000 + 2ⁿn

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

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

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