冗長なアラートは、重大なインシデントをノイズの中に隠します。アラートの品質はチームがインシデントにどれだけうまく対応できるかにつながるため、既存のアラートを評価することは優先順位付け戦略の重要な部分です。ノイズが多すぎると、ビジネスへの影響がほとんどまたはまったくない優先度の低いインシデントでチームが疲労する危険があります。ただし、アラートに失敗したインシデントは、顧客エクスペリエンスに影響を与える機能停止につながります。
目的
このチュートリアルでは、すでにアクティブなアラートがあることを前提としています。アラートの品質管理に関するいくつかの推奨事項を提供し、新しいアラートを作成するためのいくつかの NRQL クエリを提供します。あなたはするであろう：
- アラート品質管理 (AQM) ダッシュボードをインストールする
- 良いアラートと悪いアラートを区別する
- アラートの作成に推奨される NRQL 文字列を確認してください。
AQMダッシュボードのインストール
AQM は迷惑インシデントの数を減らすことに重点を置いているため、チームは次のことに集中できます。 真のビジネスインパクトをもたらします。 次の場合、AQM の候補者として適しています。
- アラートの数が多すぎます。
- 長時間開いたままのアラートがある。
- モニタリングツールが発見する前に、お客様が問題を発見する。
まず、クイックスタートから AQM ダッシュボードをインストールします。
- Alert Quality Management のインスタント オブザーバビリティ ページに移動します。
- [今すぐインストール]ボタンをクリックします。
- プロンプトに従って、ダッシュボードをインストールするアカウントを選択します。
- ダッシュボードを表示します。
AQM ダッシュボードを少なくとも 2 週間使用することをお勧めします。その間、AQM ダッシュボードは、チームがすべてのアラートとどのようにやり取りするかに関するデータを収集します。
原則として、次の種類のアラートを削除することをお勧めします。
- 累積継続時間が数千分以上の「常時稼働」インシデントを生成します。
- インシデントの 30% 以上が 5 分未満で開かれている場合。
- 平均成約時間が 30 分を超えている。
- 週に 350 以上のインシデントを作成します。
ピーク時の需要に合わせて新しいアラートを作成する
既存のポリシーを見直しながら、ピーク時の需要に合わせて調整された新しいアラートを作成することが必要になる場合があります。適切なアラートを作成できるかどうかは、設定の具体性によって決まります。2 つのアラートは、同じアラート条件クエリを共有できます。次に例を示します。
SELECT average(`apm.service.memory.heap.used`) FROM Metric WHERE appName = 'Inventory Service'クエリ自体は強力なアラート ポリシーですが、このアラートをどのように構成すると冗長性やノイズが生じる可能性があります。不正なアラートは、ウィンドウ期間が短すぎる、しきい値が低い、または遅延やベースラインがない可能性があります。さらに、比較的新しいデータ ソースにアラート条件を付加すると、異常な動作を検出するのに十分な履歴がないため、問題が発生する可能性があります。
新しいアラートを作成する準備ができている場合は、試合当日に使用できる推奨クエリをいくつか示します。