このページでは、一部のアラート ポリシーが意図したものと異なる動作をとる理由を説明し、そのような状況に備えるための方法を説明します。
時間枠の選択など、アラート ポリシーに影響を与える可能性がある変数については、指標ベースのアラート ポリシーの動作をご覧ください。
指標ラベルの変数が null である
アラート ポリシーを作成し、ドキュメント セクションに指標ラベルの変数を追加します。通知に変数の値が表示されると想定します。ただし、値は null
に設定されます。
この状況を解決するには、次のことを試してください。
アラート ポリシーの集計設定で、表示するラベルが保持されていることを確認します。
たとえば、VM インスタンスによって書き込まれるディスクバイト数をモニタリングするアラート ポリシーを作成するとします。ドキュメントに前述の通知の原因となったデバイスを一覧表示するには、ドキュメント フィールドに
device: ${metric.label.device}
を追加します。また、集計設定で
device
ラベルの値が保持されるようにする必要もあります。このラベルを保持するには、集計関数をnone
に設定するか、グループ化の選択にdevice
を含めます。変数の構文と適用範囲を確認します。構文については、ユーザー定義のドキュメントでアラートにアノテーションを付けるをご覧ください。
たとえば、変数
log.extracted_label.KEY
はログベースのアラートでのみサポートされています。アラート ポリシーが指標をモニタリングする場合、この変数はログベースの指標であっても、常にnull
としてレンダリングされます。
ディスク使用率ポリシーにより予期しないインシデントが作成される
システム内のディスクの「使用」容量をモニタリングするためにアラート ポリシーを作成しました。このポリシーによって、指標 agent.googleapis.com/disk/percent_used
がモニタリングされます。物理ディスクの使用率が条件で設定したしきい値を超えた場合にのみ通知されることを想定しています。しかし、このポリシーでは、すべての物理ディスクのディスク使用率がしきい値を下回るとインシデントが作成されます。
こうしたポリシーの予期しないインシデントの原因は、条件が物理ディスクのモニタリングに限定されていないことです。代わりに、こうしたポリシーでは、ループバック デバイスなどの仮想ディスクを含むすべてのディスクをモニタリングします。仮想ディスクの使用率が 100% になるように構成されている場合、ポリシーのインシデントが作成されます。
たとえば、次の Linux df
コマンドの出力を検討してください。これは、1 つのシステムについて、マウントされたファイル システムで使用可能なディスク スペースを示しています。
$ df /dev/root 9983232 2337708 7629140 24% / devtmpfs 2524080 0 2524080 0% /dev tmpfs 2528080 0 2528080 0% /dev/shm ... /dev/sda15 106858 3934 102924 4% /boot/efi /dev/loop0 56704 56704 0 100% /snap/core18/1885 /dev/loop1 129536 129536 0 100% /snap/google-cloud-sdk/150 ...
このシステムでは、ループバック デバイス /dev/loop0
と /dev/loop1
の時系列を除外するようにディスク使用率のアラート ポリシーを構成する必要があります。たとえば、フィルタ device !=~ ^/dev/loop.*
を追加すると、device
ラベルが正規表現 ^/dev/loop.*
と一致しないすべての時系列を除外できます。
稼働時間ポリシーによって想定されるアラートが作成されない
仮想マシン(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 分以下になるよう短縮します。
異常なインシデントの一般的な原因
アラート ポリシーを作成済みで、ポリシーがインシデントを早期または誤って作成しているように見えることがあります。
間違っているように見えるインシデントの通知を受信する理由はさまざまです。
特に、指標の不在や「しきい値未満」条件のアラート ポリシーのデータにギャップがある場合は、異常であることを示すインシデントを作成できます。インシデントにはデータギャップが見られず、データギャップが自動的に修正されることもあります。
たとえば、グラフでは、欠損データの値が補間されているため、欠落が表示されない場合があります。数分のデータが欠落している場合でも、グラフは視覚的には連続して表示されるため、欠落しているポイントを接続させます。基盤となるデータでそのようなギャップがあれば、アラート ポリシーがインシデントを作成するのに十分であることがあります。
ログベースの指標でのポイントは到着が遅延して、最大で過去 10 分間バックフィルされることがあります。このバックフィル動作によってギャップが効果的に修正され、データが到着したときにそのギャップが埋められます。このように、ログベースの指標のギャップが表示されなくなったために、アラート ポリシーがインシデントを作成した可能性があります。
「指標の不在」および「しきい値未満」の条件は、クエリの遅延が小さく、リアルタイムで評価されます。条件のステータスは、評価された時刻と、対応するインシデントが Monitoring で表示される時刻との間で変化することがあります。
1 つの尺度に基づいてインシデントを作成するように構成された条件では、インシデントが早すぎる、または正しくないように見えることがあります。この状況を回避するには、条件の期間フィールドを指標のサンプリング レートの 2 倍以上になるように設定して、インシデントを作成する前に複数の測定を行う必要があります。
たとえば、指標が 60 秒ごとにサンプリングされる場合は、期間を 3 分以上に設定します。期間フィールドを直近の値(0 秒と同等の値)に設定すると、1 回の測定でインシデントが作成されます。
アラート ポリシーの条件が編集されると、アラート インフラストラクチャに変更が反映されるまで数分かかることがあります。この間は、元のアラート ポリシーの条件を満たすインシデントの通知を受け取る可能性があります。
時系列データが届いたとき、そのデータがアラート インフラストラクチャ全体へ反映されるまで最大 1 分かかることがあります。アライメント期間を 1 分または最新のサンプルに設定すると、反映のレイテンシによりアラート ポリシーが正しくトリガーされていないように見えることがあります。この状況が発生する可能性を減らすには、5 分以上のアライメント期間を使用します。
データの受信が停止しても、インシデントはクローズされません
部分的な指標データのガイダンスに沿って、データが到着しなくなったときにインシデントを閉じるようにアラート ポリシーを構成します。データの受信が停止しても、対応待ちのインシデントが自動的に終了しないことがあります。
アラート ポリシーによってモニタリングされる基盤となるリソースに metadata.system_labels.state
ラベルが含まれ、そのポリシーが Monitoring Query Language で記述されていない場合、Monitoring はリソースの状態を特定できます。リソースの状態が無効であることがわかっている場合、データの到着が停止しても、Monitoring はインシデントを自動的にクローズしません。ただし、これらのインシデントは手動でクローズできます。
複数の条件に基づくポリシーによって複数の通知が作成される
複数の条件を含むアラート ポリシーを作成し、それらの条件は論理 AND
で結合していました。すべての条件が満たされたときに、インシデントが 1 つ作成され、通知を 1 つ受信することを想定しています。しかし、複数の通知を受信し、インシデントが複数作成されていることがわかります。
Monitoring によって通知が送信され、条件を満たす時系列ごとにインシデントが作成されます。その結果、複数の条件を持つアラート ポリシーがある場合は、結合された条件を満たす時系列ごとに 1 つの通知とインシデントを受け取る可能性があります。
たとえば、2 つの条件を含むアラート ポリシーがあり、各条件が 3 つの時系列をモニタリングするとします。ポリシーは、両方の条件が満たされた場合にのみ通知を送信します。ポリシーの条件が満たされると、2 個(各条件で 1 つの時系列が満たされている)から 6 個(各条件ですべての時系列が満たされている)の通知とインシデントを受け取ることができます。
単一のインシデントを作成して単一の通知を送信するように Cloud Monitoring を構成することはできません。
詳細については、インシデントごとの通知をご覧ください。
権限エラーのため、インシデントの詳細を表示できない
Google Cloud コンソールの [インシデント] ページに移動し、表示するインシデントを選択します。詳細ページが開くことを想定しています。しかし、詳細ページは開かず、「アクセスが拒否されました」というメッセージが表示されます。
指標データを除くすべてのインシデントの詳細を表示するには、Cloud コンソールのインシデントのモニタリング閲覧者(roles/monitoring.cloudConsoleIncidentViewer
)と Stackdriver アカウント閲覧者(roles/stackdriver.accounts.viewer
)の Identity and Access Management(IAM)ロールがあることを確認します。
指標データを含むすべてのインシデントの詳細を表示し、インシデントを確認またはクローズできるようにするには、Monitoring 閲覧者(roles/monitoring.viewer
)と Cloud コンソールのインシデントのモニタリング編集者(roles/monitoring.cloudConsoleIncidentEditor
)の IAM ロールがあることを確認します。
カスタムロールでは、インシデント詳細の表示に必要な権限を付与することはできません。
条件が満たされたときにインシデントが作成されない
1 つの条件を持つアラート ポリシーを作成しました。アラートグラフは、モニタリング対象データが条件に違反しているものの、通知は送信されず、インシデントも作成されていないことを示しています。
アラート ポリシーの条件が満たされた後に、次のいずれかの条件が当てはまる場合、Monitoring ではインシデントが開かれません。
- アラート ポリシーはスヌーズされています。
- アラート ポリシーは無効になっています。
- アラート ポリシーが、同時に開くことができるインシデントの最大数に達した。
アラート ポリシーがモニタリングするリソースの状態は、無効であることがわかっています。リソースに
metadata.system_labels.state
ラベルが含まれている場合と、Monitoring Query Language でアラート ポリシーが作成されていない場合、Monitoring はリソースの状態を判別できます。
インシデントの詳細によって間違ったプロジェクトが一覧表示される
通知を受信すると、状態の概要には、インシデントが作成された Google Cloud プロジェクト、つまりスコーピング プロジェクトが一覧表示されます。しかし、そのインシデントには、Monitoring でインシデントを作成する原因となった時系列を保存する Google Cloud プロジェクトの名前が一覧表示されることを想定しています。
通知で参照される Google Cloud プロジェクトは、アラート ポリシーの条件で指定された集計オプションによって決まります。
集計オプションでプロジェクト ID を保存しているラベルを削除すると、インシデント情報にはスコーピング プロジェクトが一覧表示されます。たとえば、データをゾーンでグループ化すると、プロジェクト ID を保存するラベルはグループ化後に削除されます。
集計オプションでプロジェクト ID を保存するラベルが保持されている場合、インシデント通知には、インシデントが発生する時系列を保存している Google Cloud プロジェクトの名前が含まれます。プロジェクト ID ラベルを保持するには、グループ化フィールドにラベル
project_id
を含めるか、時系列をグループ化しないでください。
インシデントを手動で終了できない
システムでのインシデントに関する通知を受け取りました。インシデントの詳細ページに移動し、[Close incident] をクリックします。インシデントがクローズされることを想定していましたが、次のエラー メッセージが表示されます。
Unable to close incident with active conditions.
インシデントをクローズできるのは、最新のアラート期間にモニタリング情報がなかったときだけです。アラート期間(通常はデフォルト値の 5 分)はアラート ポリシー条件の一部として定義され、構成できます。上記のエラー メッセージは、アラート期間内にデータが受信されたことを示しています。
内部エラーが原因でインシデントをクローズできない場合は、次のエラーが発生します。
Unable to close incident. Please try again in a few minutes.
前のエラー メッセージが表示されたら、終了オペレーションを再試行するか、Monitoring でインシデントを自動的に終了させることができます。
詳細については、インシデントの管理をご覧ください。
通知が受信されない
通知チャンネルを構成し、インシデントが発生したときに通知が届くようにします。通知は受信されません。
Webhook と Pub/Sub の通知に関する問題を解決する方法については、このドキュメントの次のセクションをご覧ください。
障害の原因に関する情報を収集するには、次の操作を行います。
-
Google Cloud コンソールのナビゲーション パネルで、[Logging] を選択してから、[ログ エクスプローラ] を選択します。
- 適切な Google Cloud プロジェクトを選択します。
ログに対して通知チャンネル イベントをクエリします。
- [ログ名] メニューを開き、[notification_channel_events] を選択します。
- [重大度] メニューを開き、[エラー] を選択します。
- 省略可: カスタムの期間を選択するには、期間セレクタを使用します。
- [クエリを実行] をクリックします。
上記の手順によって、次のクエリが作成されます。
logName="projects/PROJECT_ID/logs/monitoring.googleapis.com%2Fnotification_channel_events" severity=ERROR
障害情報は通常、概要行と
jsonPayload
フィールドに含まれます。通常、障害情報は、概要行と
jsonPayload
フィールドに含まれます。たとえば、ゲートウェイ エラーが発生すると、概要行に「failed with 502 Bad Gateway」が表示されます。
指標の定義の変更後に新しいデータがない
ユーザー定義の指標の定義を変更する(たとえば、ログベースの指標で使用したフィルタを変更するなど)。また、アラート ポリシーには指標定義に加えた変更が反映されません。
この問題を解決するには、ポリシーの表示名を編集してアラート ポリシーを強制的に更新します。
Google Chat に送信された Webhook 通知を受信できない
Monitoring で Webhook 通知チャンネルを構成し、Google Chat に送信する Webhook を構成します。しかし、通知も、400 Bad Request
エラーも受信しません。
この問題を解決するには、Cloud Monitoring で Pub/Sub 通知チャネルを構成してから、Pub/Sub メッセージを Chat が想定する形式に変換し、通知を Google Chat に送信するように Cloud Run サービスを構成します。この構成の例については、Cloud Monitoring と Cloud Run を使用したカスタム通知の作成をご覧ください。
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 通知チャンネルを構成しても、通知を受信しません。
この問題を解決するには、次のことを試してください。
通知のサービス アカウントが存在することを確認します。サービス アカウントが削除されている場合、通知は送信されません。
サービス アカウントが存在することを確認するには、次のようにします。
-
Google Cloud コンソールのナビゲーション パネルで [IAM] を選択します。
次の命名規則を使用するサービス アカウントを検索します。
service-PROJECT_NUMBER@gcp-sa-monitoring-notification.iam.gserviceaccount.com
このサービス アカウントが一覧にない場合は、[Google 提供のロール付与を含む] を選択します。
通知のサービス アカウントが存在しない場合は、Monitoring がサービス アカウントを作成するための Pub/Sub 通知チャンネルを作成するプロセスを開始する必要があります。
-
Google Cloud コンソールのナビゲーション パネルで、[Monitoring] を選択してから、notifications [アラート] を選択します。
- [Edit notification channels] をクリックします。
[Pub/Sub] セクションで、[新しく追加] をクリックします。
通知サービス アカウントが存在しない場合、Monitoring によって通知サービス アカウントが作成されます。[Pub/Sub チャンネルの作成] ダイアログに、通知サービス アカウントの名前が表示されます。
通知チャンネルを追加しない場合は、[キャンセル] をクリックします。それ以外の場合は、通知チャンネルの作成を完了し、[チャンネルを追加] をクリックします。
サービス アカウントに Pub/Sub トピックを公開する権限を付与します。
- 新しいブラウザタブで、[通知チャンネルの作成] ドキュメントを開きます。
- [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
通知のサービス アカウントを承認する方法については、サービス アカウントを承認するをご覧ください。