クラウドオペレーション

Cloud Monitoring と Cloud Run を使用したカスタム通知の作成

2022年2月1日

Google Cloud Japan Team

※この投稿は米国時間 2022 年 1 月 20 日に、Google Cloud blog に投稿されたものの抄訳です。

エンタープライズ IT スペースに所属する各組織では、その独自性ゆえにアラートの処理方法について興味深い課題が発生します。IT サービス管理（ITSM）市場に存在する多くの商用ツールと、多くのカスタム内部ツールにより、Google はチームに柔軟で強力なツールを提供できます。

この投稿は、通知チャンネルをサポートしていないサードパーティのサービスに Cloud Monitoring のアラート通知を配信したい、Google Cloud のお客様を対象としています。

ここでは、Cloud Pub/Sub 通知チャンネルを Google Chat サービスと統合して、アラート通知を Google Chat のルームに転送する実用的な実装を提供し、それが Google Cloud にどのようにデプロイされるかを示します。それに加えて、Cloud Build、Terraform、および GitHub を使用した継続的インテグレーションの手順の概要についても説明します。このプロジェクトのすべてのソースコードは、この GitHub リポジトリにあります。

このチュートリアルでは、Google Cloud のお客様が、Webhook / Http API インターフェースを提供するサードパーティのサービスにアラート通知を配信するために適応できる汎用フレームワークが提供されていることに注目してください。

サンプルコードを変更して他のサードパーティサービスと統合する方法については、「他のサードパーティサービスへの拡張」のセクションで説明されています。

目標

Google Cloud Monitoring アラート通知を Cloud Monitoring Pub/Sub 通知チャンネルからサードパーティサービスに転送するサービスを作成します。
Cloud Build、Terraform、GitHub を使用してサービスをビルドし、Cloud Run にデプロイします。

費用

このチュートリアルでは、Google Cloud の課金対象となるコンポーネントを使用します。

Cloud Build
Cloud Compute Engine（GCE）
Cloud Container Registry
Cloud Pub/Sub
Cloud Run
Cloud Storage

料金計算ツールを使うと、予想使用量に基づいて費用の見積もりを出すことができます。

はじめに

このチュートリアルでは GCP プロジェクトが必要です。新しいプロジェクトを作成することも、すでに作成済みのプロジェクトを選択することもできます。

Google Cloud プロジェクトを選択するか、新しく作成します。
プロジェクトセレクタページに移動する
プロジェクトに対して課金を有効にします。
課金を有効にする

このチュートリアルを終了した後、作成したリソースを削除すると、それ以上の請求は発生しません。詳細については、このチュートリアルの最後にある「クリーンアップ」セクションを参照してください。

Google Chat との統合

このチュートリアルでは、Google Cloud のお客様がアラート通知を Google Chat のルームに転送できるようにするための、統合のサンプルを提供します。システムアーキテクチャは次のとおりです。

https://storage.googleapis.com/gweb-cloudblog-publish/images/Creating_custom_notifications_with_Cloud_Mon.max-800x800.jpg

この例では、Terraform を使用して 2 つのモニタリングアラートポリシーが作成されます。1 つは GCE インスタンスの CPU の usage_time 指標に基づいており、もう 1 つは GCE インスタンスのディスクの read_bytes_count 指標に基づいています。どちらのアラートポリシーも、Cloud Monitoring Pub/Sub 通知チャンネルを使用してアラート通知を送信します。Cloud Pub/Sub push サブスクリプションは、Cloud Pub/Sub 通知チャンネルごとに構成されます。Cloud Pub/Sub push サブスクリプションの push エンドポイントは、Cloud Pub/Sub 通知チャンネルに送信されるすべてのアラート通知が Cloud Run サービスに転送されるように実装する、Cloud Run サービスを指します。Cloud Run サービスは、受け取った Cloud Pub/Sub メッセージを Google Chat メッセージに変換し、受け取った Webhook URL を介して構成済みの Google Chat ルームに送信するシンプルな Http サーバーです。

すべてのインフラストラクチャコンポーネントは、Terraform を使用して自動的に作成および構成されます。これには次のものが含まれます。

Cloud Pub/Sub トピック、push サブスクリプション、サービスアカウントの設定
Cloud Pub/Sub 通知チャンネル
Cloud Monitoring のアラートポリシー
Cloud Run サービスとサービスアカウントの設定

Terraform のコードは、./tf-modules および./environments にあります。

Cloud Run のコードを見る

Cloud Run サービスは、構成された Google Chat ルームに Cloud Pub/Sub アラート通知を配信する役割を果たします。統合コードは ./notification_integration フォルダーにあります。

この例では、基本的な Flask HTTP サーバーが main.py にセットアップされ、Cloud Monitoring Pub/Sub チャンネルから受け取った Cloud Monitoring アラート通知を処理します。Cloud Pub/Sub push サブスクリプションを使用して、Pub/Sub 通知メッセージを Flask サーバーにリアルタイムで転送します。Cloud Pub/Sub サブスクリプションの詳細については、サブスクライバーの概要をご参照ください。

以下は、Pub/Sub メッセージを処理するハンドラーです。

読み込んでいます...

@app.route('/<config_id>', methods=['POST'])
def handle_pubsub_message(config_id):
   try:
       config_param = config_params_server.GetConfig(config_id)
   except BaseException as e:
       err_msg = 'Failed to get config parameters for {}: {}'.format(config_id, e)
       logging.error(err_msg)
       return(f'500: {err_msg}', 200)
   if 'service_name' not in config_param:
       err_msg = '"service_name" not found in the config parameters: {}'.format(config_id)
       logging.error(err_msg)
       return(f'500: {err_msg}', 200)
   if config_param['service_name'] not in service_names_to_handlers:
       err_msg = 'No handler found for the service {}'.format(config_param['service_name'])
       logging.error(err_msg)
       return(f'500: {err_msg}', 200)
 
   handler = service_names_to_handlers[config_param['service_name']]
 
   # Pub/Sub raw メッセージを解析して通知を取得します
   pubsub_received_message = request.get_json()
   try:
       notification = pubsub.ExtractNotificationFromPubSubMsg(pubsub_received_message)
       response, status_code = handler.SendNotification(config_param, notification)
       logging.info(f'Notification was sent with the status code = {status_code}: {response}')
       return(f'{status_code}: {response}', 200) 
   except pubsub.DataParseError as e:
       logging.error(f'Pubsub message parse error: {e}')
       return(f'400: {e}', 200)
   except BaseException as e:
       logging.error(f'Unexpected error when processing Pubsub message: {e}')
       return(f'400: {e}', 200)

ハンドラーは、utilities/pubsub.py の ExtractNotificationFromPubSubMsg() 関数を呼び出して、Pub/Sub メッセージから関連する通知データを解析し、通知データをディクショナリに読み込みます。出力は、ここで定義されたスキーマを持つ json オブジェクトです。

読み込んでいます...

def ExtractNotificationFromPubSubMsg(pubsub_msg: Dict[Text, Any]) -> Dict[Text, Any]:
 """Parses notification messages from Pub/Sub.
   Args:
       pubsub_msg: Dictionary containing the Pub/Sub message.
       The message itself should be a base64-encoded string.
   Returns:
       The decoded 'data' value of the provided Pub/Sub message, returned as a json dictory.
   Raises:
       DataParseError: If data cannot be parsed.
"""
   try:
       data_base64_string = pubsub_msg['message']['data']
   except (KeyError, TypeError) as e:
       raise DataParseError('invalid Pub/Sub message format') from e

try:
    data_bytes = base64.b64decode(data_base64_string)
   except (binascii.Error, ValueError) as e:
       raise DataParseError('data should be base64-encoded') from e
   except TypeError as e:
       raise DataParseError('data should be in a string format') from e
   data_string = data_bytes.decode('utf-8')
   data_string = data_string.strip()

try:
       data_json = json.loads(data_string)
   except json.JSONDecodeError as e:
       raise DataParseError('data can not be loaded as a json object: {}'.format(e), 400)

return data_json

次に、この通知ディクショナリは SendNotification() に渡され、SendNotification() は config_params とともに通知を utilities/service_handler.py の _SendHttpRequest() に送信します。これにより、API クライアントを使用して、アラートがサードパーティサービスに適切に通知されます。URL パラメータ「config_id」は、Cloud Run サービスが構成データ「config_params」を取得するために使用する構成 ID です。「config_params」には、受け取った通知をサードパーティのサービスに転送するために Cloud Run サービスに必要なすべてのパラメータ（HTTP URL やユーザーの認証情報など）が含まれています。この例では、「config_id」は、ここで定義されている Pub/Sub トピックに対応しています。

このディスパッチ機能を変更して、アラートをサードパーティのサービスに転送できます。

読み込んでいます...

成功の HTTP ステータスコード（200 または 204）を返すことにより、Pub/Sub メッセージの成功を確認応答することを忘れないでください。push メッセージの受信をご確認ください。

Cloud Run サービスに書き込まれたすべてのログには、Cloud Logging Logs Explorer または Cloud Run UI から簡単にアクセスできます。ログは、Cloud Run サービスのデバッグに非常に役立ちます。さらにユーザーは、Cloud Pub/Sub 通知チャンネルで使用される Pub/Sub トピックの追加の pull サブスクリプションを作成して、通知配信の問題のトリアージを簡素化できます。たとえば、一部のアラート通知がユーザーの Google Chat ルームに配信されなかった場合、ユーザーは最初に、欠落しているアラート通知の Cloud Pub/Sub メッセージを pull サブスクリプションが受信したかどうかを確認できます。欠落しているアラート通知を pull サブスクリプションが正しく受信した場合、それはアラート通知が Cloud Run サービスで失われたことを意味します。それ以外の場合は、Cloud Pub/Sub 通知チャンネルの問題ということになります。

最後に、Cloud Run にデプロイされたときに Flask サーバーをホストするイメージを構築するための手順を含む、Dockerfile についてです。

読み込んでいます...

アプリのデプロイ

このセクションでは、GitOps の方法論に従って、Cloud Build、Terraform、GitHub を使用して継続的インテグレーションをデプロイおよびセットアップする方法について説明します。この手順は、Terraform、Cloud Build、GitOps を使用したコードとしてのインフラストラクチャの管理に基づいており、GitOps の方法論とアーキテクチャについても説明しています。ガイドのセクションは、以下の手順でも参照します。重要な違いは、このドキュメントでは、dev 環境と prod 環境に別々の Google Cloud プロジェクトが使用されていることを前提としているのに対し、参照ガイドでは環境を仮想プライベートクラウド（VPC）として構成していることです。そのため、dev プロジェクトと prod プロジェクトごとに、次のデプロイ手順（「GitHub リポジトリのセットアップ」を除く）を実行する必要があります。

GitHub リポジトリを設定する

すべてのコードを取得し、アプリのデプロイに必要なリポジトリ構造を理解するには、GitHub リポジトリの設定の手順を実施します。

Google Chat 統合をデプロイする

webhook URL の設定

ハードコードされた Webhook URL

main.py 内に、webhook URL を保存するための config_map 変数を提供しています。まず、Google Chat の webhook URL を見つけて、config_map ディクショナリ内のキー「webhook_url」の値を置き換える必要があります。

読み込んでいます...

手動 GCS バケット Webhook URL

Webhook URL を保存するためのより安全なオプションが必要な場合は、GCS バケットを作成して Webhook URL を保存できます。

gchat ルームの Google Chat webhook URL を見つけて、config_params.json という名前の json ファイルに次の形式で保存します。

{“topic”: “webhook url”, “topic”: “webhook url”}

Cloud Storage バケットを作成し、gcs_config_bucket_{PROJECT_ID} という名前の json ファイルを格納します。

次のコマンドを Cloud Console で実行することもできます。gsutil mb gs://gcs_config_bucket_{PROJECT_ID}

読み取り権限（Storage レガシーバケット読み取りとストレージレガシーオブジェクトリーダー）を次のデフォルトの Cloud Run サービスアカウントに付与します。<PROJECT_NUMBER>-compute@developer.gserviceaccount.com

通知チャンネル統合サンプルを初めて自動的にデプロイするために、デプロイに必要なアクションの大部分を処理するスクリプト deploy.py を提供しました。上記の webhook URL の手順を完了したら、次のコマンドを実行します。

読み込んでいます...

手動でのデプロイ

通知チャンネル統合を手動でデプロイするには、次の手順を完了する必要があります。

1. Cloud Shell で Cloud Platform プロジェクトを設定します。<PROJECT_ID> を Cloud Platform プロジェクト ID に置き換えます。

読み込んでいます...

2. Cloud Build サービスを有効にします。

読み込んでいます...

3. Cloud Resource Manager サービスを有効にします。

読み込んでいます...

4. Cloud Service Usage サービスを有効にします。

読み込んでいます...

5. Cloud Build サービスアカウントに必要な権限を付与します。

読み込んでいます...

6. Cloud Storage バケットを作成して、Terraform の状態をリモートで保存します。

PROJECT_ID=$(gcloud config get-value project)

読み込んでいます...

7. （オプション）オブジェクトのバージョニングを有効にして、デプロイの履歴を保持できます。

読み込んでいます...

8. ビルドをトリガーし、Cloud Run にデプロイします。

インメモリ構成サーバーを使用した場合は、次を実行します（<BRANCH> を現在の環境ブランチに置き換える）。

読み込んでいます...

GCS ベースの構成サーバーを使用する場合は、次を実行します。

読み込んでいます...

継続的デプロイのセットアップ

これはオプションのフローであり、このセクションでは、トリガーを使用して、Cloud Build を使用した継続的デプロイを設定する方法について説明します。フローは次の図に示されています。ユーザーが新しいバージョンを Git リポジトリに push するたびに、Cloud Build トリガーがトリガーされます。Cloud Build は YAML ファイルを実行して、Cloud Run docker イメージを再構築し、インフラストラクチャセットアップを更新し、Cloud Run サービスを再デプロイします。

https://storage.googleapis.com/gweb-cloudblog-publish/images/Creating_custom_notifications_with_Cloud_Mon.max-800x800_hqHW7wt.jpg

この手順は、Cloud Build を使用したビルドの自動化に基づいています。

コードリポジトリを設定します。GitHub、Google Cloud Source リポジトリ、または任意のプライベートリポジトリを設定できます。

GitHub からリポジトリのクローンを作成します。
新しいプロジェクトに切り替えて、クローンされたリポジトリをリモートリポジトリに push します。

読み込んでいます...

https://storage.googleapis.com/gweb-cloudblog-publish/images/cloud_source_repositories.max-1900x1900.jpg

次に、Cloud Build で新しいトリガーを作成します。

クリーンアップ

このチュートリアル用に新規プロジェクトを作成した場合は、そのプロジェクトを削除します。既存のプロジェクトを使用し、このチュートリアルでの変更を加えずに残す場合は、チュートリアル用に作成したリソースを削除します。

プロジェクトの削除

課金を停止する最も簡単な方法は、チュートリアル用に作成したプロジェクトを削除することです。

プロジェクトを削除すると、次のような影響があります。

プロジェクト内のすべてのものが削除されます。このチュートリアルで既存のプロジェクトを使用した場合、それを削除すると、そのプロジェクトで行った他の作業もすべて削除されます。
カスタムプロジェクト ID が失われます。このプロジェクトを作成したときに、将来使用するカスタムプロジェクト ID を作成した可能性があります。appspot.com URL など、プロジェクト ID を使用する URL を保持するには、プロジェクト全体を削除するのではなく、プロジェクト内の選択したリソースを削除します。

複数のチュートリアルとクイックスタートを実施する予定がある場合は、プロジェクトを再利用すると、プロジェクトの割り当て上限を超えないようにできます。

プロジェクトを削除する手順は次のとおりです。

Cloud Console で、[リソースの管理] ページに移動します。
[リソースの管理] ページに移動する
プロジェクトリストで、削除するプロジェクトを選択し、[削除] をクリックします。
ダイアログでプロジェクト ID を入力し、[シャットダウン] をクリックしてプロジェクトを削除します。

チュートリアルリソースの削除

Terraform によってプロビジョニングされた Cloud リソースを削除します。
terraform destroy
{PROJECT_ID}-tfstate という名前の Cloud Storage バケットを削除します。
Cloud Build サービスアカウントに付与された権限を削除します。
gcloud projects remove-iam-policy-binding $PROJECT_ID --member serviceAccount:$CLOUDBUILD_SA --role roles/iam.securityAdmin
gcloud projects remove-iam-policy-binding $PROJECT_ID --member serviceAccount:$CLOUDBUILD_SA --role roles/run.admin
gcloud projects remove-iam-policy-binding $PROJECT_ID --member serviceAccount:$CLOUDBUILD_SA --role roles/storage.admin
tf-topic に公開するサービスアカウントの権限を削除します。
gcloud pubsub topics remove-iam-policy-binding \ projects/[PROJECT_NUMBER]/topics/tf-topic --role=roles/pubsub.publisher \ --member=serviceAccount:service-[PROJECT_NUMBER]@gcp-sa-monitoring-notification.iam.gserviceaccount.com
tf-topic を使用する通知チャンネルを削除します。
フォークされた notification_integrationGitHub リポジトリを削除します。
Cloud Build トリガーを削除して、GitHub リポジトリを Cloud Build から切断します。
Google Cloud API を無効にします。

他のサードパーティサービスへの拡張

チュートリアルのサンプルコードは一般的なフレームワークを提供しており、Google Cloud のお客様向けに簡単にカスタマイズして、Webhook/Http API インターフェースを提供するサードパーティサービスにアラート通知を配信できます。

新しいサードパーティサービスと統合する場合は、./notification_channel/service_handler.py で定義された抽象クラス HttpRequestBasedHandler の新しい派生クラスを作成し、次のメンバー関数を更新します。

CheckConfigParams(): 特定の統合構成が有効かどうかをチェックする関数です。必要な API キーが与えられます。
_GetHttpUrl(): 構成データから Http URL（Http リクエストの送信先）を取得する関数です。
_BuildHttpRequestHeaders(): Http リクエストヘッダーを作成する関数です。
_BuildHttpRequestBody(): 受け取った Cloud Pub/Sub メッセージに基づいて Http リクエストメッセージ本文を構築する関数です。
SendNotification(): GchatHandler クラスで定義されたものを再利用できます。

アラートポリシーをカスタマイズする必要がある場合を除いて、Terraform コードを更新する必要はありません。追加の提案がある場合は、いつでもコミュニティからフィードバックをお寄せください。pull リクエストを送信して、一緒に GitHub リポジトリの構築を継続しましょう。

- ソフトウェアエンジニア Dong Wang

投稿先