誤ったアラート(false alerts)に関するトラブルシューティングフレームワーク

原文: Alerts Troubleshooting Framework False Alerts

トラブルシューティングフレームワークの翻訳済みリスト

このガイドでは、アラート違反に関して、偽陰性（違反が発生するべきなのに発生しなかった）と偽陽性（違反が発生するべきではなかったのに発生した）の両方をトラブルシューティングする方法を順を追って説明します。ここでは主にNRQLとNRQL中心のアラート条件（Infrastructure MetricsはNRQL中心の例）に焦点を当てていますが、データを表示するために実行するクエリを考え出すことができれば、どのようなタイプのアラート条件にも使用することができます。このガイドに従っても問題が解決しない場合は、New Relic Global Technical Support に連絡してください。その際、このガイドに従ったことを必ず伝えてください。そうすることですでに確認済みのトラブルシューティングを避けることができます。

まず、以下のよくあるお問い合わせの例にないかご確認ください。

• New Relic AlertsにはCriticalとWarningの2種類の閾値がありますが、違反（violation）の通知を送信するのはCriticalのみです。
• アラート条件画面のプレビュー機能で閾値を超えたが表示されますが、このプレビュー画面にはLoss of signalをサポートしていないなどの既知の制約および不具合があります。参考程度にとどめ、違反があったかどうかの確認は以下の手順に従ってください。
• Metrics Streamではない従来のCloud Integrationではデータ到達の遅延があります。NRQLアラート条件では遅延したデータはすべてNULL値として扱われます。offsetを少なくとも15分以上に設定するか、Infrastructureアラート条件のご利用を検討ください。
• Infrastructureアラート条件のUIでは、直近に存在しているデータにのみフィルタ条件などを設定できます。直近では存在していない条件を設定シたい場合はAPIをご利用ください。
• NRQLアラート条件ではNRQLクエリの結果が0の場合は、0という値ではなくNULL値として評価されます。
• NRQLアラート条件では、NRQLとしては実行できても、アラート条件としては利用できないNRQLの機能があります。ドキュメントにも記載がありますが、ご不明な点は　具体的に利用したいNRQLを添えてお問い合わせください。

以上の例になかった場合、次の手順に従って調査ください。

1. インシデントへのリンク（偽陽性の場合）、またはアラート条件へのリンクと、メトリクスが閾値を超えたときのタイムウィンドウ、さらにファセット情報（どのアプリ、どのサーバー、など）が必要です。
   1. インシデントは、違反が起こった時間と、どのアラート条件が原因かを示します。偽陰性の場合は、その条件へのリンクと、違反が発生するはずだった比較的短い時間枠（1～2時間）の心当たりがすでにあるはずです。
2. データを表示するクエリを作成し、集計ウィンドウ(aggregation window)にTIMESERIESを設定できるようにスコープを設定します（例：1分の集計ウィンドウであればTIMESERIES 1 minute）。システムは最大で366個のバケットしか表示できないので、時間ウィンドウを設定する際にはそれを考慮してください。
   1. ヒント: リンクを共有して誰もが自分の見ているデータを見ることができるように、相対時間（SINCE ~ ago UNTIL ~ ago）ではなくエポックタイムスタンプ（もしくは絶対時刻）を使用してください。
3. データが違反(violation)を開くべきかそうでないかを評価します。データが、違反が正しくないこと、または違反がないことが正しくないことを明確に示している場合は、このフレームワークを終了し、New Relicサポートに連絡して、できるだけ詳細を知らせるようにします。
   1. at least X minutesという設定は閾値が違反を開くために X 分間の連続した違反データを必要とする一方で、at least once in X minutes は、閾値を超えた1 つの集約されたデータポイントのみで違反を発生させます。
   2. sum of … の閾値については、NRQL クエリを使用してこれを表示する方法がないため、手動で合計を計算する必要があります。合計は X 分単位で行われ、ここでXはしきい値の時間ウィンドウです。
4. 偽陰性または違反がクローズしない場合: ステップ 2 で使用したクエリを使用して、NULL 値について結果を分析します。以下の記事では、クエリの操作順序を紹介していますので、いつこれらの問題が発生するかを知ることができます。 Relic Solution: How Can I Figure Out When To Use Gap Filling and Loss of Signal?
   1. 計画外のNULL値は、偽陰性の原因となったり、違反が時間通りに終了しない原因となったりします。データの形状に応じて、Loss of Signal や (場合によっては) Gap Filling の使用を検討してください。
   2. 偽陰性の原因がNULL値である場合、Loss of SignalまたはGap Fillingの使用を検討する。
   3. NULL値が偽陽性の原因になることはありません。

このガイドに従っても問題が解決しない場合は、New Relic Global Technical Support に連絡してください。その際、このガイドに従ったことを必ず伝えてください。そうすることで、すでに確認済みのトラブルシューティングを避けることができます。