ノイズ低減のためのインテリジェントアラート

現代のアプリケーションは静かに問題を起こすことはありません。ダッシュボード、ログ、アラートで、時にはこれらすべてで同時に通知が送られます。しかし、どのようなわずかな変化でも通知を生成する場合、本当の問題は静寂ではなく、問題を覆い隠してしまうノイズです。そして、そのノイズは、チームが状況を鮮明に把握することを必要とするまさにその瞬間に、対応スピードを低下させることがよくあります。

ここで、アラート疲れが始まります。クラウドワークロード、マイクロサービス、迅速な導入に取り組んでいる DevOps チームと SRE チームでは、毎日何百ものアラートがトリガーされます。多くは重複しており、中には無関係なものもあり、実際に注意を要する問題を指摘しているアラートはほんの一握りです。その結果、何が起こるでしょうか？すべてのアラートが「重大」と叫んでいると、何も緊急ではないように感じられます。エンジニアは誤検知のトリアージに何時間も費やし、重要なシグナルが埋もれてしまう危険があります。この遅延により、平均解決時間（MTTR）が直接的に増加し、最終的には顧客の不満と企業の経済的損失につながります。

根本的な問題は、従来の閾値ベースのアラートが、このような動的な環境向けに設計されていなかったことです。ベースラインが絶えず変化すると、静的なルールは崩壊します。これに対応していくため、チームには、AI を使用してノイズを排除し、異常をリアルタイムで検出し、本当に重要なことを明らかにするインテリジェントアラートが必要です。

このブログでは、インテリジェントアラートの具体的な機能、New Relic が AI を適用してノイズを削減し異常を検出する方法、そしてそれを独自の環境で設定する方法について説明します。

インテリジェントアラートとは

本質的に、インテリジェントアラートは静的なルールや閾値よりも高度なアプローチです。従来のアラートシステムでは、CPU 使用率が 80% を超えたり、レスポンスタイムが 2 秒を超えたりするなど、固定の閾値を超えたメトリクスにフラグを立てることで機能します。このアプローチは単純ですが、現代のシステムの動的な性質を考慮していません。一瞬だけ急増したように見えても、次の瞬間には単なる通常の負荷になる場合があります。

インテリジェントアラートはプロセスに AI と機械学習を導入します。事前に定義された閾値だけに頼るのではなく、時間の経過とともにシステムの自然な動作を学習します。パターン、季節性、ワークロードの変化に適応し、本当に異常な事態が発生した場合にのみアラートがトリガーされます。この際の重要な点はアラートがトリガーされるに至った背景や経緯です。インテリジェントアラートは、「何かがおかしい」と知らせるだけでなく、予想される変動と実際の異常を区別するのに役立ちます。つまり、誤検知やノイズが減り、実際に顧客や業務運営に影響を与える可能性のある問題がより迅速に特定されることになります。つまり、インテリジェントアラートは、チームがダッシュボード上のあらゆる変化を追うのではなく、実際の問題に集中できるようにする、よりスマートで適応性の高いアプローチです。

仕組みの裏側: New Relic AIOps がアラートをどのように変革するか

インテリジェントアラートが「何を」行うかということであれば、AIOps は「どのように」行うかということです。AIOps（IT 運用のための人工知能の略）は、アラートをよりスマートにする New Relic 内のインテリジェンスレイヤーです。適応型のコンテキスト認識アラートの原理を採用し、テレメトリー信号のモニター、相関、ルーティングといったさまざまな手法に反映されます。

New Relic AIOps は、静的な閾値や 1 回限りの条件に依存せず、環境から継続的に学習するアルゴリズムを活用します。メトリクス、トレース、ログ全体のパターンを調べて、イベントがノイズなのか、異常なのか、それとも注意すべき大きな問題の一部なのかを判断します。具体的な仕組みは次のとおりです。

条件とポリシー（コア）
ユーザーは、テレメトリー信号に対するアラート条件（固定閾値または異常ルール）を定義し、それらをポリシーごとにグループ化します。これらの定義は、インシデントを生成するタイミングを指定するものです。
異常検知（動的ベースライン）
インシデントは、季節性やワークロードのパターンを考慮した動的なベースラインによってトリガーされ、動作が平常の範囲から大きく異なる場合にのみアラートが生成されます。
インシデントと相関関係
アラート条件（静的または動的）が満たされると、インシデントが生成されます。次に、AIOps は時間、エンティティ関係、メタデータに基づいて相関ロジック（組み込みまたはカスタム）を適用し、関連するインシデントを 1 つの問題にグループ化します。これによりノイズが軽減され、チームは乱発される個別のアラートに悩まされることなく実際の問題に集中できるようになります。
予測アラート
予測アラートは、履歴データを使用して短期的な値を予測し、閾値違反の可能性が高くなる前にアラートを発します。この機能は現在、プラットフォームで一般に利用可能です。
ワークフローと通知
ユーザーはワークフローを構成して、Slack、PagerDuty、ServiceNow、またはその他の送信先に問題をルーティングする方法を管理します。AIOps はこのルーティングを実行し、影響を受けるエンティティやタグなどの関連コンテキストを添付して調査をサポートします。

つまり、AIOps は、アラートの作成、相関、ルーティングを行う仕組みを提供します。しかし、このシステムの精度は、インシデントが最初にどのように生成されるかによって異なります。ほとんどのインシデントは異常な動作を追跡する状況から発生するため、ベースラインと閾値を調整する方法によってアラートの精度と有用性が直接決まります。

異常検知

New Relic AIOps の異常検知は、履歴テレメトリーから予想される値を予測し、その予想結果が大幅に逸脱した場合にインシデント作成します。このアプローチにより、柔軟性が大幅に向上し、通常の変動によるノイズが削減されますが、誤検知を回避するために慎重な調整も必要になります。

New Relic では、異常検知を微調整するためのいくつかのパラメーターを用意しています。

感度（標準偏差閾値): 感度は、データが予測ベースラインからどの程度逸脱した場合にインシデントをトリガーするかを定義します。狭い帯域（例: 1.5σ）では小さな偏差を素早く捕捉できますが、ノイズのリスクがあります。一方、広い帯域（例: 3σ）では誤検知は減りますが、検出が遅れる可能性があります。
季節性: デフォルトでは、AIOps は平日のトラフィックのピークや夜間のバッチジョブなどの定期的なサイクルを自動的に検出します。ただし、ユーザーはこの動作を無効にして、固定の季節性（時間別、日別、週別）を設定したり、完全に無効にしたりすることができます。これにより、予測可能なパターンによって不要なインシデントが生成されるのを防ぐことができます。
方向性: ユーザーは、アラートを発する条件として、増加のみ、減少のみ、または増減両方を指定できます。たとえば、レイテンシは通常、上限ルールを使用してモニターされますが、スループットでは下限ルールを使用して予期しないドロップを検出する場合があります。
閾値の期間と評価モード: 定義された時間枠内に偏差が継続する場合にのみ、インシデントが生成されます。チームは、時間枠内のすべてのデータポイントが（少なくとも）違反することを条件とすることも、単一のデータポイントが（少なくとも 1 回）違反することを許可することもできます。
複数の信号条件: FACET を使用する NRQL クエリでは、異常検知において 1 つの条件下で最大 5,000 個の信号をモニターできます。各信号は個別に評価されますが、同じ閾値ルールが信号全体に一貫して適用されます。

たとえば、キャンペーン中にバーストトラフィックを処理するサービスは、次の例に示すように、 3σ 、上限のみ、少なくともモードに調整できます。これにより、持続的な異常を検出しながらも、一時的な急増による誤検知を防ぐことができます。

微調整を行ったとしても、下流の依存関係によって単一の障害に対して複数のインシデントが生成され、ノイズが発生する可能性があります。ここで相関関係が重要になります。

アラートの相関関係

異常検知を慎重に調整したとしても、複雑なシステムでは大量の有効なインシデントが生成される可能性があります。チームの過負荷を防ぐために、New Relic AIOps は相関関係を適用し、関連するインシデントを実用的な問題にまとめます。

実際には、相関関係はいくつかのコア戦略を通じて機能します。

時間的近接性: 同じ時間枠内で発生したインシデントはグループ化され、多数の関連するアラートが個別に報告されるのを防ぎます。
エンティティとメタデータの分析: 各インシデントには、サービス名、環境、デプロイメントマーカーなどのメタデータが含まれます。相関ロジックは、これらの属性を共有するインシデントをリンクします。たとえば、キャッシュ層に障害が発生すると、下流の何十ものサービスでレイテンシやエラーのアラートが発生する可能性があります。AIOps は、それぞれに個別のインシデントを開くのではなく、それらを 1 つのキャッシュ関連の問題にグループ化します。
判断フレームワーク: 相関関係は判断を通じて管理します。New Relic は一般的なケースに対する組み込みの判断を提供しており、チームはアーキテクチャに合わせてカスタムの判断を定義できます。たとえば、マイクロサービスのグループからのインシデントは、同時に不具合が起こった場合は常に 1 つの問題として扱うことができます。
正規化と抑制: 重複またはほぼ同一と判断できるインシデントは自動的に折りたたまれ、重複するモニターやツールからのノイズが削減されます。

これらの戦略により、チームは数十の関連アラートを精査する代わりに、問題単位でインシデントに対応できるようになります。判断を使用して相関ロジックを構成する方法については、ドキュメントで説明されています。また、アラート相関を使用して根本原因を探求し、ノイズを削減する方法については、ブログを参照してください。

予測アラート

予測アラートは、アラート発生を検出ベースから予測ベースに移行することでインテリジェントアラートを拡張します。New Relic は、データがラインを越えたときに発動するのではなく、テレメトリー信号に予測を適用し、将来の予測期間に値が閾値を超えると予測されるときにインシデントを生成します。次の画像は、New Relic での予測アラートの設定を示しています。

この機能は、データに応じて季節モデルまたは非季節モデルを自動的に選択する Holt-Winters アルゴリズム（指数平滑化）を使用します。季節モデルは、少なくとも 3 サイクルの履歴がある場合に、毎日のトラフィックの急増や毎週のワークロードパターンなどの繰り返しサイクルを処理します。非季節性モデルは、繰り返しパターンが存在しない場合に傾向とレベルを捉えます。アラート条件で定義された予測期間を使用して、最大 360 個の将来のデータポイントを予測できます。

このアプローチには、ノイズ低減に関して 2 つの大きな利点があります。

実際のリスクを予測する: CPU 使用率やスループットなどのメトリクスを予測することで、制限を超える前に早期に警告を発し、チームに対応する時間を確保できます。
予想されるピーク時の誤検知を抑制: 季節的な挙動を学習することにより、予測アラートは、毎日のトラフィックの急増といった既知の変動時にトリガーされることを回避しながらも、パターンを破る異常を明らかにします。

たとえば、ストリーミングサービスでは、夜間は一貫してトラフィックが増加することがあります。そして、静的閾値や異常検知が毎晩発動することがあります。予測アラートを使用すると、システムはパターンを認識し、トラフィックが安全な許容範囲を超えると予測される場合にのみアラートを生成します。

予測アラートは、予測と異常検知および相関関係を組み合わせることで、アラートの精度、コンテキスト、プロアクティブな対応を保証し、チームは確認したインシデントが有意義かつ実用的なものであると確信できるようになります。予測アラートを有効にして設定する方法については、ドキュメントをご覧ください。

影響の測定: ノイズ低減とアラート精度の定量化

インテリジェントアラートの価値は、それがどのように機能するかだけでなく、それがもたらす結果にもあります。どのチームもアラートポリシーを導入していますが、測定を行わないと、それらのポリシーによってノイズが削減されているのか、それとも単にアラートのレイヤーが追加されているだけなのかを知ることは困難です。異常検知、相関、予測アラートの影響を測定することで、次のような重要な質問に答えることができます。

より少ない、より意味のあるアラートを受信していますか？
エンジニアが適切なコンテキストを把握できるようになり、インシデントの解決が迅速化していますか？
ノイズは本当に減少していますか？それとも、別のチャネルにシフトしているだけですか？

New Relic は、これらの結果を定量化するために必要なテレメトリーを提供します。インシデントおよび問題データを使用することで、チームは次のものを追跡できます。

インシデントの量と優先度の組み合わせ

シンプルですが強力な指標は、全体的なインシデントが減少傾向にあるかどうか、および重大度の組み合わせがより健全になっているかどうか（たとえば、重大度の高いインシデントが減少する傾向にあるかどうか）です。これを次の NRQL で視覚化できます。

SELECT count(*) 
FROM NrAiIncident 
SINCE 30 days ago 
TIMESERIES 1 day 
FACET priority

インシデント期間（MTTR の代替）

解決までの時間が短いということは、アラートがより明確になり、相関性が高くなっていることを意味します。これは、次のようにインシデントの開始時間と終了時間から直接測定できます。

SELECT average(closeTime - openTime)/1000/60 AS 'Incident duration (min)' 
FROM NrAiIncident 
WHERE event = 'close' 
SINCE 30 days ago

問題レベルの洞察
生のインシデントメトリクス以外にも、New Relic の問題フィードでは、アラートがどのように相関し、優先順位が付けられているかが表示されます。各項目の内容は次のとおりです。
- 関連するインシデントのタイムライン。
- 影響を受けるエンティティとその関係のマップ。
- 最も重大度の高いインシデントから自動的に導出される優先度。
- ノイズパターンを見つけるための、タグ、相関状態、または優先度によるフィルタリングオプション。
- 問題解決後にイベント、メトリクス、メタデータを収集する事後分析レポート。

多くのチームは、インシデントの傾向に関する NRQL ダッシュボードを構築し、相関ビューのために問題フィードを利用して、生のデータと概要の両方の視点を提供しています。詳細なガイダンスについては、問題とインシデントの管理と対応に関するドキュメントを参照してください。

最後に

静的な閾値と 1 回限りの条件は、もはや現代のシステムの複雑さに適合していません。異常検知、相関、予測分析を活用した New Relic のインテリジェントアラート機能は、ノイズの多いアラートを追跡することから重要なシグナルに対応することに重点を移します。

異常検知により、チームは環境に合わせて調整された正確なアラートを受信できます。相関関係により、重複するインシデントの連鎖を遮断し、根本原因に焦点を当てることができます。予測アラートにより、問題が発生する前に予測できます。また、インシデントの傾向と問題の洞察を通じて影響を測定することで、アラート戦略の価値を長期にわたって証明できます。

その結果、アラートが少なくなるだけでなく、コンテキストが豊富で正確かつ実用的な、より優れたアラートが実現します。このように、インテリジェントアラートは、エンジニアリングチームが問題を事前に把握し、大規模なシステムの信頼性を維持するのに役立ちます。