通知が表示されない場合のトラブルシューティング

このページでは、通知が想定どおりに届かない理由と、その場合の解決策について説明します。

通知が受信されない

通知チャンネルを構成し、インシデントが発生したときに通知が届くようにします。通知は受信されません。

障害の原因に関する情報を収集するには、次の手順を行います。

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

検索バーを使用してこのページを検索する場合は、小見出しが [Logging] である結果を選択します。
適切な Google Cloud プロジェクトを選択します。
ログに対して通知チャンネルイベントをクエリします。
1. [ログ名] メニューを開き、[notification_channel_events] を選択します。
2. [重大度] メニューを開き、[エラー] を選択します。
3. 省略可: カスタムの期間を選択するには、期間セレクタを使用します。
4. [クエリを実行] をクリックします。
上記の手順では、次のクエリを作成します。
```
resource.type:"stackdriver_notification_channel"
logName="projects/PROJECT_ID/logs/monitoring.googleapis.com%2Fnotification_channel_events"
severity=ERROR
```
通常、障害情報は、概要行と jsonPayload フィールドに含まれます。たとえば、ゲートウェイエラーが発生すると、概要行に「failed with 502 Bad Gateway」が表示されます。

Webhook 通知を受信できない

Webhook 通知チャネルを構成して、インシデントが発生したときに通知されるのを待ちます。通知は受信されません。

プライベートエンドポイント

エンドポイントが公開されていない限り、通知に Webhook を使用することはできません。

この状況を解決するには、この通知トピックへの pull サブスクリプションと組み合わせて、Pub/Sub 通知を使用します。

Pub/Sub 通知チャネルを構成すると、インシデント通知が Identity and Access Management コントロールを持つ Pub/Sub キューに送信されます。Pub/Sub トピックにクエリまたはリッスンできるすべてのサービスでこれらの通知を使用できます。たとえば、App Engine、Cloud Run、Compute Engine 仮想マシンで実行されているアプリケーションでこれらの通知を使用できます。

pull サブスクリプションを使用する場合、メッセージの受信を待機するリクエストが Google に送信されます。これらのサブスクリプションには Google へのアクセスが必要ですが、ファイアウォールや受信アクセス用のルールは必要ありません。

パブリックエンドポイント

配信が失敗した理由を特定するには、Cloud Logging ログエントリで失敗情報を調べます。

たとえば、ログエクスプローラを使用し、次のようなフィルタによって、通知チャネルリソースのログエントリを検索できます。

resource.type="stackdriver_notification_channel"

Pub/Sub 通知を受信できない

Pub/Sub 通知チャンネルを構成しても、通知を受信しません。

この問題を解決するには、次のことを試してください。

通知サービスアカウントが存在することを確認します。サービスアカウントが削除されている場合、通知は送信されません。

サービスアカウントが存在することを確認するには、次のようにします。
1. Google Cloud コンソールの [IAM] ページに移動します。
  [IAM] に移動
  
  検索バーを使用してこのページを検索する場合は、小見出しが [IAM と管理者] である結果を選択します。
2. 次の命名規則を使用するサービスアカウントを検索します。
```
service-PROJECT_NUMBER@gcp-sa-monitoring-notification.iam.gserviceaccount.com
```
  このサービスアカウントが一覧にない場合は、[Google 提供のロール付与を含む] を選択します。
通知のサービスアカウントが存在しない場合は、Monitoring がサービスアカウントを作成するための Pub/Sub 通知チャンネルを作成するプロセスを開始する必要があります。
1. Google Cloud コンソールで [アラート] ページに移動します。
  アラートに移動
  
  検索バーを使用してこのページを検索する場合は、小見出しが [Monitoring] である結果を選択します。
2. [Edit notification channels] をクリックします。
3. [Pub/Sub] セクションで、[新しく追加] をクリックします。
  
  通知サービスアカウントが存在しない場合、Monitoring によって作成されます。[Pub/Sub チャンネルの作成] ダイアログに、通知サービスアカウントの名前が表示されます。
  
  注: Monitoring で通知サービスアカウントを作成するための Pub/Sub 通知チャンネルの作成を完了する必要はありません。
4. 通知チャンネルを追加しない場合は、[キャンセル] をクリックします。それ以外の場合は、通知チャンネルの作成を完了し、[チャンネルを追加] をクリックします。
5. サービスアカウントに Pub/Sub トピックを公開する権限を付与します。
  1. 新しいブラウザタブで、[通知チャンネルの作成] ドキュメントを開きます。
  2. [Pub/Sub] タブを選択し、そのページの [サービスアカウントを承認する] セクションの手順に沿って操作します。
通知のサービスアカウントに、目的の Pub/Sub トピックの通知を送信する権限があることを確認します。

サービスアカウントの権限を表示するには、Google Cloud コンソールか Google Cloud CLI コマンドを使用します。
- Google Cloud コンソールの [IAM] ページに、各サービスアカウントのロールが一覧表示されます。
- Google Cloud コンソールの Pub/Sub トピックページに、各トピックが一覧表示されます。トピックを選択すると、[権限] タブにサービスアカウントに付与されているロールが一覧表示されます。
- すべてのサービスアカウントとそれらのロールを一覧表示するには、次の Google Cloud CLI コマンドを実行します。
```
gcloud projects get-iam-policy PROJECT_ID
```
  このコマンドに対するレスポンスの一部を次に示します。
```
    serviceAccount:service-PROJECT_NUMBER@gcp-sa-monitoring-notification.iam.gserviceaccount.com
       role: roles/monitoring.notificationServiceAgent
     - members:
       [...]
       role: roles/owner
     - members:
       - serviceAccount:service-PROJECT_NUMBER@gcp-sa-monitoring-notification.iam.gserviceaccount.com
       role: roles/pubsub.publisher
```
  コマンドレスポンスにはロールのみが含まれ、トピックオーソリティは含まれません。
- 特定のトピックの IAM バインディングを一覧表示するには、次のコマンドを実行します。
```
gcloud pubsub topics get-iam-policy TOPIC
```
  このコマンドのレスポンスの例を次に示します。
```
    bindings:
    - members:
      - serviceAccount:service-PROJECT_NUMBER@gcp-sa-monitoring-notification.iam.gserviceaccount.com
      role: roles/pubsub.publisher
    etag: BwXPRb5WDPI=
    version: 1
```
通知のサービスアカウントを承認する方法については、サービスアカウントを承認するをご覧ください。

稼働時間チェックのアラートポリシーの通知が受信されない

仮想マシン（VM）が再起動またはシャットダウンした場合に通知を受け取るには、指標 compute.googleapis.com/instance/uptime をモニタリングするアラートポリシーを作成します。指標データがない場合にインシデントを生成する条件を作成して構成します。条件の定義に、Monitoring Query Language（MQL）¹ は使用しません。仮想マシン（VM）が再起動またはシャットダウンしても通知されません。

このアラートポリシーは、RUNNING 状態の Compute Engine VM インスタンスの時系列のみをモニタリングします。他の状態（STOPPED や DELETED など）にある VM の時系列は、条件が評価される前に除外されます。この動作のため、VM インスタンスが実行されているかどうかを判断するために、指標の不在アラート条件でアラートポリシーを使用することはできません。VM インスタンスの状態の詳細については、VM インスタンスのライフサイクルをご覧ください。

この問題を解決するには、アラートポリシーを作成して稼働時間チェックをモニタリングします。プライベートエンドポイントの場合は、プライベート稼働時間チェックを使用してください。

稼働時間チェックに関するアラートの代わりに、アラートポリシーを使用してデータがないことをモニタリングすることもできます。データがないことをアラートするのではなく、稼働時間チェックについてアラートすることを強く推奨します。指標がないことについてのアラートポリシーでは、Monitoring データの利用可否に関する一時的な問題によって誤検出される可能性があります。

ただし、稼働時間チェックを使用できない場合は、MQL でアラートポリシーを作成して、VM がシャットダウンされたことを通知できます。MQL 定義の条件では、時系列データが、VM インスタンスの状態に基づいて事前にフィルタリングされることはありません。MQL では VM の状態によってデータがフィルタリングされないため、これを使用して、シャットダウンされた VM からデータの不在を検出できます。

compute.googleapis.com/instance/cpu/utilization 指標をモニタリングする次の MQL 条件を検討してください。

fetch gce_instance::compute.googleapis.com/instance/cpu/utilization
|absent_for 3m

この条件でモニタリングしている VM がシャットダウンされると、3 分後にインシデントが生成され、通知が送信されます。absent_for 値は 3 分以上にする必要があります。

MQL の詳細については、MQL のアラートポリシーをご覧ください。

¹: MQL は表現力に優れたテキストベースの言語であり、Cloud Monitoring API 呼び出しや Google Cloud コンソールで使用できます。Google Cloud コンソールを使用するときに MQL で条件を構成するには、コードエディタを使用する必要があります。

リクエスト数のアラートポリシーの通知が受信されない

完了したリクエストの数をモニタリングする必要があります。指標 serviceruntime.googleapis.com/api/request_count をモニタリングするアラートポリシーを作成しましたが、リクエスト数が構成されたしきい値を超えた場合に通知されません。

リクエスト数の指標のアライメント期間の最大値は 7 時間 30 分です。

この問題を解決するには、アラートポリシーでアライメント期間の値を確認します。値がこの指標の最大値を超えている場合は、アライメント期間が 7 時間 30 分以下になるよう短縮します。

通知が表示されない場合のトラブルシューティング

通知が受信されない

Webhook 通知を受信できない

プライベート エンドポイント

パブリック エンドポイント

Pub/Sub 通知を受信できない

稼働時間チェックのアラート ポリシーの通知が受信されない

リクエスト数のアラート ポリシーの通知が受信されない

プライベートエンドポイント

パブリックエンドポイント

稼働時間チェックのアラートポリシーの通知が受信されない

リクエスト数のアラートポリシーの通知が受信されない