合成モニターと稼働時間チェックのトラブルシューティング

このドキュメントでは、ログデータを検索する方法と、合成モニターと稼働時間チェックのエラーをトラブルシューティングする方法について説明します。

ログの検索
通知のトラブルシューティング
公開稼働時間チェックのトラブルシューティング
非公開稼働時間チェックのトラブルシューティング
合成モニターのトラブルシューティング

ログの検索

このセクションでは、合成モニターと稼働時間チェックのログを検索する方法について説明します。

Google Cloud コンソールで、[ログエクスプローラ] ページに移動します。
[ログエクスプローラ] に移動

このページを検索バーで検索する場合は、小見出しが「Logging」の結果を選択します。
Google Cloud コンソールのツールバーで、 Google Cloud プロジェクトを選択します。App Hub 構成の場合は、App Hub ホストプロジェクトまたはアプリ管理用フォルダの管理プロジェクトを選択します。
以下のいずれかの操作を行います。
- 合成モニターまたは稼働時間チェックに関連付けられているすべてのログを検索するには、リソースタイプでクエリを実行します。[リソース] メニューを使用するか、クエリを入力します。
  
  稼働時間チェックの場合、[リソース] メニューから [稼働時間チェック URL] を選択するか、クエリエディタに次のクエリを入力して、[クエリを実行] をクリックします。
```
resource.type="uptime_url"
```
  合成モニターの場合、[リソース] メニューから [Cloud Run のリビジョン] を選択するか、クエリエディタに次のクエリを入力して、[クエリを実行] をクリックします。
```
resource.type="cloud_run_revision"
```
- 合成モニターまたは稼働時間チェックの実行中に受信したレスポンスに関する情報を含むログを検索するには、次のいずれかを行います。
  - 合成モニターまたは稼働時間チェックの ID を使用してクエリを実行するには、クエリエディタに ID を入力する際に次の形式を使用し、[クエリを実行] をクリックします。
```
labels.check_id="my-check-id"
```
  - 合成モニターと稼働時間チェックによって発行されたリクエストのレスポンスデータを含むログをクエリするには、クエリエディタに次のクエリを入力して、[クエリを実行] をクリックします。
```
"UptimeCheckResult"
```
    上記のクエリは、文字列 "UptimeCheckResult" を含むすべてのログエントリと一致します。
  これらのログには次のものが含まれます。
  - 合成モニターまたは稼働時間チェックの ID。labels.check_id フィールドに格納されます。
  - 合成モニターの場合は、Cloud Run functions の関数の名前。resource.labels.service_name フィールドに格納されます。
  - トレースデータが収集される場合は、関連するトレースの ID。trace フィールドに格納されます。
- サービスが Google Cloud サーバーからリクエストを受信したことを確認するには、次のクエリをクエリエディタにコピーし、[クエリを実行] をクリックします。
```
"GoogleStackdriverMonitoring-UptimeChecks"
```
  protoPayload.ip フィールドには、稼働時間チェックサーバーによって使用されるアドレスの 1 つが格納されます。すべての IP アドレスを一覧表示する方法については、IP アドレスを一覧表示するをご覧ください。

通知のトラブルシューティング

このセクションでは、アラートポリシーの構成時に発生する可能性のあるエラーとその解決方法について説明します。

1 つのチェッカーが失敗したが、他のチェッカーは失敗しなかった

稼働時間チェックの指標を確認していたところ、他のすべてのチェッカーが成功を報告しているにもかかわらず、1 つのチェッカーが失敗を報告していることに気づきました。

この状況を解決するために必要な操作はありません。

1 つのチェッカーのみが失敗を報告した場合、その失敗は、ネットワークの問題によりチェッカーのコマンドがタイムアウトしたために発生した可能性があります。つまり、コマンドが失敗したのではなく、指定されたタイムアウト内にコマンドが完了しなかったということです。

デフォルト構成を使用するアラートポリシーでは、インシデントを作成して通知を送信する前に、少なくとも 2 つのチェッカーで失敗が発生する必要があります。1 つのチェッカーによって報告された失敗は通知されません。

通知を受信したため、障害をデバッグしたい

障害がいつ始まったのかを特定するには、次のいずれかを行います。
- 稼働時間チェックで障害がいつ発生したのかを確認するには、[稼働時間の詳細] ページを表示します。
  1. Google Cloud コンソールで、[ 稼働時間チェック] ページに移動します。
    稼働時間チェックに移動する
    
    このページを検索バーで検索する場合は、小見出しが「Monitoring」の結果を選択します。
  2. Google Cloud コンソールのツールバーで、 Google Cloud プロジェクトを選択します。App Hub 構成の場合は、App Hub ホストプロジェクトまたはアプリ管理用フォルダの管理プロジェクトを選択します。
  3. 稼働時間チェックを見つけて選択します。
    
    [合格したチェック] グラフにはチェックの履歴が表示されます。稼働時間チェックが最初に失敗した日時を特定するには、グラフの期間の変更が必要になる場合があります。期間セレクタは、[稼働時間の詳細] ページのツールバー内にあります。
- 合成モニターで障害がいつ発生したのかを確認するには、[稼働時間の詳細] ページを表示します。
  1. Google Cloud コンソールで、[ 合成モニタリング] ページに移動します。
    [合成モニタリング] に移動
    
    このページを検索バーで検索する場合は、小見出しが「Monitoring」の結果を選択します。
  2. Google Cloud コンソールのツールバーで、 Google Cloud プロジェクトを選択します。App Hub 構成の場合は、App Hub ホストプロジェクトまたはアプリ管理用フォルダの管理プロジェクトを選択します。
  3. 合成モニターを見つけて選択します。
関連するログデータを検索する方法については、このページのログの検索セクションをご覧ください。

稼働時間チェックの失敗が通知されない

構成した稼働時間チェックの [稼働時間の詳細] ページを確認したところ、[合格したチェック] グラフに、少なくとも 1 つのチェッカーの失敗が示されていることに気づきました。しかし、通知は届いていません。

デフォルトでは、少なくとも 2 つのリージョンのチェッカーが稼働時間チェックへのレスポンスを受信できなかったときに、インシデントを作成して通知を送信するようにアラートポリシーが構成されています。これらの障害は同時に発生する必要があります。

単一のリージョンがレスポンスを受信できなかったときに通知を受け取るようにアラートポリシーの条件を編集できます。ただし、デフォルトの構成を使用することをおすすめします。そうすることで、一時的な障害が原因で受信する可能性のある通知の数を減らすことができます。

アラートポリシーを表示または編集する手順は次のとおりです。

Google Cloud コンソールで、[ アラート] ページに移動します。
[アラート] に移動

このページを検索バーで検索する場合は、小見出しが「Monitoring」の結果を選択します。
Google Cloud コンソールのツールバーで、 Google Cloud プロジェクトを選択します。App Hub 構成の場合は、App Hub ホストプロジェクトまたはアプリ管理用フォルダの管理プロジェクトを選択します。
[ポリシー] ペインで [すべてのポリシーを表示] をクリックします。
表示または編集するポリシーを見つけて、ポリシーの名前をクリックします。

ポリシーの表示と編集は、[ポリシーの詳細] ページで行えます。

公開稼働時間チェックのトラブルシューティング

このセクションでは、公開稼働時間チェックの使用時に発生する可能性のあるエラーとその解決方法について説明します。

公開稼働時間チェックが失敗している

公開稼働時間チェックを構成しましたが、検証ステップを実行するとエラーが発生します。

以下に、稼働時間チェックが失敗する原因の一部を示します。

Connection Error - Refused: デフォルトの HTTP 接続タイプを使用している場合、HTTP リクエストに応答しているウェブサーバーがインストールされていることを確認します。新しいインスタンスにウェブサーバーがインストールされていない場合、接続エラーが発生することがあります。Compute Engine のクイックスタートをご覧ください。HTTPS 接続タイプを使用する場合は、追加の構成手順を実行しなければならないことがあります。ファイアウォールの問題については、稼働時間チェックサーバーの IP アドレスを一覧表示するをご覧ください。
Name or service not found: ホスト名が正しくない可能性があります。
403 Forbidden: サービスが稼働時間チェッカーにエラーコードを返しています。たとえば、Apache ウェブサーバーのデフォルト構成は、Amazon Linux ではこのコードを返しますが、他のいくつかの Linux バージョンではコード 200 (Success) を返します。Amazon Linux の LAMP チュートリアルまたはご使用のウェブサーバーのドキュメントをご覧ください。
404 Not found: パスが正しくない可能性があります。
408 Request timeout、またはレスポンスなし: ポート番号が正しくないか、サービスが稼働していない可能性があります。また、サービスがアクセスできない状態になっているか、タイムアウト値が小さすぎる可能性もあります。ファイアウォールが稼働時間サーバーからのトラフィックを許可していることを確認してください。詳しくは稼働時間チェックサーバーの IP アドレスを一覧表示するをご覧ください。タイムアウトの上限は、[レスポンスの検証] オプションの一部として指定されます。

失敗したパブリック稼働時間チェックをトラブルシューティングするには、稼働時間チェック中に最大 3 つの ICMP ping を送信するように稼働時間チェックを構成できます。ping を使用すると、ネットワーク接続の問題やアプリケーションのタイムアウトなど、さまざまな原因による障害を区別できます。詳細については、ICMP ping を使用するをご覧ください。

非公開稼働時間チェックのトラブルシューティング

このセクションでは、プライベート稼働時間チェックの使用時に発生する可能性のあるエラーとその解決方法について説明します。

稼働時間チェックの作成に失敗する

Google Cloud プロジェクトの設定により、稼働時間チェックが Service Directory サービスとのやり取りを管理する際に使用するサービスアカウントのロールを変更できなくなる場合があります。この場合、稼働時間チェックの作成は失敗します。

このセクションでは、サービスアカウントに必要なロールを付与する方法について説明します。

Google Cloud コンソール

Google Cloud コンソールを使用してプライベート稼働時間チェックを作成すると、 Google Cloud コンソールは Service Directory ロールをサービスアカウントに付与するコマンドを実行します。

サービスアカウントにロールを付与する方法については、サービスアカウントを認可するをご覧ください。

API: スコーピングプロジェクト

1 つの Google Cloud プロジェクトで、Service Directory サービスとプライベートリソースのプライベート稼働時間チェックを初めて作成するときは、リクエストが成功することも失敗することもあります。この結果は、プロジェクトでサービスアカウントに対する自動的なロール付与を無効にしているかどうかによって変わります。

プロジェクトでサービスアカウントに対する自動的なロール付与が許可されている場合、最初の稼働時間チェックは正常に作成されます。サービスアカウントが作成され、必要なロールが付与されます。
プロジェクトでサービスアカウントに対する自動的なロール付与が許可されていない場合、最初の稼働時間チェックの作成は失敗します。サービスアカウントは作成されますが、ロールは付与されません。

稼働時間チェックの作成に失敗した場合は、次の操作を行います。

サービスアカウントを認可します。
権限が反映されるまで数分待ちます。
プライベート稼働時間チェックを再度作成してください。

API: モニタリング対象プロジェクト

モニタリング対象プロジェクトの Service Directory サービスまたは別の Google Cloud プロジェクトのプライベートリソースを対象とするプライベート稼働時間チェックを初めて作成するときに、リクエストが失敗し、Monitoring サービスアカウントが作成されます。

サービスアカウントを認可する方法は、使用しているGoogle Cloud プロジェクトの数とその関係によって異なります。最大 4 つのプロジェクトが関係する可能性があります。

プライベート稼働時間チェックを定義したプロジェクト。
Service Directory サービスを構成したモニタリング対象プロジェクト。
VPC ネットワークを構成したプロジェクト。
ネットワークリソース（VM やロードバランサなど）が構成されているプロジェクト。このプロジェクトには、ここで説明するサービスアカウントの認可でのロールがありません。

最初の稼働時間チェックの作成に失敗した場合は、次の操作を行います。

サービスアカウントを認可します。
権限が反映されるまで数分待ちます。
プライベート稼働時間チェックを再度作成してください。

アクセスが拒否された

VPC_ACCESS_DENIED という結果で稼働時間チェックが失敗しています。この結果は、ネットワーク構成やサービスアカウントの認可の一部が正しくないことを意味します。

稼働時間チェックの作成が失敗するの説明に沿って、スコーピングプロジェクトまたはモニタリング対象プロジェクトを使用するためのサービスアカウントの認可を確認します。

プライベートネットワークへのアクセスについての詳細は、ネットワークプロジェクトを構成するをご覧ください。

プライベート稼働時間チェックからの異常な結果

複数の VM を含む Service Directory サービスがあり、サービス構成には複数のエンドポイントが含まれます。いずれかの VM をシャットダウンしても、稼働時間チェックは成功を示します。

サービス構成に複数のエンドポイントがある場合は、ランダムに 1 つが選択されます。選択したエンドポイントに関連付けられた VM が実行されている場合、VM の 1 つが停止していても、稼働時間チェックは成功します。

デフォルトのヘッダー

稼働時間チェックからエラーまたは予期しない結果が返されます。これは、デフォルトのヘッダー値をオーバーライドした場合に発生することがあります。

プライベート稼働時間チェックのリクエストがターゲットエンドポイントに送信されると、リクエストには次のヘッダーと値が含まれます。

ヘッダー	値
`HTTP_USER_AGENT`	`GoogleStackdriverMonitoring-UptimeChecks(https://cloud.google.com/monitoring)`
`HTTP_CONNECTION`	`keep-alive`
`HTTP_HOST`	Service Directory エンドポイントの IP
`HTTP_ACCEPT_ENCODING`	`gzip`、`deflate`、`br`
`CONTENT_LENGTH`	稼働時間の投稿データから計算

これらの値をオーバーライドしようとすると、次のようになる可能性があります。

稼働時間チェックでエラーが報告される
オーバーライド値が破棄され、テーブル内の値で置き換えられる

データが表示されない

稼働時間チェックが Service Directory サービスとは異なる Google Cloud プロジェクトにある場合、稼働時間チェックのダッシュボードにデータは表示されません。

稼働時間チェックを含む Google Cloud プロジェクトが、Service Directory サービスを含む Google Cloud プロジェクトをモニタリングしていることを確認します。

モニタリング対象プロジェクトを一覧表示してプロジェクトを追加する方法については、複数のプロジェクトの指標スコープを構成するをご覧ください。

合成モニターのトラブルシューティング

このセクションでは、合成モニターのトラブルシューティングに役立つ情報を提供します。

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 が有効になっていることを確認したら、作成フローを続行できます。条件は、API が有効になったことがバックエンドを介して伝播されると自動的に解決されます。

アウトバウンド HTTP リクエストがトレースされない

出力の HTTP リクエストのトレースデータを収集するように合成モニターを構成します。次のスクリーンショットと同様に、トレースデータにはスパンが 1 つだけ表示されます。

1 つのトレースのみを表示する Cloud Trace。

この状況を解決するには、サービスアカウントに Cloud Trace エージェント（roles/cloudtrace.agent）ロールが付与されていることを確認します。編集者（roles/editor）ロールでも十分です。

サービスアカウントに付与されているロールを確認する方法は次のとおりです。

Google Cloud コンソールで [IAM] ページに移動します。
[IAM] に移動

このページを検索バーで検索する場合は、小見出しが「IAM と管理」の結果を選択します。
Google Cloud コンソールのツールバーで、 Google Cloud プロジェクトを選択します。App Hub 構成の場合は、App Hub ホストプロジェクトまたはアプリ管理用フォルダの管理プロジェクトを選択します。
[Google 提供のロール付与を含む] を選択します。
合成モニターで使用されるサービスアカウントがリストにない場合、または Cloud Trace エージェント（roles/cloudtrace.agent）ロールの権限を含むロールが付与されていない場合は、このロールをサービスアカウントに付与します。

サービスアカウントの名前がわからない場合は、ナビゲーションメニューで [サービスアカウント] を選択します。

進行中のステータス

[合成モニター] ページには、ステータスが In progress の合成モニターが一覧表示されます。ステータスが In progress であることは、合成モニターが最近作成され、表示するデータがないか、関数のデプロイに失敗したことを意味します。

関数のデプロイに失敗したかどうかを判断するには、次のようにします。

Cloud Run functions の関数の名前にアンダースコアが含まれていないことを確認してください。アンダースコアが含まれている場合は、アンダースコアを削除して Cloud Run functions の関数を再デプロイします。
合成モニターの [合成モニターの詳細] ページを開きます。

次のメッセージが表示された場合は、合成モニターを削除します。
```
Cloud Function not found for this Synthetic monitor. Please confirm it exists or delete this monitor.
```
このエラーメッセージは、関数が削除されているため、合成モニターで関数を実行できないことを示しています。
関数の Cloud Run 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 Run functions のメモリ不足が原因である可能性があります。このエラーを解決するには、Cloud Run 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."
      }
    ]
  }
}

問題を解決するには、合成モニターの結果をモニタリングするアラートポリシーを削除してから、合成モニターを削除します。

無効なリンクチェッカーの設定を編集できない

Google Cloud コンソールを使用して無効なリンクチェッカーを作成しました。テストする HTML 要素を変更するか、URI タイムアウト、再試行、セレクタの待機、リンクごとのオプションを変更することを考えています。しかし、無効なリンクチェッカーを編集しても、 Google Cloud コンソールに構成フィールドが表示されません。

この問題を解決するには、次の操作を行います。

Google Cloud コンソールで、[ 合成モニタリング] ページに移動します。
[合成モニタリング] に移動

このページを検索バーで検索する場合は、小見出しが「Monitoring」の結果を選択します。
Google Cloud コンソールのツールバーで、 Google Cloud プロジェクトを選択します。App Hub 構成の場合は、App Hub ホストプロジェクトまたはアプリ管理用フォルダの管理プロジェクトを選択します。
編集する合成モニターを見つけて、（その他のオプション）をクリックし、[編集] を選択します。
[関数を編集] をクリックします。
index.js ファイルの options オブジェクトを編集し、[関数を適用] をクリックします。

このオブジェクトのフィールドと構文については、broken-links-ok/index.js をご覧ください。
[保存] をクリックします。

Google Cloud コンソールにスクリーンショットの保存が失敗したと表示される

無効なリンクチェッカーを作成し、スクリーンショットを保存するように構成しました。しかし、 Google Cloud コンソールに次のいずれかの警告メッセージと詳細な情報が表示されます。

InvalidStorageLocation
StorageValidationError
BucketCreationError
ScreenshotFileUploadError

これらのエラーを解決するには、次の手順を試してください。

InvalidStorageLocation メッセージが表示された場合は、options.screenshot_options.storage_location という名前のフィールドで指定された Cloud Storage バケットが存在することを確認します。
Cloud Run functions の関数に関連するログを表示します。詳細については、ログの検索をご覧ください。
対応する Cloud Run functions の関数で使用されているサービスアカウントに、Cloud Storage バケットの作成、アクセス、書き込みを可能にする Identity and Access Management ロールが付与されていることを確認します。