アラート ポリシーのトラブルシューティング

このページでは、一部のアラート ポリシーが意図したものと異なる動作をとる理由を説明し、そのような状況に備えるための方法を説明します。

アラート ポリシーに影響を与える変数(期間ウィンドウなど)については、アラートの動作をご覧ください。

ディスク使用率ポリシーにより予期しないインシデントが作成される

システム内のディスクの「使用済み」容量をモニタリングするためのアラート ポリシーを作成しました。このポリシーは、指標 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 の時系列を除外するようにディスク使用率のアラート ポリシーを構成する必要があります。

稼働時間ポリシーによって想定されるアラートが作成されない

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

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

この問題を解決するには、アラート ポリシーを作成して稼働時間チェックをモニタリングします。稼働時間チェックを作成するには、VM に外部 IP アドレスが必要です。

VM に外部 IP アドレスがない場合は、VM がシャットダウンされたことを通知する MQL のアラート ポリシーを作成できます。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 Console で使用できます。Cloud Console を使用するときに MQL で条件を構成するには、[クエリエディタ] を選択する必要があります。

異常インシデントの一般的な原因

アラート ポリシーを作成済みで、ポリシーがインシデントを早期または誤って作成しているように見えることがあります。

特に、指標の不在や「しきい値未満」条件のアラート ポリシーのデータにギャップがある場合は、異常であることを示すインシデントを作成できます。データにギャップがあるかどうかを判断するのは簡単なことではありません。そのようなギャップは不明瞭なこともあります。また、自動的に補正されていることもあります。

  • たとえばグラフでは、欠落しているデータの値は補間されるため、ギャップが不明瞭になる場合があります。数分のデータが欠落している場合でも、グラフは視覚的な連続性のために、欠落しているポイントを接続させます。基盤となるデータでそのようなギャップがあれば、アラート ポリシーがインシデントを作成するのに十分であることがあります。

  • ログベースの指標でのポイントは、到着が遅延して、最大で過去 10 分間バックフィルされることがあります。このバックフィル動作によってギャップが効果的に修正され、データが到着したときにそのギャップが埋められます。このように、ログベースの指標のギャップが表示されなくなったために、アラート ポリシーがインシデントを作成した可能性があります。

「指標の不在」および「しきい値未満」の条件は、クエリの遅延が小さく、リアルタイムで評価されます。条件のステータスは、評価された時刻と、対応するインシデントが Monitoring で表示される時刻との間で変化できます。

インシデントを作成する前に複数の測定値が必要な場合は、条件の期間フィールドが指標のサンプリング レートの 2 倍を超える値に設定されるようにしてください。たとえば、指標が 60 秒ごとにサンプリングされる場合は、期間を少なくとも 3 分に設定します。期間フィールドを最新の値(またはほぼ 0 秒)に設定すると、1 回の測定でインシデントが作成されます。

複数の条件に基づくポリシーによって複数の通知が作成される

複数の条件を含むアラート ポリシーを作成し、それらの条件を論理 AND で結合しました。すべての条件が満たされたときに 1 つの通知が送信され、1 つのインシデントが作成されると想定されます。ただし、複数の通知を受信し、複数のインシデントが作成されたことを確認できます。

論理 AND で結合された複数の条件がアラート ポリシーに含まれている場合、ポリシーによってトリガーされると、条件が満たされる時系列ごとに、ポリシーによって通知が送信され、インシデントが作成されます。たとえば、あるポリシーに 2 つの条件があり、各条件で 1 つの時系列をモニタリングする場合、2 つのインシデントが開かれ、通知が 2 通届きます。

単一のインシデントを作成して単一の通知を送信するように Cloud Monitoring を構成することはできません。

詳細については、インシデントごとの通知をご覧ください。

権限エラーのため、インシデントの詳細を表示できない

Google Cloud Console のインシデント ページに移動し、表示するインシデントを選択します。詳細ページが開きます。ただし、詳細ページが開かず、「アクセスが拒否されました」というメッセージが表示されます。

この状況を解決するには、Identity and Access Management(IAM)ロールが roles/monitoring.viewer であるか、このロールのすべての権限が含まれていることを確認します。たとえば、ロール roles/monitoring.editorroles/monitoring.admin には、閲覧者のロールのすべての権限が含まれています。

カスタムロールでは、インシデント詳細の表示に必要な権限を付与することはできません。

インシデントを手動で終了できない

システムでのインシデントに関する通知を受け取りました。インシデントの詳細ページに移動し、[Close incident] をクリックします。インシデントがクローズされることを想定していましたが、次のエラー メッセージが表示されます。

Unable to close incident with active conditions.

インシデントを閉じることができるのは、最新のアラート期間にモニタリングが受信していない場合のみです。アラート期間(通常はデフォルト値 5 分)は、アラート ポリシー条件の一部として定義できます。上記のエラー メッセージは、アラート期間内にデータが受信されたことを示しています。

内部エラーのためにインシデントを閉じることができない場合は、次のエラーが発生します。

Unable to close incident. Please try again in a few minutes.

前のエラー メッセージが表示されたら、終了オペレーションを再試行するか、Monitoring でインシデントを自動的に終了させることができます。

詳細については、インシデントの管理をご覧ください。

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"