アラームのトラブルシューティング
トラブルシューティング情報を使用して、モニタリングでのアラームの操作中に発生する可能性のある一般的な問題を特定し、対処します。
トラブルシューティングの前に、アラームの評価方法を理解していることを確認してください。「アラーム評価の図」を参照してください。
アラームが発火しない
警報は発砲の条件を満たしたが、発砲しなかった。たとえば、コンピュート・インスタンスが停止したとします。
原因: 長いトリガー遅延
トリガー遅延期間中にアラーム式が連続した分間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分間のトリガー遅延期間中は継続しないため、アラームは起動しません。
アラームのメトリック・チャートを表示するには、その履歴を取得します。
アラームの評価方法の詳細は、「アラーム評価の図」を参照してください。
Remedy: トリガーの遅延を短縮
トリガー遅延が長すぎて、しきい値を超えた直後にアラームを起動する場合は、より短いトリガー遅延を使用するようにアラームを更新します。たとえば、トリガー遅延を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まで起動し続けます。
アラームのメトリック・チャートを表示するには、その履歴を取得します。
アラームの評価方法の詳細は、「アラーム評価の図」を参照してください。
処置: 間隔を増やす
アラームを起動する場合は、アラーム間隔をメトリックの排出頻度と同じかそれより長くします。たとえば、StoredBytesメトリックでは、アラームを3:01に起動し、前の例の4:00まで起動し続ける場合は、アラーム間隔を少なくとも1時間に更新します。アラーム問合せの間隔の選択およびMonitoring Query Language (MQL)リファレンスを参照してください。
原因: ディメンションが正しくありません
リソースがディメンションを使用してフィルタで除外されたため、リソースがアラームで定義された条件を満たしたときに、アラーム式がtrueと評価されませんでした。
たとえば、可用性ドメイン1に対してディメンションが選択されたアラームについて考えてみます。この条件を満たすリソースは、可用性ドメイン2にあります。アラーム評価では、指定されたディメンションに一致するリソースのみが考慮されます。
処置: ディメンションの更新
ディメンションを削除するか、リソースを含めるように更新してください。アラーム問合せのディメンションの選択を参照してください。
原因: 誤った問合せ
一般的な例:
CpuUtilizationを選択する場合は、アラーム問合せでメトリックMemoryUtilizationを指定できます。- アラーム問合せでは、かわりにアラームで間隔(
sum())のデータ・ポイントの合計を監視する場合に、統計mean()を指定できます。
アラームの問合せを確認するには、その詳細を取得します。
問合せ要素の詳細は、Monitoring Query Language (MQL)リファレンスを参照してください。アラームの評価方法の詳細は、「アラーム評価の図」を参照してください。
処置: 問合せの更新
原因: アラームは無効です
処置: アラームを有効にします。
アラームが通知を送信しない
アラームが起動しても、通知は送信されません。
原因: アラームまたは寸法が抑制されています
処置: 抑制の削除
「単一のアラームからの抑制の削除」および「複数のアラームからの抑制の削除」を参照してください。
原因: サブスクリプションが構成済トピックの一部ではありません
たとえば、受信ボックスにアラーム・メッセージが表示されないとします。アラームに指定されたトピックには、目的の電子メール・アドレスの電子メール・サブスクリプションがない可能性があります。
トピックに予想されるサブスクリプションが含まれているかどうかを確認するには、トピックの詳細の取得を参照してください。
Remedy: サブスクリプションを含めるためのトピックの更新
サブスクリプションの作成に関する項を参照してください。
アラームを更新して、新しいトピックとサブスクリプション、または必要なサブスクリプションを含む既存のトピックを参照することもできます。アラームの通知宛先としてのトピックの選択を参照してください。
アラームが通知を多すぎます
アラームが起動すると、予想よりも多くの通知が送信されます。
原因: 繰返し通知が使用可能です
アラームは、アラームが中断せずに起動し続けるときにアラーム通知を繰り返すように構成されます。
Remedy: 繰返し通知の無効化
原因: 分割通知が使用可能です
アラームは、起動するメトリック・ストリームごとに通知を送信するように構成されます。たとえば、50個のメトリック・ストリームが起動すると、アラームは50個の通知を送信します。これは分割通知の動作です。シナリオ: メトリック・ストリーム別のメッセージの分割を参照してください。
たとえば、次のイメージは、2つのメトリック・ストリームがしきい値1:30を超え、アラームが起動する原因となったアラーム・メトリック・チャートを示しています。
メトリック値が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分 |
| 統計 | 平均 |
| トリガー・ルール |
|
| メッセージ・グループ化 | メトリック・ストリーム全体で通知をグループ化 |
- 例: アラーム・ステータスの切替え
次に、Firingから1:00から1:08でアラームのステータス値がOKと1:08の間で切り替える例を示します。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分間隔ではゼロのメトリックが存在していました)。