このドキュメントでは、サービス、アプリケーション、ウェブページ、API の可用性、整合性、パフォーマンスをテストするための合成モニターを作成する方法について説明します。アプリケーションのテストを行います。合成モニターがそのスクリプトを実行し、テスト結果と追加データ（レイテンシなど）を記録します。テストに失敗したときに通知されるには、テスト結果をモニタリングするアラート ポリシーを構成します。
合成モニターについて
合成モニターは、Cloud Run にデプロイされた単一目的の第 2 世代の Cloud Functions を定期的に実行します。合成モニターの作成時に、Node.js で記述する必要がある Cloud Functions と実行頻度を定義します。たとえば、Puppeteer を使用して、ウェブページとやり取りするように Cloud Function を構成できます。また、Axios モジュールを使用して API とやり取りするように Cloud Function を構成することもできます。VPC ネットワーク内のリソースをテストすることもできます。
Cloud Function を作成するには、インライン エディタを使用するか、zip ファイルをアップロードします。インライン エディタを使用する場合は、指定したスケルトンを使って開始できます。合成モニターを作成すると、Cloud Monitoring は、Cloud Function の定期的な実行をスケジューリングするスケジューリング システムを使用します。Cloud Function が存在するリージョンを指定する間、実行をトリガーするコマンドは、稼働時間チェック サーバーでサポートされている任意のリージョンで指定できます。詳細については、稼働時間チェック サーバーの IP アドレスを一覧表示するをご覧ください。
テストポリシーが失敗したときに通知を受け取るには、アラート ポリシーを作成できます。
Google Cloud コンソールを使用して合成モニターを作成する場合、デフォルトの動作ではアラート ポリシーが作成されます。通知チャネルを指定します。デフォルトのアラート ポリシーは、2 つ以上の連続したテストの失敗について通知するように構成されています。
Cloud Monitoring API を使用して合成モニターを作成する場合は、アラート ポリシーを作成して、Cloud Functions が実行される Cloud Run リソースの
uptime_check/check_passed指標タイプをモニタリングする必要があります。
実行頻度に関する考慮事項
Cloud Function を実行する頻度を構成します。実行頻度を決めるには、サービスのサービスレベル目標（SLO）を検討してください。潜在的な SLO 違反を捕捉するには、テストを頻繁に実行する必要があります。ただし、考慮されるのはサービスの SLO だけではありません。また、実行速度がサービスの負荷にどのように関係し、コストに影響するかも考慮する必要があります。実行ごとにサービスの負荷がかかるため、Cloud Function を実行する頻度が高いほどサービスに適用される負荷が増加します。参考として、稼働時間チェックのデフォルトの実行間隔は 1 分です。
実行頻度によって、テストに失敗したときに通知される速度も決まります。Monitoring によってインシデントが開かれ、2 回連続のテストの失敗後に通知が送信されます。たとえば、実行頻度が 5 分の場合、2 回のテスト失敗までに 10 分かかることがあります。2 回目のテストの失敗後に通知されます。
Cloud Functions のサンプルコード
テンプレートとサンプルについては、合成モニターのサンプルをご覧ください。これらのサンプルを Cloud Functions の開始点として使用できます。 経験豊富なデベロッパーの場合は、Gemini を使用して合成モニターのコードを生成し、開発時間を短縮することを検討してください。Gemini を使用したコードの生成は、公開プレビュー版です。
Google Cloud コンソールを使用して合成モニターを作成するときに選択できる汎用テンプレートは、送信 HTTP リクエストのトレースデータとログデータを収集するように構成されます。このソリューションでは、OpenTelemetryauto-instrumentation-node モジュールと winston ロガーを利用します。オープンソース プロダクトに依存するため、トレースデータとログデータの構造は変化するはずです。したがって、収集したトレースとログデータはデバッグの目的でのみ使用する必要があります。
送信 HTTP リクエストのトレースデータとログデータを収集するために、独自のアプローチを実装できます。カスタム アプローチの例については、クラス SyntheticAutoInstrumentation をご覧ください。
Cloud Functions の構成
Cloud Functions を構成する場合は、ランタイム、ビルド、接続、セキュリティの設定を指定するか、デフォルト設定をそのまま使用します。
割り当てられたメモリのデフォルト値では不十分な場合があります。このフィールドは、2 GiB 以上に設定することをおすすめします。
Cloud Functions の受信データ転送設定のデフォルト値は、すべてのトラフィックを許可することです。この設定を使用することも、より制限された設定を使用することもできます。
すべてのトラフィックを許可すると、Cloud Functions で実行される検証の最初のフェーズがネットワーク レベルで行われ、常に合格します。検証の 2 番目のフェーズでは、呼び出し元に Cloud Functions の実行権限が付与されているかどうかを確認します。認可は、呼び出し元の Identity and Access Management（IAM）ロールによって異なります。デフォルトでは、Cloud Monitoring には Cloud Function を実行する権限が付与されています。受信データ移転設定を表示または変更する方法については、上り（内向き）設定をご覧ください。
Cloud Functions に関する制限
Cloud Function の名前にアンダースコアを含めることはできません。
送信 HTTP リクエストのトレースデータとログデータを収集できるのは、汎用テンプレートを使用する場合のみです。
HTTP 関数のみがサポートされています。Google Cloud コンソールを使用して合成モニターを作成すると、URL をクエリするデフォルト関数が提供されます。デフォルト関数のソースは変更可能で、
generic-synthetic-nodejsGit リポジトリで入手できます。HTTP 関数の詳細については、HTTP 関数を作成するをご覧ください。
API を使用する場合、デプロイ コマンドでは Cloud Function が第 2 世代であることを指定する必要があります。Google Cloud コンソールを使用する場合、デプロイは自動的に処理されます。詳細については、Cloud Function をデプロイするをご覧ください。
ランタイム環境は Node.js に制限されています。詳細については、ノードをご覧ください。以下のバージョンの Node.js がサポートされています。12、14、16、18、20。
合成モニターによって収集されるデータ
このセクションでは、合成モニター用に収集されるデータについて説明します。実行結果を表示する方法については、合成モニターの結果を探索するをご覧ください。
実行履歴
合成モニターごとに、実行結果の履歴が収集されます。このデータには以下が含まれます。
時間とともに実行の成功または失敗を記録する時系列。
コードの実行時間を記録する時系列。関数の実行時間は記録されません。レイテンシ データは、Cloud Functions が実行されている Cloud Run リソースの
uptime_check/request_latency時系列として書き込まれます。このデータのグラフは、合成モニターの詳細ページに表示されます。テストや失敗の詳細など、合成モニターの実行に関する情報を含むログ。使用可能なログは、Cloud Functions によって異なります。たとえば、Mocha テンプレートを使用する場合、ログにはテストが成功したか失敗したかに関する情報とテスト期間が含まれます。スタック トレースには（含まれる場合）、失敗したコード行、エラータイプ、エラー メッセージが一覧表示されます。
必要に応じて、送信 HTTP リクエストのトレースとログ。このデータの収集方法については、リクエストのレイテンシをご覧ください。
Cloud Functions の指標とログ
Cloud Functions の指標とログ。Cloud Functions によって収集されるこのデータには、1 秒あたりの実行数、実行時間、関数のメモリ使用率に関する情報が含まれています。
リクエストのレイテンシ
合成モニターによる HTTP リクエストのレイテンシ データは Cloud Trace によって自動的に収集され、保存されます。
合成モニターによる送信 HTTP リクエストのトレース、ログ、レイテンシを収集するには、汎用テンプレートを使用する必要があります。詳しくは、合成モニターのサンプルをご覧ください。
準備
-
Google Cloud コンソールを使用して合成モニターを表示して変更するために必要な権限を取得するには、プロジェクトに対する次の IAM ロールを付与するように管理者に依頼してください。
-
モニタリング編集者（
roles/monitoring.editor） -
Cloud Functions デベロッパー（
roles/cloudfunctions.developer）
ロールの付与の詳細については、アクセスの管理をご覧ください。
-
モニタリング編集者（
-
Cloud Monitoring API、Artifact Registry API、Cloud Build API、Cloud Functions API、Cloud Logging API、Pub/Sub API、Cloud Run Admin API API を有効にします。
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 によって通知チャネルを作成して管理するをご覧ください。
合成モニターを作成する
コンソール
Google Cloud コンソールを使用して合成モニターを作成すると、新しい Cloud Function（第 2 世代）がデプロイされ、その Cloud Function のモニターが作成されます。既存の Cloud Function をモニタリングする合成モニターは作成できません。
- 必要な API が有効になっていること、プロジェクトにデフォルトの Compute Engine サービス アカウントが含まれていること、このアカウントに編集者（
roles/editor）のロールが付与されていることを確認します。詳細については、始める前にをご覧ください。 -
Google Cloud コンソールで、
[合成モニタリング] ページに移動します。
検索バーを使用してこのページを検索する場合は、小見出しが [Monitoring] である結果を選択します。
- [合成モニターを作成] を選択します。
Cloud Functions のテンプレートを選択します。
カスタム合成モニター: 送信 HTTP リクエストのログデータまたはトレースデータを収集する場合は、このテンプレートを使用します。
Mocha 合成モニター: Mocha テストスイートを作成するときにこのテンプレートを使用します。
無効なリンクのチェッカー: このテンプレートを使用して、その URI で見つかった URI と構成可能な数のリンクをテストします。このチェッカーのフィールドの詳細については、無効なリンクのチェッカーを作成するをご覧ください。
モニターの名前を入力します。
省略可: [レスポンスのタイムアウト] と [チェック頻度] を更新し、ユーザー定義のラベルを追加します。
次のいずれかを行います。
このプロジェクトの Gemini Code Assist へのアクセス権があり、コード作成のサポートが必要な場合は、[コーディングをサポート] をクリックします。この機能は公開プレビュー版です。 プロンプトのガイダンスについては、合成モニターのプロンプトの作成方法を学習するをご覧ください。
コードに問題がなければ、[Cloud Function に挿入] をクリックします。
[ファンクションを作成] をクリックします。
[Cloud Function] ダイアログで、次の操作を行います。
表示名を入力し、リージョンを選択します。名前はリージョン内で一意である必要があります。
[ランタイム、ビルド、接続、セキュリティの設定] セクションで、次の操作を行います。
デフォルトの設定を確認し、必要に応じて更新します。
[ランタイム サービス アカウント] フィールドで、サービス アカウントを選択します。
生成されたコードを編集するか、Cloud Functions の関数のコードを記述またはアップロードします。
生成されたコードを編集するか、独自のコードを入力するか、デフォルトのサンプル関数を読み込むには、[インライン エディタ] を選択します。前に選択したテンプレートに依存するサンプル関数は、特定の URL にリクエストを送信します。デフォルト関数を変更できます。
ローカル システムから zip ファイルを読み込むには、[ZIP アップロード] を選択します。
ローカル システムから zip ファイルをアップロードする場合は、zip ファイル用の Cloud Storage バケットも指定する必要があります。適切な Cloud Storage バケットがない場合は、1 つ作成します。
- Cloud Storage から ZIP ファイルを読み込むには、[Cloud Storage の ZIP] を選択し、ストレージ バケットを選択して、読み込む ZIP ファイルを選択します。
Google Cloud コンソールの Cloud Functions ページを使用して、Cloud Function を作成することもできます。その Cloud Function のコピーをモニタリングする合成モニターを作成するには、[ソース] タブに移動して [zip をダウンロードする] をクリックします。その後、zip ファイルをアップロードできます。
[関数を適用する] をクリックします。
アラート ポリシーを構成します。
省略可: アラート ポリシー名と、通知が送信されるまでの障害継続期間を更新します。
通知チャンネルを追加します。
[作成] をクリックします。
定義した Cloud Function が第 2 世代としてビルドされ、デプロイされ、合成モニターが作成されます。
gcloud
Google Cloud CLI または Cloud Monitoring API を使用して合成モニターを作成する場合は、関数名を API 呼び出しに渡します。したがって、既存の Cloud Function をモニタリングする合成モニターのみを作成できます。
- 必要な API が有効になっていること、プロジェクトにデフォルトの Compute Engine サービス アカウントが含まれていること、このアカウントに編集者（
roles/editor）のロールが付与されていることを確認します。詳細については、始める前にをご覧ください。 - 第 2 世代の Cloud Function を書き込み、デプロイします。
たとえば、
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 Function をデプロイします。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 Functions は Cloud Function をビルドしてデプロイします。Google Cloud CLI コマンドの結果には、関数の完全修飾名などの関数に関する情報が含まれます。
name: projects/PROJECT_ID/locations/REGION/functions/FUNCTION_NAME関数のデプロイについては、Cloud Function をデプロイするをご覧ください。
Google Cloud プロジェクト内の Cloud Functions を一覧表示するには、
gcloud functions listコマンドを使用します。gcloud functions listこの呼び出しのレスポンスはリストエントリです。各エントリには Cloud Function が一覧表示されます。
NAME: function-1 STATE: ACTIVE TRIGGER: HTTP Trigger REGION: us-west2 ENVIRONMENT: 2nd gen特定の Cloud Functions の関数の完全修飾名を確認するには、
gcloud monitoring uptime describeコマンドを実行します。 合成モニターを作成するには、
gcloud monitoring uptime createコマンドを実行します。gcloud monitoring uptime create DISPLAY_NAME --synthetic-target=TARGET前述のコマンドを実行する前に、次のようにしてください。
- DISPLAY_NAME は、合成モニターの名前に置き換えます。
- TARGET は、Cloud 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 は、合成モニターの ID に置き換えてください。この ID は、create コマンドのレスポンス データに含まれています。アラート ポリシーを作成する方法については、API を使用してアラート ポリシーを作成するをご覧ください。
API
Google Cloud CLI または Cloud Monitoring API を使用して合成モニターを作成する場合は、関数名を API 呼び出しに渡します。したがって、既存の Cloud Function をモニタリングする合成モニターのみを作成できます。
- 必要な API が有効になっていること、プロジェクトにデフォルトの Compute Engine サービス アカウントが含まれていること、このアカウントに編集者（
roles/editor）のロールが付与されていることを確認します。詳細については、始める前にをご覧ください。 - 第 2 世代の Cloud Function を書き込み、デプロイします。
たとえば、
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 Function をデプロイします。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 Functions は Cloud Function をビルドしてデプロイします。Google Cloud CLI コマンドの結果には、関数の完全修飾名などの関数に関する情報が含まれます。
name: projects/PROJECT_ID/locations/REGION/functions/FUNCTION_NAME関数のデプロイについては、Cloud Function をデプロイするをご覧ください。
Google Cloud プロジェクト内の Cloud Functions を一覧表示するには、
gcloud functions listコマンドを使用します。gcloud functions listこの呼び出しのレスポンスはリストエントリです。各エントリには Cloud Function が一覧表示されます。
NAME: function-1 STATE: ACTIVE TRIGGER: HTTP Trigger REGION: us-west2 ENVIRONMENT: 2nd gen特定の Cloud Functions の関数の完全修飾名を確認するには、
gcloud monitoring uptime describeコマンドを実行します。 合成モニターを作成する手順は次のとおりです。
- [
projects.uptimeCheckConfigs.create] をクリックして、メソッドの API リファレンス ページを開きます。 - [Try it] をクリックして API Explorer を開きます。
次のフィールドを設定して、コマンドを実行します。
- 親フィールド:
projects/PROJECT_ID。 リクエスト本文には、次のように指定します。
displayName: 合成モニターの表示名に設定します。syntheticMonitor: Cloud 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 は、合成モニターの ID に置き換えてください。この 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 Function の名前にアンダースコアが含まれていないことを確認してください。アンダースコアが存在する場合は、アンダースコアを削除して Cloud Function を再デプロイします。
合成モニターの [合成モニターの詳細] ページを開きます。
次のメッセージが表示されたら、合成モニターを削除します。
Cloud Function not found for this Synthetic monitor. Please confirm it exists or delete this monitor.
エラー メッセージは、関数が削除されて、そのために合成モニターで関数を実行できないことを示しています。
関数の Cloud Functions ページを開きます。[合成モニターの詳細] ページからこのページを開くには、[コード] をクリックしてから、関数名をクリックします。
次のようなメッセージが表示された場合は、関数のデプロイに失敗しました。
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 Functions の関数がメモリ不足になっている可能性があります。このエラーを解決するには、Cloud Functions の関数を編集してから、メモリを 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."
}
]
}
}
問題を解決するには、合成モニターの結果をモニタリングするアラート ポリシーを削除してから、合成モニターを削除します。