排解監控資訊主頁的問題

本頁說明如何解決 Google Kubernetes Engine (GKE) 監控資訊主頁的問題，例如資訊主頁未顯示或資料無法使用。如要進一步瞭解如何使用這些資訊主頁排解叢集和工作負載問題，請參閱「GKE 疑難排解簡介」。

建立叢集時，系統預設會啟用 Monitoring。 如果您在 Monitoring 中查看提供的 Google Cloud 資訊主頁時，沒有看到 GKE 資訊主頁，表示所選 Google Cloud 專案中的叢集未啟用 Monitoring。啟用監控功能，即可查看這些資訊主頁。

資訊主頁中沒有 Kubernetes 資源

如果您沒有在 GKE 資訊主頁中看見任何 Kubernetes 資源，請確認以下幾點：

選取的 Google Cloud 專案

確認已從 Google Cloud 控制台選單列的下拉式清單中選取正確的 Google Cloud 專案。您必須選取您要查看其資料的專案。

叢集活動

如果您剛剛建立叢集，請等待幾分鐘，讓其填入資料。詳情請參閱「設定 GKE 的記錄和監控功能」。

時間範圍

所選時間範圍可能太小。您可以使用資訊主頁工具列中的「時間」選單選取其他時間範圍，或定義「自訂」範圍。

查看資訊主頁的權限

如果您在查看服務的部署詳細資料或 Google Cloud 專案指標時，看到下列其中一個權限遭拒的錯誤訊息，則需要更新身分與存取權管理角色，以便納入 roles/monitoring.viewer 或 roles/viewer：

  • You do not have sufficient permissions to view this page
  • You don't have permissions to perform the action on the selected resources

詳情請參閱預先定義的角色。

叢集和節點服務帳戶將資料寫入 Monitoring 和 Logging 的權限

如果 Google Cloud 控制台的「已啟用 API 和服務」頁面顯示錯誤率較高，則表示您的服務帳戶可能缺少以下角色：

  • roles/logging.logWriter：在 Google Cloud 控制台中，這個角色稱為「記錄寫入者」。如要進一步瞭解 Logging 角色，請參閱 Logging 存取權控管指南。

  • roles/monitoring.metricWriter：在 Google Cloud 控制台中，這個角色名為「監控指標寫入者」。如要進一步瞭解 Monitoring 角色，請參閱 Monitoring 存取權控管指南。

  • roles/stackdriver.resourceMetadata.writer：在 Google Cloud 控制台中，這個角色稱為「Stackdriver 資源中繼資料寫入者」。這個角色可授予資源中繼資料的唯寫權限，並提供代理程式傳送中繼資料所需的適切權限。如要進一步瞭解 Monitoring 角色，請參閱 Monitoring 存取權控管指南。

如要列出服務帳戶，請在 Google Cloud 控制台中前往「IAM and Admin」(IAM 與管理)，然後選取「Service Accounts」(服務帳戶)。

無法查看記錄

如果資訊主頁未顯示記錄，請檢查下列事項：

代理程式正在執行且健康狀態良好

GKE 1.17 以上版本會使用 Fluent Bit 擷取記錄。Fluent Bit 是在 Kubernetes 節點上執行的 Logging 代理程式。如要檢查代理程式是否正常運作，請按照下列步驟操作：

  1. 執行下列指令，檢查代理程式是否重新啟動：

    kubectl get pods -l k8s-app=fluentbit-gke -n kube-system

    如果沒有重新啟動，輸出內容會類似如下：

    NAME                  READY   STATUS    RESTARTS   AGE
fluentbit-gke-6zr6g   2/2     Running   0          44d
fluentbit-gke-dzh9l   2/2     Running   0          44d

  2. 執行下列指令，檢查 Pod 狀態條件：

    JSONPATH='{range .items[*]};{@.metadata.name}:{range @.status.conditions[*]}{@.type}={@.status},{end}{end};'  \
 && kubectl get pods -l k8s-app=fluentbit-gke -n kube-system -o jsonpath="$JSONPATH" | tr ";" "\n"

    如果部署作業正常運作，輸出內容會與下列內容類似：

    fluentbit-gke-nj4qs:Initialized=True,Ready=True,ContainersReady=True,PodScheduled=True,
fluentbit-gke-xtcvt:Initialized=True,Ready=True,ContainersReady=True,PodScheduled=True,

  3. 執行下列指令，檢查 Pod 狀態，這有助於判斷部署作業是否正常運作：

    kubectl get daemonset -l k8s-app=fluentbit-gke -n kube-system

    如果部署作業正常運作，輸出內容會與下列內容類似：

    NAME            DESIRED   CURRENT   READY   UP-TO-DATE   AVAILABLE   NODE SELECTOR            AGE
fluentbit-gke   2         2         2       2            2           kubernetes.io/os=linux   5d19h

    在這個輸出範例中，所需狀態與目前狀態相符。

如果代理程式在這些情況下正常運作，但您仍未看到所有記錄，可能是因為代理程式超載而捨棄記錄。

代理程式負載過重，導致記錄檔遭捨棄

如果節點的記錄量過大，可能會導致代理程式過載，因此您可能無法看到所有記錄。GKE 中的預設 Logging 代理程式設定，是針對每個節點每秒 100 KiB 的速率進行調整，如果記錄檔量超過該限制，代理程式可能會開始捨棄記錄檔。

如要判斷是否達到這項限制，請留意下列指標：

  • 使用 container_name=fluentbit-gke 篩選器查看 kubernetes.io/container/cpu/core_usage_time 指標，確認 Logging 代理程式的 CPU 使用率是否接近或達到 100%。

  • 查看依 logging.googleapis.com/byte_count 分組的 metadata.system_labels.node_name 指標，確認是否有任何節點達到每秒 100 KiB。

如果出現上述任一情況，您可以為叢集新增更多節點，減少節點的記錄檔量。如果所有記錄檔容量都來自單一 Pod，則需要減少該 Pod 的容量。

如要進一步瞭解如何調查及解決 GKE 記錄相關問題，請參閱「排解 GKE 記錄問題」。

事件未與 GKE 資源相符？

如果警報政策條件會匯總不同 GKE 資源的指標，您可能需要編輯政策條件，加入更多 GKE 階層標籤，將事件與特定實體建立關聯。

舉例來說，您可能有兩個 GKE 叢集，一個用於正式環境，另一個用於暫存環境，每個叢集都有自己的服務 lilbuddy-2 副本。當快訊政策條件在兩個叢集中的容器之間彙整指標時，GKE Monitoring 資訊主頁無法將這項事件與正式版服務或測試版服務建立專屬關聯。

如要解決這個問題，請在政策的「依群組分組」欄位中新增 namespace、cluster 和 location，將快訊政策的目標設為特定服務。在快訊的事件資訊卡上，按一下「Update alert policy」(更新快訊政策) 連結，開啟相關快訊政策的「Edit alerting policy」(編輯快訊政策) 頁面。您可以在這裡更新快訊政策，加入額外資訊，讓資訊主頁找到相關聯的資源。

更新快訊政策後，GKE 監控資訊主頁就能將所有未來的事件與特定叢集中的專屬服務建立關聯，提供更多資訊來診斷問題。

視用途而定，您可能想篩選部分標籤，並將這些標籤新增至「分組依據」欄位。舉例來說，如果只想接收實際工作環境叢集的快訊，可以依 cluster_name 篩選。

後續步驟