アラート定義のガイダンス

システムの問題を早期に検知するためにはアラートの設定は必要不可欠です。New RelicのNRQLアラートは、多様なユースケースに対応できるようにフレキシブルにアラートの条件が指定できる様になっています。
一方、監視対象データの特性や収集方法によって、どういった条件でアラートを定義すべきかは変わってくるため、頭を抱えられている人も多いのではないでしょうか。本ブログでは、アラート設定の際のガイドとなるよう、設定項目や設定値を選択する際の考慮点やNew Relicのアラートの挙動について説明します。

対象データの特徴と考慮点

対象となるデータの特性やデータの収集方法によってアラート設定時に考慮すべき点は変わってきます。どの様なことを考慮すべきか以下に記します。

異常と判断できる明確な基準があるか？

データが異常と判断できる明確な境界値がある場合は、静的な閾値による異常検知が適しています。一方で、新しいシステムで明確な値が不透明な場合や絶対値ではなく周期的な異常を検知したい場合は、ベースラインからの逸脱による異常検知が適しています。閾値かベースラインのいずれで判定するかは、Threshold Typeにて設定します。

データを評価するのに適した期間は？

デフォルトでは1分間のデータを集約してアラート条件に合致するかを評価します。データの発生頻度や変化の仕方によってはより長い（短い）期間のデータを集約して評価したいケースもあるでしょう。その場合は、Window durationにてデータの集約期間を調整します。

上下（山谷）の変動が激しいデータか？

CPU利用率など短期間で上下の変動が激しい場合、短期間のデータを集約して評価するとノイズになり、問題の検知に影響が出る場合があります。この場合は、評価対象データを集約する期間を長く取り、かつ評価期間をオーバーラップさせながらスライドさせていくアプローチ（Sliding window）が有効です。

欠損データはどう扱うか？

監視対象の問題やデータ転送の際のネットワークの問題などにより、データに欠損が生じるケースがあります。この欠損値をどのように扱うか次第でデータの評価結果が変わってきますので、監視対象データの性質に基づいて適切に欠損データの取り扱い（Gap filling）を決める必要があります。

コンスタントにデータが到着するか？それとも不均一か？

コンスタントにデータが到着するケースと、離散的にデータが到着するケースでは、対象データを集約・評価するタイミングが変わってきます。例えば、APMやAWS MetricStreamのデータは高いスループットでデータが到着するので前者となりますが、API Polling方法で取得するCloud Integrationやバッチ的に送られてくるデータは後者となります。監視対象データの到着の仕方を踏まえて、ストリーミング方法（Streaming Method）を選択します。

Threshold Type

前述の通り、違反を判定する方法としては、事前に設定した静的な閾値の超過によるものと、過去の振る舞いに基づいて算出されたベースラインからの逸脱によるもの、の2点があり、それぞれStatic Threshold Type、Baseline Threshold Typeになります。

“Static” Threshold Type

予め決めた”静的”な閾値の超過有無によって、データのバイオレーションを判定します。一定期間連続して超過しているか、もしくは期間内に一度でも超過した場合にバイオレーションと判定することができます。

“Baseline” Threshold Type

過去のデータから学習したデータに基づいて予測された正常範囲からの逸脱有無によって、データのバイオレーションを判定します。Staticと同様に期間内に継続して超過しているか、1度でも超過した場合にアラートあげるかを選択できます。また、逸脱と判断する際の感度も調節できます。
利用に適しているケース：
・値の上下ではなく、周期性の異常を判定したい場合 (7日以内)
・新システムなど、静的な閾値を予め決めるほどの材料がない場合

Threshold Typeの詳細は、オンラインドキュメントを参照してください。

Window duration

評価対象のデータを集約する期間を定義するものです。1minであれば1min範囲内のデータが集約対象、2minであれば2min範囲内のデータを集約します。

なお、Window durationを大きくした場合、集約する期間が広がるため、アラート通知のタイミングもそれに従います。つまり、Window durationが2minであれば、最短2min間隔となります。Window durationを広げつつ、アラート通知タイミングを細かくしたい場合は、Sliding windowを利用して評価範囲をオーバーラップさせます。

Sliding window

データの上下変動が激しく（揮発性が高く）、短期間での集約ではノイズになる場合に、評価対象データの集約期間（WIndow duration）を広げつつ、短期間（Sliding window）でスライドさせることで平滑化したデータで評価を行うことができます。
適しているデータ：
データの山谷が激しく、かつ短期間の集約では適切に評価することができないデータ
・CPU%
・スループット
・不安定、頻繁でない、または一貫性のないシグナル

Sliding windowの詳細は、オンラインドキュメントを参照ください。

Gap filling

到着したデータに欠損が存在する場合に、欠損データをどう扱って評価するかを定義します。以下の設定が可能です。

欠損のまま（None）

欠損データは閾値の違反に該当しないので、欠損がある場合に違反のアクションを起こしたくない場合に適しています。欠損データはそのまま欠損データ（Null）として扱われます。

固定値（Custom static value）

妥当な固定値はケースによる。欠損した場合に違反の方に倒す、安全サイドに倒す、もしくは対象メトリクスに応じた値など設定できます。

前出の値（Last known value）

最長2時間前出の値を保持し、それを適用します。値の変化が予測可能なもので、短時間で大きく変化しないもの。例えばディスク使用率など。

Gap fillingの詳細は、オンラインドキュメントを参照ください。

Streaming method

Streaming methodは、データの集約方法を定義するものです。本ブログ執筆時点では、Event flow, Event timer, Cadenceの3種類がありますが、Cadenceは古い手法のため本ブログでは説明を割愛します。

Event Flow

指定した遅延（Delay）の時間経過し、後続のウィンドウのデータが到着したタイミングで評価対象期間（Window duration）のデータを集約します。それを超えて到着したデータは評価対象外となります。
適しているデータ：
・スループットが高く、コンスタントに到着するデータ
・APMエージェントデータ
・Infrastructureデータ
・サードパーティから頻繁かつ確実に送られてくるあらゆるデータ
・AWS Metric Streamから来るほとんどのAWS Cloudwatch （S3ボリュームデータなど不定期なものは除く）

Event Timer

データ到着のたびにタイマーがリセットされ、タイマーが切れるまで到着した評価対象期間内のデータを集約。タイマーが切れた後の到着データは評価対象外。データ到着の遅れに対応できる反面アラート通知はその分遅れる。
適しているデータ：
・発生や到着にムラがあるデータ
・New Relic が生成したUsage Data 
・Pollingで取得しているCloud Integrationsのデータ（GCPやAzure、AWS API Polling）
・いつデータが送られてくるかわからないが、バッチでデータが送られてくる場合
・NRQLのフィルタ条件によってはデータ件数が0 (NULL) になる場合（Synthetics、Logなど）

Streaming methodの詳細は、オンラインドキュメントをください。

まとめ

このブログでは、アラート設定時の考慮点やNew Relicのアラートの振る舞いについて説明しました。データの特性を理解して適したアラート設定をすることは、問題を確実に検知するためには重要です。このブログを参考にアラート設定を進めてみてください。

なお、アラート設定の挙動は本ブログ執筆時点のもの記載しています。最新の仕様に関しては公式ドキュメントをご確認ください。

リファレンス

• NRQLアラート条件に追加された新しい集計方法とどれを選ぶべきかの指針
• LogやSyntheticの監視のベストプラクティス
• Relic Solution: How Can I Figure Out Which Aggregation Method To Use?
• Streaming alerts: key terms and concepts