1. はじめに
最終更新日: 2023 年 6 月 21 日
可用性に関するログベース エラーのアラート
ログベースのアラートを使用すると、ログ内の特定のイベントやパターンをモニタリングすることで、アプリケーションの可用性を判断できます*。サービスの停止やユーザーが直面するその他の問題に対するアラートを受け取ることで、ユーザーや顧客への影響を最小限に抑えるための措置を講じることができます。
稼働時間チェックは可用性の全般的なスナップショットを提供しますが、ログから取得されるエラー メッセージを、より具体的な種類の利用不能性の指標として使用し、問題が発生しているユーザーの割合を把握するためのほうが正確です。
エラーは、ユーザーのミスからシステムのメンテナンスやアップグレードまで、また悪天候などのシステムの外的な要因まで、さまざまな原因で発生します。アラートで重要なのは、考えられるすべての原因を予測しようとするのではなく、トラブルシューティングの開始に役立つ主な症状をいくつか選択することです。
アラート通知チャンネルとしての Pub/Sub トピック
Pub/Sub トピックは、Pub/Sub サブスクリプションにアラートを送信するための Google Cloud Monitoring 通知チャンネルとして使用できます。これにより、Cloud Monitoring のアラートを、サードパーティの通知サービスを含む他のシステムと統合できます。
Pub/Sub トピックを通知チャンネルとして使用するには、まず Pub/Sub トピックと Pub/Sub サブスクリプションを作成する必要があります。次に、Pub/Sub トピックを宛先として使用する Cloud Monitoring 通知チャンネルを作成する必要があります。
アラートがトリガーされると、Cloud Monitoring は Pub/Sub トピックにメッセージを送信します。Pub/Sub サブスクリプションのサブスクライバーは、メッセージを処理して適切なアクションを実行できます。
作成するアプリの概要
この Codelab では、アプリをデプロイし、Pub/Sub トピックを作成して、アプリの特定の部分のエラーをチェックし、Pub/Sub トピックを通知チャンネルとして使用するログベースのアラートを作成します。
学習内容
- Pub/Sub トピックを作成する方法
- ログベースのアラートの作成方法
この Codelab では、エラーのアラートの作成に焦点を当てます。関連のない概念とアプリケーション コードについては軽く触れるにとどめ、そのままコピーして貼り付けられるようにしています。
必要なもの
- 以下の権限を持つ Google Cloud アカウント。
- Cloud Run アプリケーションをデプロイする
- Pub/Sub トピックを作成する
- アラートを作成する
2. 設定方法
Google Cloud プロジェクトを選択または作成する
既存のプロジェクトを選択するには、プルダウンを使用します。
Google Cloud で新しいプロジェクトを作成する手順は次のとおりです。
- Google Cloud Platform Console に移動します。
- [プロジェクトを作成] ボタンをクリックします。
- プロジェクトの名前を入力します。
- プロジェクトの請求先アカウントを選択します。
- [作成] ボタンをクリックします。
プロジェクトが作成され、プロジェクト ダッシュボードが表示されます。そこから、Google Cloud サービスの使用を開始できます。
各ステップの詳細は次のとおりです。
- 名前: プロジェクトの名前は組織内で一意にする必要があります。
- 請求先アカウント: 既存の請求先アカウントを使用することも、新しいアカウントを作成することもできます。
- 作成: 必要な情報をすべて入力したら、[作成] ボタンをクリックしてプロジェクトを作成します。
詳細については、プロジェクトの作成に関する Google Cloud ドキュメントをご覧ください。
3. API アプリケーションをデプロイする
サンプル アプリケーションまたは API について
このアプリケーションは、REST API エンドポイントを公開するシンプルな Inventory API アプリケーションです。このアプリケーションでは、在庫アイテムをリストしたり、特定のアイテム在庫数を取得したりします。
API をデプロイし、https://<somehost> でホストされていることを確認したら、次のようにして API エンドポイントにアクセスできます。
https://<somehost>/inventory
これにより、すべての商品アイテムが手持ちの在庫レベルとともに一覧表示されます。
https://<somehost>/inventory/{productid}
これにより、その商品の productid と手持ち在庫レベルを含む単一のレコードが提供されます。
返されるレスポンス データは JSON 形式です。
注: この API アプリケーションはデモ専用であり、安全で堅牢な API 実装を表すものではありません。このラボの主な目的は、Google Cloud Operations であり、
サンプルデータと API リクエスト/レスポンス
処理をシンプルにするため、このアプリケーションはバックエンドのデータベースを基盤としていません。3 つのサンプル商品 ID とそれぞれの手持ち在庫レベルが含まれています。
製品 ID | 手持ち在庫レベル |
I-1 | 10 |
I-2 | 20 |
I-3 | 30 |
API リクエストとレスポンスの例を以下に示します。
API リクエスト | API レスポンス |
https://<somehost>/inventory | [ { "I-1": 10, "I-2": 20, "I-3": 30 }] |
https://<somehost>/inventory/I-1 | { "productid": "I-1", "qty": 10} |
https://<somehost>/inventory/I-2 | { "productid": "I-2", "qty": 20} |
https://<somehost>/inventory/I-200 | { "productid": I-200, "qty": -1} |
リポジトリのクローンを作成する
Google Cloud はノートパソコンからリモートで操作できますが、この Codelab では、Google Cloud Shell(Cloud 上で動作するコマンドライン環境)を使用します。
GCP Console で右上のツールバーにある Cloud Shell アイコンをクリックします。
プロビジョニングと環境への接続にはそれほど時間はかかりません。完了すると、次のように表示されます。
この仮想マシンには、必要な開発ツールがすべて含まれています。永続的なホーム ディレクトリが 5 GB 用意されており、Google Cloud で稼働します。そのため、ネットワークのパフォーマンスと認証機能が大幅に向上しています。このラボでの作業はすべてブラウザ上で実行できます。
gcloud を設定する
Cloud Shell でプロジェクト ID を設定し、PROJECT_ID 変数として保存します。
PROJECT_ID=[YOUR-PROJECT-ID]
gcloud
config
set
project
$PROJECT_ID
次のコマンドを実行します。
$
git
clone
https://github.com/rominirani/cloud-code-sample-repository.git
このフォルダに cloud-code-sample-repository というフォルダが作成されます。
(省略可)Cloud Shell でアプリケーションを実行する
アプリケーションをローカルで実行するには、次の手順を行います。
- ターミナルから次のコマンドを使用して、API の Python バージョンに移動します。
$
cd
cloud-code-sample-repository
$
cd
python-flask-api
- ターミナルで、以下のコマンドを実行します(このドキュメントの作成時点では、Cloud Shell には Python 3.9.x がインストールされており、デフォルト バージョンを使用します。ノートパソコンでローカルで実行する場合は、Python 3.8+ を使用します)。
$
python
app.py
- 次のコマンドを実行して、Python サーバーをローカルで起動できます。
[ポート 8080 でプレビュー] をクリックします。5. ブラウザ ウィンドウが開きます。404 エラーが表示されますが、これは問題ありません。URL を変更し、ホスト名の後ろに /inventory が含まれるように変更します。
例:すると次のようになります。
https://8080-cs-557561579860-default.cs-asia-southeast1-yelo.cloudshell.dev/inventory
前述のとおり、在庫アイテムのリストが表示されます。
- ターミナルに移動して Ctrl+C キーを押すと、サーバーを停止できます。
アプリケーションをデプロイする
次に、この API アプリケーションを Cloud Run にデプロイします。このプロセスでは、gcloud コマンドライン クライアントを使用してコマンドを実行し、コードを Cloud Run にデプロイします。
ターミナルから、次の gcloud コマンドを実行します。
$ gcloud run deploy --source .
いくつかの質問が寄せられ、そのいくつかを以下に示します。
- サービス名(python-flask-api): このデフォルトを使用するか、my-inventory-api などを選択します
- API [run.googleapis.com] がプロジェクト [613162942481] で有効になっていません。有効にして再試行しますか(数分かかる場合があります)(はい/いいえ)?Y
- リージョンを指定してください: 31(us-west-1)を選択してください
- API [artifactregistry.googleapis.com] がプロジェクト [613162942481] で有効になっていません。有効にして再試行しますか(数分かかる場合があります)(はい/いいえ)?Y
- ソースからデプロイするには、ビルドされたコンテナを保存するための Artifact Registry Docker リポジトリが必要です。リージョン [us-west1] に [cloud-run-source-deploy] という名前のリポジトリが作成されます。
- 続行しますか(Y/n)?Y
- [my-inventory-api] への未認証の呼び出しを許可する(はい/いいえ)?Y
最終的に、ソースコードを取得してコンテナ化し、Artifact Registry に push してから、Cloud Run サービスとリビジョンをデプロイするプロセスが開始されます。このプロセスはしばらく待つ必要があり(3 ~ 4 分かかる場合があります)、サービス URL が表示されてプロセスが完了するはずです。
実行例を以下に示します。
アプリケーションをテストする
アプリケーションが Cloud Run にデプロイされたので、次のようにして API アプリケーションにアクセスできます。
- 前のステップのサービスの URL をメモします。たとえば、この設定では、
https://my-inventory-api-bt2r5243dq-uw.a.run.app
と表示されます。これを<SERVICE_URL>
とします。 - ブラウザを開き、API エンドポイントの次の 3 つの URL にアクセスします。
<SERVICE_URL>/inventory
<SERVICE_URL>/inventory/I-1
<SERVICE_URL>/inventory/I-100
その仕様は、前のセクションで API リクエストとレスポンスのサンプルで示した仕様に沿っている必要があります。
Cloud Run からサービスの詳細を取得する
サーバーレス コンピューティング環境である Cloud Run に API サービスをデプロイしました。Google Cloud コンソールからいつでも Cloud Run サービスにアクセスできます。
メインメニューから [Cloud Run] に移動します。Cloud Run で実行されているサービスのリストが表示されます。先ほどデプロイしたサービスが表示されます。選択した名前に応じて、次のように表示されます。
サービス名をクリックして詳細を表示します。サンプルの詳細は次のとおりです。
URL に注目してください。これはサービス URL だけです。ブラウザに入力して、先ほどデプロイした Inventory API にアクセスできます。指標などの詳細を確認します。
それでは、Google Cloud オペレーション スイートから始めましょう。
4. アラート通知を受け取る Pub/Sub トピックの作成
Pub/Sub トピックを作成するには、Google Cloud コンソールで次の手順に沿って操作します。
- 検索ボックスで「Pub/Sub」を検索し、Pub/Sub に移動します。
- [トピック] タブが表示されていない場合は、タブをクリックします。
- [トピックを作成] ボタンをクリックします。
- トピックに認識可能な名前を入力してください。
- [Create] ボタンをクリックします。
- コピーアイコンボタンを使用してトピック名をコピーします。これは次のセクションで必要になります。
5. エラーのアラート ポリシーの作成
エラーログの確認
アプリケーションのエラーログを表示するには:
[ロギング] タブをクリックします。
ログのインターフェースが表示され、さまざまなリソース(プロジェクト、Google Cloud リソース、サービス名など)を個別に選択または選択解除できます。必要に応じてログレベルも選択できます。
I-1、I-2、I-3 以外の商品 ID を指定して、在庫サービスに対する無効なリクエストをシミュレートします。例:正しくないリクエストの例は次のとおりです。
https://<SERVICE_URL>/inventory/I-999
クエリで間違ったプロダクト ID が指定された場合に、API によって生成されたすべての WARNING アラートを検索します。
エラー用のカスタム ログベースのアラート ポリシーの作成
アプリケーションの一部で非常に具体的なエラー メッセージの発生に注意する必要があるとします。商品 ID の検索でエラーが多数見つかったとします。この問題は、考えられる多くの問題(不適切なリンク、データベースの不整合、bot によるサイトの列挙など)の兆候です。すべての潜在的な原因を想像するのは困難または不可能ですが、このメッセージを1 回でも送信するアプリケーションは、概要レベルの問題として認識する必要があります。アラートを生成するには、エラーログのデータに基づいてポリシーを作成する必要があります。
- クエリボックスに、次のクエリ パラメータを挿入します。
resource.type="cloud_run_revision"
textPayload =~ "WARNING in app: Received inventory request for wrong productid"
次のようになります。
- [クエリを実行] をクリックします。受信したすべてのリクエストと、この問題が発生しているリクエストがすべて表示されます。
- 上記をアラートに変換するには、ログ エクスプローラのクエリ フィールドのすぐ下に表示されている [アラートを作成] ボタンをクリックします。
- これにより、ログベースのアラート ポリシーを作成するためのフォームが表示されます。
- アラートに含めるログの最初のクエリを使用します。
resource.type="cloud_run_revision"
textPayload
=~
"WARNING
in
app:
Received
inventory
request
for
incorrect
productid"
- 通知頻度とインシデント期間を設定します。この例では、それぞれに最小値を使用できます。
- 最後に [誰に通知するか]では先ほど作成した Pub/Sub 通知チャンネルを選択します。
- [保存] をクリックします。アラート ポリシーを表示および管理するには、[アラート] ページにアクセスし、[ポリシー] で を確認します。
6. 完了
これで、Pub/Sub にアラートを送信するように稼働時間チェックを構成できました。