GSP736

總覽

Cloud Logging 和其輔助工具 Cloud Monitoring 都是功能完整的產品，且與 Google Kubernetes Engine 深度整合。本實驗室將說明 Cloud Logging 如何搭配 GKE 叢集和應用程式運作，並透過記錄的常見用途，介紹記錄收集作業的最佳做法。

目標

本實驗室的學習內容包括：

• 使用 Cloud Monitoring 偵測問題
• 使用 Cloud Logging 排解應用程式在 GKE 執行時出現的問題

實驗室中使用的示範應用程式

您會使用一個具體範例，對部署至 GKE 叢集的微服務示範應用程式進行疑難排解。這個示範應用程式包含許多微服務，且彼此之間有依附關係。您將使用 loadgenerator 產生流量，然後透過 Logging、Monitoring 和 GKE 注意到錯誤 (警告/指標)，並使用 Logging 找出根本原因，最後透過 Logging 和 Monitoring 修正/確認問題已修正。

設定和需求

瞭解以下事項後，再點選「Start Lab」按鈕

請詳閱以下操作說明。實驗室活動會計時，且中途無法暫停。點選「Start Lab」後就會開始計時，顯示可使用 Google Cloud 資源的時間。

您將在真正的雲端環境完成實作實驗室活動，而不是模擬或示範環境。為此，我們會提供新的暫時憑證，供您在實驗室活動期間登入及存取 Google Cloud。

為了順利完成這個實驗室，請先確認：

• 可以使用標準的網際網路瀏覽器 (Chrome 瀏覽器為佳)。

注意事項：請使用無痕模式 (建議選項) 或私密瀏覽視窗執行此實驗室，這可以防止個人帳戶和學員帳戶之間的衝突，避免個人帳戶產生額外費用。

• 是時候完成實驗室活動了！別忘了，活動一旦開始將無法暫停。

注意事項：務必使用實驗室專用的學員帳戶。如果使用其他 Google Cloud 帳戶，可能會產生額外費用。

如何開始研究室及登入 Google Cloud 控制台

1. 點選「Start Lab」按鈕。如果實驗室會產生費用，畫面上會出現選擇付款方式的對話方塊。左側的「Lab Details」窗格會顯示下列項目：

   • 「Open Google Cloud console」按鈕
   • 剩餘時間
   • 必須在這個研究室中使用的臨時憑證
   • 完成這個實驗室所需的其他資訊 (如有)

2. 點選「Open Google Cloud console」；如果使用 Chrome 瀏覽器，也能按一下滑鼠右鍵，選取「在無痕視窗中開啟連結」。

   接著，實驗室會啟動相關資源，並開啟另一個分頁，顯示「登入」頁面。

   提示：您可以在不同的視窗中並排開啟分頁。

   注意：如果頁面中顯示「選擇帳戶」對話方塊，請點選「使用其他帳戶」。

3. 如有必要，請將下方的 Username 貼到「登入」對話方塊。

   {{{user_0.username | "Username"}}}

   您也可以在「Lab Details」窗格找到 Username。

4. 點選「下一步」。

5. 複製下方的 Password，並貼到「歡迎使用」對話方塊。

   {{{user_0.password | "Password"}}}

   您也可以在「Lab Details」窗格找到 Password。

6. 點選「下一步」。

   重要事項：請務必使用實驗室提供的憑證，而非自己的 Google Cloud 帳戶憑證。 注意：如果使用自己的 Google Cloud 帳戶來進行這個實驗室，可能會產生額外費用。

7. 按過後續的所有頁面：

   • 接受條款及細則。
   • 由於這是臨時帳戶，請勿新增救援選項或雙重驗證機制。
   • 請勿申請免費試用。

Google Cloud 控制台稍後會在這個分頁開啟。

注意：如要使用 Google Cloud 產品和服務，請點選「導覽選單」，或在「搜尋」欄位輸入服務或產品名稱。

啟動 Cloud Shell

Cloud Shell 是搭載多項開發工具的虛擬機器，提供永久的 5 GB 主目錄，而且在 Google Cloud 中運作。Cloud Shell 提供指令列存取權，方便您使用 Google Cloud 資源。

1. 點按 Google Cloud 控制台頂端的「啟用 Cloud Shell」圖示 。

2. 系統顯示視窗時，請按照下列步驟操作：

   • 繼續操作 Cloud Shell 視窗。
   • 授權 Cloud Shell 使用您的憑證發出 Google Cloud API 呼叫。

連線建立完成即代表已通過驗證，而且專案已設為您的 Project_ID：。輸出內容中有一行文字，宣告本工作階段的 Project_ID：

Your Cloud Platform project in this session is set to {{{project_0.project_id | "PROJECT_ID"}}}

gcloud 是 Google Cloud 的指令列工具，已預先安裝於 Cloud Shell，並支援 Tab 鍵自動完成功能。

3. (選用) 您可以執行下列指令來列出使用中的帳戶：

gcloud auth list

4. 點按「授權」。

輸出內容：

ACTIVE: * ACCOUNT: {{{user_0.username | "ACCOUNT"}}} To set the active account, run: $ gcloud config set account `ACCOUNT`

5. (選用) 您可以使用下列指令來列出專案 ID：

gcloud config list project

輸出內容：

[core] project = {{{project_0.project_id | "PROJECT_ID"}}} 注意：如需 gcloud 的完整說明，請前往 Google Cloud 參閱 gcloud CLI 總覽指南。

設定區域和可用區

某些 Compute Engine 資源專屬於特定的區域和可用區。「區域」是您可以執行資源的特定地理位置，每個區域中會有一或多個「可用區」。

請在 Cloud 控制台中執行下列 gcloud 指令，設定研究室的預設區域和可用區：

gcloud config set compute/zone "{{{project_0.default_zone|ZONE}}}" export ZONE=$(gcloud config get compute/zone) gcloud config set compute/region "{{{project_0.default_region|REGION}}}" export REGION=$(gcloud config get compute/region)

工作 1：設定基礎架構

請連線至 Google Kubernetes Engine 叢集，並確認虛擬機器已正確建立。

1. 設定專案 ID 變數：

export PROJECT_ID={{{project_0.startup_script.project | Project ID}}}

2. 使用下列指令查看叢集狀態：

gcloud container clusters list

叢集狀態會顯示「PROVISIONING」。

3. 請稍候片刻，然後再次執行上方指令，直到狀態顯示為「RUNNING」。這可能需要幾分鐘的時間。

4. 確認已建立名為 central 的叢集。

您也可以依序點選「導覽選單」>「Kubernetes Engine」>「叢集」，從 Cloud 控制台監控進度。

5. 叢集狀態成為「RUNNING」後，請取得叢集憑證：

gcloud container clusters get-credentials central --zone $ZONE

輸出內容：

Fetching cluster endpoint and auth data. kubeconfig entry generated for central.

6. 確認節點已建立：

kubectl get nodes

輸出內容應如下所示：

NAME STATUS ROLES AGE VERSION gke-central-default-pool-5ff4130f-qz8v Ready 24d v1.27.2-gke.1200 gke-central-default--pool-5ff4130f-ssd2 Ready 24d v1.27.2-gke.1200 gke-central-default--pool-5ff4130f-tz63 Ready 24d v1.27.2-gke.1200 gke-central-default--pool-5ff4130f-zfmn Ready 24d v1.27.2-gke.1200

工作 2：部署應用程式

接著，將名為 Hipster Shop 的微服務應用程式部署至叢集，建立可監控的工作負載。

1. 執行下列指令，複製存放區：

git clone https://github.com/xiangshen-dk/microservices-demo.git

2. 切換至 microservices-demo 目錄：

cd microservices-demo

3. 使用 kubectl 安裝應用程式：

kubectl apply -f release/kubernetes-manifests.yaml

4. 確認一切運作正常：

kubectl get pods

輸出內容大致如下：

NAME READY STATUS RESTARTS AGE adservice-55f94cfd9c-4lvml 1/1 Running 0 20m cartservice-6f4946f9b8-6wtff 1/1 Running 2 20m checkoutservice-5688779d8c-l6crl 1/1 Running 0 20m currencyservice-665d6f4569-b4sbm 1/1 Running 0 20m emailservice-684c89bcb8-h48sq 1/1 Running 0 20m frontend-67c8475b7d-vktsn 1/1 Running 0 20m loadgenerator-6d646566db-p422w 1/1 Running 0 20m paymentservice-858d89d64c-hmpkg 1/1 Running 0 20m productcatalogservice-bcd85cb5-d6xp4 1/1 Running 0 20m recommendationservice-685d7d6cd9-pxd9g 1/1 Running 0 20m redis-cart-9b864d47f-c9xc6 1/1 Running 0 20m shippingservice-5948f9fb5c-vndcp 1/1 Running 0 20m

5. 請重新執行指令，直到所有 Pod 的狀態都顯示為「Running」，再繼續下一個步驟。

點選「Check my progress」，確認目標已達成。 部署應用程式

6. 執行下列指令，取得應用程式的外部 IP。這項指令只會在服務部署完成後傳回 IP 位址，因此您可能需要重複執行指令，直到系統指派外部 IP 位址為止：

export EXTERNAL_IP=$(kubectl get service frontend-external | awk 'BEGIN { cnt=0; } { cnt+=1; if (cnt > 1) print $4; }')

7. 最後，確認應用程式已啟動並執行：

curl -o /dev/null -s -w "%{http_code}\n" http://$EXTERNAL_IP

確認訊息如下所示：

200

應用程式部署完成後，您也可以前往 Cloud 控制台查看狀態。

在「Kubernetes Engine」>「工作負載」頁面，您會看到所有 Pod 均正常運作。

8. 接著選取「閘道、Service 與 Ingress」，然後點按「服務」分頁標籤，確認所有服務都正常運作。請停留在這個畫面，以繼續設定應用程式的監控作業。

工作 3：開啟應用程式

1. 向下捲動至 frontend-external，然後點按服務的端點 IP。

應用程式應該會開啟，您會看到類似下方的頁面：

工作 4：建立記錄指標

接著設定 Cloud Logging，建立記錄指標。記錄指標是 Cloud Monitoring 中的自訂指標，由記錄項目組成。記錄指標適合用來計算記錄項目數量，以及追蹤記錄中值的分布情形。在本例中，您將使用記錄指標計算前端服務中的錯誤數量。接著，您就能在資訊主頁和警告中使用這個指標。

1. 返回 Cloud 控制台，從「導覽選單」開啟「Logging」，然後點選「Logs Explorer」。

2. 啟用「顯示查詢」，並在「查詢建立工具」方塊中新增下列查詢：

resource.type="k8s_container" severity=ERROR labels."k8s-pod/app": "recommendationservice"

3. 按一下「執行查詢」。

您使用的查詢可找出前端 Pod 的所有錯誤。不過，由於目前沒有錯誤，因此您應該不會看到任何結果。

4. 要建立記錄指標，請點選「動作」下拉式選單，然後選取「建立指標」。

5. 將指標命名為 Error_Rate_SLI，然後點選「建立指標」儲存記錄指標：

現在，您會在「記錄指標」頁面的「使用者定義的指標」下方看到該指標。

點選「Check my progress」，確認目標已達成。 建立記錄指標

工作 5：建立警告政策

警告可讓您及時瞭解雲端應用程式中的問題，以便您快速解決問題。現在您要使用 Cloud Monitoring，根據先前建立的前端錯誤記錄指標，建立警告政策來監控前端服務可用性。當符合警告政策的條件時，Cloud Monitoring 會建立事件，並在 Cloud 控制台中顯示。

1. 在「導覽選單」中開啟「監控」，然後點選「警告」。

2. 工作區建立完成後，點選頂端的「Create Policy」(建立政策)。

附註：如有需要，點選「試試看！」即可使用更新的警告建立流程。

3. 按一下「選取指標」下拉式選單。取消勾選「Active」。

4. 在「依據資源或指標名稱篩選」欄位中，輸入 Error_Rate。

5. 依序點選「Kubernetes Container」>「記錄指標」。選取「logging/user/Error_Rate_SLI」，然後點選「套用」。

畫面應如下所示：

6. 將「滾動週期函式」設為 Rate。

7. 點按「Next」。

8. 將「門檻值」設為 0.5。

如預期，沒有任何失敗，應用程式符合可用性服務水準目標 (SLO)。

9. 再次點按「Next」。

10. 停用「使用通知管道」。

11. 提供警告名稱，例如 Error Rate SLI，然後點按「Next」。

12. 檢查警告是否設定妥當，然後點選「建立政策」。

附註：本實驗室不會建立通知管道，但您應為正式環境中執行的應用程式建立通知管道，以便透過電子郵件、行動應用程式、簡訊、Pub/Sub 和 Webhook 等方式傳送通知。

點選「Check my progress」，確認目標已達成。 建立警告政策

觸發應用程式錯誤

現在您要使用負載產生器，為網頁應用程式建立一些流量。由於這個版本的應用程式刻意導入錯誤，因此當流量達到一定程度時，就會觸發錯誤。您將逐步找出並修正錯誤。

1. 在「導覽選單」中，依序選取「Kubernetes Engine」>「閘道、Service 與 Ingress」，然後點選「服務」分頁標籤。

2. 找出 loadgenerator-external 服務，然後點按端點連結。

或者，您也可以開啟新的瀏覽器分頁或視窗，將 IP 複製/貼上至網址欄位，例如：http://\[loadgenerator-external-ip\]

您現在應該會位於 Locust 負載產生器頁面：

Locust 是開放原始碼的負載產生器，可讓您對網頁應用程式進行負載測試。這項工具能以特定速率，模擬多位使用者同時存取應用程式端點。

1. 模擬 300 名使用者以 30 的產生率存取應用程式。Locust 會以每秒 30 名使用者的速度新增使用者，直到達到 300 名為止。

2. 在「主機」欄位中，請使用 frontend-external。從「閘道、Service 與 Ingress」頁面複製網址，請務必去除通訊埠。例如：

3. 點選「Start swarming」按鈕。您應該會有約 300 名使用者在幾秒內造訪預先定義的網址。

4. 點選「Failures」分頁標籤，即可看到開始出現失敗。您可以看到有大量的 500 錯誤。

同時，如果從首頁點選任何產品，速度會明顯變慢，或是點選產品時收到下列錯誤訊息：

確認警告和應用程式錯誤

1. 在控制台的「導覽選單」中，依序點選「監控」和「警告」。您應該很快就會看到 logging/user/Error_Rate_SLI 的事件。如果沒有立即看到事件，請稍候一兩分鐘，然後重新整理頁面。警告最多可能需要 5 分鐘才會觸發。

2. 點選事件連結：

系統會將您導向詳細資料頁面。

3. 在「Logs」部分，點選「在 Logs Explorer 中查看」，然後從下拉式選單中選取專案 ID，即可查看 Pod 記錄。

4. 您也可以在記錄檔欄位瀏覽器面板中點選「錯誤」標籤，只查詢錯誤。

或者，您也可以點按「查詢預覽」欄位，使系統顯示查詢建立工具，然後點按「嚴重性」下拉式選單，將「錯誤」新增至查詢。點選「新增」按鈕，然後點選「執行查詢」。下拉式選單可新增多個嚴重性值。

無論採用哪種方式，結果都是在查詢中加入 severity=ERROR。完成後，您應該會看到 recommendationservice Pod 的所有錯誤。

5. 展開錯誤事件，即可查看錯誤詳細資料。例如：

6. 展開 textPayload。

7. 點按錯誤訊息，然後選取「在摘要行中新增欄位」，即可將錯誤訊息顯示為摘要欄位：

從這裡可以確認 RecommendationService 服務確實發生許多錯誤。根據錯誤訊息，RecommendationService 無法連線至部分下游服務，因此無法取得產品或推薦內容。不過，目前仍不清楚錯誤的根本原因。

回顧架構圖，您會發現 RecommendationService 會向 Frontend 服務提供建議清單。然而 Frontend 服務和 RecommendationService 都會叫用 ProductCatalogService 來取得產品清單。

在下一個步驟中，您將查看主嫌 ProductCatalogService 的指標，尋找任何異常狀況。無論如何，您都可以深入查看記錄檔，設法取得一些洞察資訊。

使用 Kubernetes 資訊主頁和記錄檔進行疑難排解

1. 要查看指標，您可以先前往 Monitoring 控制台的「Kubernetes Engine」部分 (依序點選「導覽選單」>「Monitoring」>「資訊主頁」>「GKE」)。

2. 查看「工作負載」部分。

3. 依序前往「Kubernetes Engine」>「工作負載」>「productcatalogservice」。您會發現服務的 Pod 不斷異常終止並重新啟動。

接著，查看記錄中是否有任何值得注意的內容。

有 2 種簡單的方法可取得容器記錄：

1. 點選「記錄」分頁標籤，即可快速查看最新記錄。接著點選記錄面板右上角的外部連結按鈕，返回 Logs Explorer。

2. 在總覽頁面的「Deployment 詳細資料」頁面，點選「Container logs」連結。

您再次來到「Logs Explorer」頁面，現在頁面中已預先定義查詢，專門篩選您在 GKE 中查看的容器記錄。

從記錄檢視器中，記錄訊息和直方圖都顯示容器在短時間內重複剖析產品目錄。這似乎非常沒有效率。

查詢結果底部也可能出現執行階段錯誤，像是：

panic: runtime error: invalid memory address or nil pointer dereference [signal SIGSEGV: segmentation violation

這實際上可能會導致 Pod 異常終止。

如要進一步瞭解原因，請在程式碼中搜尋記錄訊息。

1. 在 Cloud Shell 中執行下列指令：

grep -nri 'successfully parsed product catalog json' src

輸出內容應如下所示，其中包含來源檔案名稱和行號：

src/productcatalogservice/server.go:237: log.Info("successfully parsed product catalog json")

2. 如要查看來源檔案，請點選 Cloud Shell 選單中的「開啟編輯器」按鈕，然後點選「在新視窗中開啟」 (如果看到「第三方 Cookie 已停用，因此無法載入程式碼編輯器」錯誤，請點選 Chrome 頁面頂端的眼睛圖示)。

3. 點選 microservices-demo/src/productcatalogservice/server.go 檔案，向下捲動至第 237 行，您會看到 readCatalogFile 方法記錄了以下訊息：

再多花點心思，您會發現如果布林變數 reloadCatalog 為 true，服務每次叫用時都會重新載入並剖析產品目錄，這似乎沒有必要。

在程式碼中搜尋 reloadCatalog 變數，即可看到該變數是由環境變數 ENABLE_RELOAD 控制，而且系統會記錄其狀態訊息。

將這則訊息新增至查詢，再次檢查記錄，判斷是否有任何項目存在。

1. 返回「Logs Explorer」分頁，在查詢中加入下列程式碼行：

jsonPayload.message:"catalog reloading"

因此，查詢建立工具中的完整查詢如下：

resource.type="k8s_container" resource.labels.location="{{{project_0.startup_script.zone | ZONE}}}" resource.labels.cluster_name="central" resource.labels.namespace_name="default" labels.k8s-pod/app="productcatalogservice" jsonPayload.message:"catalog reloading"

2. 再次點選「執行查詢」，在容器記錄中尋找「Enable catalog reloading」訊息，確認目錄重新載入功能已啟用。

這時您就能確定，前端錯誤是因為每次要求都必須載入目錄造成的。這個問題增加了額外的負荷，導致服務失敗並產生錯誤。

工作 6：修正問題並驗證效果

根據程式碼和記錄內容，您可以停用目錄重新載入功能，嘗試藉此解決問題。您現在要移除產品目錄服務的 ENABLE_RELOAD 環境變數。變更後，即可重新部署應用程式，確認此變更已解決觀察到的問題。

1. 如果 Cloud Shell 終端機已關閉，請點選「開啟終端機」按鈕返回。

2. 執行下列指令：

grep -A1 -ni ENABLE_RELOAD release/kubernetes-manifests.yaml

輸出內容會顯示資訊清單檔案中環境變數的行號：

373: - name: ENABLE_RELOAD 374- value: "1"

3. 執行下列指令，刪除這兩行程式碼，即可停用重新載入功能：

sed -i -e '373,374d' release/kubernetes-manifests.yaml

4. 接著重新套用資訊清單檔案：

kubectl apply -f release/kubernetes-manifests.yaml

您會發現只有 productcatalogservice 顯示「configured」，其他服務則是「unchanged」。

5. 返回「Deployment 詳細資料」頁面 (依序點選「導覽選單」>「Kubernetes Engine」>「工作負載」>「productcatalogservice」)，等待 Pod 順利執行。等待 2 至 3 分鐘，或確認應用程式不再異常終止。

6. 再次點選「Container logs」連結，您會發現重複的 successfully parsing the catalog json 訊息已消失：

7. 回到網頁應用程式網址，點選首頁上的產品，你會發現回應速度快很多，而且不會遇到任何 HTTP 錯誤。

8. 返回負載產生器，按一下右上方的「Reset Stats」按鈕。失敗百分比已重設，應該不會再增加。

上述所有檢查都顯示問題已修正。如果仍看到 500 錯誤，請再稍候幾分鐘，然後再次點選產品。

恭喜！

您使用 Cloud Logging 和 Cloud Monitoring 找出微服務示範應用程式 (刻意設定錯誤的版本) 中的錯誤。這與您在正式環境中縮小 GKE 應用程式問題範圍時使用的疑難排解程序類似。

首先，您將應用程式部署至 GKE，然後針對前端錯誤設定指標和警告。接著您產生負載，並發現警告已觸發。您從警告中得知問題出在特定服務，並使用 Cloud Logging 縮小問題範圍。接著，您使用 Cloud Monitoring 和 GKE UI 查看 GKE 服務的指標。為了修正問題，您將更新後的設定部署至 GKE，並確認記錄中的錯誤因此得到解決。

後續步驟/瞭解詳情

• 本實驗室以這篇網誌文章為基礎，說明如何使用 Logging 記錄在 GKE 中執行的應用程式。
• 此外，您可能也會對這篇後續文章感興趣，瞭解開發運作團隊如何使用 Cloud Monitoring 和 Logging 快速找出問題。

Google Cloud 教育訓練與認證

協助您瞭解如何充分運用 Google Cloud 的技術。我們的課程會介紹專業技能和最佳做法，讓您可以快速掌握要領並持續進修。我們提供從基本到進階等級的訓練課程，並有隨選、線上和虛擬課程等選項，方便您抽空參加。認證可協助您驗證及證明自己在 Google Cloud 技術方面的技能和專業知識。

使用手冊上次更新日期：2025 年 2 月 21 日

實驗室上次測試日期：2025 年 2 月 21 日

Copyright 2025 Google LLC 保留所有權利。Google 和 Google 標誌是 Google LLC 的商標，其他公司和產品名稱則有可能是其關聯公司的商標。