アラームのトラブルシューティング
トラブルシューティング情報を使用して、モニタリングでのアラームの操作中に発生する可能性のある一般的な問題を特定し、対処します。
トラブルシューティングの前に、アラームの評価方法を理解していることを確認してください。アラーム評価の図を参照してください。
アラームは起動しません
アラームは起動の条件を満たしましたが、起動しませんでした。たとえば、コンピュート・インスタンスが停止したとします。
原因: 長いトリガー遅延
アラーム式は、トリガー遅延期間の連続した分数に対してtrueと評価されませんでした。
アラームのメトリック・チャートの次のイメージには、トリガー遅延期間を示す影付きの領域が含まれています。この例では、アラームの詳細ページに表示されるアラーム・サマリーはAlarm fires when the Mean of CpuUtilization is greater than the threshold value of 80, with a trigger delay of 10 minutesです。トリガー遅延は1:30(しきい値を超えた場合)に始まり、1:40に終了します。アラーム式は1:30にtrueと評価され、1:32にfalseと評価されます。この真の評価は、10分間のトリガー遅延期間全体では継続されないため、アラームは起動しません。
アラームのメトリック・チャートを表示するには、履歴を取得します。
アラームの評価方法の詳細は、アラーム評価の図を参照してください。
処置: トリガー遅延の短縮
トリガー遅延が長すぎて、しきい値に違反した直後にアラームを起動する場合は、より短いトリガー遅延を使用するようにアラームを更新します。たとえば、トリガー遅延を1分に設定します。アラームのトリガー遅延の定義およびMonitoring Query Language (MQL)リファレンスを参照してください。
原因: 間隔が排出頻度より短いです
アラーム式はtrueと評価され、アラームが起動しますが、最後のデータ・ポイントがしきい値を超えた場合でも次の間隔でアラームはクリアされます。選択したメトリックの間隔が排出の頻度より短いため、アラームはクリアされました。
アラームのメトリック・チャートの次のイメージは、oci_object_storageメトリック・ネームスペースから選択したメトリックStoredBytesの1時間当たりのデータ・ポイントを示しています。アラーム問合せはStoredBytes[1m].sum() > 800000000で、1分間隔を指定します。この間隔は、メトリックの排出頻度(1時間)より短くなります。(頻度はオブジェクト・ストレージ・メトリックに記載されています。)
この例では、アラームは3:00に起動し、3:01にクリアされます。間隔が1時間に設定されている場合、アラーム式はtrueに評価され続け、アラームは4:00まで起動し続けます。
アラームのメトリック・チャートを表示するには、履歴を取得します。
アラームの評価方法の詳細は、アラーム評価の図を参照してください。
Remedy: 間隔を増やす
アラームを起動する場合は、アラーム間隔をメトリックの放出頻度と同じかそれ以上に更新します。たとえば、StoredBytesメトリックの場合、アラームを3:01に起動し、前の例の4:00まで起動し続ける場合は、アラーム間隔を少なくとも1時間に更新します。アラーム問合せの間隔の選択およびMonitoring Query Language (MQL)リファレンスを参照してください。
原因: 寸法が間違っています
リソースがディメンションを使用してフィルタで除外されたため、リソースがアラームで定義された条件を満たしたときにアラーム式がtrueと評価されませんでした。
たとえば、可用性ドメイン1に対してディメンションが選択されたアラームを考えてみます。条件を満たすリソースは、可用性ドメイン2にあります。アラーム評価では、指定したディメンションに一致するリソースのみが考慮されます。
処置: ディメンションの更新
ディメンションを削除するか、リソースを含めるように更新してください。「アラーム問合せのディメンションの選択」を参照してください。
原因: 問合せが正しくありません
一般的な例:
CpuUtilizationを選択すると、アラーム問合せでメトリックMemoryUtilizationが指定される場合があります。- アラーム問合せでは、かわりにアラームで間隔(
sum())内のデータ・ポイントの合計をモニターする場合に、統計mean()を指定できます。
アラームの問合せを確認するには、その詳細を取得します。
問合せ要素の詳細は、Monitoring Query Language (MQL)リファレンスを参照してください。アラームの評価方法の詳細は、アラーム評価の図を参照してください。
処置: 問合せの更新
原因: アラームが無効です
処置: アラームの有効化
アラームは通知を送信しません
アラームが起動しても、通知は送信されません。
原因: アラームまたはディメンションが抑制されています
Remedy: 抑制の削除
「単一のアラームからの抑制の削除」および「複数のアラームからの抑制の削除」を参照してください。
原因: サブスクリプションが構成済トピックの一部ではありません
たとえば、受信ボックスにアラーム・メッセージが表示されないとします。アラームに指定されたトピックには、目的の電子メール・アドレスの電子メール・サブスクリプションがない可能性があります。
トピックに予想されるサブスクリプションが含まれているかどうかを確認するには、トピックの詳細の取得を参照してください。
処置: サブスクリプションを含めるためのトピックの更新
詳細は、サブスクリプションの作成を参照してください。
また、アラームを更新して、新しいトピックおよびサブスクリプションを参照したり、必要なサブスクリプションを含む既存のトピックを参照することもできます。「アラームの通知宛先としてのトピックの選択」を参照してください。
アラーム送信通知が多すぎます
アラームが起動すると、予想よりも多くの通知が送信されます。
原因: 繰返し通知は有効です
アラームは、アラームが中断せずに起動し続けるときに、アラーム通知を繰り返すように構成されます。
処置: 繰返し通知の無効化
原因: 分割通知は使用可能です
アラームは、起動するメトリック・ストリームごとに通知を送信するように構成されます。たとえば、50のメトリック・ストリームが起動すると、アラームは50の通知を送信します。これは、分割通知に対して予想される動作です。シナリオ: メトリック・ストリーム別のメッセージの分割を参照してください。
たとえば、次の図は、しきい値1:30を超える2つのメトリック・ストリームがあり、アラームが起動するアラーム・メトリック・チャートを示しています。
メトリック値が87のコンピュート・インスタンスに対して送信されるアラーム・メッセージを次に示します。
メトリック値が95のコンピュート・インスタンスに対して送信されるアラーム・メッセージを次に示します。
アラームのメトリック・チャートを表示するには、履歴を取得します。
アラーム・リセット
アラーム履歴には、RESET遷移状態が表示されます。
アラームがリセットされ、起動状態をトリガーしたメトリックがないかどうかのチェックが停止されます。詳細は、内部リセット期間についてを参照してください。
アラームが保存されない(404エラー)
新規または更新されたアラームを保存しようとすると、アラームの作成または更新を妨げる404エラーが表示されます。
原因: ポリシーが不十分です
404エラーは、必要なIAMポリシーがないことを示します。
処置: 必要なポリシーの取得
アラームが継続的に起動およびクリアされる
Firingステータス値とOKステータス値を切り替え続けるアラームをトラブルシューティングします。
アラーム間隔が小さすぎるか、トリガー遅延が大きすぎるのいずれか(あるいはその両方)です。リソースは、指定したメトリックをアラーム間隔より大きい頻度で発行します。
たとえば、5分ごとに発行されるメトリックDatabaseAvailabilityについて考えてみます。
APIリクエスト(関連部分):
"isNotificationsPerMetricDimensionEnabled":false,
"namespace":"oci_autonomous_database",
"query":"DatabaseAvailability[1m].absent()",
"pendingDuration":"PT3M",コンソール構成:
| フィールド | 値 |
|---|---|
| メトリック・ネームスペース | oci_autonomous_database |
| メトリック名 | DatabaseAvailability |
| 間隔 | 1分 |
| 統計 | 平均 |
| トリガー・ルール |
|
| メッセージのグループ化 | メトリック・ストリーム全体で通知をグループ化 |
- 例: アラーム・ステータスの切替え
次に、1:00から1:08でアラームのステータスがFiringとOKの間で切り替わる例を示します。1:01、1:02、1:06および1:07のOKステータスに注意してください。これらの時間では、アラーム評価の結果は1分間隔の条件を満たしていましたが、3分間のトリガー遅延のため、ステータス変更は内部で保留になりました。3回の連続評価が条件を満たしたため、アラーム・ステータスは1:03および1:08でFiringに変更されました。
| 時間 | メトリック・チャートの値* | アラーム条件を満たしていますか。 | アラーム・ステータス |
|---|---|---|---|
| 1:00 | 0 |
いいえ | OK |
| 1:01 | 1 |
はい。ステータス変更は内部で待ち状態です | OK |
| 1:02 | 1 |
はい。ステータス変更は内部で待ち状態です | OK |
| 1:03 | 1 |
はい | Firing |
| 1:04 | 1 |
はい | Firing |
| 1:05 | 0 |
いいえ | OK |
| 1:06 | 1 |
はい。ステータス変更は内部で待ち状態です | OK |
| 1:07 | 1 |
はい。ステータス変更は内部で待ち状態です | OK |
| 1:08 | 1 |
はい | Firing |
*メトリック・チャートの値の場合、0はメトリックが存在することを意味し、1はメトリックが存在しないことを意味します。メトリック・チャートの例は、不在アラームの作成を参照してください。
この状況を修正するには、次のアラーム構成を更新します:
- アラーム間隔をメトリック発行の頻度以上の値にします。アラーム問合せの間隔の選択を参照してください。
- 待機時間に対応したトリガー遅延にします。アラームのトリガー遅延の定義を参照してください。
たとえば、間隔を10分に更新し、トリガー遅延を1分に更新します。
APIリクエスト(関連部分):
"isNotificationsPerMetricDimensionEnabled":false,
"namespace":"oci_autonomous_database",
"query":"DatabaseAvailability[10m].absent()",
"pendingDuration":"PT1M",コンソール構成:
| フィールド | 値 |
|---|---|
| メトリック・ネームスペース | oci_autonomous_database |
| メトリック名 | DatabaseAvailability |
| 間隔 | 10分 |
| 統計 | 平均 |
| トリガー・ルール |
|
| メッセージのグループ化 | メトリック・ストリーム全体で通知をグループ化 |
- 例: メトリックが存在し、アラームは
OK - この例では、メトリックは予想時間(5分ごと) 2:00、2:05および2:10に存在します。各時間で、アラームは過去10分間のメトリックの存在を評価します。アラームのステータスは、リストされた時間では
OKのままです。
- 例: メトリックがない、アラームは
Firing - この例では、メトリックは2:00に存在しますが、2:05および2:10には存在しません。アラーム間隔は10分であるため、アラーム条件は2:05では満たされませんでした。2:10では、アラーム条件が満たされたため、アラームは
Firingステータスに変わります(10分間隔ではゼロのメトリックが存在していました)。