このページでは、一部のアラート ポリシーが意図したものと異なる動作をとる理由を説明し、そのような状況に備えるための方法を説明します。
再テスト ウィンドウの選択など、アラート ポリシーに影響を与える可能性がある変数については、指標ベースのアラート ポリシーの動作をご覧ください。
ディスク使用率ポリシーにより予期しないインシデントが作成される
システム内のディスクの「使用」容量をモニタリングするためにアラート ポリシーを作成しました。このポリシーによって、指標 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.* と一致しないすべての時系列を除外できます。
異常なインシデントの一般的な原因
アラート ポリシーを作成済みで、ポリシーがインシデントを早期または誤って作成しているように見えることがあります。
間違っているように見えるインシデントの通知を受信する理由はさまざまです。
特に、指標の不在や「しきい値未満」条件のアラート ポリシーのデータにギャップがある場合は、異常であることを示すインシデントを作成できます。インシデントにはデータギャップが見られず、データギャップが自動的に修正されることもあります。
たとえば、グラフでは、欠損データの値が補間されているため、欠落が表示されない場合があります。数分のデータが欠落している場合でも、グラフは視覚的には連続して表示されるため、欠落しているポイントを接続させます。基盤となるデータでそのようなギャップがあれば、アラート ポリシーがインシデントを作成するのに十分であることがあります。
ログベースの指標でのポイントは到着が遅延して、最大で過去 10 分間バックフィルされることがあります。このバックフィル動作によってギャップが効果的に修正され、データが到着したときにそのギャップが埋められます。このように、ログベースの指標のギャップが表示されなくなったために、アラート ポリシーがインシデントを作成した可能性があります。
「指標の不在」および「しきい値未満」の条件は、クエリの遅延が小さく、リアルタイムで評価されます。条件のステータスは、評価された時刻と、対応するインシデントが Monitoring で表示される時刻との間で変化することがあります。
1 つの尺度に基づいてインシデントを作成するように構成された条件では、インシデントが早すぎる、または正しくないように見えることがあります。この状況を回避するには、条件の再テスト ウィンドウを指標のサンプリング レートの 2 倍以上になるように設定して、インシデントを作成する前に複数の測定を行う必要があります。
たとえば、指標が 60 秒ごとにサンプリングされる場合は、再テスト ウィンドウを 3 分以上に設定します。再テスト ウィンドウを直近の値（0 秒と同等の値）に設定すると、1 回の測定でインシデントが作成されます。
アラート ポリシーの条件が編集されると、アラート インフラストラクチャに変更が反映されるまで数分かかることがあります。この間は、元のアラート ポリシーの条件を満たすインシデントの通知を受け取る可能性があります。
時系列データが届いたとき、そのデータがアラート インフラストラクチャ全体へ反映されるまで最大 1 分かかることがあります。このプロセス中、時系列データが期間グラフに伝播されていない場合でも、アラート ポリシーによって条件が満たされていると評価されることがあります。そのため、グラフに条件が満たされていることが示されていなくても、通知が届くことがあります。この状況が発生する可能性を減らすには、5 分以上のアライメント期間を使用します。
データの受信が停止しても、インシデントはクローズされない
部分的な指標データのガイダンスに沿って、データの受信が停止したときにインシデントを閉じるようにアラート ポリシーを構成します。データの受信が停止しても、対応待ちのインシデントは自動的に終了しない場合があります。
アラート ポリシーによってモニタリングされる基盤となるリソースに metadata.system_labels.state ラベルが含まれ、そのポリシーが Monitoring Query Language で記述されていない場合、Monitoring はリソースの状態を特定できます。リソースの状態が無効であることがわかっている場合、データの受信が停止しても、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 でインシデントを自動的に終了させることができます。
詳細については、インシデントの管理をご覧ください。
複数の条件に基づくポリシーによって複数の通知が作成される
複数の条件を含むアラート ポリシーを作成し、それらの条件は論理 AND で結合していました。すべての条件が満たされたときに、インシデントが 1 つ作成され、通知を 1 つ受信することを想定しています。しかし、複数の通知を受信し、インシデントが複数作成されていることがわかります。
条件を満たす時系列ごとに、モニタリングによって通知が送信され、インシデントが作成されます。その結果、複数の条件を持つアラート ポリシーがある場合は、結合された条件を満たす時系列ごとに 1 つの通知とインシデントを受け取る可能性があります。
たとえば、2 つの条件を含むアラート ポリシーがあり、各条件が 3 つの時系列をモニタリングするとします。ポリシーは、両方の条件が満たされた場合にのみ通知を送信します。ポリシーの条件が満たされると、2 個（各条件で 1 つの時系列が満たされている）から 6 個（各条件ですべての時系列が満たされている）の通知とインシデントを受け取ることができます。
単一のインシデントを作成して単一の通知を送信するように Cloud Monitoring を構成することはできません。
詳細については、インシデントごとの通知をご覧ください。
指標ラベルの変数が null である
アラート ポリシーを作成し、指標ラベルの変数をドキュメント セクションに追加します。通知に変数の値が表示されると想定します。ただし、値は null に設定されます。
この状況を解決するには、次のことを試してください。
アラート ポリシーの集計設定で、表示するラベルが保持されていることを確認します。
たとえば、VM インスタンスによって書き込まれるディスクバイト数をモニタリングするアラート ポリシーを作成するとします。ドキュメントに前述の通知の原因となったデバイスを一覧表示するには、ドキュメント フィールドに
device: ${metric.label.device}を追加します。また、集計設定で
deviceラベルの値が保持されるようにする必要もあります。このラベルを保持するには、集計関数をnoneに設定するか、グループ化の選択にdeviceを含めます。変数の構文と適用範囲を確認します。構文については、ユーザー定義のドキュメントで通知にアノテーションを付けるをご覧ください。
たとえば、変数
log.extracted_label.KEYは、ログベースのアラート ポリシーでのみサポートされています。アラート ポリシーが指標をモニタリングする場合、この変数はログベースの指標であっても、常にnullとしてレンダリングされます。
指標定義の変更後に新しいデータがない
たとえば、ログベースの指標で使用したフィルタを変更するなどして、ユーザー定義指標の定義を変更した場合、アラート ポリシーに指標定義に加えた変更が反映されません。
この問題を解決するには、ポリシーの表示名を編集して、アラート ポリシーを強制的に更新します。