排解 Monitoring API 問題

本指南說明使用 Monitoring API 時可能發生的問題。

Monitoring API 是 Cloud API 的其中一組。這些 API 共用一組錯誤代碼。如需 Cloud API 定義的錯誤代碼清單，以及處理錯誤的一般建議，請參閱「處理錯誤」。

一般 API 錯誤

以下列出您可能會在 API 呼叫中看到的 Monitoring API 錯誤和訊息：

404 NOT_FOUND，並顯示「在這個伺服器上找不到您要求的網址」：網址的某個部分有誤。將網址與方法參考頁面顯示的方法網址進行比較。這項錯誤可能表示有拼字錯誤 (例如「project」而非「projects」)，或是大小寫錯誤 (例如「TimeSeries」而非「timeSeries」)。
401 UNAUTHENTICATED with「User is not authorized to access the project(or metric)」：這個錯誤代碼通常表示授權問題，但也可能表示專案 ID 或指標類型名稱有誤。確認拼字和大小寫是否正確。
400 INVALID_ARGUMENT，並顯示「Field filter had an invalid value」(欄位篩選器值無效) 訊息：請檢查監控篩選器的拼字和格式。詳情請參閱「監控篩選器」。
400 INVALID_ARGUMENT「Request was missing field interval.endTime」：如果缺少結束時間，或結束時間格式不正確，就會看到這則訊息。

以下是有效時間規格的範例：
```
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)，並確認是否能取得結果。逐一新增其他篩選器元件，建構要求。

使用 timeSeries.list 方法時，資料點可能會遺漏，原因如下：

資料可能已過時。詳情請參閱「資料保留」。
資料可能尚未傳播至監控服務。詳情請參閱「指標資料的延遲時間」。
間隔無效：
- 確認結束時間是否正確。
- 確認開始時間正確無誤，且早於結束時間。如果缺少開始時間或格式錯誤，API 會將開始時間設為結束時間。如果是 GAUGE 指標，這個時間間隔只會比對開始和結束時間完全符合間隔結束時間的點。如果是 CUMULATIVE 或 DELTA 指標 (用於評估時間間隔)，則不會比對任何點。詳情請參閱「時間間隔」。

有兩個 Cloud API 錯誤代碼指出可能需要重試要求的情況：

503 UNAVAILABLE：如果問題是短暫或暫時性的狀況，重試就很有用。
429 RESOURCE_EXHAUSTED：對於有時間配額的長時間背景工作 (例如每 t 秒 n 次呼叫)，延遲後重試很有用。如果問題是短暫或暫時性狀況，或是您已用盡以量為準的配額，重試就沒有用。如果是暫時性狀況，請考慮容許失敗。如要解決配額相關問題，請考慮減少配額用量或申請提高配額。

編寫可能會重試要求的程式碼時，請先確認要求是否可安全重試。

如果要求是等冪，可以放心重試。等冪動作是指狀態的任何變更都不取決於目前狀態。例如：

實作程式碼來重試要求時，您不希望無限期快速發出新要求。如果系統負載過重，這種做法會加劇問題。

請改用部分指數輪詢方法。如果要求失敗是因為暫時超載，而非真正無法使用，解決方法是降低負載。部分指數輪詢遵循下列一般模式：

決定重試時願意等待的時間長度，或願意嘗試的次數。超過這項限制時，請將服務視為無法使用，並為應用程式適當處理該情況。這會導致退避遭到截斷，也就是在某個時間點停止重試。
請重試要求，並逐漸延長暫停時間，以減少重試頻率。請重試，直到要求成功或達到您設定的限制為止。

間隔通常會根據重試次數的冪次，以某個函式增加，因此稱為「指數輪詢」。

實作指數輪詢的方法有很多種。以下範例會將遞增的輪詢延遲時間新增至 1000 毫秒的最小延遲時間。初始暫停延遲時間為 2 毫秒，每次嘗試都會增加至 2^retry_count 毫秒。

下表顯示使用初始值的重試間隔：

您可以停止重試週期，方法是在 n 次嘗試後停止，或是當所花時間超過應用程式的合理值時停止。

詳情請參閱維基百科的「指數輪詢」一文。