このドキュメントでは、合成モニターを作成して、サービス、アプリケーション、ウェブページ、API の可用性、整合性、パフォーマンスをテストする方法について説明します。アプリケーションのテストを行います。合成モニターは、そのスクリプトを実行して、テスト結果やレイテンシなどの追加データを記録します。テストに失敗したときに通知されるには、テスト結果をモニタリングするアラート ポリシーを構成します。
合成モニターについて
合成モニターは、Cloud Run にデプロイされた単一目的の第 2 世代の Cloud Run functions を定期的に実行します。合成モニターの作成時に、Node.js で記述する必要がある Cloud Run functions と実行頻度を定義します。たとえば、Puppeteer を使用して、ウェブページとやり取りするように Cloud Run functions を構成できます。また、Axios モジュールを使用して API とやり取りするように Cloud Run functions を構成することもできます。VPC ネットワーク内にあるリソースをテストすることもできます。
Cloud Run functions を作成するには、インライン エディタを使用するか、zip ファイルをアップロードします。インライン エディタを使用する場合は、指定したスケルトンを使って開始できます。合成モニターを作成すると、Cloud Monitoring は、Cloud Run functions の定期的な実行をスケジューリングするスケジューリング システムを使用します。Cloud Run functions が存在するリージョンを指定する間、実行をトリガーするコマンドは、稼働時間チェック サーバーでサポートされている任意のリージョンで指定できます。詳細については、稼働時間チェック サーバーの IP アドレスを一覧表示するをご覧ください。
テストが失敗したときに通知されるようにアラート ポリシーを作成できます。
Google Cloud コンソールを使用して合成モニターを作成する場合、デフォルトの動作としてアラート ポリシーが作成されます。通知チャンネルを指定します。デフォルトのアラート ポリシーは、連続して 2 回以上テストが失敗したときに通知するように構成されています。
Cloud Monitoring API を使用して合成モニターを作成する場合は、アラート ポリシーを作成して、Cloud Run functions が実行される Cloud Run リソースの
uptime_check/check_passed指標タイプをモニタリングする必要があります。
実行頻度に関する考慮事項
Cloud Run functions を実行する頻度を構成します。実行頻度を決めるには、サービスのサービスレベル目標（SLO）を考慮します。潜在的な SLO 違反を捕捉するには、テストを頻繁に実行する必要があります。ただし、サービスの SLO だけを考慮するわけではありません。また、実行頻度がサービスの負荷と費用にどのように影響するかも考慮する必要があります。実行ごとにサービスの負荷がかかるため、Cloud Run functions を実行する頻度が高いほどサービスに適用される負荷が増加します。なお、稼働時間チェックのデフォルトの実行間隔は 1 分です。
実行頻度によって、テストに失敗したときに通知される速度も決まります。Monitoring によってインシデントが開かれ、2 回連続のテストの失敗後に通知が送信されます。たとえば、実行頻度が 5 分の場合、2 回のテスト失敗までに 10 分かかることがあります。2 回目のテストの失敗後に通知されます。
Cloud Run functions のサンプルコード
テンプレートとサンプルについては、合成モニターのサンプルをご覧ください。これらのサンプルを Cloud Run functions の開始点として使用できます。 経験豊富なデベロッパーの場合は、Gemini を使用して合成モニターのコードを生成し、開発時間を短縮することを検討してください。 Gemini を使用してコードを生成する機能はパブリック プレビュー版です。
Google Cloud コンソールを使用して合成モニターを作成するときに選択できる汎用テンプレートは、送信 HTTP リクエストのトレースデータとログデータを収集するように構成されます。このソリューションでは、OpenTelemetry auto-instrumentation-node モジュールと winston ロガーを利用します。オープンソース プロダクトに依存しているため、トレースデータとログデータの構造が変更される可能性があります。したがって、収集されたトレースデータとログデータは、デバッグ目的でのみ使用してください。
独自のアプローチを実装して、送信 HTTP リクエストのトレースデータとログデータを収集できます。カスタム アプローチの例については、クラス SyntheticAutoInstrumentation をご覧ください。
Cloud Run functions の構成
Cloud Run functions を構成する場合は、ランタイム、ビルド、接続、セキュリティの設定を指定するか、デフォルト設定をそのまま使用します。
割り当てられたメモリのデフォルト値では十分ではない場合があります。このフィールドは 2 GiB 以上に設定することをおすすめします。
Cloud Run functions の受信データ転送設定のデフォルト値は、すべてのトラフィックを許可することです。この設定またはより制限の厳しい設定を使用できます。
すべてのトラフィックを許可すると、Cloud Run functions で実行される検証の最初のフェーズがネットワーク レベルで行われ、常に合格します。検証の 2 番目のフェーズでは、呼び出し元に Cloud Run functions の実行権限が付与されているかどうかを確認します。承認は、呼び出し元の Identity and Access Management（IAM）ロールによって異なります。デフォルトでは、Cloud Monitoring には Cloud Run functions を実行する権限が付与されています。受信データ移転設定を表示または変更する方法については、上り（内向き）設定をご覧ください。
Cloud Run functions の制限
Cloud Run functions の名前にアンダースコアを含めることはできません。
送信 HTTP リクエストのトレースデータとログデータを収集できるのは、汎用テンプレートを使用する場合のみです。
HTTP 関数のみがサポートされています。Google Cloud コンソールを使用して合成モニターを作成する場合は、URL をクエリするデフォルト関数が提供されます。デフォルト関数のソースは変更可能で、
generic-synthetic-nodejsGit リポジトリで入手できます。HTTP 関数の詳細については、HTTP 関数を作成するをご覧ください。
API を使用する場合、デプロイ コマンドでは Cloud Run functions が第 2 世代であることを指定する必要があります。Google Cloud コンソールを使用する場合、デプロイは自動的に行われます。詳細については、Cloud Run functions をデプロイするをご覧ください。
ランタイム環境は Node.js に制限されています。詳細については、ノードをご覧ください。以下のバージョンの Node.js がサポートされています。12、14、16、18、20。
合成モニターによって収集されるデータ
このセクションでは、合成モニター用に収集されるデータについて説明します。実行結果を表示する方法については、合成モニターの結果を探索するをご覧ください。
実行履歴
合成モニターごとに、実行結果の履歴が収集されます。このデータには次のものが含まれます。
時間とともに実行の成功または失敗を記録する時系列。
コードの実行時間を記録する時系列。関数の実行時間は記録されません。レイテンシ データは、Cloud Run functions が実行されている Cloud Run リソースの
uptime_check/request_latency時系列として書き込まれます。このデータのチャートは、[合成モニターの詳細] ページにあります。合成モニターの実行に関する情報（テストと障害の詳細など）を含むログ。使用可能なログは、Cloud Run functions によって異なります。たとえば、Mocha テンプレートを使用する場合、ログには、テストの成否とテスト時間に関する情報が含まれます。スタック トレースには（含まれる場合）、失敗したコード行、エラータイプ、エラー メッセージが一覧表示されます。
必要に応じて、送信 HTTP リクエストのトレースとログ。このデータを収集する方法については、リクエスト レイテンシをご覧ください。
Cloud Run functions の指標とログ
Cloud Run functions の指標とログ。このデータは Cloud Run functions によって収集され、関数の 1 秒あたりの実行回数、実行時間、メモリ使用量に関する情報が含まれます。
リクエストのレイテンシ
合成モニターによる HTTP リクエストのレイテンシ データは Cloud Trace によって自動的に収集され、保存されます。
合成モニターによって行われた送信 HTTP リクエストのトレースデータ、ログデータ、レイテンシ データを収集するには、汎用テンプレートを使用する必要があります。詳細については、合成モニターのサンプルをご覧ください。
始める前に
-
Google Cloud コンソールを使用して合成モニターを表示して変更するために必要な権限を取得するには、プロジェクトに対する次の IAM ロールの付与を管理者に依頼してください。
-
モニタリング編集者（
roles/monitoring.editor） -
Cloud Functions デベロッパー（
roles/cloudfunctions.developer）
ロールの付与については、プロジェクト、フォルダ、組織へのアクセス権の管理をご覧ください。
-
モニタリング編集者（
-
Enable the Cloud Monitoring API, Artifact Registry API, Cloud Build API, Cloud Functions API, Cloud Logging API, Pub/Sub API, and Cloud Run Admin API APIs.
Google Cloud プロジェクトにデフォルトの Compute Engine サービス アカウントが含まれていることを確認します。このサービス アカウントは、Compute Engine API を有効にしたときに作成され、名前は
12345-compute@developer.gserviceaccount.comのようになります。Google Cloud コンソールで、[サービス アカウント] ページに移動します:
検索バーを使用してこのページを検索する場合は、小見出しが [IAM と管理者] である結果を選択します。
デフォルトの Compute Engine サービス アカウントが存在しない場合は、[サービス アカウントを作成する] をクリックしてダイアログを完了します。
デフォルトの Compute Engine サービス アカウントまたは作成したサービス アカウントに、編集者（
roles/editor）のロールが付与されていることを確認します。サービス アカウントに付与されているロールを表示する方法は次のとおりです。
-
Google Cloud コンソールの [IAM] ページに移動します。
検索バーを使用してこのページを検索する場合は、小見出しが [IAM と管理者] である結果を選択します。
- [Google 提供のロール付与を含む] を選択します。
- 合成モニターで使用されるサービス アカウントがリストに表示されていない場合、または Cloud Trace エージェント（
roles/cloudtrace.agent）のロールの権限を含むロールが付与されていない場合、このロールをサービス アカウントに付与します。
-
- 通知の受信に使用する通知チャンネルを構成します。複数の種類の通知チャンネルを作成することをおすすめします。詳細については、通知チャネルを作成して管理すると API によって通知チャネルを作成して管理するをご覧ください。
合成モニターを作成する
Console
Google Cloud コンソールを使用して合成モニターを作成すると、新しい Cloud Run 関数（第 2 世代）がデプロイされ、その Cloud Run 関数のモニターが作成されます。既存の Cloud Run 関数をモニタリングする合成モニターは作成できません。
- 必要な API が有効になっていること、プロジェクトにデフォルトの Compute Engine サービス アカウントが含まれていること、このアカウントに編集者（
roles/editor）のロールが付与されていることを確認します。詳細については、始める前にをご覧ください。 -
Google Cloud コンソールで、
[合成モニタリング] ページに移動します。検索バーを使用してこのページを検索する場合は、小見出しが [Monitoring] である結果を選択します。
- [合成モニターを作成] を選択します。
Cloud Run functions のテンプレートを選択します。
カスタム合成モニター: 送信 HTTP リクエストのログデータまたはトレースデータを収集する場合は、このテンプレートを使用します。
Mocha 合成モニター: Mocha テストスイートを作成するときにこのテンプレートを使用します。
無効なリンクのチェッカー: このテンプレートを使用して、その URI で見つかった URI と構成可能な数のリンクをテストします。このチェッカーのフィールドについては、無効なリンクのチェッカーを作成するをご覧ください。
モニターの名前を入力します。
省略可: [レスポンスのタイムアウト] と [チェック頻度] を更新し、ユーザー定義のラベルを追加します。
次のいずれかを行います。
このプロジェクトの Gemini Code Assist へのアクセス権があり、コード作成のサポートが必要な場合は、[コーディングをサポート] をクリックします。この機能は公開プレビュー版です。プロンプトのガイダンスについては、合成モニターのプロンプトの作成方法を学習するをご覧ください。
コードに問題がなければ、[Cloud Functions の関数に挿入] をクリックします。
[ファンクションを作成] をクリックします。
Cloud Run functions のダイアログで、次の操作を行います。
表示名を入力し、リージョンを選択します。名前はリージョン内で一意でなければなりません。
[ランタイム、ビルド、接続、セキュリティの設定] セクションで、次の操作を行います。
デフォルト設定を確認し、必要に応じて更新します。
[Runtime サービス アカウント] フィールドで、サービス アカウントを選択します。
生成されたコードを編集するか、Cloud Run functions のコードを記述またはアップロードします。
生成されたコードを編集したり、独自のコードやデフォルトのサンプル関数を読み込んだりする場合は、[インライン エディタ] を選択します。サンプル関数は、前に選択したテンプレートに依存し、特定の URL にリクエストを送信します。デフォルト関数を変更できます。
ローカル システムから zip ファイルを読み込むには、[ZIP アップロード] を選択します。
ローカル システムから ZIP ファイルをアップロードする場合は、ZIP ファイルの Cloud Storage バケットも指定する必要があります。適切な Cloud Storage バケットがない場合は、作成します。
Cloud Storage から ZIP ファイルを読み込むには、[Cloud Storage の ZIP] を選択し、ストレージ バケットを選択して、読み込む ZIP ファイルを選択します。
Google Cloud コンソールの Cloud Run functions ページを使用して、Cloud Run functions を作成することもできます。その Cloud Run functions のコピーをモニタリングする合成モニターを作成するには、[ソース] タブに移動して [zip をダウンロードする] をクリックします。その後、zip ファイルをアップロードできます。
[関数を適用する] をクリックします。
アラート ポリシーを構成します。
省略可: アラート ポリシー名と、通知が送信されるまでの障害継続期間を更新します。
通知チャンネルを追加します。
[作成] をクリックします。
定義した Cloud Run functions が第 2 世代としてビルドされ、デプロイされ、合成モニターが作成されます。
gcloud
Google Cloud CLI または Cloud Monitoring API を使用して合成モニターを作成する場合は、関数名を API 呼び出しに渡します。したがって、既存の Cloud Run functions をモニタリングする合成モニターのみを作成できます。
- 必要な API が有効になっていること、プロジェクトにデフォルトの Compute Engine サービス アカウントが含まれていること、このアカウントに編集者（
roles/editor）のロールが付与されていることを確認します。詳細については、始める前にをご覧ください。 - 第 2 世代の Cloud Run functions を書き込み、デプロイします。
たとえば、
Google Cloud/synthetics-sdk-nodejsリポジトリにsynthetics-sdk-nodejsサンプルをデプロイするには、次のようにします。リポジトリのクローンを作成し、ソースコードのロケーションに移動します。
git clone https://github.com/GoogleCloudPlatform/synthetics-sdk-nodejs.git cd synthetics-sdk-nodejs/samples/generic-synthetic-nodejsgcloud functions deployコマンドを使用して Cloud Run functions をデプロイします。gcloud functions deploy FUNCTION_NAME \ --gen2 --region="us-west2" --source="." \ --entry-point=SyntheticFunction --trigger-http --runtime=nodejs18gcloud functions deployコマンドで、次のようにします。FUNCTION_NAME フィールドの値がデプロイ リージョン内で一意であることを確認します。
--gen2フラグを指定して、デプロイ リージョンを設定します。次のように
--entry-pointフィールドを設定します。- Mocha:
SyntheticMochaSuite - Mocha 以外:
SyntheticFunction。
- Mocha:
--runtimeフィールドをnodejs18に設定します。フラグ
--trigger-httpを追加します。すべてのトラフィックを許可するデフォルト設定を使用しない場合は、
--ingress-settingsフィールドを設定します。
Cloud Run functions は、Cloud Run functions をビルドしてデプロイします。Google Cloud CLI コマンドの結果には、関数の完全修飾名などの関数に関する情報が含まれます。
name: projects/PROJECT_ID/locations/REGION/functions/FUNCTION_NAME関数のデプロイについては、Cloud Run functions をデプロイするをご覧ください。
Google Cloud プロジェクト内の Cloud Run functions を一覧表示するには、
gcloud functions listコマンドを使用します。gcloud functions listこの呼び出しのレスポンスはリストエントリです。各エントリには Cloud Run functions が一覧表示されます。
NAME: function-1 STATE: ACTIVE TRIGGER: HTTP Trigger REGION: us-west2 ENVIRONMENT: 2nd gen特定の Cloud Run functions の完全修飾名を確認するには、
gcloud monitoring uptime describeコマンドを実行します。 合成モニターを作成するには、
gcloud monitoring uptime createコマンドを実行します。gcloud monitoring uptime create DISPLAY_NAME --synthetic-target=TARGET前述のコマンドを実行する前に、次のようにしてください。
- DISPLAY_NAME は、合成モニターの名前に置き換えます。
- TARGET は、Cloud Run functions の完全修飾名に置き換えます。
アラート ポリシーを作成します。
アラート ポリシーの構成の複雑さのため、Google Cloud コンソールで [合成モニター] ページに移動し、オプションを使用してアラート ポリシーを作成することをおすすめします。このアプローチでは、ほとんどのアラート ポリシー フィールドに値が自動入力されます。Google Cloud コンソールを使用してアラート ポリシーを作成するには、合成モニター ページで ポリシーを作成するをクリックします。
Google Cloud CLI または Cloud Monitoring API を使用する場合は、次のように条件のフィルタを構成します。
"filter": "resource.type = \"cloud_run_revision\" AND metric.type = \"monitoring.googleapis.com/uptime_check/check_passed\" AND metric.labels.check_id = \"CHECK_ID\"",条件は、合成モニターによって書き込まれた
uptime_check/check_passed時系列をモニタリングします。CHECK_ID は、合成モニターの識別子に置き換えるようにしてください。これは create コマンドのレスポンス データに含まれます。アラート ポリシーの作成方法については、API を使用してアラート ポリシーを作成するをご覧ください。
API
Google Cloud CLI または Cloud Monitoring API を使用して合成モニターを作成する場合は、関数名を API 呼び出しに渡します。したがって、既存の Cloud Run functions をモニタリングする合成モニターのみを作成できます。
- 必要な API が有効になっていること、プロジェクトにデフォルトの Compute Engine サービス アカウントが含まれていること、このアカウントに編集者（
roles/editor）のロールが付与されていることを確認します。詳細については、始める前にをご覧ください。 - 第 2 世代の Cloud Run functions を書き込み、デプロイします。
たとえば、
Google Cloud/synthetics-sdk-nodejsリポジトリにsynthetics-sdk-nodejsサンプルをデプロイするには、次のようにします。リポジトリのクローンを作成し、ソースコードのロケーションに移動します。
git clone https://github.com/GoogleCloudPlatform/synthetics-sdk-nodejs.git cd synthetics-sdk-nodejs/samples/generic-synthetic-nodejsgcloud functions deployコマンドを使用して Cloud Run functions をデプロイします。gcloud functions deploy FUNCTION_NAME \ --gen2 --region="us-west2" --source="." \ --entry-point=SyntheticFunction --trigger-http --runtime=nodejs18gcloud functions deployコマンドで、次のようにします。FUNCTION_NAME フィールドの値がデプロイ リージョン内で一意であることを確認します。
--gen2フラグを指定して、デプロイ リージョンを設定します。次のように
--entry-pointフィールドを設定します。- Mocha:
SyntheticMochaSuite - Mocha 以外:
SyntheticFunction。
- Mocha:
--runtimeフィールドをnodejs18に設定します。フラグ
--trigger-httpを追加します。すべてのトラフィックを許可するデフォルト設定を使用しない場合は、
--ingress-settingsフィールドを設定します。
Cloud Run functions は、Cloud Run functions をビルドしてデプロイします。Google Cloud CLI コマンドの結果には、関数の完全修飾名などの関数に関する情報が含まれます。
name: projects/PROJECT_ID/locations/REGION/functions/FUNCTION_NAME関数のデプロイについては、Cloud Run functions をデプロイするをご覧ください。
Google Cloud プロジェクト内の Cloud Run functions を一覧表示するには、
gcloud functions listコマンドを使用します。gcloud functions listこの呼び出しのレスポンスはリストエントリです。各エントリには Cloud Run functions が一覧表示されます。
NAME: function-1 STATE: ACTIVE TRIGGER: HTTP Trigger REGION: us-west2 ENVIRONMENT: 2nd gen特定の Cloud Run functions の完全修飾名を確認するには、
gcloud monitoring uptime describeコマンドを実行します。 合成モニターを作成する手順は次のとおりです。
- [
projects.uptimeCheckConfigs.create] をクリックして、メソッドの API リファレンス ページを開きます。 - [試す] をクリックして API Explorer を開きます。
次のフィールドを設定して、コマンドを実行します。
- 親フィールド:
projects/PROJECT_ID。 リクエスト本文には、次のように指定します。
displayName: 合成モニターの表示名に設定します。syntheticMonitor: Cloud Run functions の完全修飾名に設定します。
成功すると、API 呼び出しのレスポンスは次のようになります。
{ "name": "projects/myproject/uptimeCheckConfigs/17272586127463315332", "displayName": "MyMonitor", ... "syntheticMonitor": { "cloudFunctionV2": { "name": "projects/myproject/locations/us-west2/functions/function-1", "cloudRunRevision": { "type": "cloud_run_revision", "labels": { "project_id": "myproject", "configuration_name": "", "location": "us-west2", "revision_name": "", "service_name": "function-1" } } } } }- 親フィールド:
- [
アラート ポリシーを作成します。
アラート ポリシーの構成の複雑さのため、Google Cloud コンソールで [合成モニター] ページに移動し、オプションを使用してアラート ポリシーを作成することをおすすめします。このアプローチでは、ほとんどのアラート ポリシー フィールドに値が自動入力されます。Google Cloud コンソールを使用してアラート ポリシーを作成するには、合成モニター ページで ポリシーを作成するをクリックします。
Google Cloud CLI または Cloud Monitoring API を使用する場合は、次のように条件のフィルタを構成します。
"filter": "resource.type = \"cloud_run_revision\" AND metric.type = \"monitoring.googleapis.com/uptime_check/check_passed\" AND metric.labels.check_id = \"CHECK_ID\"",条件は、合成モニターによって書き込まれた
uptime_check/check_passed時系列をモニタリングします。CHECK_ID は、合成モニターの識別子に置き換えるようにしてください。これは create コマンドのレスポンス データに含まれます。アラート ポリシーの作成方法については、API を使用してアラート ポリシーを作成するをご覧ください。
Terraform
Terraform 構成を適用または削除する方法については、基本的な Terraform コマンドをご覧ください。 詳細については、Terraform プロバイダのリファレンス ドキュメントをご覧ください。
合成モニターと、そのチェックをモニタリングするアラート ポリシーを作成するには、次の手順を行います。
必要な API が有効になっていること、プロジェクトにデフォルトの Compute Engine サービス アカウントが含まれていること、このアカウントに編集者（
roles/editor）のロールが付与されていることを確認します。詳細については、始める前にをご覧ください。Terraform 構成ファイルを編集して
google_storage_bucketリソースを追加し、変更を適用します。次のコードは、
USロケーションに Cloud Storage バケットを定義します。resource "google_storage_bucket" "gcf_source" { name = "gcf-v2-source-9948673986912-us" location = "US" uniform_bucket_level_access = true }Terraform 構成ファイルを編集して
google_storage_bucket_objectリソースを追加し、変更を適用します。このリソースでは、バケット内のオブジェクトの名前と、ローカル システム上の zip ファイルのロケーションを指定します。たとえば、次のコードを適用すると、
example-function.zipという名前のファイルがストレージ バケットに追加されます。resource "google_storage_bucket_object" "object" { name = "example-function.zip" bucket = google_storage_bucket.gcf_source.name source = "generic-synthetic-node.js.zip" }Terraform 構成ファイルを編集して
google_cloudfunctions2_functionリソースを追加し、変更を適用します。google_cloudfunctions2_functionリソースで、Node.js ランタイムと合成モニターで使用されるエントリ ポイントを指定していることを確認します。たとえば、次のコードを適用すると、sm-central1という名前の関数がデプロイされます。resource "google_cloudfunctions2_function" "central1" { name = "sm-central1" location = "us-central1" build_config { runtime = "nodejs20" entry_point = "SyntheticFunction" source { storage_source { bucket = google_storage_bucket.gcf_source.name object = google_storage_bucket_object.object.name } } } service_config { max_instance_count = 1 available_memory = "256Mi" timeout_seconds = 60 } }合成モニターを作成するには、Terraform 構成ファイルを編集して
google_monitoring_uptime_check_configリソースを追加し、変更を適用します。このリソースには、
synthetic_monitorブロックを指定します。resource "google_monitoring_uptime_check_config" "synthetic" { display_name = "sm-central1" timeout = "30s" synthetic_monitor { cloud_function_v2 { name = google_cloudfunctions2_function.central1.id } } }省略可: 通知チャンネルとアラート ポリシーを作成します。
次の手順では、Google Cloud コンソールを使用して通知チャンネルとアラート ポリシーを作成します。このアプローチにより、アラート ポリシーは合成モニターによって生成されたデータのみをモニタリングします。
通知チャネルを作成する方法は、次のとおりです。
-
Google Cloud コンソールで、notifications [アラート] ページに移動します。
検索バーを使用してこのページを検索する場合は、小見出しが [Monitoring] である結果を選択します。
- [通知チャンネルを管理] を選択します。
- 追加するチャネルの種類に移動し、[追加] をクリックして、ダイアログを完了します。
-
アラート ポリシーを作成するには:
-
Google Cloud コンソールで、
[合成モニタリング] ページに移動します。検索バーを使用してこのページを検索する場合は、小見出しが [Monitoring] である結果を選択します。
- 合成モニターを見つけて、more_vert [その他] を選択し、[アラート ポリシーを追加] を選択します。
- ダイアログで [通知と名前] セクションに移動し、[通知チャンネル] を展開して選択します。
- アラート ポリシーに名前を付けて、[ポリシーを作成] をクリックします。
-
料金
一般に、Cloud Monitoring システムの指標は無料であり、外部システム、エージェント、またはアプリケーションの指標はそうではありません。課金対象の指標は、取り込まれたバイト数とサンプル数のいずれかによって課金されます。
Cloud Monitoring の料金の詳細については、次のドキュメントをご覧ください。
合成モニターのトラブルシューティング
このセクションでは、合成モニターのトラブルシューティングに役立てるために使用できる情報を提供します。
API を有効にした後のエラー メッセージ
合成モニターの作成フローを開くと、少なくとも 1 つの API を有効にするように促されます。API を有効にすると、次のようなメッセージが表示されます。
An error occurred during fetching available regions: Cloud Functions API has not been used in project PROJECT_ID before or it is disabled.
エラー メッセージでは、API が有効であることを確認することを推奨してから、待機して再試行することを助言します。
API が有効になっていることを確認するには、プロジェクトの [API とサービス] ページに移動します。
API が有効になっていることを確認したら、作成フローを続行できます。条件は、API 有効化がバックエンドを通じて伝播されると自動的に解決されます。
送信 HTTP リクエストがトレースされない
出力 HTTP リクエストのトレースデータを収集するように合成モニターを構成します。次のスクリーンショットと同様に、トレースデータにはスパンが 1 つだけ表示されます。
この状況を解決するには、サービス アカウントに Cloud Trace エージェント（roles/cloudtrace.agent）のロールが付与されていることを確認します。編集者（roles/editor）のロールでも十分です。
サービス アカウントに付与されているロールを表示する方法は次のとおりです。
-
Google Cloud コンソールの [IAM] ページに移動します。
検索バーを使用してこのページを検索する場合は、小見出しが [IAM と管理者] である結果を選択します。
- [Google 提供のロール付与を含む] を選択します。
合成モニターで使用されるサービス アカウントがリストに表示されていない場合、または Cloud Trace エージェント（
roles/cloudtrace.agent）のロールの権限を含むロールが付与されていない場合、このロールをサービス アカウントに付与します。サービス アカウントの名前がわからない場合は、ナビゲーション メニューで [サービス アカウント] を選択します。
進行中のステータス
[合成モニター] ページには、ステータスが In progress の合成モニターが一覧表示されます。ステータスが In progress であることは、合成モニターが最近作成され、表示するデータがない、または関数のデプロイに失敗したことを意味します。
関数のデプロイに失敗したかどうかを判断するには、次のようにします。
Cloud Run 関数の名前にアンダースコアが含まれていないことを確認してください。アンダースコアが存在する場合は、アンダースコアを削除して Cloud Run 関数を再デプロイします。
合成モニターの [合成モニターの詳細] ページを開きます。
次のメッセージが表示された場合は、合成モニターを削除します。
Cloud Function not found for this Synthetic monitor. Please confirm it exists or delete this monitor.
エラー メッセージは、関数が削除されて、そのために合成モニターで関数を実行できないことを示しています。
関数の [Cloud Run 関数] ページを開きます。[合成モニターの詳細] ページからこのページを開くには、[コード]、[関数名] の順にクリックします。
次のようなメッセージが表示された場合は、関数のデプロイに失敗しました。
This function has failed to deploy and will not work correctly. Please edit and redeploy
この問題を解決するには、関数コードを確認して、関数の構築またはデプロイを妨げるエラーを修正します。
合成モニターを作成すると、関数のデプロイと実行に数分かかる場合があります。
警告ステータス
[合成モニター] には、ステータスが Warning の合成モニターが一覧表示されます。ステータスが Warning の場合、実行結果には整合性がないことを意味します。これは、テストの設計上の問題を示している、またはテスト対象に不整合な動作があることを示している場合があります。
失敗ステータス
[合成モニター] には、ステータスが Failing の合成モニターが一覧表示されます。失敗の理由について詳しくは、最新の実行履歴を表示します。
エラー メッセージ
Request failed with status code 429が表示されている場合、HTTP リクエストのターゲットがコマンドを拒否しました。このエラーを解決するには、合成モニターのターゲットを変更する必要があります。エンドポイント
https://www.google.comは、合成モニターによって行われたリクエストを拒否します。失敗で実行時間
0msが返された場合は、Cloud Run functions のメモリ不足が原因である可能性があります。このエラーを解決するには、Cloud Run 関数を編集してから、メモリを 2 GiB 以上に増やし、CPU フィールドを1に設定します。
合成モニターで削除が失敗する
Cloud Monitoring API を使用して合成モニターを削除しようとすると、API 呼び出しが失敗し、次のようなレスポンスが返されます。
{
"error": {
"code": 400,
"message": "Request contains an invalid argument.",
"status": "INVALID_ARGUMENT",
"details": [
{
"@type": "type.googleapis.com/google.rpc.DebugInfo",
"detail": "[ORIGINAL ERROR] generic::invalid_argument: Cannot delete check 1228258045726183344. One or more alerting policies is using it.Delete the alerting policy with id projects/myproject/alertPolicies/16594654141392976482 and any other policies using this uptime check and try again."
}
]
}
}
問題を解決するには、合成モニターの結果をモニタリングするアラート ポリシーを削除してから、合成モニターを削除します。