排解觀測能力問題

本文提供疑難排解程序和預先定義系統警告的參考說明，協助您找出部署失敗的原因，並透過 Google Distributed Cloud (GDC) 實體隔離設備中的記錄和監控元件，解決作業事件。您可以使用這些程序和警告定義，確認記錄和監控堆疊是否正在執行、檢查管道設定，以及排解元件問題。

找出觀測能力元件

觀測能力平台會將元件部署至組織基礎架構叢集的 obs-system 命名空間。

基礎架構運算子 (IO) 的 Grafana 執行個體可讓您存取組織層級指標，監控 CPU 使用率和儲存空間用量等基礎架構元件。此外，您也可以存取作業和稽核記錄。此外，您也可以存取 GDC 可操作元件的快訊、記錄和指標。

GDC 監控和記錄堆疊使用開放原始碼解決方案，做為觀測能力平台的一部分。這些元件會從 Kubernetes Pod、裸機、網路切換裝置、儲存空間和代管服務收集記錄和指標。

下表說明整合觀測能力平台的所有元件：

元件 說明
Prometheus Prometheus 是時間序列資料庫，用於收集和儲存指標，以及評估快訊。Prometheus 會將指標儲存在組織基礎架構叢集的 Cortex 執行個體中，以便長期儲存。Prometheus 會以鍵/值組合的形式新增標籤，並從 Kubernetes 節點、Pod、裸機、網路切換裝置和儲存裝置收集指標。
Alertmanager Alertmanager 是使用者定義的管理系統，會在記錄或指標顯示系統元件故障或運作異常時傳送快訊。負責管理 Prometheus 警告的轉送、靜音和匯總。
Loki Loki 是時間序列資料庫，可儲存及匯總各種來源的記錄。為記錄建立索引，提高查詢效率。
Grafana Grafana 提供使用者介面 (UI)，可查看 Prometheus 收集的指標，並查詢對應 Loki 執行個體的稽核和作業記錄。使用者介面會以視覺化方式呈現指標和警告資訊主頁。
Fluent Bit Fluent Bit 是一種處理器，可從各種元件或位置提取記錄，並傳送至 Loki。在所有叢集的每個節點上執行。

找出部署失敗

如果部署作業正在執行且健康狀態良好，元件會以 READY 狀態執行。

請按照下列步驟找出部署失敗的原因：

  1. 確認元件的目前狀態：

    kubectl get -n obs-system TYPE/COMPONENT

    更改下列內容：

    • TYPE：元件類型
    • COMPONENT：元件名稱

    輸出內容大致如下：

    NAME       READY  AGE
COMPONENT  1/1    23h

    如果元件健康狀態良好，輸出內容的 READY 欄會顯示 N/N 值。如果 READY 欄未顯示值，不一定代表失敗。服務可能需要更多時間處理。

  2. 檢查各元件中的 Pod：

    kubectl get pods -n obs-system | awk 'NR==1 | /COMPONENT/'

    將 COMPONENT 替換為元件名稱。

    輸出內容大致如下：

    NAME       READY  STATUS   RESTARTS  AGE
COMPONENT  1/1    Running  0         23h

    確認 READY 欄顯示 N/N 值、STATUS 欄顯示 Running 值，且 RESTARTS 的數量不超過 2。

    重新啟動次數過多表示有下列問題：

    • Pod 失敗，Kubernetes 重新啟動 Pod。
    • 「STATUS」欄會顯示 CrashLoopBackoff 值。

    如要解決失敗狀態，請查看 Pod 的記錄檔。

    如果 Pod 處於 PENDING 狀態，表示出現下列一或多種症狀：

    • Pod 正在等待網路存取權，以便下載必要的容器。
    • 設定問題導致 Pod 無法啟動。例如，Pod 缺少必要的 Secret 值。
    • Kubernetes 叢集已用盡資源，無法排定 Pod。如果叢集上執行許多應用程式，就會發生這種情況。

  3. 判斷 PENDING 狀態的原因：

    kubectl describe -n obs-system pod/POD_NAME

    將 POD_NAME 替換為顯示 PENDING 狀態的 Pod 名稱。

    輸出內容會顯示 Pod 的詳細資料。

  4. 前往輸出內容的 Events 部分，查看列出 Pod 近期事件的表格，以及 PENDING 狀態原因的摘要。

    以下輸出內容顯示 Grafana StatefulSet 物件的 Events 區段範例：

    Events:
  Type    Reason            Age                From                    Message
  ----    ------            ----               ----                    -------
  Normal  SuccessfulCreate  13s (x3 over 12d)  statefulset-controller  create Pod grafana-0 in StatefulSet grafana successful

    如果 Pod 或任何其他資源長時間沒有事件，您會收到下列輸出內容：

      Events:         <none>

確認觀測能力記錄堆疊正在執行

請按照下列步驟操作，確認記錄堆疊正在運作：

  1. 確認所有 Loki 執行個體或 Pod 都已插入 Istio 邊車容器。確認所有名為 anthos-audit-logs-forwarder-SUFFIX 和 anthos-log-forwarder-SUFFIX 的 Fluent Bit Pod 都已插入 Istio sidecar。

  2. 確認所有 Loki 執行個體在組織基礎架構叢集中正常運作。

  3. 檢查 anthos-audit-logs-forwarder 和 anthos-log-forwarder DaemonSet 物件的狀態，確認所有執行個體都在所有節點中執行，且沒有錯誤。

  4. 確認您已取得所有叢集過去五分鐘內 kube-apiserver-SUFFIX 容器的作業記錄，以及 Kubernetes API 伺服器的稽核記錄。如要這麼做，請在 Grafana 執行個體中執行下列查詢：

    • 作業記錄：sum (count_over_time({service_name="apiserver"} [5m])) by (cluster, fluentbit_pod)
    • 稽核記錄：sum (count_over_time({cluster=~".+"} [5m])) by (cluster, node)

    機構基礎架構叢集中，所有控制層節點的值都不得為零。

確認觀測能力監控堆疊正在執行

請按照下列步驟，確認監控堆疊是否正在運作：

  1. 確認 Grafana 執行個體正在組織基礎架構叢集中執行。grafana-0 Pod 必須在下列命名空間中順利執行：

    • obs-system
    • infra-obs-obs-system
    • platform-obs-obs-system

  2. 確認所有監控元件都位於 Istio 服務網格中。請按照「找出部署作業失敗原因」一節中的步驟操作。下列每個 Pod 都必須在 READY 欄中顯示所有容器皆已就緒。例如，如果值為 3/3，表示三個容器都已準備就緒。此外，Pod 必須有 istio-proxy 容器。如果 Pod 不符合這些條件，請重新啟動 Pod：

    Pod 名稱 準備就緒的容器數量
    cortex- 2/2
    cortex-etcd-0 2/2
    cortex-proxy-server- 2/2
    cortex-tenant- 2/2
    meta-blackbox-exporter- 2/2
    meta-grafana-0 3/3
    meta-grafana-proxy-server- 2/2
    meta-prometheus-0 4/4
    cortex-alertmanager- 2/2
    cortex-compactor- 2/2
    cortex-distributor- 2/2
    cortex-etcd-0 2/2
    cortex-ingester- 2/2
    cortex-querier- 2/2
    cortex-query-frontend- 2/2
    cortex-query-scheduler- 2/2
    cortex-ruler- 2/2
    cortex-store-gateway- 2/2
    cortex-tenant- 2/2
    grafana-proxy-server- 2/2
    meta-blackbox-exporter- 2/2
    meta-grafana-0 3/3
    meta-grafana-proxy-server-* 2/2
    meta-prometheus-0 4/4

  3. 確認 Cortex 運作正常，沒有錯誤。

擷取觀測能力記錄

下表列出您必須執行的指令，以便擷取觀測平台部署的各個元件記錄。

元件 記錄擷取指令
grafana kubectl logs -n obs-system statefulset/grafana
anthos-prometheus-k8s kubectl logs -n obs-system statefulset/anthos-prometheus-k8s
alertmanager kubectl logs -n obs-system statefulset/alertmanager
ops-logs-loki-io kubectl logs -n obs-system statefulset/ops-logs-loki-io
ops-logs-loki-io-read kubectl logs -n obs-system statefulset/ops-logs-loki-io-read
ops-logs-loki-all kubectl logs -n obs-system statefulset/ops-logs-loki-all
ops-logs-loki-all-read kubectl logs -n obs-system statefulset/ops-logs-loki-all-read
audit-logs-loki-io kubectl logs -n obs-system statefulset/audit-logs-loki-io
audit-logs-loki-io-read kubectl logs -n obs-system statefulset/audit-logs-loki-io-read
audit-logs-loki-pa kubectl logs -n obs-system statefulset/audit-logs-loki-pa
audit-logs-loki-pa-read kubectl logs -n obs-system statefulset/audit-logs-loki-pa-read
audit-logs-loki-all kubectl logs -n obs-system statefulset/audit-logs-loki-all
audit-logs-loki-all-read kubectl logs -n obs-system statefulset/audit-logs-loki-all-read
anthos-log-forwarder kubectl logs -n obs-system daemonset/anthos-log-forwarder
anthos-audit-logs-forwarder kubectl logs -n obs-system daemonset/anthos-audit-logs-forwarder
oplogs-forwarder kubectl logs -n obs-system daemonset/oplogs-forwarder
logmon-operator kubectl logs -n obs-system deployment/logmon-operator

如要查看元件先前執行個體的記錄，請在每個指令結尾加上 -p 旗標。新增 -p 旗標後，您就能查看先前失敗執行個體的記錄，而非目前執行中的執行個體。

查看設定

觀測能力堆疊會使用 Kubernetes API 自訂資源，設定監控和記錄管道。

LoggingPipeline 自訂資源會部署在組織基礎架構叢集，並設定 Loki 執行個體。

下列指令會顯示您可對記錄管道執行的可用動作：

  • 查看記錄管道部署作業目前的設定：

    kubectl get loggingpipeline -n obs-system default -o yaml

  • 變更記錄管道部署作業的設定：

    kubectl edit loggingpipeline -n obs-system default

GDC 使用名為 logmon-operator 的記錄和監控運算子，管理 Prometheus 和 Fluent Bit 等觀測能力元件的部署作業。logmon-operator 元件的 API 是 logmon 自訂資源定義。logmon 自訂資源定義會指示 logmon-operator 如何為部署作業設定觀測能力。這項自訂資源定義包含儲存指標的磁碟區屬性、Alertmanager 的警告規則、收集指標的 Prometheus 設定，以及資訊主頁的 Grafana 設定。

下列指令會顯示您可對 logmon 自訂資源定義執行的可用動作：

  • 查看 Observability 部署作業目前的設定：

    kubectl get logmon -n obs-system logmon-default -o yaml

  • 變更觀測能力部署作業的設定：

    kubectl edit logmon -n obs-system logmon-default

執行任一指令的輸出內容可能會參照多個 Kubernetes ConfigMap 物件，以便進一步設定。舉例來說，您可以在個別的 ConfigMap 物件中設定 Alertmanager 規則，並在 logmon 自訂資源定義中依名稱參照該物件。您可以透過名為 gpc-alertmanager-config 的 logmon 自訂資源定義，變更及查看 Alertmanager 設定。

如要查看 Alertmanager 設定，請執行：

kubectl get configmap -n obs-system gpc-alertmanager-config -o yaml

常見問題

本節說明部署觀測平台時可能遇到的常見問題。

無法存取 Grafana

根據預設，Grafana 不會向 Kubernetes 叢集外部的機器公開。如要從組織基礎架構叢集外部暫時存取 Grafana 介面，可以將 Service 轉送至 localhost。如要轉送 Service 的通訊埠，請執行：

kubectl port-forward -n gpc-system service/grafana 33000\:3000

在網路瀏覽器中前往 http://localhost:33000，查看部署作業的 Grafana 資訊主頁。如要結束程序，請按下 Control+C 鍵。

Grafana 執行速度緩慢

Grafana 執行速度緩慢，表示：

  • 對 Prometheus 或 Loki 執行的查詢傳回過多資料。
  • 查詢傳回的資料量超過單一圖表可合理顯示的範圍。

如要解決 Grafana 速度緩慢的問題，請檢查自訂 Grafana 資訊主頁上的查詢。如果查詢傳回的資料量超過單一圖表可合理顯示的範圍，建議您減少顯示的資料量，以提升資訊主頁效能。

Grafana 資訊主頁未顯示任何指標或記錄

Grafana 未顯示任何指標或記錄，可能是因為下列原因：

  • Grafana 資料來源設定有誤。
  • 系統與監控或記錄資料來源的連線發生問題。
  • 系統未收集指標或記錄。

如要查看記錄和指標，請按照下列步驟操作：

  1. 在 Grafana 使用者介面中，按一下 「Dashboard settings」(資訊主頁設定)。
  2. 選取「資料來源」。
  3. 在「資料來源」頁面，確認您看到下列來源：
名稱 組織 網址
Audit Logs All http://audit-logs-loki-io-read.obs-system.svc:3100
Operational Logs Root http://ops-logs-loki-io-read.obs-system.svc:3100
Operational Logs Org http://ops-logs-loki-all-read.obs-system.svc:3100
prometheus http://anthos-prometheus-k8s.obs-system.svc:9090

如果缺少這些資料來源，表示觀測能力堆疊無法正確設定 Grafana。

如果您已正確設定資料來源，但未顯示任何資料，這可能表示收集指標或記錄檔並饋送至 Prometheus 或 Loki 的 Service 物件發生問題。

Prometheus 收集指標時，會遵循提取模型，定期查詢 Service 物件的指標，並儲存找到的值。如要讓 Prometheus 探索 Service 物件來收集指標，必須符合下列條件：

  • Service 物件的所有 Pod 都會加上 'monitoring.gke.io/scrape: "true"' 註解。

  • Prometheus 指標格式會透過 HTTP 公開 Pod 指標。根據預設，Prometheus 會在端點 http://POD_NAME:80/metrics 尋找這些指標。如有需要，您可以透過註解覆寫通訊埠、端點和結構定義。

Fluent Bit 會收集記錄，並在 Kubernetes 叢集的每個節點上執行。Fluent Bit 會將記錄傳送至 Loki，以便長期儲存。

如果 Grafana 中沒有任何記錄，請嘗試下列解決方法：

  • 查看 Loki 執行個體的記錄，確保執行時沒有錯誤。

  • 如果 Loki 執行個體運作正常，但未顯示記錄，請檢查 Fluent Bit 中的記錄，確保服務正常運作。如要瞭解如何提取記錄，請參閱「擷取觀測能力記錄」。

Alertmanager 未開啟警告

如果 Alertmanager 無法開啟快訊，請按照下列步驟操作：

  1. 在 gpc-system 命名空間中的 configMap 物件中，確認標籤 logmon: system_metrics 存在。
  2. 確認 configMap 資料區段包含名為 alertmanager.yml 的鍵。alertmanager.yml 鍵的值必須是有效的 Alertmanager 設定檔中包含的警告規則。

  3. 請確認 gpc-system 命名空間中名為 logmon-default 的 logmon 自訂資源定義含有 configMap 物件的參照。logmon-default 自訂資源定義必須包含 configMap 物件的名稱，如以下範例所示：

    apiVersion: addons.gke.io/v1
kind: Logmon
spec:
  system_metrics:
    outputs:
      default_prometheus:
        deployment:
          components:
            alertmanager:
              alertmanagerConfigurationConfigmaps:
                - alerts-config

    範例中的 alerts-config 值是 configMap 物件的名稱。

Alertmanager 未將警告傳送至設定的通知管道

即使 Alertmanager 在 Grafana 執行個體中產生快訊，設定錯誤仍可能導致您無法在設定為通知管道的外部軟體 (例如 Slack) 中收到通知。

如要在外部軟體中接收快訊，請按照下列步驟操作：

  1. 請檢查 Alertmanager 設定檔中的值格式是否正確。Alertmanager 觸發警告時，會查詢外部軟體上的 Webhook。

  2. 確認連結至外部軟體的 Webhook 網址正確無誤。如果網址正確，請確認軟體已設為接受 Webhook。您可能需要產生 API 金鑰，才能存取外部服務 API，或者目前的 API 金鑰可能已過期，需要重新整理。

  3. 如果外部服務位於 GDC 實體隔離方案設備部署項目之外，請確認組織基礎架構叢集已設定輸出規則。這項設定可讓 Alertmanager 將要求傳送至內部 Kubernetes 網路以外的服務。如果未驗證輸出規則，Alertmanager 可能無法找到外部軟體。

您無法查看專案範圍工作負載的指標

請按照下列步驟套用解決方法，並取得工作負載的指標：

  1. 確認 MonitoringTarget 自訂資源的狀態為 Ready。
  2. 如要抓取工作負載，您必須在工作負載 Pod 規格中，宣告指定給 MonitoringTarget 的所有目標資訊。舉例來說，如果您宣告指標可在通訊埠 8080 上使用，工作負載 Pod 必須向 Kubernetes 宣告通訊埠 8080 已開啟。否則 Prometheus 會忽略工作負載。
  3. Prometheus 會執行多個 shard，因此並非所有 Prometheus Pod 都會抓取您的 Pod。您可以從每個 Prometheus Pod 的名稱中找出 shard 編號。舉例來說，primary-prometheus-shard0-replica0-0 是 shard 0 的一部分。檢查要從每個 Prometheus shard 抓取資料的 Pod：
    1. 將 obs-system 命名空間中 Prometheus 的 primary-prometheus-shardSHARD_NUMBER-replica0-0 Pod 轉送至通訊埠，即可存取 Prometheus UI。每次檢查新的 shard 時，請將 Pod 名稱中的 SHARD_NUMBER 替換為遞增數字。
    2. 在網路瀏覽器中前往 Prometheus UI，然後按照下列步驟操作：
      1. 依序點選「狀態」>「目標」。
      2. 確認要抓取的 Pod 位於清單中。如果沒有，請檢查下一個 shard。如果沒有其他 shard 需要檢查，請重新驗證 Prometheus 是否有足夠的資訊可供探索。
    3. 確認 Prometheus 的 primary-prometheus-shardSHARD_NUMBER-replica0-0 Pod 會在 obs-system 命名空間中記錄錯誤。
  4. 確認 obs-system 命名空間中的 cortex-tenant Pod 記錄錯誤。

未建立資訊主頁

請按照下列步驟套用解決方法，並找出資訊主頁未建立的原因：

  1. 查看 Dashboard 自訂資源的狀態，確認是否有任何錯誤。自訂資源必須處於 Ready 狀態。
  2. 請確認您查看的是正確的 Grafana 執行個體。舉例來說，如果您在名為 my-namespace 的專案命名空間中部署資訊主頁，則資訊主頁必須位於 https://GDCH_URL/my-namespace/grafana 端點的 Grafana 執行個體中。
  3. 檢查 gpc-system 命名空間中 fleet-admin-controller 的記錄。在記錄中搜尋資訊主頁名稱，找出與資訊主頁相關的錯誤。如果發現錯誤，表示 configMap 物件中的 JSON 檔案格式不正確，必須修正。
  4. 查看 PROJECT_NAME-obs-system 命名空間中的 Grafana 記錄，找出任何錯誤。資訊主頁會查詢 Grafana REST API，因此 Grafana 必須正常運作，才能建立資訊主頁。

無法開啟快訊

請按照下列步驟套用解決方法，並找出快訊無法開啟的原因：

  1. 確認 Cortex 和 Loki 都處於 bucket-storage 模式。後端必須由 bucket 儲存空間支援，規則才會生效。
  2. 確認 MonitoringRule 和 LoggingRule 自訂資源的狀態為 Ready。
  3. 請檢查下列警告觸發條件：
    • PromQL 和 LogQL 運算式：請參閱「建立警告規則」說明文件，比較您使用的所有函式，確保規則設定符合需求。確認運算式會傳回 true 或 false 值。
    • 持續時間：自訂資源的 for 欄位定義條件必須符合的時間長度。interval 欄位定義評估條件的頻率。請檢查這些欄位的值是否彼此相符，並確保條件符合邏輯。
  4. 在 Grafana UI 的「Alerts」(快訊) 頁面，查看快訊是否已開啟。
  5. 如果 Grafana 顯示快訊已開啟，請檢查通知管道，並確認 Alertmanager 可以與這些管道聯絡，以產生快訊。

無法提供預期記錄

如果找不到元件的作業記錄，請按照下列步驟操作：

  1. 檢查元件是否正在執行並產生記錄。
  2. 確認是否應將元件記錄收集為內建功能。如果沒有，請確認您已部署 LoggingTarget 自訂資源，且該資源具有有效規格和 Ready 狀態。

如果找不到元件的稽核記錄，請按照下列步驟操作：

  1. 如果元件會將記錄寫入檔案，請確認該檔案確實存在於節點的檔案系統中，路徑為 /var/log/audit/SERVICE_NAME/NAMESPACE/ACCESS_LEVEL/audit.log。
  2. 確認同一節點上的 anthos-audit-logs-forwarder-SUFFIX Pod 沒有錯誤。
  3. 如果元件使用 syslog 端點接收記錄，請確認您已部署 AuditLoggingTarget 自訂資源，且該資源具有有效規格和 Ready 狀態。

找出預先定義的警告規則

本節說明 Observability 元件中預先定義的警告規則，這些規則會在系統故障時通知您。

Loki 中預先定義的警告規則

下表列出 Loki 中預先安裝的稽核記錄失敗警告規則：

Loki 預先安裝的警告規則，用於稽核記錄失敗
名稱 類型 說明
FluentBitAuditLoggingWriteFailure 重大 Fluent Bit 在過去五分鐘內無法轉送稽核記錄。
LokiAuditLoggingWriteFailure 重大 Loki 無法將稽核記錄寫入後端儲存空間。

如果顯示一或多則這類快訊，代表系統遺失至少一筆稽核記錄。

Prometheus 預先定義的警告規則

下表列出 Prometheus for Kubernetes 元件預先安裝的警告規則：

Prometheus 預先安裝的警告規則
名稱 類型 說明
KubeAPIDown 重大 Kube API 已從 Prometheus 目標探索中消失 15 分鐘。
KubeClientErrors 警告 Kubernetes API 伺服器用戶端的錯誤率已超過 0.01 達 15 分鐘。
KubeClientErrors 重大 Kubernetes API 伺服器用戶端的錯誤率已超過 0.1，且持續 15 分鐘。
KubePodCrashLooping 警告 Pod 處於當機迴圈狀態超過 15 分鐘。
KubePodNotReady 警告 Pod 處於未就緒狀態超過 15 分鐘。
KubePersistentVolumeFillingUp 重大 已聲明 PersistentVolume 物件的可用位元組數小於 0.03。
KubePersistentVolumeFillingUp 警告 已聲明 PersistentVolume 物件的可用位元組數小於 0.15。
KubePersistentVolumeErrors 重大 永久磁碟區處於 Failed 或 Pending 階段的時間已達五分鐘。
KubeNodeNotReady 警告 節點未就緒的時間超過 15 分鐘。
KubeNodeCPUUsageHigh 重大 節點的 CPU 使用率超過 80%。
KubeNodeMemoryUsageHigh 重大 節點的記憶體用量超過 80%。
NodeFilesystemSpaceFillingUp 警告 節點的檔案系統用量超過 60%。
NodeFilesystemSpaceFillingUp 重大 節點的檔案系統用量超過 85%。
CertManagerCertExpirySoon 警告 憑證將於 21 天後到期。
CertManagerCertNotReady 重大 10 分鐘後，憑證仍無法提供流量。
CertManagerHittingRateLimits 重大 建立或更新憑證時，您在五分鐘內達到頻率限制。
DeploymentNotReady 重大 組織基礎架構叢集上的 Deployment 處於未就緒狀態超過 15 分鐘。
StatefulSetNotReady 重大 組織基礎架構叢集上的 StatefulSet 物件處於未就緒狀態超過 15 分鐘。
AuditLogsForwarderDown 重大 anthos-audit-logs-forwarder DaemonSet 已停機超過 15 分鐘。
AuditLogsLokiDown 重大 audit-logs-loki StatefulSet 處於未就緒狀態超過 15 分鐘。