アラートのベストプラクティス

次の推奨事項を実装してアラートのカバレッジを改善し、アラート設定を最大限に活用します。

また、アラートの根本原因の発見に関するこのビデオ（5分1秒）もご覧ください。

以下のベストプラクティスをお読みください。

• ポリシー
• 通知チャネル
• インシデントプリファレンス
• 閾値と違反
• ミュートルール

推奨アラート

アラートを初めて使用する場合、またはアラートカバレッジを最適化する提案が必要な場合は、推奨アラート条件を使用します。

ポリシーを整理する

ポリシーは、同様の条件のコンテナです。

アラートを初めてご利用になる場合は、ポリシーの作成、編集、検索方法を習得します。

可能な場合は、ポリシーの範囲を単一のエンティティに整理します。ポリシーを重要なチーム、またはインシデント発生時に通知する必要のあるチームに割り当てます。こうすることで、ポリシーを一元化し、集中的に管理します。

チームが同じエンティティタイプの複数のグループを監視している場合は、サーバーなどのエンティティクラスタを1つのポリシーにまとめます。この方法では、複数のポリシーを一度にナビゲートするのではなく、1つのポリシーからチームに通知できます。

アラートを使用して、すべてのエンティティを監視できます。自分自身をポリシーに割り当てる際には、自分のロールと優先事項を考慮してください。

たとえば、

• ソフトウェア開発者はウェブページのレスポンスタイムやページロード時の JavaScript エラーなど、フロントエンドとバックエンド両方のパフォーマンスに対して通知が必要かもしれません。
• 運用担当者はサーバーのメモリやロードアベレージなど、バックエンドのパフォーマンス悪化時の通知が必要かもしれません。
• プロダクト所有者（オーナー）は、エンドユーザーのApdexスコア改善やダッシュボードがモニターするセールスの増加といった、ポジティブなフロントエンドパフォーマンスに関する通知を必要とするかもしれません。

条件の閾値と違反を設定する

有意義な閾値レベルを設定して、ビジネス向けにアラートを最適化します。以下は、いくつかの状況を想定したガイドラインです。

当社の大半の製品において（インフラストラクチャを除く）、ユーザーインタフェース内の稼働ステータスインジケータのカラーコードは、アラートの閾値を超えた際、または正常状態に戻った際に変わります。これによって、クリティカルの閾値を超える前に所定の通知を受信することなく、当社のUIで状況をモニターすることができます。

違反の閾値には、クリティカル（赤）と警告（黄）の2つがあります。上の提案を念頭に置いて、これらの閾値を異なる基準で定義し ます。

信号がない場合に何が起こるかを決定する

信号の損失は、New Relicがデータの受信をしばらく停止すると発生します。技術的には、データが時系列で最後に受信されてからかなりの時間が経過した後に、信号の損失を検出します。信号の損失は、違反をトリガーまたは解決するために使用でき、これを使用してアラートを設定できます。

信号損失の設定は、UIの状態によって、またはNerdGraph APIを使用して信号損失を設定できます。

アラート条件を設定して、毎日のバッチジョブが実行されるようにする

バッチジョブの一部としてNew Relicにイベントを送信していると仮定すると、バッチジョブの実行に失敗した場合に通知するアラート条件を設定できます。

1. イベントに単純なカウントクエリを設定します（SELECT count(*) FROM MyBatchEvent）
2. 信号損失を設定して、24時間30分後に新しい違反を開きます（調整はできますが、バッチジョブの実行を遅らせることをお勧めします）
3. イベントタイマーストリーミング集計方法を使用してください。24時間ごとに1つのデータポイントしか取得できないため、タイマーを最短設定の5秒に設定することができます。

信号がない場合にnull値以外を使用する

デフォルトでは、データ信号のギャップはnull値で埋められます。これらのデータギャップに基づいて条件を作成する必要がある場合は、カスタム値または最後に認識された値でギャップを埋められます。この設定は、UIで条件ごとに設定するか、NerdGraphを介してギャップの充填値を設定できます

インシデントプリファレンスを定義する

インシデント通知を受け取るタイミングを決定し、インシデントが発生したときに対応できるようにします。

アラートを初めて使用する場合は、インシデントプリファレンスのオプションの詳細を確認してください。

デフォルトのインシデントプリファレンス設定では、ポリシー内のすべての条件を1つのインシデントに組み合わせます。受信するインシデントおよびインシデント通知の数を増減するには、デフォルトのインシデントプリファレンス設定を変更します。

組織内の各チームには、異なるニーズがあります。インシデントプリファレンスを決定する際に、次の2つの重要な 質問をチームに確認してください。

• 問題が起きるたびに、通知を受けたいですか？
• 同様の通知をすべてまとめて、一度に通知されるようにしますか？

ポリシーとその条件の範囲が広い場合（複数のエンティティのパフォーマンスを管理する場合など）は、受信するインシデントの数を増やします。2つのインシデントは必ずしも相互に関係しないため、さらに通知が必要になります。

ポリシーとその条件に重点的な範囲がある場合（1つのエンティティのパフォーマンスの管理など）は、デフォルトのインシデントプリファレンスを選択します。2つのインシデントが相互に関係している場合、またはチームがすでに通知を受け、既存の問題を修正している場合は、通知は少なくなります。

通知チャネルのベストプラクティスを使用して、インシデント通知の取得方法を決定します。

通知チャネルを選択する

通知を最も有益なチャネルとポリシーに調整すると、アラート疲れを回避すると共に、適切なスタッフがインシデントを受け取り、体系的なやり方で対処できます。

アラートを初めて使用する場合は、通知チャネルの設定方法をご覧ください。

インシデントが発生した際に、最新情報を把握または問題を解決する必要があるチームおよび個人に通知します。

最新情報を確認するには、メールなど控えめな通知チャネルを選択します。

重要な通知やインシデントの応答には、PagerDutyまたはSlackなど、より直接的な通知チャネルを選択してください。

遅延が発生した場合の迅速な通知については、メールに依存しないでください。

ミュートルールを理解する

メンテナンスまたは計画的なダウンタイムなどのルーチンイベント中にアラートをミュートします。

また、必要に応じて、ポリシー、特定のエンティティ、条件をサイレントに設定することもできます。インシデントはまだ開くことができますが、通知はされません。

アラートを初めて使用する場合は、ミュートルールの作成と管理方法をご覧ください。

次のステップ

アラートの使用方法に関する詳細をご希望の場合：

• APIについて詳しく知る。
• 最小/最大限度および規則に関する技術的な詳細を読みます。
• 信号損失およびギャップの充填設定を使用するタイミングについての詳細をお読みください。