排解 Managed Service for Prometheus 的疑難問題

本文說明使用 Google Cloud Managed Service for Prometheus 時可能遇到的問題，並提供診斷及解決問題的相關資訊。

您已設定 Managed Service for Prometheus，但 Grafana 或 Prometheus UI 中未顯示任何指標資料。整體來說，原因可能是下列任一情況：

• 查詢端發生問題，導致無法讀取資料。查詢端問題通常是因為讀取資料的服務帳戶權限不正確，或是 Grafana 設定錯誤所致。

• 擷取端發生問題，因此未傳送任何資料。 服務帳戶、收集器或規則評估的設定問題，都可能導致擷取端發生問題。

如要判斷問題是出在擷取端還是查詢端，請在 Google Cloud 控制台中使用 Metrics Explorer 的 PromQL 分頁標籤查詢資料。這個頁面保證不會有任何讀取權限或 Grafana 設定問題。

如要查看這個頁面，請按照下列步驟操作：

1. 使用 Google Cloud 控制台專案挑選器，選取未顯示資料的專案。

2. 前往 Google Cloud 控制台的 「Metrics Explorer」頁面：

   前往 Metrics Explorer

   如果您是使用搜尋列尋找這個頁面，請選取子標題為「Monitoring」的結果。

3. 在查詢建構工具窗格的工具列中，選取名稱為  MQL 或  PromQL 的按鈕。

4. 確認已在「Language」(語言) 切換按鈕中選取「PromQL」。語言切換按鈕位於同一工具列，可供你設定查詢格式。

5. 在編輯器中輸入以下查詢，然後點選「執行查詢」：

   up
   

如果查詢 up 指標並看到結果，問題就出在查詢端。如要瞭解如何解決這些問題，請參閱「查詢端問題」。

如果查詢 up 指標時沒有看到任何結果，表示問題出在擷取端。如要瞭解如何解決這些問題，請參閱「擷取端問題」一文。

防火牆也可能導致擷取和查詢問題；詳情請參閱「防火牆」。

Cloud Monitoring 的「指標管理」頁面提供相關資訊，協助您控管可計費指標的支出金額，同時不影響可觀測性。「指標管理」頁面會回報下列資訊：

• 以位元組和樣本為準的計費方式，在指標網域和個別指標的擷取量。
• 指標的標籤和基數相關資料。
• 每個指標的讀取次數。
• 在警告政策和自訂資訊主頁中使用指標。
• 指標寫入錯誤率。

您也可以使用「指標管理」頁面排除不必要的指標，藉此省下擷取這些指標的費用。

如要查看「指標管理」頁面，請按照下列步驟操作：

1. 前往 Google Cloud 控制台的 「指標管理」頁面：

   前往「指標管理」

   如果您是使用搜尋列尋找這個頁面，請選取子標題為「Monitoring」的結果。

2. 在工具列中選取時間範圍。根據預設，「指標管理」頁面會顯示前一天收集到的指標資訊。

如要進一步瞭解「指標管理」頁面，請參閱「查看及管理指標用量」。

查詢端問題

大多數查詢端問題的原因如下：

• 服務帳戶的權限或憑證不正確。
• 如果叢集已啟用這項功能，則可能是 GKE 適用的工作負載身分聯盟設定錯誤。詳情請參閱「設定 GKE 適用的 Workload Identity Federation 服務帳戶」。

請先執行下列操作：

• 請仔細檢查設定，並參照查詢設定操作說明。

• 如果您使用 Workload Identity Federation for GKE，請執行下列操作，確認服務帳戶具備正確的權限：

  1. 前往 Google Cloud 控制台的「IAM」(身分與存取權管理) 頁面：

     前往 IAM

     如果您是使用搜尋列尋找這個頁面，請選取子標題為「IAM & Admin」(IAM 與管理) 的結果。

  2. 在主體清單中找出服務帳戶名稱。確認服務帳戶名稱的拼寫方式正確無誤。然後按一下「Edit」(編輯)。

  3. 選取「角色」欄位，然後按一下「目前使用中」並搜尋「監控檢視者」角色。如果服務帳戶沒有這個角色，請立即新增。

如果問題仍未解決，請參考下列可能原因：

密鑰設定有誤或輸入錯誤

如果看到下列任一訊息，表示您可能遺漏或誤打密鑰：

• Grafana 或 Prometheus UI 中出現下列其中一個「禁止」錯誤：

  • 「警告：擷取伺服器時間時，出現非預期的回應狀態：Forbidden」
  • 「Warning: Error fetching metrics list: Unexpected response status when fetching metric names: Forbidden」

• 記錄檔中出現類似這樣的訊息：
  「cannot read credentials file: open /gmp/key.json: no such file or directory」(無法讀取憑證檔案：開啟 /gmp/key.json 時發生錯誤，沒有這個檔案或目錄)

如果您使用資料來源同步器驗證及設定 Grafana，請嘗試下列方法解決這些錯誤：

1. 請確認您已選擇正確的 Grafana API 端點、Grafana 資料來源 UID 和 Grafana API 權杖。您可以執行 kubectl describe cronjob datasource-syncer 指令，檢查 CronJob 中的變數。

2. 確認您已將資料來源同步器的專案 ID 設為與服務帳戶具有憑證的指標範圍或專案相同。

3. 確認 Grafana 服務帳戶具有「管理員」角色，且 API 權杖未過期。

4. 確認服務帳戶是否具備所選專案 ID 的監控檢視者角色。

5. 執行 kubectl logs job.batch/datasource-syncer-init，確認資料來源同步器作業的記錄中沒有錯誤。套用 datasource-syncer.yaml 檔案後，請立即執行這項指令。

6. 如果使用 GKE 的 Workload Identity 聯盟，請確認您未誤植帳戶金鑰或憑證，並確認已將其繫結至正確的命名空間。

如果您使用舊版前端 UI Proxy，請嘗試下列方法解決這些錯誤：

1. 確認您已將前端 UI 的專案 ID 設為與服務帳戶具有憑證的指標範圍或專案相同。

2. 確認您為任何--query.project-id標記指定的專案 ID。

3. 確認服務帳戶是否具備所選專案 ID 的監控檢視者角色。

4. 確認您在部署前端 UI 時已設定正確的專案 ID，且未將其設為字串常值 PROJECT_ID。

5. 如果使用 Workload Identity，請確認您未誤植帳戶金鑰或憑證，並確認已將其繫結至正確的命名空間。

6. 如果掛接自己的密鑰，請確認密鑰存在：

   kubectl get secret gmp-test-sa -o json | jq '.data | keys'
   

7. 確認密鑰已正確掛接：

   kubectl get deploy frontend -o json | jq .spec.template.spec.volumes
   
   kubectl get deploy frontend -o json | jq .spec.template.spec.containers[].volumeMounts
   

8. 確認密鑰已正確傳遞至容器：

   kubectl get deploy frontend -o json | jq .spec.template.spec.containers[].args
   

Grafana 的 HTTP 方法不正確

如果 Grafana 顯示下列 API 錯誤，表示 Grafana 設定為傳送 POST 要求，而非 GET 要求：

• "{"status":"error","errorType":"bad_data","error":"no match[] parameter provided"}%"

如要解決這個問題，請按照「設定資料來源」一文中的操作說明，將 Grafana 設為使用 GET 要求。

大型或長時間執行的查詢逾時

如果在 Grafana 中看到下列錯誤訊息，表示預設查詢逾時時間過短：

• 「Post "http://frontend.NAMESPACE_NAME.svc:9090/api/v1/query_range": net/http: timeout awaiting response headers」

Managed Service for Prometheus 的查詢逾時時間為 120 秒，而 Grafana 預設為 30 秒。如要修正這個問題，請按照「設定資料來源」中的操作說明，將 Grafana 中的逾時時間調高至 120 秒。

標籤驗證錯誤

如果在 Grafana 中看到下列任一錯誤，表示您可能使用了不支援的端點：

• 「Validation: labels other than name are not supported yet」(驗證：目前不支援 name 以外的標籤)
• 「範本化 [工作]：更新選項時發生錯誤：目前尚不支援 name 以外的標籤。」

Managed Service for Prometheus 僅支援 __name__ 標籤的 /api/v1/$label/values 端點。因此，在 Grafana 中使用 label_values($label) 變數的查詢會失敗。

請改用 label_values($metric, $label) 表單。建議使用這項查詢，因為它會依指標限制傳回的標籤值，避免擷取與資訊主頁內容無關的值。這項查詢會呼叫 Prometheus 的支援端點。

如要進一步瞭解支援的端點，請參閱 API 相容性。

超過配額

如果看到下列錯誤，表示您已超出 Cloud Monitoring API 的讀取配額：

• 「429: RESOURCE_EXHAUSTED: Quota exceeded for quota metric 'Time series queries ' and limit 'Time series queries per minute' of service 'monitoring.googleapis.com' for consumer 'project_number:...'」。

如要解決這個問題，請提交要求，提高 Monitoring API 的讀取配額。如需協助，請與Google Cloud 支援團隊聯絡。如要進一步瞭解配額，請參閱 Cloud Quotas 說明文件。

多項專案的指標

如要查看多個 Google Cloud 專案的指標，不必設定多個資料來源同步器，也不必在 Grafana 中建立多個資料來源。

請改為在一個Google Cloud 專案 (即範圍界定專案) 中建立 Cloud Monitoring 指標範圍，其中包含您要監控的專案。使用限定範圍專案設定 Grafana 資料來源時，您就能存取指標範圍內所有專案的資料。詳情請參閱「查詢和指標範圍」。

未指定受監控的資源類型

如果看到下列錯誤，表示使用 PromQL 查詢Google Cloud 系統指標時，需要指定受監控資源類型：

• 「metric is configured to be used with more than one monitored resource type; series selector must specify a label matcher on monitored resource name」

您可以透過 monitored_resource 標籤篩選，指定受監控的資源類型。如要進一步瞭解如何識別及選擇有效的受監控資源類型，請參閱「指定受監控資源類型」。

收集器 UI 和 Google Cloud 控制台的計數器、直方圖和摘要原始值不相符

查詢累計 Prometheus 指標 (包括計數器、直方圖和摘要) 的原始值時，您可能會發現本機收集器 Prometheus UI 和 Google Cloud Google Cloud 控制台中的值有所差異。這是正常現象。

Monarch 需要開始時間戳記，但 Prometheus 沒有開始時間戳記。Managed Service for Prometheus 會略過任何時間序列中第一個擷取的點，並將其轉換為開始時間戳記，藉此產生開始時間戳記。後續點的值會減去初始跳過點的值，確保比率正確。這會導致這些點的原始值持續不足。

收集器 UI 中的數字與Google Cloud 控制台中的數字差異，等於收集器 UI 中記錄的第一個值，這是預期行為，因為系統會略過該初始值，並從後續點減去該值。

這是可接受的，因為不需要查詢累計指標的原始值；所有實用查詢都需要 rate() 函式或類似函式，在這種情況下，兩個 UI 在任何時間範圍內的差異都相同。累計指標只會增加，因此您無法對原始查詢設定快訊，因為時間序列只會達到一次門檻。所有實用快訊和圖表都會查看值的變化或變化率。

收集器只會在本地保留約 10 分鐘的資料。如果重設作業發生在 10 分鐘的範圍內，原始累計值也可能出現差異。如要排除這種可能性，請在比較收集器 UI 與 Google Cloud 控制台時，只設定 10 分鐘的查詢回溯期。

如果應用程式有多個工作執行緒，且每個執行緒都有 /metrics 端點，也可能導致資料不一致。如果應用程式啟動多個執行緒，您必須將 Prometheus 用戶端程式庫設為多程序模式。詳情請參閱 Prometheus Python 用戶端程式庫中的多進程模式使用說明文件。

缺少計數器資料或直方圖損毀

如果查詢一般計數器指標 (例如 metric_name_foo 的 PromQL 查詢) 時沒有資料或出現資料缺口，就是最常見的信號。如果查詢中加入 rate 函式後 (例如 rate(metric_name_foo[5m]))，資料就會顯示，即可確認問題。

您也可能會發現，在 Cloud Monitoring 中，擷取的樣本數大幅增加，但擷取量並未出現重大變化，或是建立的新指標帶有「unknown」或「unknown:counter」後置字元。

您可能也會發現直方圖作業 (例如 quantile() 函式) 無法正常運作。

如果收集指標時沒有 Prometheus 指標 TYPE，就會發生這些問題。由於 Monarch 是強型別，Managed Service for Prometheus 會將未輸入型別的指標加上「unknown」後置字串，並擷取兩次，一次是量規，一次是計數器。查詢引擎接著會根據您使用的查詢函式，選擇是否查詢基礎計量表或計數器指標。

雖然這項啟發式方法通常運作良好，但查詢原始「unknown:counter」指標時，可能會導致奇怪的結果等問題。此外，由於直方圖是 Monarch 中的特定型別物件，因此將三項必要直方圖指標做為個別計數器指標擷取時，直方圖函式將無法運作。由於系統會擷取兩次「不明」類型的指標，因此如果未設定 TYPE，擷取的樣本就會加倍。

TYPE 可能未設定的常見原因包括：

• 不小心將 Managed Service for Prometheus 收集器設定為同盟伺服器。使用 Managed Service for Prometheus 時，系統不支援同盟。由於聯邦會刻意捨棄 TYPE 資訊，因此實作聯邦會導致「不明」類型的指標。
• 在擷取管道的任何時間點使用 Prometheus Remote Write。這個通訊協定也會刻意捨棄 TYPE 資訊。
• 使用會修改指標名稱的重新標記規則。這會導致重新命名的指標與原始指標名稱相關聯的 TYPE 資訊取消關聯。
• 匯出工具未針對每個指標發出 TYPE。
• 暫時性問題：收集器首次啟動時，TYPE 會遭到捨棄。

如要解決這個問題，請按照下列步驟操作：

• 停止搭配使用同盟與 Managed Service for Prometheus。如要在將資料傳送至 Monarch 前「匯總」資料，藉此降低基數和成本，請參閱「設定本機匯總」。
• 停止在收集路徑中使用 Prometheus Remote Write。
• 前往 /metrics 端點，確認每個指標都有 # TYPE 欄位。
• 刪除會修改指標名稱的任何重新標記規則。
• 刪除任何帶有「unknown」或「unknown:counter」後置字串的衝突指標，方法是呼叫 DeleteMetricDescriptor。
• 或者，一律使用 rate 或其他計數器處理函式查詢計數器。

您也可以在「指標管理」中建立指標排除規則，使用規則運算式 prometheus.googleapis.com/.+/unknown.*，防止系統擷取任何以「unknown」為後置字串的指標。如果未先修正根本問題就安裝這項規則，可能會導致系統無法擷取所需的指標資料。

Pod 重新啟動後，Grafana 資料不會保留

如果 Pod 重新啟動後，資料似乎從 Grafana 消失，但 Cloud Monitoring 中仍可看到資料，表示您使用 Grafana 查詢的是本機 Prometheus 執行個體，而非 Managed Service for Prometheus。

如要瞭解如何設定 Grafana，將受管理服務做為資料來源，請參閱 Grafana。

查詢或快訊規則結果不一致，但系統會自動修正

您可能會發現某種模式，即最近時間範圍內的查詢 (例如記錄或快訊規則執行的查詢) 會傳回無法解釋的資料尖峰。在 Grafana 或 Metrics Explorer 中執行查詢來調查尖峰時，您可能會發現尖峰已消失，資料也恢復正常。

如果符合下列任一情況，這種情形可能會更常發生：

• 您持續並行執行許多非常相似的查詢，可能使用了規則。這些查詢可能只差一個屬性。舉例來說，您可能正在執行 50 項記錄規則，這些規則只在篩選器 VALUE 的 {foo="VALUE"} VALUE 值不同，或只在 rate 函式的 [duration] 值不同。
• 您正在執行 time=now 的查詢，且沒有緩衝區。
• 您正在執行即時查詢，例如快訊或記錄規則。如果您使用記錄規則，可能會發現儲存的輸出內容有尖峰，但對原始資料執行查詢時找不到尖峰。
• 您正在查詢兩項指標，以建立比率。當分子或分母查詢中的時間序列計數偏低時，尖峰會更明顯。
• 指標資料會儲存在較大的 Google Cloud 區域，例如 us-central1或 us-east4。

這類查詢暫時暴增的原因可能如下：

• (最常見的原因) 類似的平行查詢都要求從同一組 Monarch 節點取得資料，導致每個節點的記憶體用量總計偏高。當 Monarch 在雲端區域中擁有足夠的可用資源時，您的查詢就會正常運作。當 Monarch 雲端區域的資源不足時，每個節點都會節流查詢，優先節流在每個節點上耗用最多記憶體的使用者。Monarch 資源充足後，查詢就會恢復運作。這些查詢可能是從 Sloth 等工具自動產生的 SLI。
• 您有延遲抵達的資料，且查詢無法容許這種情況。新寫入的資料大約需要 3 到 7 秒才能查詢，不包括網路延遲，以及環境中資源壓力造成的任何延遲。如果查詢未建立延遲或偏移，以因應資料延遲，您可能會在只有部分資料的期間進行查詢。資料送達後，查詢結果就會正常顯示。
• 在不同副本中儲存資料時，Monarch 可能會出現些微不一致的情況。查詢引擎會嘗試挑選「最佳品質」的副本，但如果不同查詢挑選的副本資料集略有不同，查詢結果可能會略有差異。這是系統的預期行為，您的快訊應能容許這些微小的差異。
• 整個 Monarch 區域可能會暫時無法使用。如果無法連線至某個地區，查詢引擎會將該地區視為不存在。該區域開放使用後，查詢結果仍會傳回該區域的資料。

為因應這些可能的原因，請確保查詢、規則和快訊遵循下列最佳做法：

• 將類似的規則和快訊整合成單一規則，並依標籤匯總，不必為標籤值的每個排列組合設定個別規則。如果是快訊規則，您可以使用以標籤為準的通知，從匯總規則傳送快訊，不必為每個快訊設定個別的傳送規則。

  舉例來說，如果您有值為 bar、baz 和 qux 的標籤 foo，請針對該標籤匯總單一規則，並視需要篩選您關心的標籤值 (例如 sum by (foo) metric{foo=~"bar|baz|qux"})，而不是為每個標籤值設定個別規則 (一個規則的查詢為 sum(metric{foo="bar"})，一個規則的查詢為 sum(metric{foo="baz"})，一個規則的查詢為 sum(metric{foo="qux"}))。

  如果指標有 2 個標籤，每個標籤有 50 個值，且您為每個標籤值組合設定個別規則，而規則查詢是比率，則每個週期您會啟動 50 x 50 x 2 = 5,000 個並行 Monarch 查詢，每個查詢都會命中同一組 Monarch 節點。總體而言，這 5,000 個並行查詢會耗用每個 Monarch 節點的大量記憶體，當 Monarch 區域的資源不足時，您遭到節流的風險就會增加。

  如果改用匯總函式將這些規則整合成單一規則 (比例)，則每個週期只會啟動 2 個平行 Monarch 查詢。這 2 個並行查詢的匯總記憶體用量遠低於 5,000 個並行查詢，因此受到節流的風險也低得多。

• 如果規則回溯期超過 1 天，請減少執行頻率，不要每分鐘都執行。如果查詢存取超過 25 小時前的資料，系統會將查詢傳送至 Monarch 磁碟資料存放區。這些存放區查詢速度較慢，且耗用的記憶體比查詢近期資料時多，這會加劇平行記錄規則造成的記憶體耗用問題。

  建議您每小時執行一次這類查詢，而非每分鐘一次。每分鐘執行一次查詢，一天下來結果的變化幅度只有 1/1440 = 0.07%，微不足道。每小時執行一次全天查詢，每個週期的結果變化為 60/1440 = 4%，這是較為相關的信號大小。如要在近期資料變更時收到快訊，您可以每分鐘執行一次不同的規則，並縮短回溯期 (例如 5 分鐘)。

• 在規則中使用 for: 欄位，容許暫時的異常結果。除非警示條件已符合至少設定的時長，否則 for: 欄位會停止觸發警示。將這個欄位設為規則評估間隔的兩倍以上。

  使用 for: 欄位有助於解決問題，因為暫時性問題通常會自行解決，也就是說，問題不會連續發生在警報週期。如果看到尖峰，且該尖峰持續出現在多個時間戳記和多個快訊週期，您就能更有把握這是真正的尖峰，而非暫時性問題。

• 在 PromQL 中使用 offset 修飾符延遲查詢評估，這樣查詢就不會針對最近一段時間的資料運作。查看取樣間隔和規則評估間隔，找出較長者。理想情況下，查詢偏移量至少是較長間隔長度的兩倍。舉例來說，如果您每 15 秒傳送一次資料，且每 30 秒執行一次規則，則查詢的偏移時間至少要 1 分鐘。1 分鐘的偏移量會導致規則使用至少 60 秒前的結束時間戳記，這會建立緩衝區，讓延遲的資料在規則執行前送達。

  這不僅是 Cloud Monitoring 的最佳做法 (所有受管理的 PromQL 快訊至少都有 1 分鐘的偏移)，也是 Prometheus 的最佳做法。

• 依 location 標籤將結果分組，找出可能無法使用的區域。含有 Google Cloud 區域的標籤在某些系統指標中可能稱為 zone 或 region。

  如果沒有依區域分組，且某個區域無法使用，結果就會突然下降，您也可能會看到歷史結果下降。如果按區域分組，且某個區域無法使用，您就不會收到該區域的任何結果，但其他區域的結果不受影響。

• 如果您的比率是成功率 (例如 2xx 回應數除以總回應數)，請考慮改為錯誤率 (例如 4xx+5xx 回應數除以總回應數)。錯誤比率對資料不一致的容忍度較高，因為資料暫時下降會導致查詢結果低於門檻，因此不會觸發快訊。

• 盡可能將比率查詢或記錄規則拆分成個別的分子和分母查詢。這是 Prometheus 最佳做法。使用比率是可行的，但由於分子中的查詢會獨立於分母中的查詢執行，因此使用比率可能會放大暫時性問題的影響：

  • 如果 Monarch 節流分子查詢，但未節流分母查詢，您可能會看到出乎意料的低結果。如果 Monarch 節流分母查詢，但未節流分子查詢，您可能會看到出乎意料的高結果。
  • 如果您查詢的是近期時間範圍，且有延遲抵達的資料，則比例中的一項查詢可能在資料抵達前執行，比例中的另一項查詢則在資料抵達後執行。
  • 如果比率的任一側包含的時序相對較少，任何錯誤都會放大。如果分子和分母各有 100 個時間序列，且 Monarch 未在分子查詢中傳回 1 個時間序列，您可能會發現 1% 的差異。如果分子和分母各有 1,000,000 個時間序列，且 Monarch 未在分子查詢中傳回 1 個時間序列，您不太可能注意到 0.0001% 的差異。

• 如果資料稀疏，請在查詢中使用較長的速率時間長度。舉例來說，如果資料每 10 分鐘送達一次，而查詢使用 rate(metric[1m])，則查詢只會回溯 1 分鐘尋找資料，因此有時會得到空白結果。一般來說，請將 [duration] 設為至少是擷取間隔的 4 倍。

  根據預設，量表查詢會回溯 5 分鐘的資料。如要讓他們回頭查看更久以前的內容，請使用任何有效的 x_over_time 函式，例如 last_over_time。

如果您在查詢近期資料時，發現查詢結果不一致，這些建議就非常實用。如果查詢超過 25 小時的資料時發生這個問題，可能是 Monarch 發生技術問題。如果發生這種情況，請與 Cloud Customer Care 團隊聯絡，以便我們進行調查。

匯入 Grafana 資訊主頁

如要瞭解如何使用及排解資訊主頁匯入工具的問題，請參閱「將 Grafana 資訊主頁匯入 Cloud Monitoring」。

如要瞭解轉換資訊主頁內容時發生的問題，請參閱匯入工具的 README 檔案。

擷取端問題

擷取端問題可能與集合或規則評估有關。 請先查看代管集合的錯誤記錄。您可以執行下列指令：

kubectl logs -f -n gmp-system -lapp.kubernetes.io/part-of=gmp

kubectl logs -f -n gmp-system -lapp.kubernetes.io/name=collector -c prometheus

在 GKE Autopilot 叢集上，您可以執行下列指令：

kubectl logs -f -n gke-gmp-system -lapp.kubernetes.io/part-of=gmp

kubectl logs -f -n gke-gmp-system -lapp.kubernetes.io/name=collector -c prometheus

目標狀態功能可協助您偵錯抓取目標。詳情請參閱目標狀態資訊。

端點狀態缺漏或過舊

如果您已啟用目標狀態功能，但一或多個 PodMonitoring 或 ClusterPodMonitoring 資源缺少 Status.Endpoint Statuses 欄位或值，則可能發生下列問題：

• Managed Service for Prometheus 無法連線至與其中一個端點位於相同節點的收集器。
• 您的一或多個 PodMonitoring 或 ClusterPodMonitoring 設定未產生有效目標。

類似問題也可能導致 Status.Endpoint Statuses.Last Update Time 欄位的值比幾分鐘加上擷取間隔還舊。

如要解決這個問題，請先檢查與擷取端點相關聯的 Kubernetes Pod 是否正在執行。如果 Kubernetes Pod 正在執行、標籤選取器相符，且您可以手動存取擷取端點 (通常是前往 /metrics 端點)，請檢查 Managed Service for Prometheus 收集器是否正在執行。

收集器比例小於 1

如果您已啟用目標狀態功能，系統就會提供資源的狀態資訊。PodMonitoring 或 ClusterPodMonitoring 資源的 Status.Endpoint Statuses.Collectors Fraction 值代表可連線的收集器比例，以 0 到 1 表示。舉例來說，值為 0.5 表示 50% 的收集器可連線，值為 1 則表示 100% 的收集器可連線。

如果 Collectors Fraction 欄位的值不是 1，表示有一或多個收集器無法連線，且可能無法擷取任何節點中的指標。確認所有收集器都已啟動，且可透過叢集網路連線。您可以使用下列指令查看收集器 Pod 的狀態：

kubectl -n gmp-system get pods --selector="app.kubernetes.io/name=collector"

在 GKE Autopilot 叢集上，這個指令看起來會略有不同：

kubectl -n gke-gmp-system get pods --selector="app.kubernetes.io/name=collector"

您可以使用下列指令，調查個別收集器 Pod (例如名為 collector-12345 的收集器 Pod)：

kubectl -n gmp-system describe pods/collector-12345

在 GKE Autopilot 叢集上，執行下列指令：

kubectl -n gke-gmp-system describe pods/collector-12345

如果收集器運作不正常，請參閱「GKE 工作負載疑難排解」。

如果收集器運作正常，請檢查運算子記錄。如要檢查運算子記錄，請先執行下列指令，找出運算子 Pod 名稱：

kubectl -n gmp-system get pods --selector="app.kubernetes.io/name=gmp-collector"

在 GKE Autopilot 叢集上，執行下列指令：

kubectl -n gke-gmp-system get pods --selector="app.kubernetes.io/name=gmp-collector"

接著，使用下列指令檢查運算子記錄 (例如名為 gmp-operator-12345 的運算子 Pod)：

kubectl -n gmp-system logs pods/gmp-operator-12345

在 GKE Autopilot 叢集上，執行下列指令：

kubectl -n gke-gmp-system logs pods/gmp-operator-12345

健康狀態不良的目標

如果您已啟用目標狀態功能，但一或多個 PodMonitoring 或 ClusterPodMonitoring 資源的 Status.Endpoint Statuses.Unhealthy Targets 欄位值不是 0，收集器就無法擷取一或多個目標。

查看 Sample Groups 欄位，該欄位會依錯誤訊息將目標分組，並找出 Last Error 欄位。Last Error 欄位來自 Prometheus，會說明目標無法擷取的原因。如要解決這個問題，請參考範例目標，檢查您的擷取端點是否正在執行。

未經授權的擷取端點

如果看到下列任一錯誤，且擷取目標需要授權，表示收集器未設為使用正確的授權類型，或使用的授權酬載不正確：

• server returned HTTP status 401 Unauthorized
• x509: certificate signed by unknown authority

如要解決這個問題，請參閱「設定授權的擷取端點」。

超過配額

如果看到下列錯誤，表示您已超出 Cloud Monitoring API 的擷取配額：

• "429: Quota exceeded for quota metric 'Time series ingestion requests' and limit 'Time series ingestion requests per minute' of service 'monitoring.googleapis.com' for consumer 'project_number:PROJECT_NUMBER'., rateLimitExceeded"

首次啟動受管理服務時，最常發生這個錯誤。 預設配額用盡時，每秒擷取的樣本數為 100,000 個。

如要解決這個問題，請提交申請，提高 Monitoring API 的擷取配額。如需協助，請與Google Cloud 支援團隊聯絡。如要進一步瞭解配額，請參閱 Cloud Quotas 說明文件。

節點預設服務帳戶缺少權限

如果看到下列任一錯誤訊息，表示節點上的預設服務帳戶可能缺少權限：

• 「execute query: Error querying Prometheus: client_error: client error: 403」
• 「Readiness probe failed: HTTP probe failed with statuscode: 503」
• 「Error querying Prometheus instance」(查詢 Prometheus 執行個體時發生錯誤)

Managed Service for Prometheus 中的代管收集作業和代管規則評估工具，都會使用節點上的預設服務帳戶。這個帳戶建立時會具備所有必要權限，但有時客戶會手動移除監控權限。移除後，系統就無法收集資料和評估規則。

如要驗證服務帳戶的權限，請執行下列其中一項操作：

• 找出基礎 Compute Engine 節點名稱，然後執行下列指令：

  gcloud compute instances describe NODE_NAME --format="json" | jq .serviceAccounts
  

  尋找字串 https://www.googleapis.com/auth/monitoring。如有必要，請按照「設定錯誤的服務帳戶」一文所述新增 Monitoring。

• 前往叢集中的基礎 VM，然後檢查節點服務帳戶的設定：

  1. 在 Google Cloud 控制台中，前往「Kubernetes clusters」(Kubernetes 叢集) 頁面：

     前往「Kubernetes clusters」(Kubernetes 叢集)

     如果您是使用搜尋列尋找這個頁面，請選取子標題為「Kubernetes Engine」的結果。

  2. 選取「節點」，然後點選「節點」表格中的節點名稱。

  3. 按一下「詳細資料」。

  4. 按一下「VM Instance」(VM 執行個體) 連結。

  5. 找到「API and identity management」(API 與身分識別管理) 窗格，然後按一下「Show details」(顯示詳細資料)。

  6. 尋找具有完整存取權的「Stackdriver Monitoring API」。

資料來源同步器或 Prometheus UI 也可能設定為查看錯誤的專案。如要瞭解如何確認您查詢的是預期指標範圍，請參閱「變更查詢的專案」。

服務帳戶設定錯誤

如果看到下列任一則錯誤訊息，表示收集器使用的服務帳戶沒有正確的權限：

• 「code = PermissionDenied desc = Permission monitoring.timeSeries.create denied (or the resource may not exist)」
• 「google: could not find default credentials. 詳情請參閱 https://developers.google.com/accounts/docs/application-default-credentials。」

如要確認服務帳戶具備正確的權限，請執行下列操作：

1. 前往 Google Cloud 控制台的「IAM」(身分與存取權管理) 頁面：

   前往 IAM

   如果您是使用搜尋列尋找這個頁面，請選取子標題為「IAM & Admin」(IAM 與管理) 的結果。

2. 在主體清單中找出服務帳戶名稱。確認服務帳戶名稱的拼寫方式正確無誤。然後按一下「Edit」(編輯)。

3. 選取「角色」欄位，然後按一下「目前使用中」，並搜尋「Monitoring Metric Writer」(監控指標寫入者) 或「Monitoring Editor」(監控編輯者) 角色。 如果服務帳戶沒有這些角色，請將監控指標寫入者 (roles/monitoring.metricWriter) 角色授予服務帳戶。

如果您在非 GKE Kubernetes 上執行，則必須明確將憑證傳遞至收集器和規則評估工具。您必須在 rules 和 collection 區段中重複輸入憑證。詳情請參閱「明確提供憑證」(適用於集合) 或「明確提供憑證」(適用於規則)。

服務帳戶通常會限定在單一 Google Cloud 專案中。如果使用一個服務帳戶為多個專案寫入指標資料 (例如，一個受管理規則評估工具正在查詢多專案指標範圍)，就可能導致這項權限錯誤。如果您使用預設服務帳戶，建議設定專屬服務帳戶，以便安全地為多個專案新增 monitoring.timeSeries.create 權限。如果無法授予這項權限，可以使用指標重新標記功能，將 project_id 標籤重新命名。專案 ID 預設為 Prometheus 伺服器或規則評估工具執行的專案。 Google Cloud

無效的擷取設定

如果看到下列錯誤，表示 PodMonitoring 或 ClusterPodMonitoring 格式不正確：

• 「Internal error occurred: failed calling webhook "validate.podmonitorings.gmp-operator.gmp-system.monitoring.googleapis.com": Post "https://gmp-operator.gmp-system.svc:443/validate/monitoring.googleapis.com/v1/podmonitorings?timeout=10s": EOF""

如要解決這個問題，請確認自訂資源已根據規格正確形成。

准入 Webhook 無法剖析或 HTTP 用戶端設定無效

如果 Managed Service for Prometheus 版本早於 0.12，您可能會看到類似下列的錯誤，這與非預設命名空間中的密鑰注入有關：

• 「admission webhook "validate.podmonitorings.gmp-operator.gmp-system.monitoring.googleapis.com" denied the request: invalid definition for endpoint with index 0: unable to parse or invalid Prometheus HTTP client config: must use namespace "my-custom-namespace", got: "default"」

如要解決這個問題，請升級至 0.12 以上版本。

擷取間隔和逾時問題

使用 Managed Service for Prometheus 時，擷取逾時時間不得大於擷取間隔。如要檢查這個問題的記錄，請執行下列指令：

kubectl -n gmp-system logs ds/collector prometheus

在 GKE Autopilot 叢集上，執行下列指令：

kubectl -n gke-gmp-system logs ds/collector prometheus

尋找這則訊息：

• 「scrape timeout greater than scrape interval for scrape config with job name "PodMonitoring/gmp-system/example-app/go-metrics"」(抓取逾時時間大於抓取間隔，適用於工作名稱為「PodMonitoring/gmp-system/example-app/go-metrics」的抓取設定)

如要解決這個問題，請將擷取間隔的值設為大於或等於擷取逾時的值。

指標缺少 TYPE

如果看到下列錯誤，表示指標缺少類型資訊：

• 「no metadata found for metric name "{metric_name}"」(找不到指標名稱「{metric_name}」的中繼資料)

如要確認問題是否出在缺少型別資訊，請檢查匯出應用程式的 /metrics 輸出內容。如果沒有類似下列的行，表示缺少類型資訊：

# TYPE {metric_name} <type>

某些程式庫 (例如舊版 VictoriaMetrics 1.28.0 之前的版本) 會刻意捨棄型別資訊。Managed Service for Prometheus 不支援這些程式庫。

時間序列衝突

如果看到下列任一錯誤，可能是因為有多個收集器嘗試寫入相同的時間序列：

• 「無法寫入一或多個 TimeSeries：寫入一或多個資料點的頻率高於為指標設定的取樣週期上限。」
• 「無法寫入一或多個 TimeSeries：必須依序寫入點。 指定的一或多個點的結束時間早於最近的點。」

以下是最常見的原因和解決方法：

• 使用高可用性配對。Managed Service for Prometheus 不支援傳統的高可用性收集作業。使用這項設定可能會建立多個收集器，嘗試將資料寫入同一時間序列，導致發生這個錯誤。

  如要解決這個問題，請將副本數量減少至 1，藉此停用重複的收集器，或是使用支援的高可用性方法。

• 使用重新標記規則，特別是針對工作或例項運作的規則。Managed Service for Prometheus 會根據 {project_id、location、cluster、namespace、job、instance} 標籤的組合，部分識別不重複的時間序列。使用重新標記規則捨棄這些標籤 (尤其是 job 和 instance 標籤) 經常會導致衝突。我們不建議重新編寫這些標籤。

  如要解決問題，請刪除造成問題的規則；通常只要刪除使用 labeldrop 動作的 metricRelabeling 規則即可。如要找出有問題的規則，請註解掉所有重新標記規則，然後逐一恢復，直到錯誤再次發生為止。

如果抓取間隔短於 5 秒，也可能導致時間序列發生衝突，但這種情況較不常見。Managed Service for Prometheus 支援的最低擷取間隔為 5 秒。

超出標籤數量上限

如果看到下列錯誤，表示您可能為其中一項指標定義了過多標籤：

• 「One or more TimeSeries could not be written: The new labels would cause the metric prometheus.googleapis.com/METRIC_NAME to have over PER_PROJECT_LIMIT labels」。

如果您快速變更指標定義，導致一個指標名稱在整個指標生命週期內，有多個獨立的標籤鍵集，通常就會發生這項錯誤。Cloud Monitoring 會限制每個指標的標籤數量；詳情請參閱使用者定義指標的限制。

注意： 標籤數量 (也稱為標籤名稱、標籤鍵或維度) 與基數不同。基數是指所有標籤中不重複標籤值的組合數量。

如要解決這個問題，請按照下列三個步驟操作：

1. 找出特定指標的標籤過多或經常變更的原因。

   • 您可以使用 metricDescriptors.list 頁面上的 APIs Explorer 小工具呼叫方法。詳情請參閱 API Explorer。如需範例，請參閱「列出指標和資源類型」。

2. 解決問題的來源，可能需要調整 PodMonitoring 的重新標記規則、變更匯出工具，或修正檢測。

3. 刪除這項指標的指標描述元 (會導致資料遺失)，以便使用較小且更穩定的標籤集重新建立。您可以使用 metricDescriptors.delete 方法執行這項操作。

最常見的問題來源如下：

• 從匯出工具或應用程式收集指標，這些工具或應用程式會將動態標籤附加至指標。舉例來說，您可使用額外的容器標籤和環境變數，自行部署 cAdvisor，或是使用 DataDog 代理程式，該代理程式會插入動態註解。

  如要解決這個問題，您可以在 PodMonitoring 中使用 metricRelabeling 區段保留或捨棄標籤。部分應用程式和匯出工具也允許變更匯出指標的設定。舉例來說，cAdvisor 有許多進階執行階段設定，可動態新增標籤。使用代管收集功能時，建議使用內建的自動 kubelet 收集功能。

• 使用重新標記規則，尤其是動態附加標籤名稱的規則，這可能會導致標籤數量超出預期。

  如要解決這個問題，請刪除造成問題的規則項目。

建立及更新指標和標籤的速率限制

如果看到下列錯誤訊息，表示您已達到每分鐘建立新指標，以及為現有指標新增指標標籤的速率限制：

• 「Request throttled. 您每分鐘可變更的指標定義或標籤定義已達專案上限。

通常只有在首次與 Managed Service for Prometheus 整合時，才會達到這項速率限制。舉例來說，當您遷移現有的成熟 Prometheus 部署作業，改為使用自行部署的集合時，就會發生這種情況。這並非資料點的擷取速率限制。只有在建立前所未見的指標，或為現有指標新增標籤時，才會套用這項速率限制。

這項配額是固定的，但只要在每分鐘的限制內建立新指標和指標標籤，任何問題都應會自動解決。

指標描述元數量限制

如果看到下列錯誤訊息，表示您已達到單一Google Cloud 專案中指標描述元的數量配額上限：

• 「Your metric descriptor quota has been exhausted.」

這項限制預設為 25,000。 如果指標格式正確，您可以提出要求來提高這項配額，但如果系統中含有格式錯誤的指標名稱，您很可能就會達到這項限制。

Prometheus 採用多維度資料模型，其中叢集或命名空間名稱等資訊應編碼為標籤值。如果維度資訊內嵌在指標名稱中，指標描述元的數量就會無限增加。此外，由於在此情境中標籤未正確使用，因此跨叢集、命名空間或服務查詢及彙整資料會變得更加困難。

Cloud Monitoring 和 Managed Service for Prometheus 都不支援非維度指標，例如以 StatsD 或 Graphite 格式設定的指標。雖然大多數 Prometheus 匯出工具都已預先正確設定，但某些匯出工具 (例如 StatsD 匯出工具、Vault 匯出工具或 Istio 隨附的 Envoy Proxy) 必須明確設定為使用標籤，而非在指標名稱中嵌入資訊。不正確的指標名稱範例包括：

• request_path_____path_to_a_resource____istio_request_duration_milliseconds
• envoy_cluster_grpc_method_name_failure
• envoy_cluster_clustername_upstream_cx_connect_ms_bucket
• vault_rollback_attempt_path_name_1700683024
• service__________________________________________latency_bucket

如要確認這個問題，請按照下列步驟操作：

1. 在 Google Cloud 控制台中，選取 Google Cloud 與錯誤連結的專案。

2. 前往 Google Cloud 控制台的 「指標管理」頁面：

   前往「指標管理」

   如果您是使用搜尋列尋找這個頁面，請選取子標題為「Monitoring」的結果。

3. 確認「有效」和「無效」指標的總和超過 25,000。在大多數情況下，您應該會看到大量處於非使用中狀態的指標。
4. 在「快速篩選器」面板中選取「無效」，然後瀏覽清單並尋找模式。
5. 在「快速篩選器」面板中選取「有效」，依「可計費的樣本量」遞減排序，瀏覽清單並找出模式。
6. 依「可計費的樣本量」遞增排序，瀏覽清單並找出模式。

或者，您可以使用 Metrics Explorer 確認這個問題：

1. 在 Google Cloud 控制台中，選取 Google Cloud 與錯誤連結的專案。

2. 前往 Google Cloud 控制台的 「Metrics Explorer」頁面：

   前往 Metrics Explorer

   如果您是使用搜尋列尋找這個頁面，請選取子標題為「Monitoring」的結果。

3. 在查詢建立工具中，按一下「選取指標」，然後取消勾選「啟用」核取方塊。
4. 在搜尋列中輸入「prometheus」。
5. 找出指標名稱中的任何模式。

找出指標格式錯誤的模式後，您可以修正來源的匯出工具，然後刪除違規的指標描述元，藉此解決問題。

如要避免再次發生這個問題，請先設定相關匯出工具，停止發出格式錯誤的指標。建議您參閱匯出工具的說明文件，尋求相關協助。如要確認問題是否已修正，請手動前往 /metrics 端點，並檢查匯出的指標名稱。

然後使用 projects.metricDescriptors.delete 方法刪除格式錯誤的指標，即可釋出配額。為方便您逐一檢查格式錯誤的指標，我們提供 Golang 指令碼供您使用。這個指令碼會接受可找出格式錯誤指標的規則運算式，並刪除符合模式的任何指標描述元。刪除指標後無法復原，因此強烈建議您先以模擬執行模式執行指令碼。

短期目標缺少部分指標

已部署 Google Cloud Managed Service for Prometheus，且沒有設定錯誤，但缺少部分指標。

找出產生部分遺漏指標的部署作業。 如果部署作業是 Google Kubernetes Engine CronJob，請判斷作業通常需要多久時間才能執行完畢：

1. 找到 Cron 工作部署 yaml 檔案，並在檔案結尾找到狀態清單。這個範例中的狀態顯示工作執行了一分鐘：

     status:
       lastScheduleTime: "2024-04-03T16:20:00Z"
       lastSuccessfulTime: "2024-04-03T16:21:07Z"
   

2. 如果執行時間少於五分鐘，工作執行時間不夠長，無法持續擷取指標資料。

   如要解決這個問題，請嘗試下列做法：

   • 設定工作，確保工作啟動後至少經過五分鐘才會結束。

   • 設定工作，在結束前偵測指標是否已完成擷取。這項功能需要程式庫支援。

   • 建議您建立以記錄為準的分配值指標，而非收集指標資料。如果資料發布率偏低，建議採用這種做法。詳情請參閱「記錄指標」的說明。

3. 如果執行時間超過五分鐘或不一致，請參閱本文的「不正常的目標」一節。

出口商收款問題

如果系統未擷取匯出工具的指標，請檢查下列事項：

• 使用 kubectl port-forward 指令，確認匯出工具是否正常運作並匯出指標。

  舉例來說，如要確認命名空間 test 中具有選取器 app.kubernetes.io/name=redis 的 Pod 是否正在通訊埠 9121 的 /metrics 端點發出指標，可以轉送通訊埠，如下所示：

  kubectl port-forward "$(kubectl get pods -l app.kubernetes.io/name=redis -n test -o jsonpath='{.items[0].metadata.name}')" 9121
  

  使用瀏覽器或另一個終端機工作階段中的 curl 存取端點 localhost:9121/metrics，確認指標是否由匯出工具公開，以供擷取。

• 檢查您是否可以在 Google Cloud 控制台中查詢指標，但無法在 Grafana 中查詢。如果是這樣，問題出在 Grafana，而非指標的收集作業。

• 檢查收集器公開的 Prometheus 網頁介面，確認受管理收集器是否能擷取匯出工具。

  1. 找出與匯出工具在同一節點上執行的受管理收集器。舉例來說，如果您的匯出工具在命名空間 test 的 Pod 上執行，且 Pod 標示為 app.kubernetes.io/name=redis，下列指令會找出在相同節點上執行的代管收集器：

     kubectl get pods -l app=managed-prometheus-collector --field-selector="spec.nodeName=$(kubectl get pods -l app.kubernetes.io/name=redis -n test -o jsonpath='{.items[0].spec.nodeName}')" -n gmp-system -o jsonpath='{.items[0].metadata.name}'
     

  2. 從受管理收集器的通訊埠 19090 設定通訊埠轉送：

     kubectl port-forward POD_NAME -n gmp-system 19090
     

  3. 前往 localhost:19090/targets 網址，存取網頁介面。如果匯出工具列為其中一個目標，表示受管理的收集器已成功擷取匯出工具。

收集器記憶體不足 (OOM) 錯誤

如果您使用代管收集功能，且收集器發生記憶體不足 (OOM) 錯誤，請考慮啟用垂直 Pod 自動調度資源。

運算子記憶體不足 (OOM) 錯誤

如果您使用受管理集合，且運算子發生記憶體不足 (OOM) 錯誤，請考慮停用目標狀態功能。在較大的叢集中，目標狀態功能可能會導致運算子效能問題。

時間序列過多，或 503 回應和內容期限超出錯誤增加，尤其是在尖峰負載期間

如果看到下列錯誤訊息，也可能遇到這個問題：

• 「受監控資源 (abcdefg) 的時間序列 (Prometheus 指標) 過多」

「Context deadline exceeded」是 Monarch 傳回的一般 503 錯誤，適用於任何沒有特定原因的擷取端問題。正常使用系統時，預期會出現極少數的「context deadline exceeded」錯誤。

不過，您可能會發現「context deadline exceeded」錯誤的模式增加，並對資料擷取作業造成重大影響。其中一個可能根本原因是目標標籤設定有誤。如果符合下列條件，就更有可能發生這種情況：

• 您的「Context deadline exceeded」錯誤具有週期性模式，會在您負載量高時或 Google Cloud 標籤指定的location區域負載量高時增加。
• 將更多指標資料量加入服務時，您會看到更多錯誤。
• 您使用 statsd_exporter for Prometheus、Istio 的 Envoy、SNMP 匯出工具、Prometheus Pushgateway、kube-state-metrics，或您有類似的匯出工具，可代表環境中執行的其他資源中介並回報指標。這個問題只會發生在由這類匯出工具發出的指標。
• 您發現受影響指標的instance標籤值中，往往含有「localhost」字串，或instance標籤的值很少。
• 如果您可以存取叢集內 Prometheus 收集器查詢 UI，就能確認系統已成功收集指標。

如果符合上述條件，表示匯出工具可能誤設資源標籤，導致與 Monarch 的規定衝突。

Monarch 會將相關資料儲存在目標中，藉此進行擴充。Managed Service for Prometheus 的目標是由 prometheus_target 資源類型和 project_id、location、cluster、namespace、job 和 instance 標籤定義。如要進一步瞭解這些標籤和預設行為，請參閱「受管理集合中的保留標籤」或「自行部署集合中的保留標籤」。

在這些標籤中，instance 是最低層級的目標欄位，因此正確性最為重要。如要在 Monarch 中有效儲存及查詢指標，需要相對較小且多樣化的目標，最好是 VM 或容器的大小。在一般情況下執行 Managed Service for Prometheus 時，收集器內建的開放原始碼預設行為通常會為 job 和 instance 標籤選取合適的值，因此本文件其他地方不會涵蓋這個主題。

不過，如果您執行的匯出工具會代表叢集中的其他資源 (例如 statsd_exporter) 匯報指標，預設邏輯可能會失敗。instance 的值不會設為發出指標的資源 IP:port，而是設為 statsd_exporter 本身的 IP:port。instancejob 標籤可能會加劇這個問題，因為標籤不僅與指標套件或服務相關，也缺乏多樣性，設定為 statsd-exporter。

發生這種情況時，特定叢集和命名空間中來自這個匯出工具的所有指標，都會寫入相同的 Monarch 目標。隨著這個目標變大，寫入作業會開始失敗，您會看到「Context deadline exceeded」503 錯誤增加。

如要確認是否發生這種情況，請與 Cloud 客戶服務團隊聯絡，並要求他們檢查「Monarch Quarantiner hospitalization logs」。在票證中加入六個保留標籤的任何已知值。請務必回報 Google Cloud 傳送資料的專案 Google Cloud ，而非指標範圍的專案。

如要修正這個問題，請變更收集管線，使用更多樣的目標標籤。以下列出幾種可能的策略，並依有效性排序：

• 請為每個 VM 執行個別的匯出工具，做為節點代理程式，或將匯出工具部署為 Kubernetes Daemonset，而不是執行代表所有 VM 或節點回報指標的中央匯出工具。為避免將 instance 標籤設為 localhost，請勿在與收集器相同的節點上執行匯出工具。
  • 如果將匯出工具分片後，您仍需要更多目標多樣性，請在每個 VM 上執行多個匯出工具，並以邏輯方式為每個匯出工具指派不同的指標集。然後，不要使用靜態名稱 statsd-exporter 探索工作，而是為每個邏輯指標集使用不同的工作名稱。job 值不同的執行個體會指派給 Monarch 中的不同目標。
  • 如果您使用 kube-state-metrics，請使用內建的水平分片，建立更多目標多樣性。其他匯出工具可能也有類似功能。
• 如果您使用 OpenTelemetry 或自行部署的收集作業，請使用重新標記規則，將 instance 的值從匯出工具的 IP:Port 或名稱，變更為產生指標的資源 IP:Port 或專屬名稱。您很可能已將來源資源的 IP:Port 或名稱擷取為指標標籤。您也必須在 Prometheus 或 OpenTelemetry 設定中，將 honor_labels 欄位設為 true。
• 如果您使用 OpenTelemetry 或自行部署的收集作業，請使用含有 hashmod 函式的重新標記規則，針對相同匯出工具執行多項擷取作業，並確保為每個擷取設定選擇不同的例項標籤。

沒有錯誤，也沒有指標

如果您使用受管理收集功能，但沒有看到任何錯誤，且資料未顯示在 Cloud Monitoring 中，最可能的原因是您的指標匯出工具或擷取設定未正確設定。除非您先套用有效的擷取設定，否則 Managed Service for Prometheus 不會傳送任何時間序列資料。

如要判斷是否為這個原因，請嘗試部署範例應用程式和範例 PodMonitoring 資源。如果現在看到 up 指標 (可能需要幾分鐘)，則問題出在擷取設定或匯出工具。

根本原因可能有很多種。建議檢查下列項目：

• PodMonitoring 參照有效的通訊埠。

• 匯出工具的 Deployment 規格已正確命名通訊埠。

• 選取器 (最常見的是 app) 會比對 Deployment 和 PodMonitoring 資源。

• 您可以手動前往預期端點和連接埠，查看相關資料。

• 您已在與要擷取的應用程式相同的命名空間中，安裝 PodMonitoring 資源。請勿在 gmp-system 或 gke-gmp-system 命名空間中安裝任何自訂資源或應用程式。

• 您的指標和標籤名稱符合 Prometheus 的驗證規則運算式。 Managed Service for Prometheus 不支援以 _ 字元開頭的標籤名稱。

• 您使用的篩選器組合不會導致所有資料遭到篩除。 使用 OperatorConfig 資源中的 collection 篩選器時，請特別注意不要有衝突的篩選器。

• 如果是在 Google Cloud以外的環境中執行，請將 project 或 project-id 設為有效的 Google Cloud 專案，並將 location 設為有效的 Google Cloud 區域。您無法將 global 做為 location 的值。

• 您的指標是四種 Prometheus 指標類型之一。 部分程式庫 (例如 Kube State Metrics) 會公開 OpenMetrics 指標類型，例如 Info、Stateset 和 GaugeHistogram，但 Managed Service for Prometheus 不支援這些指標類型，因此會自動捨棄。

防火牆

防火牆可能會導致擷取和查詢問題。您必須設定防火牆，允許 POST 和 GET 要求傳送至 Monitoring API 服務 monitoring.googleapis.com，才能擷取及查詢資料。

並行編輯錯誤

「Too many concurrent edits to the project configuration」(專案設定同時編輯次數過多) 錯誤訊息通常是暫時性的，幾分鐘後就會解決。通常是因為移除會影響許多不同指標的重新標記規則所致。移除作業會導致專案中形成指標描述元更新佇列。處理佇列後，錯誤就會消失。

詳情請參閱「建立及更新指標和標籤的限制」。

Monarch 封鎖及取消的查詢

如果看到下列錯誤訊息，表示您已達到任何指定專案可執行的並行查詢數量內部上限：

• "internal: expanding series: generic::aborted: invalid status monarch::220: Cancelled due to the number of queries whose evaluation is blocked waiting for memory is 501, which is equal to or greater than the limit of 500."

為防範濫用行為，系統會強制限制一個專案可在 Monarch 中同時執行的查詢數量。在一般 Prometheus 用量下，查詢速度應該很快，而且絕不會達到這個上限。

如果您發出大量並行查詢，且查詢執行時間超出預期，就可能會達到這個上限。要求超過 25 小時資料的查詢，執行速度通常會比要求少於 25 小時資料的查詢慢，而且查詢回溯時間越長，查詢速度就越慢。

通常是因為以效率不彰的方式執行大量回溯時間較長的規則所致。舉例來說，您可能每分鐘執行多項規則，並要求 4 週的費率。如果這些規則的執行時間過長，最終可能會導致專案中待執行的查詢備份，進而導致 Monarch 節流查詢。

如要解決這個問題，請增加長期回溯規則的評估間隔，以免規則每 1 分鐘執行一次。每 1 分鐘查詢一次 4 週的費率並無必要，因為 4 週有 40,320 分鐘，因此每分鐘幾乎不會提供額外信號 (資料最多只會變動 1/40,320)。如果查詢要求的是 4 週的費率，1 小時的評估間隔應該就足夠。

解決因執行時間過長且執行頻率過高的查詢而造成的瓶頸後，這個問題應該就會自動解決。

不相容的值類型

如果在擷取或查詢時看到下列錯誤，表示指標的值類型不相容：

• 「Value type for metric prometheus.googleapis.com/metric_name/gauge must be INT64, but is DOUBLE」(指標 prometheus.googleapis.com/metric_name/gauge 的值類型必須為 INT64，但卻是 DOUBLE)
• 「Value type for metric prometheus.googleapis.com/metric_name/gauge must be DOUBLE, but is INT64」(指標 prometheus.googleapis.com/metric_name/gauge 的值類型必須為 DOUBLE，但目前為 INT64)
• 「無法寫入一或多個 TimeSeries：指標 prometheus.googleapis.com/target_info/gauge 的值類型與現有值類型 (INT64) 衝突」

在擷取資料時，您可能會看到這則錯誤訊息，因為 Monarch 不支援將 DOUBLE 類型資料寫入 INT64 類型指標，也不支援將 INT64 類型資料寫入 DOUBLE 類型指標。使用多專案指標範圍查詢時，也可能會看到這則錯誤訊息，因為 Monarch 無法合併一個專案中的 DOUBLE 型別指標，以及另一個專案中的 INT64 型別指標。

只有在 OpenTelemetry 收集器回報資料時，才會發生這項錯誤。如果 OpenTelemetry (使用 googlemanagedprometheus 匯出工具) 和 Prometheus 都回報相同指標的資料 (例如 target_info 指標)，就更有可能發生這項錯誤。

原因可能是下列其中一項：

• 您正在收集 OTLP 指標，而 OTLP 指標程式庫已將值類型從 DOUBLE 變更為 INT64，就像 OpenTelemetry 的 Java 指標一樣。新版指標程式庫與舊版指標程式庫建立的指標值類型不相容。
• 您同時使用 Prometheus 和 OpenTelemetry 收集 target_info 指標。Prometheus 會以 DOUBLE 形式收集這項指標，而 OpenTelemetry 則會以 INT64 形式收集。現在，收集器會將兩種值類型寫入同一專案中的相同指標，只有最先建立指標描述元的收集器會成功。
• 您在一個專案中以 OpenTelemetry 收集 target_info，並將其設為 INT64，在另一個專案中則以 Prometheus 收集 target_info，並將其設為 DOUBLE。將這兩個指標新增至相同的指標範圍，然後透過指標範圍查詢該指標，會導致不相容的指標值類型之間出現無效的聯集。

如要解決這個問題，請強制將所有指標值類型設為 DOUBLE，方法如下：

1. 重新設定 OpenTelemetry 收集器，啟用功能閘道 exporter.googlemanagedprometheus.intToDouble 旗標，強制所有指標都為 DOUBLE。
2. 刪除所有 INT64 指標描述元，讓系統以 DOUBLE 重新建立這些描述元。您可以使用delete_metric_descriptors.go指令碼自動執行這項操作。

完成這些步驟後，系統會刪除所有以 INT64 指標形式儲存的資料。 刪除 INT64 指標是徹底解決這個問題的唯一方法。