記錄指標疑難排解

本頁提供疑難排解資訊,說明如何在 Cloud Logging 中使用記錄指標時排解常見的問題。

無法查看或建立指標

記錄指標僅適用於單一 Google Cloud 專案,或專案內的 Google Cloud 記錄檔 bucket。您無法為其他資源 (例如帳單帳戶或機構) 建立以記錄為準的指標。 Google Cloud系統只會針對 Google Cloud 專案或 bucket 中收到的記錄檔計算記錄指標。

如要建立指標,您必須具備正確的 Identity and Access Management 權限。詳情請參閱「使用 IAM 控管存取權:記錄指標」。

指標遺漏記錄資料

記錄指標中遺漏資料有幾個可能的原因:

  • 新記錄項目可能與您指標的篩選器不符。記錄指標會從在建立指標後收到的相符記錄項目取得資料。記錄不會從之前的記錄項目對指標執行補充作業。

  • 新記錄項目可能不包含正確的欄位,或者資料可能不是分佈指標的正確擷取格式。請確認您的欄位名稱與規則運算式是否正確。

  • 您的指標計數可能會延遲。即使可計數的記錄項目顯示在 Logs Explorer 中,Cloud Monitoring 最多可能需要 10 分鐘,才會更新記錄指標。

  • 顯示的記錄項目可能會延遲計數,甚至根本不計數,因為這些記錄項目的時間戳記在過去或未來較遠的時間點。如果 Cloud Logging 收到的記錄項目時間超過過去 24 小時或未來 10 分鐘,系統就不會在記錄指標中計算這個記錄項目。

    系統會記錄遲到項目數,並將其納入記錄指標 logging.googleapis.com/logs_based_metrics_error_count

    範例:與記錄指標相符的記錄項目延遲送達。2020 年 2 月 20 日下午 2:30 開始,2020 年 2 月 21 日下午 2:45 結束。timestampreceivedTimestamp這個項目不會計入記錄指標。

  • 記錄指標是在可能計入的記錄項目抵達後建立。記錄指標會在記錄項目儲存在記錄值區時評估這些項目,不會評估儲存在 Logging 中的記錄項目。

  • 記錄指標的資料有缺漏。系統處理以記錄為準的指標資料時,無法保證每個指標資料點都會持續存在,因此出現部分資料缺口是正常現象。如果發生缺漏,通常是罕見且短暫的情況。不過,如果您有監控記錄指標的快訊政策,資料缺漏可能會導致誤報。您可以在警報政策中使用相關設定,降低這種可能性。

    示例:每五分鐘寫入一次「心跳」記錄項目,而記錄指標會計算「心跳」記錄項目的數量。警報政策會加總五分鐘間隔內的計數,並在總數小於一時通知您。如果時間序列缺少資料點,系統會注入合成值 (也就是最近樣本的副本,最有可能為零),然後評估條件。因此,即使只有一個資料點遺漏,總和值也可能為零,導致這項快訊政策傳送通知。

    為降低誤報風險,請將政策設為計算多個「心跳」記錄項目,而非僅計算一個。

Cloud Monitoring 中的資源類型為「未定義」

部分 Cloud Logging 受控資源類型不會直接對應至 Cloud Monitoring 受控資源類型。舉例來說,當您首次從記錄指標建立快訊政策或圖表時,可能會發現資源類型為「未定義」。

資源類型未定義。

受控資源類型會對應至 global 或 Cloud Monitoring 中的其他受控資源類型。請參閱「僅限記錄資源的對應項」,判斷需要選擇的受監控資源類型。

通知中的標籤未解析

您建立記錄指標,然後建立快訊政策來監控該記錄指標。在快訊政策的文件欄位中,您可以使用 ${log.extracted_label.KEY} 形式的變數參照擷取的標籤,其中 KEY 是您為擷取的標籤指定的名稱。通知中未解決標籤問題。

如要解決這個問題,請採取下列任一做法:

  • 從文件移除擷取的標籤內容。監控記錄指標的快訊政策無法從記錄項目中擷取資料。

  • 建立記錄型快訊。這些快訊政策可以從觸發快訊政策的記錄項目中擷取資料。

未建立事件或事件為誤報

如果快訊政策的對齊週期過短,您可能會收到誤報事件,或發生監控功能未根據記錄指標建立事件的情況。在下列情況中,您可能會遇到誤判結果:

  • 快訊政策使用「小於」邏輯。
  • 快訊政策是以分布指標的百分位數條件為準。
  • 指標資料有缺漏

記錄項目可能會延遲傳送至 Logging,因此可能發生誤報事件。舉例來說,在某些情況下,記錄欄位 timestampreceiveTimestamp 可能會有幾分鐘的差異。此外,當 Logging 將記錄儲存在記錄 bucket 中時,記錄項目產生和 Logging 接收記錄項目之間,會有固有的延遲。也就是說,在產生記錄項目後,Logging 可能要過一段時間,才能提供特定記錄項目的總數。因此,使用「小於」邏輯或以分配指標的百分位數條件為依據的警告政策,可能會產生誤報警告:因為系統尚未將所有記錄項目納入考量。

不過,記錄指標最終會保持一致,因為符合記錄指標的記錄項目可以傳送至 Logging,且 timestamp 遠早於或晚於記錄的 receiveTimestamp

也就是說,記錄指標在收到時間戳記相同的現有記錄項目後,仍可接收時間戳記較舊的記錄項目。因此必須更新指標值。

為確保即使是準時資料,通知也能保持準確,建議您將條件的對齊週期設為至少 10 分鐘。特別是,這個值應夠大,確保符合篩選條件的多個記錄項目都會計入。舉例來說,如果記錄指標會計算「心跳」記錄項目 (預計每 N 分鐘會出現一次),請將對齊週期設為 2N 分鐘或 10 分鐘,取較大者:

  • 如果您使用 Google Cloud 控制台,請使用「Rolling window」選單設定對齊週期。

  • 如果您使用 API,請使用條件的 aggregations.alignmentPeriod 欄位設定對齊週期。

指標有太多時間序列

指標中的時間序列數取決於標籤值的不同組合數。時間序列的數量稱為指標的基數,不得超過 30,000。

由於您可以為每個標籤值組合產生時間序列,因此如果有一或多個標籤的值數量較多,很容易就會超過 30,000 個時間序列。您想避免高基數指標。

指標的基數越高,指標就越可能遭到限制,某些資料點可能不會寫入到指標中。由於圖表必須處理的時間序列數變多,顯示指標的圖表載入速度也會變慢。您也可能會因查詢時間序列資料的 API 呼叫而產生費用;詳情請參閱 Cloud Monitoring 費用一文。

如要避免建立高基數指標:

  • 確認您的標籤欄位與擷取器規則運算式符合有限制基數的值。

    舉例來說,請勿在標籤中儲存大小、數量或時間長度。此外,請勿儲存網址、IP 位址或專屬 ID 等欄位,因為這些欄位可能會產生大量時間序列。

  • 避免擷取可能隨標籤值無限制變更的文字訊息。

  • 避免擷取無限制基數的數值。

  • 僅從已知基數的標籤擷取值;例如,具有一組已知值的狀態碼。

您可以根據這些系統記錄指標,評估新增或移除標籤對指標基數的影響:

檢查這些指標時,您可以依指標名稱進一步篩選結果。詳情請參閱選取指標:篩選

指標名稱無效

建立計數器或分佈指標時,請選擇在專案的記錄指標中不重複的指標名稱。 Google Cloud

指標名稱字串不得超過100 個字元,且只能包含下列字元:

  • AZ
  • az
  • 09
  • 特殊字元 _-.,+!*',()%\/

    正斜線字元 / 表示指標名稱元素階層,因此不得做為名稱的第一個字元。

指標值不正確

您發現記錄指標回報的值,有時與記錄瀏覽器回報的記錄項目數量不同。

如要盡量縮小差異,請採取下列行動:

  • 請確認應用程式不會傳送重複的記錄項目。如果記錄項目具有相同的 timestampinsertId,就會視為重複項目。記錄檔探索工具會自動隱藏重複的記錄檔項目。不過,記錄指標會計算符合指標篩選條件的每個記錄項目。

  • 請確認時間戳記在過去 24 小時內或未來 10 分鐘內時,記錄項目會傳送至 Cloud Logging。如果記錄項目的時間戳記不在這些界限內,記錄指標就不會計數。

您無法完全避免記錄重複。如果處理記錄項目時發生內部錯誤,Cloud Logging 會啟動重試程序。重試程序可能會導致記錄項目重複。 如果記錄項目重複,記錄指標的值可能會過大,因為這類指標會計算符合指標篩選條件的每個記錄項目。

標籤值會遭到截斷

使用者定義的標籤值不得超過 1,024 個位元組。

無法刪除自訂記錄指標

您嘗試使用 Google Cloud 控制台刪除自訂的記錄檔指標。刪除要求失敗,刪除對話方塊會顯示錯誤訊息 There is an unknown error while executing this operation

如要解決這個問題,請嘗試下列方法:

  • 在 Google Cloud 控制台中重新整理「記錄指標」頁面。由於內部時間問題,系統可能會顯示錯誤訊息。

  • 找出並刪除監控記錄指標的任何快訊政策。確認警告政策未監控記錄指標後,即可刪除該指標。如果記錄指標受到快訊政策監控,就無法刪除。