GSP736

概要

Cloud Logging とそれに付随するツールの Cloud Monitoring は、双方とも Google Kubernetes Engine（GKE）に密接に統合されたフル機能のプロダクトです。このラボでは、Cloud Logging が GKE クラスタとアプリケーションでどのように動作するかを学習します。また、一般的なロギングのユースケースを通じて、ログ収集のベスト プラクティスも学習します。

目標

このラボでは、次のタスクの実行方法について学びます。

• Cloud Monitoring を使用して問題を検出する。
• Cloud Logging を使用して、GKE で動作しているアプリケーションをトラブルシューティングする。

ラボで使用されているデモ アプリケーション

具体例を示すために、GKE クラスタにデプロイされているサンプルのマイクロサービス デモアプリのトラブルシューティングを行います。このデモアプリには、さまざまなマイクロサービスと、その依存関係が含まれています。負荷生成ツールを使用してトラフィックを生成し、Logging、Monitoring、GKE でエラー（アラート / 指標）が発生していることを確認し、Logging で根本原因を突き止め、Logging と Monitoring で問題を解決し、問題が解決されたことを確認します。

設定と要件

[ラボを開始] ボタンをクリックする前に

こちらの説明をお読みください。ラボには時間制限があり、一時停止することはできません。タイマーは、Google Cloud のリソースを利用できる時間を示しており、[ラボを開始] をクリックするとスタートします。

このハンズオンラボでは、シミュレーションやデモ環境ではなく実際のクラウド環境を使って、ラボのアクティビティを行います。そのため、ラボの受講中に Google Cloud にログインおよびアクセスするための、新しい一時的な認証情報が提供されます。

このラボを完了するためには、下記が必要です。

• 標準的なインターネット ブラウザ（Chrome を推奨）

注: このラボの実行には、シークレット モード（推奨）またはシークレット ブラウジング ウィンドウを使用してください。これにより、個人アカウントと受講者アカウント間の競合を防ぎ、個人アカウントに追加料金が発生しないようにすることができます。

• ラボを完了するための時間（開始後は一時停止できません）

注: このラボでは、受講者アカウントのみを使用してください。別の Google Cloud アカウントを使用すると、そのアカウントに料金が発生する可能性があります。

ラボを開始して Google Cloud コンソールにログインする方法

1. [ラボを開始] ボタンをクリックします。ラボの料金をお支払いいただく必要がある場合は、表示されるダイアログでお支払い方法を選択してください。 右側の [ラボの設定とアクセス] パネルには、以下が表示されます。

   • [Google Cloud コンソールを開く] ボタン
   • このラボで使用する一時的な認証情報（ユーザー名とパスワード）
   • このラボを行うために必要なその他の情報（ある場合）

   ラボのタイマーはページの上部に表示され、残り時間が示されます。

2. [Google Cloud コンソールを開く] をクリックします（Chrome ブラウザを使用している場合は、右クリックして [シークレット ウィンドウで開く] を選択します）。

   ラボでリソースがスピンアップし、別のタブで [ログイン] ページが表示されます。

   ヒント: タブをそれぞれ別のウィンドウで開き、並べて表示しておきましょう。

   注: [アカウントの選択] ダイアログが表示された場合は、[別のアカウントを使用] をクリックします。

3. 必要に応じて、下のユーザー名をコピーして、[ログイン] ダイアログに貼り付けます。

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

   [ラボの設定とアクセス] パネルでもユーザー名を確認できます。

4. [次へ] をクリックします。

5. 以下のパスワードをコピーして、[ようこそ] ダイアログに貼り付けます。

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

   [ラボの設定とアクセス] パネルでもパスワードを確認できます。

6. [次へ] をクリックします。

   重要: ラボで指定された認証情報を使用する必要があります。ご自身の Google Cloud アカウントの認証情報は使用しないでください。 注: このラボでご自身の Google Cloud アカウントを使用すると、追加料金が発生する場合があります。

7. その後のページはクリックして先に進みます。

   • 利用規約に同意します。
   • 一時的なアカウントなので、復元オプションや 2 要素認証プロセスは設定しないでください。
   • 無料トライアルには登録しないでください。

しばらくすると、このタブで 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 にプリインストールされており、タブ補完がサポートされています。

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"}}} 注: Google Cloud における gcloud ドキュメントの全文については、gcloud CLI の概要ガイドをご覧ください。

タスク 1. インフラストラクチャをセットアップする

Google Kubernetes Engine クラスタに接続し、そのクラスタが正しく作成されていることを確認します。

1. 次のコマンドを使用して、クラスタのステータスを表示します。

gcloud container clusters list

クラスタのステータスが「PROVISIONING」である場合は、

2. 少し待ってから、ステータスが「RUNNING」になるまで上記のコマンドを再度実行します。これには数分かかることがあります。

3. central という名前のクラスタが作成されていることを確認します。

ナビゲーション メニュー > [Kubernetes Engine] > [クラスタ] に移動して、Google 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

Cloud Shell IDE で Gemini Code Assist を有効にする

Cloud Shell などの統合開発環境（IDE）で Gemini Code Assist を使用して、コードに関するガイダンスを受けたり、コードの問題を解決したりできます。使用を開始する前に、Gemini Code Assist を有効にする必要があります。

1. Cloud Shell で、次のコマンドを使用して Gemini for Google Cloud API を有効にします。

gcloud services enable cloudaicompanion.googleapis.com

2. Cloud Shell ツールバーの [エディタを開く] をクリックします。

注: Cloud Shell エディタを開くには、Cloud Shell ツールバーの [エディタを開く] をクリックします。必要に応じて、[エディタを開く] または [ターミナルを開く] をクリックして、Cloud Shell とコードエディタを切り替えることができます。

3. 画面下部のステータスバーで [Cloud Code - No Project] をクリックします。

4. 指示に従ってプラグインを承認します。プロジェクトが自動的に選択されない場合は、[Google Cloud プロジェクトを選択する] をクリックして を選択します。

5. ステータスバーの Cloud Code ステータス メッセージに Google Cloud プロジェクト（）が表示されていることを確認します。

タスク 2. アプリケーションをデプロイする

次に、Hipster Shop というマイクロサービス アプリケーションをクラスタにデプロイし、モニタリング可能なワークロードを作成します。

1. 次のコマンドを実行して、リポジトリのクローンを作成します。

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

2. 次のコマンドを使用して、microservices-demo ディレクトリに移動します。

cd microservices-demo

3. Cloud Shell エディタのファイル エクスプローラで、microservices-demo > release > kubernetes-manifests.yaml に移動します。

Gemini Code Assist の AI を活用した機能を利用して、コードエディタで直接コードを変更できます。ここでは、Gemini Code Assist を使用して kubernetes-manifests.yaml ファイルを説明し、チームの新しいメンバーのオンボーディングをサポートすることにします。

4. kubernetes-manifests.yaml ファイルを開きます。この操作により、エディタの右上隅に アイコンが表示され、Gemini Code Assist が有効になります。

5. Gemini Code Assist: Smart Actions アイコン をクリックし、[この内容を説明] を選択します。

6. Gemini Code Assist は、「この内容を説明」というプロンプトが事前入力されたチャットペインを開きます。Code Assist チャットのインライン テキスト ボックスで、事前入力されたプロンプトを次のプロンプトに置き換えて、[送信] をクリックします。

Cymbal AI の Kubernetes アーキテクトとして、新しいチームメンバーのオンボーディング用に、kubernetes-manifests.yaml ファイルについて正式かつ包括的な説明を行ってください。 説明では、次の点に触れてください。 * 構成ファイルで使用されている主要なコンポーネントの詳細 * 主要なサービスとその機能の説明 * 共通の構成要素の説明 * 構成によってデプロイされるものの説明 改善案については、このファイルを更新しないでください。

kubernetes-manifests.yaml ファイルのコードの説明が、Gemini Code Assist のチャットに表示されます。

7. 次のコマンドを実行して、kubectl を使用してアプリをインストールします。

kubectl apply -f release/kubernetes-manifests.yaml

8. 次のコマンドを実行して、すべてが正しく動作していることを確認します。

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

9. 次のステップに進む前に、すべての Pod が「Running」のステータスになるまでコマンドを再実行してください。

[進行状況を確認] をクリックして、目標に沿って進んでいることを確認します。 アプリケーションをデプロイする

10. 次のコマンドを実行して、アプリケーションの外部 IP を取得します。このコマンドは、サービスがデプロイされると IP アドレスを返します。そのため、外部 IP アドレスが割り当てられるまでこのコマンドを繰り返さなくてはならない場合があります。

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

11. 最後に、次のコマンドを実行して、アプリが起動して稼働していることを確認します。

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

確認結果は次のような出力になります。

出力:

200

アプリケーションがデプロイされたら、Cloud コンソールに移動してステータスを表示することもできます。

[Kubernetes Engine] > [ワークロード] ページに、すべての Pod に問題がないことが表示されます。

12. 次に、[Gateways、Services、Ingress] を選択し、[Services] タブをクリックして、すべてのサービスに問題がないことを確認します。この画面のままで、アプリケーションのモニタリングを設定します。

タスク 3. アプリケーションを開く

• frontend-external まで下にスクロールして、サービスのエンドポイント IP をクリックします。

アプリケーションが開いて、次のようなページが表示されます。

タスク 4. ログベースの指標を作成する

このタスクでは、Cloud Logging を構成してログベースの指標を作成します。ログベースの指標とは、ログエントリを基に生成される Cloud Monitoring のカスタム指標のことです。ログベースの指標は、ログエントリ数のカウントと、ログ内の値分布の追跡に便利です。

ここでは、ログベースの指標を使用して、フロントエンド サービスのエラーの数をカウントします。そして、その指標をダッシュボードとアラートの両方で使用します。

1. Cloud コンソールに戻り、ナビゲーション メニュー で [ロギング] を開いて [ログ エクスプローラ] をクリックします。

2. [クエリを表示] をオンにして、[クエリビルダー] ボックスに次のクエリを追加します。

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

3. [クエリを実行] をクリックします。

このクエリは、フロントエンド Pod のエラーをすべて表示することができます。ただし、この時点ではまだエラーがないため、結果は表示されません。

4. ログベースの指標を作成するには、[アクション] プルダウンをクリックして [指標を作成] を選択します。

5. 指標に「Error_Rate_SLI」という名前を付け、[指標を作成] をクリックしてログベースの指標を保存します。

[ログベースの指標] ページのユーザー定義の指標の下に、指標が表示されます。

[進行状況を確認] をクリックして、目標に沿って進んでいることを確認します。 ログベースの指標を作成する

タスク 5. アラート ポリシーを作成する

アラートによって、クラウド アプリケーションの問題をタイムリーに認識し、問題をすばやく解決できます。

このタスクでは、先ほど作成したフロントエンド エラーのログベースの指標に基づいてアラート ポリシーを作成し、Cloud Monitoring を使用してフロントエンド サービスの可用性をモニタリングします。アラート ポリシーの条件が満たされると、Cloud Monitoring によりインシデントが作成されて Google Cloud コンソールに表示されます。

1. ナビゲーション メニュー で [Monitoring] を開いてから [アラート] をクリックします。

2. ワークスペースが作成されたら、上部の [CREATE POLICY] をクリックします。

注: 必要に応じて [試してみる] をクリックして最新のアラート作成フローをお試しください。

3. [指標の選択] プルダウンをクリックします。[アクティブ] チェックボックスをオフにします。

4. リソースと指標名のフィルタ フィールドに「Error_Rate」と入力します。

5. [Kubernetes Container] > [Logs Based Metric] をクリックします。[logging/user/Error_Rate_SLI] を選択して [適用] をクリックします。

画面は次のようになります。

6. ローリング ウィンドウ関数を Rate に設定します。

7. [Next] をクリックします。

8. 0.5 をしきい値に設定します。

期待どおりエラーはなく、アプリケーションは可用性のサービスレベル目標（SLO）を達成しています。

9. もう一度 [NEXT] をクリックします。

10. [通知チャンネルを使用] をオフにします。

11. Error Rate SLI などのアラート名を入力してから、[NEXT] をクリックします。

12. アラートを確認して [ポリシーを作成] をクリックします。

注: このラボでは通知チャンネルを作成しませんが、本番環境で稼働しているアプリケーションでは作成することをおすすめします。これにより、メール、モバイルアプリ、SMS、Pub/Sub、Webhook などで通知が送信されます。

[進行状況を確認] をクリックして、目標に沿って進んでいることを確認します。 アラート ポリシーを作成する

アプリケーション エラーをトリガーする

このセクションでは、負荷生成ツールを使用して、ウェブ アプリケーションにトラフィックを生成します。このバージョンのアプリケーションにはバグが意図的に導入されているため、特定のトラフィック量でエラーがトリガーされます。各ステップを実行して、バグを特定して修正します。

1. ナビゲーション メニューから [Kubernetes Engine]、次に [Gateway、Service、Ingress] を選択し、[Service] タブをクリックします。

2. loadgenerator-external サービスを探して endpoints リンクをクリックします。

または、新しいブラウザタブまたはウィンドウを開き、IP をコピーして URL フィールド（例: http://\[loadgenerator-external-ip\]）に貼り付けることもできます。

Locust 負荷生成ツールページが表示されます。

Locust はオープンソースの負荷生成ツールで、ウェブアプリの負荷テストを行うことができます。これは複数のユーザーが同時にアプリケーションのエンドポイントを特定の割合でアクセスするのをシミュレートできます。

3. 30 のハッチレートで 300 人のユーザーによるアプリへのアクセスをシミュレートします。Locust は、ユーザーが 300 人になるまで 1 秒あたり 30 人のユーザーを追加します。

4. ホスト フィールドには、frontend-external を使用します。[Gateway、Service、Ingress] ページから URL をコピーします。その際、ポートを必ず除いてください。次に例を示します。

5. [Start swarming] ボタンをクリックします。事前定義した URL が数秒の間に約 300 人のユーザーからアクセスされます。

6. [Failures] タブをクリックしてエラーが発生していることを確認します。HTTP 500 エラーが多数表示されます。

一方、ホームページからプロダクトをクリックすると、目に見えて遅いか、次のようなエラーが送信されます。

アラートとアプリケーション エラーを確認する

1. コンソール の [ナビゲーション メニュー] で [Monitoring]、次に [アラート] をクリックします。logging/user/Error_Rate_SLI に関するインシデントがすぐに表示されます。インシデントがすぐに表示されない場合は、1～2 分待ってからページを更新してください。アラートが生成されるまで最大 5 分かかる場合があります。

2. インシデントのリンクをクリックします。

詳細ページが表示されます。

3. [ログ] セクションで、[ログ エクスプローラで表示] をクリックし、プルダウンからプロジェクト ID を選択して Pod のログを表示します。

4. [ログ フィールド エクスプローラ] パネルで [エラー] ラベルをクリックして、エラーのみのクエリを行うこともできます。

または、クエリのプレビュー フィールドをクリックしてクエリビルダーを表示し、[重大度] プルダウンをクリックして [エラー] をクエリに追加できます。[追加] ボタンをクリックしてから [クエリを実行] をクリックします。プルダウン メニューでは複数の重大度値を追加できます。

いずれも、severity=ERROR がクエリに追加されます。この場合、recommendationservice Pod のすべてのエラーが表示されます。

5. エラーイベントを開いてエラーの詳細を表示します。次に例を示します。

6. textPayload を開きます。

7. エラー メッセージをクリックし、[概要行にフィールドを追加] を選択してエラー メッセージが概要フィールドとして表示されるようにします。

ここで、RecommendationService サービスにエラーが多数あることを確認できます。エラー メッセージによると、RecommendationService が一部のダウンストリーム サービスに接続できず、プロダクトまたは推奨事項のいずれかを取得できなかったようです。ただし、エラーの根本原因はまだはっきりしません。

アーキテクチャ図を再確認すると、RecommendationService はフロントエンド サービスに推奨事項のリストを提供します。一方で、フロントエンド サービスと RecommendationService の両方が、プロダクトのリストを取得するために ProductCatalogService を呼び出します。

次のステップでは、犯人と思しき ProductCatalogService の指標に異常値がないかを確認します。ログで詳細を確認して分析情報を取得できます。

Kubernetes ダッシュボードとログを使用したトラブルシューティング

1. 最初に指標を確認する場所の一つは、Monitoring コンソールの Kubernetes Engine セクション（[ナビゲーション メニュー] > [Monitoring] > [ダッシュボード] > [GKE]）です。

2. [ワークロード] セクションを表示します。

3. [Kubernetes Engine] > [ワークロード] > [productcatalogservice] に移動します。サービスの Pod が継続的にクラッシュして再起動していることが確認できます。

次に、ログに何か気になるものがないか確認します。

コンテナログを簡単に取得する方法は 2 つあります。

4. [ログ] タブをクリックして最新のログを見ます。次に、ログパネルの右上端にある外部リンクボタンをクリックして、ログ エクスプローラに戻ります。

5. [概要] ページで、[Deployment の詳細] ページの [コンテナログ] リンクをクリックします。

[ログ エクスプローラ] ページに戻ります。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 のメニューで [エディタを開く] ボタン、次に [新しいウィンドウで開く] をクリックします（「サードパーティの Cookie が無効になっているため、コードエディタを読み込めません」というエラーが表示されたら、Chrome ページの上部にある目のアイコンをクリックします）。

8. microservices-demo/src/productcatalogservice/server.go のファイルをクリックして、237 行までスクロールすると、readCatalogFile メソッドがこのメッセージを出力するのがわかります。

コードを参照すると、ブール型変数の reloadCatalog が真の場合、サービスが呼び出されるたびに不必要にプロダクト カタログを再読み込みしてパースしていることがわかります。

コードで reloadCatalog 変数を検索すると、これは環境変数 ENABLE_RELOAD によって制御されており、状態に関するログ メッセージを書き込んでいることが確認できます。

9. server.go ファイルを開き、IDE で Gemini Code Assist を有効にすると、エディタの右上隅に アイコンが表示されます。

ここでは、Gemini Code Assist を使用して、新しいチームメンバーにサーバーの実装を説明することにします。

10. Gemini Code Assist: Smart Actions アイコン をクリックし、[この内容を説明] を選択します。

11. Gemini Code Assist は、「この内容を説明」というプロンプトが事前入力されたチャットペインを開きます。Code Assist チャットのインライン テキスト ボックスで、事前入力されたプロンプトを次のプロンプトに置き換えて、[送信] をクリックします。

あなたは Cymbal AI の Kubernetes アーキテクトです。新しいチームメンバーは、このサーバーの実装に慣れていません。この server.go ファイルについて、コードで使用されている主要なコンポーネントを分解して詳しく説明してください。 改善案の提案がある場合でも、このファイルを更新しないでください。

server.go ファイルのコードの説明が、Gemini Code Assist のチャットに表示されます。

メッセージをクエリに追加してログを再度確認し、エントリがないか判断します。

12. ログ エクスプローラを開いたタブに戻り、次の行をクエリに追加します。

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"

13. [クエリを実行] を再度クリックして、コンテナログで「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. 以下のコマンドを実行してこの 2 行を削除し、再読み込みを無効にします。

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

4. 次に、以下のコマンドを実行してマニフェスト ファイルを再適用します。

kubectl apply -f release/kubernetes-manifests.yaml

productcatalogservice のみが構成されていることがわかります。他のサービスは変更されていません。

5. Deployment の詳細ページに戻り（ナビゲーション メニュー > [Kubernetes Engine] > [ワークロード] > [productcatalogservice]）、Pod が正常に動作するまで待ちます。2～3 分待つか、またはクラッシュしなくなったことが確認できるまで待ちます。

6. もう一度 [コンテナログ] リンクをクリックすると、繰り返し表示されていた successfully parsing the catalog json メッセージが消えていることを確認できます。

7. ウェブアプリ URL に戻ってホームページのプロダクトをクリックすると、応答性もはるかに向上しています。HTTP エラーも表示されなくなっているはずです。

8. 負荷生成ツールに戻り、右上の [Reset Stats] ボタンをクリックします。失敗の割合がリセットされて上昇していないことを確認できます。

この一連の確認により、問題が解決されたことがわかりました。HTTP 500 エラーがまだ表示される場合は、あと数分待ってからプロダクトを再度クリックしてみてください。

お疲れさまでした

Cloud Logging と Cloud Monitoring を使用して、意図的に誤った設定にしたマイクロサービス デモアプリのエラーを見つけることができました。これは、本番環境で GKE アプリの問題を絞り込むときに使用するトラブルシューティングのプロセスと同様です。

最初に GKE にアプリをデプロイしてから、フロントエンド エラーの指標とアラートを設定しました。次に、負荷を生成して、アラートがトリガーされたことを確認しました。アラートに基づき、Cloud Logging を使用して問題を特定のサービスに絞り込みました。そして、Cloud Monitoring と GKE UI を使用して GKE サービスの指標を確認しました。問題を解決するために、更新した設定を GKE にデプロイし、ログにエラーが表示されなくなったことを確認しました。

次のステップと詳細情報

• このラボは、GKE で動作しているアプリに対する Logging の使用に関するこちらのブログ投稿をベースにしています。
• DevOps チームが Cloud Monitoring および Logging を使用して問題をすばやく見つける方法に関するフォローアップ投稿も、よろしければご覧ください。

Google Cloud トレーニングと認定資格

Google Cloud トレーニングと認定資格を通して、Google Cloud 技術を最大限に活用できるようになります。必要な技術スキルとベスト プラクティスについて取り扱うクラスでは、学習を継続的に進めることができます。トレーニングは基礎レベルから上級レベルまであり、オンデマンド、ライブ、バーチャル参加など、多忙なスケジュールにも対応できるオプションが用意されています。認定資格を取得することで、Google Cloud テクノロジーに関するスキルと知識を証明できます。

マニュアルの最終更新日: 2025 年 8 月 26 日

ラボの最終テスト日: 2025 年 10 月 14 日

Copyright 2026 Google LLC. All rights reserved. Google および Google のロゴは Google LLC の商標です。その他すべての企業名および商品名はそれぞれ各社の商標または登録商標です。