排解觀測能力問題

本文說明如何找出 Google Distributed Cloud (GDC) 離線裝置中可能發生的部署失敗和作業事件，並說明系統顯示的所有快訊，協助您解決記錄和監控元件的常見問題。

找出可觀測性元件

可觀測性平台會將元件部署至機構基礎架構叢集中的 obs-system 命名空間。

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

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

下表說明所有整合 Observability 平台的元件：

元件 說明
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 會重新啟動。
    • 「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>

確認 Observability 記錄堆疊是否正在執行

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

  1. 確認所有 Loki 執行個體或 Pod 都已注入 Istio Sidecar。確認名為 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)

    您必須為機構基礎架構叢集中的所有控制平面節點取得非零值。

確認 Observability 監控堆疊正在執行中

請按照下列步驟操作，確認監控堆疊正在執行：

  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 執行時未發生錯誤。

擷取可觀測性記錄

下表列出您必須執行的指令，才能擷取 Observability 平台部署的各個元件記錄。

元件 記錄擷取指令
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 自訂資源定義中參照該物件。您可以透過名為 logmon 的自訂資源定義，變更及查看 Alertmanager 設定。gpc-alertmanager-config

如要查看 Alertmanager 設定，請執行下列指令：

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

常見問題

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

無法存取 Grafana

根據預設，Grafana 不會向 Kubernetes 叢集外部的機器公開。如要暫時從機構基礎架構叢集外部存取 Grafana 介面，您可以將 Service 轉送至本機主機。如要轉送 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 使用者介面中，按一下「資訊主頁設定」。
  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 會執行多個分片，因此並非所有 Prometheus Pod 都會擷取 Pod。您可以從每個 Prometheus Pod 的名稱中找出分片編號。舉例來說，primary-prometheus-shard0-replica0-0 是分片 0 的一部分。從每個 Prometheus 分片檢查要抓取的 Pod：
    1. 將 obs-system 命名空間中 Prometheus 的 primary-prometheus-shardSHARD_NUMBER-replica0-0 Pod 轉送至通訊埠，即可存取 Prometheus UI。每次檢查新分片時，請將 Pod 名稱中的 SHARD_NUMBER 替換為遞增數字。
    2. 在網路瀏覽器中前往 Prometheus UI，然後按照下列步驟操作：
      1. 依序按一下「狀態」>「目標」。
      2. 確認要擷取的 Pod 是否在清單中。如果不是，請檢查下一個分片。如果沒有其他分片可檢查，請重新驗證 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 欄位定義條件必須為 true 的時間長度。interval 欄位定義評估條件的頻率。互相檢查這些欄位的值，確保條件符合邏輯。
  4. 在 Grafana UI 中，使用「Alerts」頁面檢查快訊是否開啟。
  5. 如果 Grafana 顯示快訊已開啟，請檢查通知管道，並確認 Alertmanager 可以聯絡這些管道來產生快訊。

無法提供預期記錄

如果沒有看到元件的運作記錄，請按照下列步驟操作：

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

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

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

找出預先定義的快訊規則

本節包含有關可觀測性元件中預先定義的警報規則資訊，這些規則會通知您系統故障。

Loki 中預先定義的快訊規則

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

Loki 中預先安裝的快訊規則，可偵測稽核記錄失敗情形
名稱 類型 說明
FluentBitAuditLoggingWriteFailure 重大 Fluent Bit 無法轉送過去五分鐘內的稽核記錄。
LokiAuditLoggingWriteFailure 重大 Loki 無法將稽核記錄寫入後端儲存空間。

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

Prometheus 中預先定義的快訊規則

下表列出 Prometheus 中 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 重大 機構基礎架構叢集上的部署作業處於非就緒狀態的時間已超過 15 分鐘。
StatefulSetNotReady 重大 機構基礎架構叢集上的 StatefulSet 物件處於非就緒狀態的時間已超過 15 分鐘。
AuditLogsForwarderDown 重大 anthos-audit-logs-forwarder DaemonSet 已停機超過 15 分鐘。
AuditLogsLokiDown 重大 audit-logs-loki StatefulSet 處於非就緒狀態的時間已超過 15 分鐘。