排解 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 控制台的 leaderboard「Metrics Explorer」頁面：

   前往 Metrics Explorer

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

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

4. 確認「Language」切換鈕中已選取「PromQL」。語言切換鈕位於可讓您設定查詢格式的工具列中。

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

   up
   

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

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

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

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

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

您也可以使用「指標管理」頁面排除不需要的指標，省下擷取這些指標的成本。

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

1. 在 Google Cloud 控制台中，前往 query_stats「Metrics management」頁面：

   前往「指標管理」

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

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

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

查詢端問題

大部分的查詢端問題都是由下列原因造成：

• 服務帳戶的權限或憑證不正確。
• 如果叢集已啟用這項功能，則 Workload Identity Federation for GKE 設定不正確。詳情請參閱「為 GKE Workload Identity Federation 設定服務帳戶」。

請先執行下列操作：

• 請仔細檢查設定是否符合查詢設定操作說明。

• 如果您使用 GKE 適用的工作負載身分聯盟，請按照下列步驟確認服務帳戶是否具備正確的權限：

  1. 前往 Google Cloud 控制台的「IAM」頁面：

     前往「身分與存取權管理」頁面

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

  2. 在使用者清單中找出服務帳戶名稱。請確認服務帳戶名稱的拼法正確無誤。然後按一下「編輯」圖示 edit。

  3. 選取「角色」欄位，然後點選「目前使用中」，並搜尋「Monitoring Viewer」角色。如果服務帳戶沒有這個角色，請立即新增。

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

密鑰設定錯誤或輸入錯誤

如果您看到下列任一情況，就表示您可能遺漏了密鑰或輸入錯誤：

• Grafana 或 Prometheus UI 中的以下「forbidden」錯誤：

  • 「警告：擷取伺服器時間時傳回非預期的回應狀態：Forbidden」
  • 「警告：擷取指標清單時發生錯誤：擷取指標名稱時的回應狀態不符預期：Forbidden」

• 記錄檔中顯示類似以下的訊息：
  「cannot read credentials file: open /gmp/key.json: no such file or directory」

如果您使用資料來源同步器驗證並設定 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. 如果您使用 Workload Identity 聯盟的 GKE，請確認您沒有輸入錯誤的帳戶金鑰或憑證，並確認您已將其繫結至正確的命名空間。

如果您使用舊版前端 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 中看到下列任一錯誤，表示您可能使用了系統不支援的端點：

• 「驗證：系統目前不支援 name 以外的標籤」
• 「模板化 [工作]：更新選項時發生錯誤：系統尚不支援 name 以外的標籤。」

Managed Service for Prometheus 僅支援 /api/v1/$label/values 端點的 __name__ 標籤。這項限制會導致在 Grafana 中使用 label_values($label) 變數的查詢失敗。

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

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

超過配額

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

• 「429：RESOURCE_EXHAUSTED：消費者 'project_number:...' 的「monitoring.googleapis.com」服務的「時序查詢」配額指標和「每分鐘時序查詢數」限制已超出配額。」

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

多項專案的指標

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

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

未指定受控資源類型

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

• 「指標已設定為與多個受控資源類型搭配使用；系列選取器必須在受控資源名稱上指定標籤比對器」

您可以使用 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 分鐘的查詢回溯期。

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

缺少計數器資料或不完整的直方圖

這類問題最常見的徵兆，就是查詢一般計數器指標 (例如 metric_name_foo 的 PromQL 查詢) 時，沒有資料或資料出現空白。如果在查詢中加入 rate 函式 (例如 rate(metric_name_foo[5m])) 後，資料出現，即可確認這項問題。

您可能也會發現，擷取量沒有任何重大變化，但擷取的樣本數量卻大幅增加，或是在 Cloud Monitoring 中，新指標是以「unknown」或「unknown:counter」字尾建立。

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

收集指標時，如果沒有 Prometheus 指標類型，就會發生這些問題。由於 Monarch 是強型別，Managed Service for Prometheus 會將未指定型別的指標加上「unknown」字尾，並擷取兩次，一次是做為量測儀，另一次是做為計數器。查詢引擎會根據您使用的查詢函式，選擇是否要查詢基礎量測儀或計數器指標。

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

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

• 誤將 Managed Service for Prometheus 收集器設為聯邦伺服器。使用 Managed Service for Prometheus 時，系統不支援聯邦功能。由於連結會刻意捨棄 TYPE 資訊，因此實作連結會導致「unknown」類型的指標。
• 在擷取管道的任何位置使用 Prometheus 遠端寫入功能。這個通訊協定也會刻意捨棄 TYPE 資訊。
• 使用修改指標名稱的重新標示規則。這會導致重新命名的指標與原始指標名稱相關聯的 TYPE 資訊脫鉤。
• 匯出工具未為每個指標傳送 TYPE。
• 收集器首次啟動時，TYPE 會遭到放棄，這是暫時性問題。

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

• 停止使用 Managed Service for Prometheus 的聯合功能。如要先「匯總」資料，再傳送至 Monarch，以便減少基數和成本，請參閱「設定本機匯總」一文。
• 停止在收集路徑中使用 Prometheus 遠端寫入功能。
• 請造訪 /metrics 端點，確認每個指標都有 # TYPE 欄位。
• 刪除會修改指標名稱的重新標示規則。
• 呼叫 DeleteMetricDescriptor，刪除任何含有「unknown」或「unknown:counter」後置字元的衝突指標。
• 或者，您可以一律使用 rate 或其他計數器處理函式查詢計數器。

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

叢集重新啟動後，Grafana 資料未保留

如果在 Pod 重新啟動後，資料似乎從 Grafana 中消失，但在 Cloud Monitoring 中可見，表示您使用的是 Grafana 查詢本機 Prometheus 例項，而非 Managed Service for Prometheus。

如要瞭解如何設定 Grafana 以 Managed Service 做為資料來源，請參閱 Grafana。

不一致的查詢或自動修正的警示規則結果

您可能會發現，針對最近時間區間執行的查詢 (例如透過記錄或快訊規則執行的查詢) 會傳回無法解釋的資料尖峰。在 Grafana 或 Metrics Explorer 中執行查詢來調查尖峰值時，您可能會發現尖峰值已消失，資料又恢復正常。

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

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

這類查詢暫時出現大量流量的原因可能有以下幾種：

• (最常見的原因) 您的相似平行查詢都會從相同組的 Monarch 節點要求資料，在每個節點上消耗大量記憶體。如果 Monarch 在雲端區域中有足夠的可用資源，查詢就會正常運作。當 Monarch 在雲端地區受到資源壓力時，每個節點都會節流查詢，並優先節流在每個節點上耗用最多記憶體的使用者。當 Monarch 再次擁有足夠的資源時，查詢便會再次運作。這些查詢可能是透過 Sloth 等工具自動產生的 SLI。
• 您有延遲到達的資料，而查詢無法容許這種情況。新寫入的資料需要約 3 到 7 秒才能進行查詢，不含網路延遲時間，也不含環境中資源壓力造成的任何延遲時間。如果查詢未納入延遲或偏移時間，以便考量延遲傳送的資料，您可能會在不知情的情況下，針對只有部分資料的期間執行查詢。資料到達後，查詢結果就會恢復正常。
• 在不同的副本中儲存資料時，Monarch 可能會出現輕微不一致的情形。查詢引擎會嘗試挑選「最佳品質」的複本，但如果不同的查詢挑選的複本資料集略有不同，則不同查詢的結果可能會略有差異。這是系統的預期行為，快訊應能容許這些輕微的差異。
• 整個 Monarch 區域可能暫時無法使用。如果無法存取某個區域，查詢引擎會將該區域視為不存在。區域開放後，查詢結果會繼續傳回該區域的資料。

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

• 將類似的規則和快訊整合為單一規則，以便依標籤匯總，而非為每個標籤值排列組合建立個別規則。如果這些是快訊規則，您可以使用標籤式通知，將匯總規則的快訊轉送至其他位置，而不需要為每則快訊個別設定轉送規則。

  舉例來說，如果您有標籤 foo，其中包含值 bar、baz 和 qux，請不要為每個標籤值建立個別規則 (一個含有查詢 sum(metric{foo="bar"})、一個含有查詢 sum(metric{foo="baz"})、一個含有查詢 sum(metric{foo="qux"}))，而是建立單一規則，以便跨該標籤進行匯總，並視需要篩選您在意的標籤值 (例如 sum by (foo) metric{foo=~"bar|baz|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 容器是否正在執行。如果 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：消費者 'project_number:PROJECT_NUMBER' 的服務 'monitoring.googleapis.com' 的 '時序攝入要求' 配額指標和'每分鐘時序攝入要求數' 限制已超出配額，rateLimitExceeded」

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

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

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

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

• 「execute query: Error querying Prometheus: client_error: client error: 403」
• 「Readiness probe failed: HTTP probe failed with status code: 503」
• 「Error querying Prometheus instance」

Managed Service for Prometheus 中的代管收集作業和代管規則評估器都會使用節點上的預設服務帳戶。這個帳戶會在建立時取得所有必要權限，但客戶有時會手動移除監控權限。這項移除作業會導致收集和規則評估作業失敗。

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

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

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

  請找出字串 https://www.googleapis.com/auth/monitoring。如有需要，請新增「監控」功能，如服務帳戶設定不正確一文所述。

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

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

     前往「Kubernetes clusters」(Kubernetes 叢集)

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

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

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

  4. 按一下「VM Instance」連結。

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

  6. 找出具有完整存取權的 Stackdriver Monitoring API。

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

服務帳戶設定錯誤

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

• 「code = PermissionDenied desc = 權限 monitoring.timeSeries.create 遭拒 (或資源不存在)」
• 「google: 找不到預設憑證。詳情請參閱 https://developers.google.com/accounts/docs/application-default-credentials。

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

1. 前往 Google Cloud 控制台的「IAM」頁面：

   前往「身分與存取權管理」頁面

   如果您是使用搜尋列尋找這個頁面，請選取子標題為「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 的格式不正確：

• 「發生內部錯誤：無法呼叫 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"}」

如要解決這個問題，請確認自訂資源的格式是否符合規格。

無法剖析或無效的 HTTP 用戶端設定

在 0.12 之前的 Managed Service for Prometheus 版本中，您可能會看到類似下列的錯誤，這與非預設命名空間中的機密資料插入作業有關：

• 「admission webhook "validate.podmonitorings.gmp-operator.gmp-system.monitoring.googleapis.com"」拒絕要求：端點的定義無效 (索引為 0)：無法剖析或 Prometheus HTTP 用戶端設定無效：必須使用命名空間「my-custom-namespace」，但收到「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

請留意下列訊息：

• 「刮除逾時時間大於刮除間隔，刮除設定的工作名稱為「PodMonitoring/gmp-system/example-app/go-metrics」"

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

指標缺少 TYPE

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

• 「找不到指標名稱為『{metric_name}』的中繼資料」

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

# TYPE {metric_name}

某些程式庫 (例如 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 秒。

標籤數量超出上限

如果您看到下列錯誤訊息，表示您為某個指標定義的標籤可能過多：

• 「無法寫入一或多個 TimeSeries：新的標籤會導致 prometheus.googleapis.com/METRIC_NAME 指標擁有超過 PER_PROJECT_LIMIT 個標籤」。

這類錯誤通常會在您快速變更指標定義時發生，導致在指標的整個生命週期中，一個指標名稱實際上會有多組獨立的標籤鍵。Cloud Monitoring 會對每個指標的標籤數量設下限制。如需詳細資訊，請參閱使用者定義指標的限制。

解決這個問題的步驟如下：

1. 找出特定指標為何有太多或經常變更的標籤。

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

2. 解決問題來源，可能需要調整 PodMonitoring 的重新命名規則、變更匯出程式或修正檢測作業。

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

造成這個問題最常見的原因包括：

• 從匯出工具或應用程式收集指標，這些工具或應用程式會在指標上附加動態標籤。例如，您可以使用自部署的 cAdvisor 搭配額外的容器標籤和環境變數，或是 DataDog 代理程式，以便插入動態註解。

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

• 使用重新標示規則，特別是會動態附加標籤名稱的規則，可能會導致標籤數量不符預期。

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

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

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

• 「要求受限。您已達到每個專案每分鐘指標定義或標籤定義變更的上限。」

只有在首次與 Managed Service for Prometheus 整合時，才會觸及這項速率限制，例如在遷移現有的成熟 Prometheus 部署作業，以便使用自行部署的集合時。這不是擷取資料點的速率限制。這項速率限制只會在您建立未曾見過的指標，或在現有指標中新增標籤時生效。

這個配額是固定的，但只要新指標和指標標籤的建立次數達到每分鐘限制，系統就會自動解決任何問題。

指標描述元數量限制

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

• 「您的指標描述詞配額已用盡。」

根據預設，這個限制設為 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 控制台中，前往 query_stats「Metrics management」頁面：

   前往「指標管理」

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

3. 確認「使用中」和「非使用中」指標的總和超過 25,000。在大多數情況下，您應該會看到大量的「Inactive」指標。
4. 在「快速篩選器」面板中選取「Inactive」，然後逐頁瀏覽清單，找出模式。
5. 在「快速篩選器」面板中選取「有效」，然後依「可計費的樣本數量」排序 (由高至低)，逐頁瀏覽清單，並找出模式。
6. 依可計費的樣本數量由低至高排序，逐頁瀏覽清單，並找出模式。

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

1. 在 Google Cloud 控制台中，選取與錯誤相關聯的 Google Cloud 專案。

2. 前往 Google Cloud 控制台的 leaderboard「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 端點中發出指標，您可以執行以下 port-forward 作業：

  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」錯誤會呈現週期性模式，在您或 location 標籤指定的 Google Cloud 區域負載過高時，這些錯誤會增加。
• 您向服務導入的指標資料量越多，就會看到越多錯誤。
• 您使用 statsd_exporter for Prometheus、Envoy for Istio、SNMP 匯出工具、Prometheus Pushgateway、kube-state-metrics，或是其他類似的匯出工具，這些工具可代表在環境中執行的其他資源，對指標進行中介處理並回報。這項問題只會發生在由這類匯出工具產生的指標。
• 您發現受影響的 KPI 在 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 的值會設為 statsd_exporter 本身的 IP:port，而非設定為發出指標的資源的 IP:port。instancejob 標籤可能會加劇這個問題，因為它不但與指標套件或服務無關，也因為設為 statsd-exporter 而缺乏多樣性。

在這種情況下，從指定叢集和命名空間內的此匯出工具取得的所有指標，都會寫入相同的 Monarch 目標。隨著這個目標變大，寫入作業開始失敗，您會看到越來越多的「Context deadline exceeded」503 錯誤。

如要確認這項問題是否發生在您身上，請與 Cloud 客戶服務團隊聯絡，請他們查看「Monarch 隔離器住院記錄」。請在您的支援單中加入任何已知的六個預留標籤值。請務必回報 Google Cloud 傳送資料的專案，而非指標範圍的 Google Cloud 專案。

如要修正這個問題，您必須變更收集管道，以便使用更多元的目標標籤。以下是一些潛在策略 (依有效性排序)：

• 請不要執行中央匯出程式，讓其代表所有虛擬機器或節點回報指標，而是為每個虛擬機器執行個別的匯出程式，做為節點代理程式，或將匯出程式部署為 Kubernetes Daemonset。為避免將 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 會參照有效的通訊埠。

• 匯出工具的部署規格已正確命名埠。

• 選取器 (通常為 app) 會與部署和 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，以便擷取及查詢資料。

並行編輯時發生錯誤

「專案設定同時編輯次數過多」錯誤訊息通常是暫時性的，幾分鐘後就會解決。這通常是因為移除會影響多個指標的重複標記規則。移除會導致專案中指標描述項的更新佇列形成。處理佇列後，錯誤就會消失。

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

查詢遭到 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 分鐘就執行一次。每分鐘執行 4 週費率查詢並非必要；4 週有 40,320 分鐘，因此每分鐘幾乎不會提供額外信號 (資料最多只會變動 1/40,320)。對於要求 4 週費率的查詢，使用 1 小時的評估間隔應該就足夠了。

只要解決因執行效率不佳的長時間執行查詢過於頻繁而導致的瓶頸，這個問題就會自行解決。

不相容的值類型

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

• 「指標 prometheus.googleapis.com/metric_name/gauge 的值類型必須為 INT64，但實際上是 DOUBLE」
• 「指標 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 以 INT64 格式收集 target_info，而在另一個專案中使用 Prometheus 以 DOUBLE 格式收集 target_info。將兩個指標新增至相同的指標範圍，然後透過指標範圍查詢該指標，會導致不相容的指標值類型之間產生無效的聯集。

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

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

按照這些步驟操作會刪除所有儲存為 INT64 指標的資料。刪除 INT64 指標是完全解決這個問題的唯一方法。