GSP736

總覽

Cloud Logging 和輔助工具 Cloud Monitoring 都是功能完整的產品，且與 Google Kubernetes Engine (GKE) 深度整合。本實驗室將說明 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 setup and access」面板會顯示下列項目：

   • 「Open Google Cloud console」按鈕
   • 此實驗室所需的臨時憑證 (使用者名稱和密碼)
   • 完成此實驗室所需的其他資訊 (如有)

   請注意，實驗室計時器位於頁面頂端附近，會顯示剩餘時間。

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

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

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

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

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

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

   您也可以在「Lab setup and access」面板找到「Username」。

4. 點選「下一步」。

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

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

   您也可以在「Lab setup and access」面板找到「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 總覽指南。

工作 1：設定基礎架構

請連線至 Google Kubernetes Engine 叢集，並確認該叢集已正確建立。

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

gcloud container clusters list

叢集狀態會顯示為「PROVISIONING」。

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

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

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

4. 叢集狀態變成「RUNNING」後，請執行下列指令來取得叢集憑證：

gcloud container clusters get-credentials central --zone {{{project_0.startup_script.zone | ZONE}}}

輸出內容：

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

5. 執行下列指令，確認節點已建立：

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. 執行下列指令，查看指派的 IP 位址。如果系統尚未指派 IP 位址，請重複執行步驟 6：

echo $EXTERNAL_IP

8. 最後，執行下列指令，確認應用程式正常運作：

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

確認結果應大致如下。

輸出內容：

200

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

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

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

工作 3：開啟應用程式

• 向下捲動至「frontend-external」，然後點選服務的端點 IP。

應用程式應該會開啟，並顯示類似下方的頁面：

工作 4：建立記錄指標

在這項工作，您將設定 Cloud Logging 來建立記錄指標，也就是 Cloud Monitoring 中根據記錄項目建立的自訂指標。這類指標適合用來計算記錄項目數量，以及追蹤記錄中特定值的分布情形。

在本例中，您將使用記錄指標計算前端服務的錯誤數量。之後，您就可以在資訊主頁和警告中使用這項指標。

1. 前往 Google Cloud 控制台，在標題列的「搜尋」欄位輸入 logging，然後點選搜尋結果中的「Logs Explorer」。

2. 啟用「顯示查詢」，並在「Query builder」方塊中加入下列查詢：

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. 工作區建立後，請點選頂端的「建立政策」。

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

3. 點選「選取指標」，並取消勾選「Active」核取方塊。

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

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

畫面應如下所示：

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

7. 點選「繼續」。

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

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

9. 再次點選「繼續」。

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

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

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

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

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

觸發應用程式錯誤

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

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

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

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

此時畫面上應會開啟 Locust 負載產生器頁面：

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

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

4. 在「Host」欄位輸入 frontend-external 服務的網址。請從「閘道、Service 與 Ingress」頁面複製網址，且務必去除通訊埠的部分。例如：

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

6. 點選「Failures」分頁標籤，就能看到失敗開始出現，而且會有大量的 500 錯誤。

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

確認警告和應用程式錯誤

1. 在控制台依序點選「導覽選單」圖示、「監控」和「警告」。您應該很快就會看到 logging/user/Error_Rate_SLI 的相關事件。若未立即顯示，請稍候一兩分鐘再重新整理頁面。警告最多可能需要 5 分鐘才會觸發。

2. 點選事件連結：

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

3. 點選左側窗格中的「Logs Explorer」。

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

還有另一種做法，就是點選「查詢預覽」欄位來顯示查詢建立工具，然後點選「嚴重性」下拉式選單，將「錯誤」新增至查詢。點選「新增」按鈕，然後點選「執行查詢」。您可以透過下拉式選單加入多個嚴重性值。

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

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

6. 展開 textPayload。

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

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

再次查看架構圖，可以看到 RecommendationService 會向 Frontend 服務提供推薦內容清單。然而，Frontend 服務和 RecommendationService 都會叫用 ProductCatalogService 來取得產品清單。

在下個步驟中，您將查看主要懷疑對象 ProductCatalogService 的指標，確認是否有任何異常狀況。無論結果如何，您都可以深入查看記錄，從中找出一些線索。

使用 Kubernetes 資訊主頁和記錄排解問題

1. 您可以先前往 Monitoring 控制台的「Kubernetes Engine」專區查看指標。請依序點選「導覽選單」圖示 >「監控」>「資訊主頁」>「GKE」。

2. 查看「工作負載」專區。

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

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

有 2 種簡單的方法可開啟容器記錄：

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

5. 在總覽分頁的「Deployment 詳細資料」頁面，點選「容器記錄」連結。

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

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

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

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

這可能正是導致 Pod 異常終止的原因。

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

6. 在 Cloud Shell 終端機執行下列指令：

grep -nri 'successfully parsed product catalog json' src

輸出內容應大致如下，其中包含來源檔案名稱和行號。

輸出內容：

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

7. 接著要查看來源檔案。請點選 Cloud Shell 選單中的「開啟編輯器」按鈕，然後點選「在新視窗中開啟」。如果看到「Unable to load code editor because third-party cookies are disabled」錯誤，請點選 Chrome 頁面頂端的眼睛圖示。

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

再深入查看，您會發現如果布林變數 reloadCatalog 為 true，服務每次收到叫用要求時，都會重新載入並剖析產品目錄，這似乎沒有必要。

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

請將這則訊息新增至查詢，再次查看記錄，確認是否有任何相符的項目。

9. 返回「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"

10. 再次點選「執行查詢」，然後在容器記錄中尋找「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. 依序點選「導覽選單」圖示 >「Kubernetes Engine」>「工作負載」>「productcatalogservice」，返回「Deployment 詳細資料」頁面，等待 Pod 順利執行。請等待 2 至 3 分鐘，或直到確定 Pod 不再異常終止。

6. 再次點選「容器記錄」連結，您會發現反覆出現的 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，並確認記錄中的錯誤已解決。

後續步驟/瞭解詳情

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

Google Cloud 教育訓練與認證

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

使用手冊上次更新日期：2026 年 7 月 13 日

實驗室上次測試日期：2026 年 7 月 13 日

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