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

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

再テストウィンドウの選択など、アラートポリシーに影響を与える可能性がある変数については、指標ベースのアラートポリシーの動作をご覧ください。

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

システム内のディスクの使用容量をモニタリングするためにアラートポリシーを作成しました。このポリシーによって、指標 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 分以上のアライメント期間を使用します。
App Hub ラベル metadata.system_labels.apphub_host_project_id の名前を metadata.system_labels.apphub_application_container に変更すると、新しいインシデントが生成されたり、一部の対応待ちのインシデントがクローズされなくなる可能性があります。

対応の必要はありません。データの受信が停止すると、自動クローズ期間が終了した後にアラートは自動的にクローズされます。詳細については、部分的な指標データをご覧ください。

データの受信が停止してもインシデントがクローズされない

部分的な指標データのガイダンスに沿って、データの受信が停止したときにインシデントをクローズするようにアラートポリシーを構成します。データの受信が停止しても、対応待ちのインシデントが自動的にクローズされない場合があります。

アラートポリシーによってモニタリングされる基盤となるリソースに 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）ロールがあることを確認します。

指標データを含むすべてのインシデントの詳細を表示し、インシデントを確認またはクローズできるようにするには、モニタリング閲覧者（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 を追加するか、時系列をグループ化しないでください。

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

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

Unable to close incident with active conditions.

インシデントをクローズできるのは、最新のアラート期間にモニタリング情報がなかったときだけです。アラート期間（通常はデフォルト値が 5 分）は、アラートポリシーの条件の一部として定義され、構成可能です。上記のエラーメッセージは、アラート期間内にデータが受信されたことを示しています。

内部エラーが原因でインシデントをクローズできない場合は、次のエラーが発生します。

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

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

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

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

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

条件が満たされるたびに、Monitoring によって通知が送信され、インシデントが作成されます。その結果、複数の条件を持つアラートポリシーがある場合は、結合された条件を満たす時系列ごとに 1 つの通知とインシデントを受け取る可能性があります。

たとえば、2 つの条件を持つアラートポリシーがあり、各条件が 3 つの時系列をモニタリングしているとします。ポリシーは、両方の条件が満たされた場合にのみ通知を送信します。ポリシーの条件が満たされると、2～6 件（各条件で 1 つの時系列が満たされる）の通知とインシデントが発生する可能性があります。

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

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

指標ラベルの変数が null である

アラートポリシーを作成し、指標ラベルの変数をドキュメントセクションに追加します。通知に変数の値が表示されることを想定していますが、値が null に設定されています。

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

アラートポリシーの集計設定で、表示するラベルが保持されていることを確認します。

たとえば、VM インスタンスによって書き込まれるディスクバイト数をモニタリングするアラートポリシーを作成するとします。前述の通知の原因となったデバイスをドキュメントに一覧表示するには、ドキュメントフィールドに device: ${metric.label.device} を追加します。

また、集計設定で device ラベルの値が保持されるようにする必要があります。このラベルを保持するには、集計関数を none に設定するか、グループ化の選択に device が含まれていることを確認します。
変数の構文と適用可能性を確認します。詳細については、ユーザー定義のドキュメントで通知にアノテーションを付けるをご覧ください。

たとえば、変数 log.extracted_label.KEY はログベースのアラートポリシーでのみサポートされます。アラートポリシーが指標をモニタリングする場合、この変数はログベースの指標であっても、常に null としてレンダリングされます。

指標の定義の変更後に新しいデータがない

ログベースの指標で使用したフィルタを変更するなどして、ユーザー定義指標の定義を変更しても、アラートポリシーに指標定義の変更が反映されません。

この問題を解決するには、ポリシーの表示名を編集して、アラートポリシーを強制的に更新します。

指標がないため、API でアラートポリシーの作成が失敗する

最近指標を作成して、Cloud Monitoring API でアラートポリシーを作成するときにその指標を参照しました。ただし、API コマンドが失敗し、次のエラーが表示されます。

Error 404: Cannot find metric(s) that match type = "METRIC_NAME".
If a metric was created recently, it could take up to 10 minutes to become
available. Please try again soon.

この問題を解決するには、10 分以上待ってから API リクエストを再送信します。

アラートポリシーのグラフにしきい値違反が表示されない

アラートポリシーでインシデントが作成されたという通知を受け取りました。ただし、ポリシーの詳細ページに移動しても、しきい値違反がチャートには表示されません。

この状況を解決するには、グラフの期間を短くしてみてください。期間を短くするには、ツールバーの期間セレクタを使用するか、ポインタでグラフ上の期間をハイライト表示します。

グラフの解像度は限られており、一部の期間についてはすべての測定値が表示されない場合があります。

アラート ポリシーのトラブルシューティング コレクションでコンテンツを整理 必要に応じて、コンテンツの保存と分類を行います。