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

このページでは、通知が想定どおりに届かない理由と、そのような状況に備えるための方法について説明します。

通知が受信されない

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

失敗の原因に関する情報を収集するには、次の操作を行います。

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

    [ログ エクスプローラ] に移動

    検索バーを使用してこのページを検索する場合は、小見出しが「Logging」の結果を選択します。

  2. 適切な Google Cloud プロジェクトを選択します。

  3. ログで通知チャンネル イベントをクエリします。

    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 によって作成されます。[Create Pub/Sub Channel] ダイアログに、通知サービス アカウントの名前が表示されます。

    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）1 は使用しません。仮想マシン（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 のアラート ポリシーをご覧ください。

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

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

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

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

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

SMS 通知メッセージまたは確認コードが届かない

SMS 通知を受け取るか、確認コードを SMS 通知用の番号で受け取るように設定していますが、メッセージが届きません。

SMS メッセージの上限に達している場合は、追加の SMS メッセージを受信できません。このエラーを確認できるログがある可能性があります。ログで Denied quota token を確認します。

一般的な推奨事項として、通知を SMS チャンネルにのみ依存することはおすすめしません。SMS 通知は「ベスト エフォート」ベースで提供されます。