排解 Monitoring API 問題

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

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

使用 API Explorer 進行除錯

API Explorer 是內建於 API 方法參考資料頁面中的小工具。可讓您填寫欄位來叫用方法,不必編寫程式碼。

如果您在方法叫用作業中遇到問題,請使用該方法參考資料頁面上的 API Explorer (「Try this API」) 小工具來偵錯。詳情請參閱 API Explorer

一般 API 錯誤

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

  • 404 NOT_FOUND 並顯示「在這個伺服器上找不到要求的網址」:網址的部分內容有誤。請比較該網址與方法參照頁面上顯示的方法網址。這個錯誤可能表示有拼字錯誤 (例如「project」而非「projects」) 或大小寫錯誤 (例如「TimeSeries」而非「timeSeries」)。

  • 401 UNAUTHENTICATED 搭配「使用者未獲授權存取專案 (或指標)」:這個錯誤代碼通常表示授權問題,但也可能表示專案 ID 或指標類型名稱有誤。檢查拼字和大小寫。

    如果您未使用 API 瀏覽器,請試著使用看看。如果 API 呼叫在 API Explorer 中運作,則在您發出 API 呼叫的環境中可能有授權問題。前往 API 管理工具頁面,確認專案已啟用 Monitoring API。

  • 400 INVALID_ARGUMENT 含有「欄位篩選器含有無效值」:請確認監控篩選器的拼字和格式是否正確。詳情請參閱「監控篩選器」。

  • 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),然後確認您是否獲得結果。逐一新增其他篩選器元件,建立要求。
  • 使用自訂指標時,請確認已指定定義指標的專案。

使用 timeSeries.list 方法時,資料可能會遺漏,原因如下:

  • 資料可能已過時。 詳情請參閱「資料保留」。

  • 資料可能尚未傳送至監控。詳情請參閱「指標資料的延遲時間」。

  • 間隔無效:

    • 確認結束時間是否正確。
    • 確認開始時間正確無誤,且早於結束時間。如果開始時間缺少或格式錯誤,API 會將開始時間設為結束時間。對於 GAUGE 指標,這個時間間隔只會比對開始和結束時間與間隔結束時間完全相符的點。對於跨時間間隔評估的 CUMULATIVEDELTA 指標,系統不會比對任何點。詳情請參閱「時間間隔」。

重試 API 錯誤

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

  • 503 UNAVAILABLE:如果問題是短暫或暫時性狀況,重試就很有用。
  • 429 RESOURCE_EXHAUSTED:重試在延遲後,對於具有時間限制配額的長時間執行背景工作 (例如每 tn 次呼叫) 很有用。如果問題是短暫或暫時性狀況,或是您已用盡以數量為準的配額,重試就沒有幫助。針對暫時性狀況,請考慮容許失敗。如有配額相關問題,請考慮減少配額用量或申請提高配額。

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

重試要求是否安全?

如果要求是冪等的,則可以放心重試。冪等動作是指任何狀態變更都不會依賴目前狀態的動作。例如:

  • 讀取 x 是冪等的,不會變更值。
  • x 設為 10 是冪等的;如果值不是 10,這可能會變更狀態,但目前的值不重要。此外,嘗試設定值的次數也不重要。
  • 增加 x具備冪等性;新值取決於目前的值。

以指數輪詢方式重試

實作重試要求的程式碼時,您不希望無限期地快速發出新要求。如果系統超載,這種做法就會導致問題。

請改用部分指數輪詢方法。如果要求因暫時性超載而失敗,而非真正無法使用,解決方法就是減少負載。部分指數輪詢的一般模式如下:

  • 請設定重試時願意等待的時間長度,或願意重試的次數。超過這個限制時,請考慮服務無法使用,並針對應用程式適當處理此情況。這就是讓後退截斷的原因;您會在某個時間點停止重試。

  • 重試要求時,請以愈來愈長的暫停時間減少重試頻率。重試,直到要求成功或達到您設定的上限為止。

    間隔通常會以重試次數的某個指數函式增加,這就是指數輪詢。

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

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

  • 最短延遲時間 = 1 秒 = 1000 毫秒
  • 初始輪詢時間 = 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 次嘗試後或在花費的時間超過應用程式合理值時,停止重試週期。

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