針對 Azure 監視器中的 Prometheus 計量集合進行疑難解答

發行項
03/20/2024

請遵循本文中的步驟，判斷在 Azure 監視器中未如預期收集 Prometheus 計量的原因。

復本 Pod 會從 kube-state-metrics、configmap 中的ama-metrics-prometheus-config自定義報廢目標，以及自定義資源中定義的自定義報廢目標來擷取計量。 DaemonSet Pod 會從其個別節點上的下列目標擷取計量：kubeletconfigmap 中的 ama-metrics-prometheus-config-node 、cAdvisor、 node-exporter和自定義報廢目標。您想要檢視記錄和 Prometheus UI 的 Pod 取決於您正在調查的目標。

使用 powershell 腳本進行疑難解答

如果您嘗試啟用 AKS 叢集的監視時發生錯誤，請遵循此處所述的指示來執行疑難解答腳本。此腳本的設計目的是要針對叢集上的任何組態問題執行基本診斷，而且您可以在建立支援要求以更快解決支援案例的同時，檢查產生的檔案。

計量節流

在 Azure 入口網站中，流覽至您的 Azure 監視器工作區。移至 Metrics 並確認計量 Active Time Series % Utilization 和 Events Per Minute Ingested % Utilization 低於100%。

如果其中一個都超過 100%，則會節流擷取至此工作區。在相同的工作區中，流覽至 New Support Request 以建立要求以增加限制。選取 [問題類型] 作為 Service and subscription limits (quotas) ，並將配額類型選取為 Managed Prometheus。

計量數據收集中的間歇性差距

在節點更新期間，您可能會看到從叢集層級收集器所收集計量數據的計量數據有 1 到 2 分鐘的差距。此差距是因為其執行的節點正在更新為一般更新程式的一部分。它會影響整個叢集的目標，例如 kube-state-metrics 和指定的自定義應用程式目標。當您的叢集手動或透過自動更新更新時，就會發生此情況。這是預期的行為，發生的原因是執行的節點正在更新。我們建議的警示規則都不會受到此行為的影響。

Pod 狀態

使用下列命令檢查 Pod 狀態：

kubectl get pods -n kube-system | grep ama-metrics

叢集上每個節點都應該有一個 ama-metrics-xxxxxxxxxx-xxxxx 復本 Pod、一個 ama-metrics-operator-targets-*、一個 ama-metrics-ksm-* Pod 和一個 ama-metrics-node-* Pod。
每個 Pod 狀態都應該是 Running ，且重新啟動數目等於已套用的 configmap 變更數目。 ama-metrics-operator-targets-* Pod 在開頭可能會有額外的重新啟動，而且這是預期的：

如果每個 Pod 狀態都只是 Running 一或多個 Pod 重新啟動，請執行下列命令：

kubectl describe pod <ama-metrics pod name> -n kube-system

此命令提供重新啟動的原因。如果已進行 configmap 變更，則 Pod 會重新啟動。如果重新啟動 OOMKilled的原因是，Pod 就無法跟上計量的量。請參閱計量數量的規模建議。

如果 Pod 如預期般執行，則下一個檢查位置是容器記錄。

容器記錄

使用下列命令檢視容器記錄：

kubectl logs <ama-metrics pod name> -n kube-system -c prometheus-collector

啟動時，會以紅色列印任何初始錯誤，而警告會以黃色列印。（檢視彩色記錄至少需要 PowerShell 第 7 版或 Linux 發行版。

確認取得驗證權杖是否有問題：
- AKS 資源未出現任何設定訊息會每隔 5 分鐘記錄一次。
- Pod 會每隔 15 分鐘重新啟動一次，再試一次，並出現錯誤： AKS 資源沒有設定。
  - 如果是，請檢查您的資源群組中是否存在數據收集規則和數據收集端點。
  - 也請確認 Azure 監視器工作區存在。
  - 確認您沒有私人 AKS 叢集，且它未連結到任何其他服務的 Azure 監視器 Private Link 範圍。目前不支援此案例。

設定處理

使用下列命令檢視容器記錄：

kubectl logs <ama-metrics-operator-targets pod name> -n kube-system -c config-reader

確認剖析 Prometheus 組態、合併已啟用任何預設的報廢目標，以及驗證完整設定沒有任何錯誤。
如果您確實包含自定義 Prometheus 組態，請確認其已在記錄中辨識。如果不是：
- 確認您的 configmap 具有正確的名稱： ama-metrics-prometheus-config 在命名空間中 kube-system 。
- 確認在 configmap 中，您的 Prometheus 組態位於名為 prometheus-config 的區段底下 data ，如下所示：
```
kind: ConfigMap
apiVersion: v1
metadata:
  name: ama-metrics-prometheus-config
  namespace: kube-system
data:
  prometheus-config: |-
    scrape_configs:
    - job_name: <your scrape job here>
```
如果您已建立自定義資源，則應該會在建立Pod/服務監視器期間看到任何驗證錯誤。如果您仍然看不到目標中的計量，請確定記錄不會顯示任何錯誤。

kubectl logs <ama-metrics-operator-targets pod name> -n kube-system -c targetallocator

確認與 Azure 監視器工作區進行驗證沒有任何錯誤 MetricsExtension 。
OpenTelemetry collector確認沒有關於擷取目標的錯誤。

執行以下命令：

kubectl logs <ama-metrics pod name> -n kube-system -c addon-token-adapter

如果向 Azure 監視器工作區進行驗證時發生問題，此命令會顯示錯誤。下列範例顯示沒有問題的記錄：

如果記錄中沒有任何錯誤，則 Prometheus 介面可用於偵錯，以確認預期的組態和目標已遭到擷取。

Prometheus 介面

每個 ama-metrics-* Pod 都有可在埠 9090 上使用 Prometheus 代理程式模式用戶介面。 Pod 會報ama-metrics-*廢自訂組態和自訂資源目標，而 Pod 的節點目標則ama-metrics-node-*為。埠轉送至複本 Pod 或其中一個精靈設定 Pod，以檢查組態、服務探索和目標端點，如這裡所述，確認自定義組態正確無誤、已針對每個作業探索預期目標，而且沒有擷取特定目標的錯誤。

執行 kubectl port-forward <ama-metrics pod> -n kube-system 9090 命令。

開啟瀏覽器至位址 127.0.0.1:9090/config。此使用者介面具有完整的抓取組態。確認所有作業都包含在組態中。
移至以 127.0.0.1:9090/service-discovery 檢視指定之服務探索物件所探索的目標，以及relabel_configs篩選目標的目標。例如，當遺漏特定 Pod 的計量時，您可以找出該 Pod 是否已探索到，以及其 URI 是什麼。然後，您可以在查看目標時使用此 URI，以查看是否有任何刮傷錯誤。
移至以 127.0.0.1:9090/targets 檢視所有作業、上次取消該作業的端點，以及任何錯誤

自訂資源

如果您確實包含自定義資源，請確定它們會顯示在設定、服務探索和目標下。

組態

服務探索

目標

如果沒有任何問題，且預定的目標正在遭到擷取，您可以啟用偵錯模式來檢視所要擷取的確切計量。

偵錯模式

警告

此模式可能會影響效能，而且只應該短時間啟用以進行偵錯。

您可以依照這裡的指示，將下的 truedebug-mode configmap 設定enabled變更為，以在偵錯模式中執行計量附加元件。

啟用時，所有已報廢的 Prometheus 計量都會裝載在埠 9091。執行以下命令：

kubectl port-forward <ama-metrics pod name> -n kube-system 9091

在瀏覽器中移至 127.0.0.1:9091/metrics ，以查看 OpenTelemetry 收集器是否已取消計量。每個 Pod 都可以存取 ama-metrics-* 此使用者介面。如果計量不存在，計量或標籤名稱長度或標籤數目可能會有問題。另請檢查是否超過本文所指定 Prometheus 計量的擷取配額。

計量名稱、標籤名稱和標籤

代理程式型擷取目前有下表的限制：

屬性	限制
標籤名稱長度	小於或等於 511 個字元。當作業中任何時間序列超過此限制時，整個報廢作業就會失敗，並在擷取之前從該作業卸除計量。您可以看到該作業的 up=0，而且目標 Ux 會顯示 up=0 的原因。
標籤值長度	小於或等於 1023 個字元。當作業中的任何時間序列超過此限制時，整個報廢就會失敗，並在擷取之前從該作業卸除計量。您可以看到該作業的 up=0，而且目標 Ux 會顯示 up=0 的原因。
每個時間序列的標籤數目	小於或等於 63。當作業中任何時間序列超過此限制時，整個報廢作業就會失敗，並在擷取之前從該作業卸除計量。您可以看到該作業的 up=0，而且目標 Ux 會顯示 up=0 的原因。
計量名稱長度	小於或等於 511 個字元。當作業中的任何時間序列超過此限制時，只會卸除該特定數列。 MetricextensionConsoleDebugLog 具有已卸除計量的追蹤。
使用不同大小寫的標籤名稱	相同計量範例內的兩個標籤，將不同的大小寫視為具有重複標籤，並在內嵌時卸除。例如，由於標籤重複，因此會卸除時間序列 `my_metric{ExampleLabel="label_value_0", examplelabel="label_value_1}` ，因為 `ExampleLabel` 和 `examplelabel` 被視為相同的標籤名稱。

檢查 Azure 監視器工作區上的擷取配額

如果您看到計量遺失，您可以先檢查 Azure 監視器工作區是否已超過擷取限制。在 Azure 入口網站中，您可以檢查任何 Azure 監視器工作區的目前使用量。您可以在 Azure 監視器工作區的功能表下 Metrics 看到目前的使用計量。下列使用率計量可作為每個 Azure 監視器工作區的標準計量。

使用中時間序列 - 過去 12 小時內最近擷取至工作區的唯一時間序列數目
使用中時間序列限制 - 可主動內嵌至工作區的唯一時間序列數目限制
使用中時間序列 % 使用率 - 目前使用中時間序列的百分比
每分鐘擷取的事件數 - 最近收到的每分鐘事件數（範例）
每分鐘擷取的事件限制 - 每個分鐘可擷取的事件數目上限，再進行節流處理
每分鐘擷取的事件 % 使用率 - 目前計量擷取速率限制的百分比為 util

請參閱預設配額的服務配額和限制，以及了解根據您的使用量可以增加的內容。您可以使用 Azure 監視器工作區的功能表，要求增加 Azure 監視器工作區 Support Request 的配額。請確定您在支援要求中包含 Azure 監視器工作區的識別碼、內部識別碼和位置/區域，您可以在 Azure 入口網站中 Azure 監視器工作區的 [屬性] 選單中找到該識別碼、內部識別碼和位置/區域。

下一步

檢查收集大規模計量的考慮。

Share via