排解 Monitoring API 問題

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

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

一般 API 錯誤

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

404 NOT_FOUND 並顯示「在這個伺服器上找不到要求的網址」：網址的部分內容有誤。請比較該網址與方法參照頁面上顯示的方法網址。這個錯誤可能表示有拼字錯誤 (例如「project」而非「projects」) 或大小寫錯誤 (例如「TimeSeries」而非「timeSeries」)。
401 UNAUTHENTICATED 搭配「使用者未獲授權存取專案 (或指標)」：這個錯誤代碼通常表示授權問題，但也可能表示專案 ID 或指標類型名稱有誤。檢查拼字和大小寫。
400 INVALID_ARGUMENT 含有「欄位篩選器含有無效值」：請確認監控篩選器的拼字和格式是否正確。詳情請參閱「監控篩選器」。
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 次嘗試後或在花費的時間超過應用程式合理值時，停止重試週期。

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