![](https://cdn.qwiklabs.com/assets/labs/start_lab-f45aca49782d4033c3ff688160387ac98c66941d.png)
Before you begin
- Labs create a Google Cloud project and resources for a fixed time
- Labs have a time limit and no pause feature. If you restart it, you'll have to start from the beginning.
- On the top left of your screen, click Start lab to begin
Deploy Application
/ 30
Create a logs-based metric
/ 30
Create an alerting policy
/ 40
Cloud Logging とそれに付随するツールの Cloud Monitoring は、双方とも Google Kubernetes Engine に密接に統合されたフル機能のプロダクトです。このラボでは、Cloud Logging が GKE クラスタとアプリケーションでどのように動作するかを学習します。また、一般的なロギングのユースケースを通じて、ログ収集のベスト プラクティスも学習します。
このラボでは、次の方法について学びます。
具体例を示すために、GKE クラスタにデプロイされているサンプルのマイクロサービス デモアプリのトラブルシューティングを行います。このデモアプリには、さまざまなマイクロサービスと、その依存関係が含まれています。負荷生成ツールを使用してトラフィックを生成してから、Logging、Monitoring、GKE を使用してエラー(アラート / 指標)を表示し、Logging で根本原因を突き止め、Logging と Monitoring で問題の修正と修正確認を行います。
こちらの手順をお読みください。ラボの時間は記録されており、一時停止することはできません。[ラボを開始] をクリックするとスタートするタイマーは、Google Cloud のリソースを利用できる時間を示しています。
このハンズオンラボでは、シミュレーションやデモ環境ではなく、実際のクラウド環境を使ってご自身でラボのアクティビティを行うことができます。そのため、ラボの受講中に Google Cloud にログインおよびアクセスするための、新しい一時的な認証情報が提供されます。
このラボを完了するためには、下記が必要です。
[ラボを開始] ボタンをクリックします。ラボの料金をお支払いいただく必要がある場合は、表示されるポップアップでお支払い方法を選択してください。 左側の [ラボの詳細] パネルには、以下が表示されます。
[Google Cloud コンソールを開く] をクリックします(Chrome ブラウザを使用している場合は、右クリックして [シークレット ウィンドウでリンクを開く] を選択します)。
ラボでリソースが起動し、別のタブで [ログイン] ページが表示されます。
ヒント: タブをそれぞれ別のウィンドウで開き、並べて表示しておきましょう。
必要に応じて、下のユーザー名をコピーして、[ログイン] ダイアログに貼り付けます。
[ラボの詳細] パネルでも [ユーザー名] を確認できます。
[次へ] をクリックします。
以下のパスワードをコピーして、[ようこそ] ダイアログに貼り付けます。
[ラボの詳細] パネルでも [パスワード] を確認できます。
[次へ] をクリックします。
その後次のように進みます。
その後、このタブで Google Cloud コンソールが開きます。
Cloud Shell は、開発ツールと一緒に読み込まれる仮想マシンです。5 GB の永続ホーム ディレクトリが用意されており、Google Cloud で稼働します。Cloud Shell を使用すると、コマンドラインで Google Cloud リソースにアクセスできます。
接続した時点で認証が完了しており、プロジェクトに各自の PROJECT_ID が設定されます。出力には、このセッションの PROJECT_ID を宣言する次の行が含まれています。
gcloud
は Google Cloud のコマンドライン ツールです。このツールは、Cloud Shell にプリインストールされており、タブ補完がサポートされています。
[承認] をクリックします。
出力は次のようになります。
出力:
出力:
出力例:
gcloud
ドキュメントの全文については、gcloud CLI の概要ガイドをご覧ください。
一部の Compute Engine リソースは、リージョン内やゾーン内に存在します。リージョンとは、リソースを実行できる特定の地理的な場所です。1 つのリージョンには 1 つ以上のゾーンがあります。
Cloud コンソールで次の gcloud コマンドを実行して、ラボのデフォルトのリージョンとゾーンを設定します。
Google Kubernetes Engine クラスタに接続し、そのクラスタが正しく作成されていることを確認します。
クラスタのステータスが「PROVISIONING」である場合は、
少し待ってから、ステータスが「RUNNING」になるまで上記のコマンドを再度実行します。これには数分かかることがあります。
central
という名前のクラスタが作成されていることを確認します。
ナビゲーション メニュー > [Kubernetes Engine] > [クラスタ] に移動して、Google Cloud Console で進行状況をモニタリングすることもできます。
出力:
出力は次のようになります。
次に、Hipster Shop というマイクロサービス アプリケーションをクラスタにデプロイし、モニタリング可能なワークロードを作成します。
microservices-demo
ディレクトリに移動します。kubectl
を使用してアプリをインストールします。出力は次のようになります。
[進行状況を確認] をクリックして、目標に沿って進んでいることを確認します。
確認結果は次のようになります。
アプリケーションがデプロイされたら、Google Cloud Console に移動してステータスを表示することもできます。
[Kubernetes Engine] > [ワークロード] ページに、すべての Pod に問題がないことが表示されます。
アプリケーションが開いて、次のようなページが表示されます。
次に、Cloud Logging を構成してログベースの指標を作成します。これは、ログエントリから作成された Cloud Monitoring のカスタム指標です。ログベースの指標は、ログエントリ数のカウントと、ログ内の値分布の追跡に便利です。この場合、ログベースの指標を使用して、フロントエンド サービス内のエラーの数をカウントします。これで、ダッシュボードとアラートの両方で指標を使用できます。
このクエリは、フロントエンド Pod からすべてのエラーを見つけられます。ただし、エラーがまだないため、この時点では結果が表示されません。
作成した指標が、[ログベースの指標] ページのユーザー定義の指標の下に表示されます。
[進行状況を確認] をクリックして、目標に沿って進んでいることを確認します。
アラートによって、クラウド アプリケーションの問題をタイムリーに認識し、問題をすばやく解決できます。次に Cloud Monitoring を使用し、先ほど作成したフロントエンド エラーのログベースの指標に基づきアラート ポリシーを作成して、フロントエンド サービスの可用性をモニタリングします。アラート ポリシーの条件が満たされると、Cloud Monitoring によりインシデントが作成されて Google Cloud コンソールに表示されます。
ナビゲーション メニュー で [Monitoring] を開いてから [アラート] をクリックします。
ワークスペースが作成されたら、上部の [CREATE POLICY] をクリックします。
[指標を選択] プルダウンをクリックします。[Show only active resources & metrics] を無効にします。
リソースと指標名のフィルタ フィールドに「Error_Rate」と入力します。
[Kubernetes Container] > [Logs Based Metric] とクリックします。[logging/user/Error_Rate_SLI] を選択して [適用] をクリックします。
画面は次のようになります。
ローリング ウィンドウ関数を Rate
に設定します。
[Next] をクリックします。
0.5 をしきい値に設定します。
期待どおりエラーはなく、アプリケーションは可用性のサービスレベル目標(SLO)を達成しています。
もう一度 [NEXT] をクリックします。
[通知チャンネルを使用] をオフにします。
Error Rate SLI
などのアラート名を入力してから、[NEXT] をクリックします。
アラートを確認して [ポリシーを作成] をクリックします。
[進行状況を確認] をクリックして、目標に沿って進んでいることを確認します。
次に、負荷生成ツールを使用して、ウェブ アプリケーションにトラフィックを生成します。このバージョンのアプリケーションにはバグが意図的に導入されているため、特定量のトラフィック量でエラーがトリガーされます。各ステップを実行して、バグを特定して修正します。
ナビゲーション メニュー から [Kubernetes Engine]、次に [Service と Ingress] を選択します。
loadgenerator-external
サービスを探して endpoints
リンクをクリックします。
または、新しいブラウザタブまたはウィンドウを開き、IP をコピーして URL フィールド(例: http://\[loadgenerator-external-ip\]
)に貼り付けることもできます。
Locust 負荷生成ツールページが表示されます。
Locust はオープンソースの負荷生成ツールで、ウェブアプリの負荷テストを行うことができます。これは複数のユーザーが同時にアプリケーションのエンドポイントを特定の割合でアクセスするのをシミュレートできます。
300 人のユーザーが 30 の生成率でアプリにアクセスするのをシミュレートします。Locust は、ユーザーが 300 人になるまで 1 秒あたり 30 人のユーザーを追加します。
ホスト フィールドには、frontend-external
を使用します。[Services と Ingress] ページから URL をコピーします。その際、ポートを必ず除いてください。次に例を示します。
一方、ホームページからプロダクトをクリックすると、目に見えて遅いか、次のようなエラーが送信されます。
Cloud コンソール の [ナビゲーション メニュー] で [Monitoring]、次に [アラート] をクリックします。logging/user/Error_Rate_SLI に関するインシデントがすぐに表示されます。インシデントがすぐに表示されない場合は、1~2 分待ってからページを更新してください。アラート発出まで最大 5 分かかる場合があります。
インシデントのリンクをクリックします。
詳細ページが表示されます。
または、クエリのプレビュー フィールドをクリックしてクエリビルダーを表示し、[重大度] プルダウンをクリックして [エラー] をクエリに追加できます。[追加] ボタンをクリックしてから [クエリを実行] をクリックします。プルダウン メニューでは複数の重大度値を追加できます。
いずれも、severity=ERROR
がクエリに追加されます。この場合、recommendationservice Pod のすべてのエラーが表示されます。
textPayload
を開きます。
エラー メッセージをクリックし、[概要行にフィールドを追加] を選択してエラー メッセージが概要フィールドとして表示されるようにします。
ここで、RecommendationService サービスにエラーが多数あることを確認できます。エラー メッセージに基づくと、RecommendationService が一部のダウンストリーム サービスに接続できず、プロダクトまたは推奨事項のいずれかを取得できなかったようです。ただし、エラーの根本原因はまだはっきりしません。
アーキテクチャ図を再確認すると、RecommendationService がフロントエンド サービスに推奨事項のリストを提供します。一方で、フロントエンド サービスと RecommendationService の両方とも、プロダクトを一覧するために ProductCatalogService を呼び出します。
次のステップでは、犯人と思しき ProductCatalogService の指標に異常値がないかを確認します。ログで詳細を確認して分析情報を取得できます。
最初に指標を確認する場所の一つは、Monitoring コンソールの Kubernetes Engine セクション([ナビゲーション メニュー] > [Monitoring] > [ダッシュボード] > [GKE])です。
[ワークロード] セクションを表示します。
[Kubernetes Engine] > [ワークロード] > [productcatalogservice] に移動します。サービスの Pod が継続的にクラッシュして再起動していることが確認できます。
次に、ログに何か気になるものがないか確認します。
コンテナログを簡単に取得する方法は 2 つあります。
[ログ エクスプローラ] ページに戻ります。GKE で表示したコンテナのログに対して特にフィルタリングされた事前定義済みクエリがここに表示されます。
ログビューアでは、ログ メッセージとヒストグラムにより、コンテナが短時間でプロダクトのカタログを繰り返しパースしていることが示されます。これは非常に非効率だと思われます。
クエリ結果の最後に、次のようなランタイム エラーがある可能性があります。
これが実際に Pod をクラッシュさせている可能性があります。
理由をもっとよく把握するために、コードでログ メッセージを検索します。
出力は次のようになります。これには、行番号の付いたソースファイル名があります。
microservices-demo/src/productcatalogservice/server.go
のファイルをクリックして、237 行までスクロールすると、readCatalogFile メソッドがこのメッセージを出力するのがわかります。コードを参照すると、ブール型変数の reloadCatalog が真の場合、サービスが呼び出されるたびに不必要にプロダクト カタログを再読み込みしてパースしていることがわかります。
コードで reloadCatalog 変数を検索すると、これは環境変数 ENABLE_RELOAD
によって制御されており、状態に関するログ メッセージを書き込んでいることが確認できます。
このメッセージをクエリに追加してログを再度確認し、エントリがないか判断します。
そして、クエリビルダーの全クエリは次のようになります。
この時点で、フロントエンド エラーは、すべてのリクエストに対してカタログを読み込むオーバーヘッドによって引き起こされていたことが確認できます。読み込みを増やすと、オーバーヘッドによりサービスが失敗をしてエラーが生じます。
コードとログに記載されていることに基づき、カタログの再読み込みを無効にして問題を修正できます。ここで、プロダクト カタログ サービスの ENABLE_RELOAD
環境変数を削除します。変数を変更したら、アプリケーションを再度デプロイして、見つかった問題が変更によって解消されたことを確認します。
[ターミナルを開く] ボタンをクリックして、Cloud Shell ターミナルに戻ります(閉じていた場合)。
次のコマンドを実行します。
出力には、マニフェスト ファイルの環境変数の行番号が示されます。
productcatalogservice のみが構成されていることがわかります。他のサービスは変更されていません。
successfully parsing the catalog json
メッセージが消えていることを確認できます。ウェブアプリ URL に戻ってホームページのプロダクトをクリックすると、応答性もずっと良くなっており、HTTP エラーも表示されないはずです。
負荷生成ツールに戻り、右上の [Reset Stats] ボタンをクリックします。失敗の割合がリセットされて上昇していないことを確認できます。
上記すべてのチェックは、問題が修正されたことを示します。HTTP 500 エラーがまだ表示される場合、あと数分待ってからプロダクトを再度クリックしてみてください。
Cloud Logging と Cloud Monitoring を使用して、意図的に誤った構成をしたマイクロサービス デモアプリでエラーを見つけました。これは、本番環境で GKE アプリの問題を絞り込むときに使用するトラブルシューティングのプロセスと同様です。
最初に GKE にアプリをデプロイしてから、フロントエンド エラーの指標とアラートを設定しました。次に、負荷を生成して、アラートがトリガーされたことを確認しました。アラートに基づき、Cloud Logging を使用して問題を特定のサービスに絞りました。そして、Cloud Monitoring と GKE UI を使用して GKE サービスの指標を検証しました。問題を修正するため、更新済みの構成を GKE にデプロイして、修正によってログのエラーが解消されたことを確認しました。
このセルフペース ラボは、Qwiklabs の「Google Cloud's Operations Suite on GKE」クエストの一部です。クエストとは学習プログラムを構成する一連のラボのことで、完了すると成果が認められてバッジが贈られます。バッジは公開して、オンライン レジュメやソーシャル メディア アカウントにリンクできます。このラボの修了後、次のクエストに登録すれば、すぐにクレジットを受け取ることができます。受講可能な全クエストについては、Google Cloud Skills Boost カタログをご覧ください。
「Kubernetes Engine での Cloud Logging」に進んでクエストを続けるか、以下のおすすめのラボをご確認ください。
Google Cloud トレーニングと認定資格を通して、Google Cloud 技術を最大限に活用できるようになります。必要な技術スキルとベスト プラクティスについて取り扱うクラスでは、学習を継続的に進めることができます。トレーニングは基礎レベルから上級レベルまであり、オンデマンド、ライブ、バーチャル参加など、多忙なスケジュールにも対応できるオプションが用意されています。認定資格を取得することで、Google Cloud テクノロジーに関するスキルと知識を証明できます。
マニュアルの最終更新日: 2023 年 7 月 31 日
ラボの最終テスト日: 2023 年 7 月 31 日
Copyright 2025 Google LLC All rights reserved. Google および Google のロゴは Google LLC の商標です。その他すべての企業名および商品名はそれぞれ各社の商標または登録商標です。