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

アラートを使用すると、問題が重大になる前にその検出を開始できます。New Relicクエリ言語であるNRQLを使用すると、最も関心のあるものに焦点を当てたアラート条件を作成しカスタマイズできます。を使用して、データ内の異常な動作についての情報を更新し、それを確認する担当者に通知することで、問題の根本原因を把握し意思決定を効果的に行います。

アラート応答、メンテナンス、品質、高度な設定における最適な使用方法に関する推奨事項を使用して、アラートの範囲を改善します。アラート品質の測定および改善方法については、アラート品質管理ガイドを参照してください。

これらの推奨アクションに従って、アラート設定を改善して最大限に活用しましょう。

ヒント

最初のアラートは作成されましたか？まだの場合は、開始に必要なすべての手順についてチュートリアルシリーズをご覧ください。

アラート応答の改善

すべきこと	利点
アラートの説明名の入力	説明とタグでは、分かりやすいアラート内容を入力する必要があります。間違っているサービス、関連する環境、所有しているチーム、エンドユーザーへの影響の有無を把握するためです。より迅速に回答し、何をすべきかを決定できるようにします。
アラート条件にタグを追加	イシューとインシデントのメタデータにこれらのタグが含まれています。それらを使用して、ワークフローで柔軟なフィルターを実行したり、通知ペイロードに追加したりします。イシューには3つのタグのソースがあります。アラート条件で定義されたタグ。アラート条件の`facet/where`句の現在の値。アラートの結果が一意のエンティティに限定されている場合、違反エンティティからのタグ。インシデントがエンティティに限定されていない場合、エンティティタグは引き継がれません。これらのイベントはNRDBに保存されます。nr*テーブルの使用は、取り込みとしてカウントされないため、問題ありません。
アラート条件の分類	組織全体で、アラートカテゴリ、通知処理に対する期待、固有の宛先を定義します。たとえば、インシデントが発生する前にSlackにプロアクティブに通知する、PagerDutyに反応して進行中のインシデントを検出して通知する、またはJiraに有益な情報を提供するなどです。
コミュニケーションおよびエスカレーション方法の定義	通知手段を決定します。メール、Slack、PagerDuty、Jiraなどの通知方法があります。
担当チームの追加	このチームは、最初の通知処理を担当します。
すべてのアラート条件にランブックURLの追加	ランブックには、従うべき修復手順と、関係者およびエスカレーション先を記載する必要があります。
エンリッチメントの使用	問題に固有の追加メトリクスを提供することで、アラート通知の優先順位付けとトリアージを迅速化します。

アラートメンテナンスの改善

すべきこと	利点
ポリシーの整理	個別の送信先またはオーディエンスが通知を受信する必要がある場合は、ポリシーを作成することをお勧めします。各チームの目標に合わせて、エンティティ、サービス、テクノロジー別にグループ化することを検討してください。
すべてのアラート条件に所有チームの追加	所有チームは、アラートが引き続き適切であることを保証します。条件への変更を承認します。
アラート条件の定期的なレビューのスケジュール	アラート概要ページを使用して、作成されたインシデントを確認し、実行するアクションを決定します。条件に最終レビュー日をタグ付けすることをお勧めします。これにより、古いアラートを特定できます。
Terraformを使用したアラート作成の自動化	文書化されていない変更を防ぎ、トレーサビリティを明確にします。

アラート品質の向上

すべきこと	利点
レポートにSLIとSLOを含める	SLIとSLOの違反は必ずしもインシデントであるとは限りません。また、それを防止する手順を文書化していない限り、アラートは必要ありません。SLI/SLOでは、イベントに対応するのではなく、改善のためにチームが重点を置くべき分野を明確化することができます。
メンテナンス中のアラートをミュート	ノイズの多い通知を抑制します。
サービスのアラートを定義する際は体系的なアプローチを取る	一貫した方法でスタック全体をカバーするのに役立ちます。テクノロジー、関係チーム別などに、アラートを整理できます。
推奨決定を確認	アラートデータを毎日分析し、推奨決定と既存の決定に関するフィードバックを提供します。これにより、ノイズ低減が改善されます。
フラッピングアラートの特定と調整	このアラートは、ノイズを発生させるアラート条件設定が不適切であることを示します。システム内での長期にわたる問題を示唆している場合もありますが、これはインシデントではありません。
閾値またはウィンドウ期間を増やし、スライディングウィンドウ集計を使用	チームが何らかのアクションを取る前にアラートが自己解決されると、受信トレイが乱雑になり、ノイズが発生する可能性があります。短い寿命のスパイクを表示し、一時的なスパイクを滑らかにしたい場合は、ダッシュボードを使用します。インシデントのクローズへの影響を理解できます。
意思決定を使用	カスタムタグとメタデータを意思決定に活用します。関連するインシデントは、1つの包括的なイシューに関連付けられます。初回の開始時にはデフォルトの意思決定を有効にしておきます。数週間で、これらの意思決定の有効性を評価できるようになります。
意思決定を使用する場合、通知猶予期間を延長する	イシューに関連するインシデントが増えます。最初の通知から、より豊富で実用的なコンテキストを取得できます。猶予期間が長いほど、通知が遅くなります。
イシューフィードを定期的に確認する	Notified列をスクロールして、すべてのイシューが少なくとも1つの宛先に転送されていることを確認します。転送が不要な場合は、ノイズの可能性があるため、条件を削除することを検討してください。

アラート条件の作成と高度な設定

アラートを初めて使用する場合、またはアラート範囲を最適化する提案が必要な場合は、以下の推奨事項に注意してください。

信号を理解する

条件にファセット句が含まれている場合、すべてのアラート条件は単一の信号または複数の信号を生成します。可能な各ファセット値は、個別の信号を生成します。

NrAiSignalですべての信号をクエリできます。これにより、観測された値、考慮されたデータポイントの数、異常条件の場合、予測値と標準偏差に関する詳細を取得できます。また、New Relic時間と生データ時間（データにタイムスタンプが付いている場合）の間の時間差に関する情報も提供し、条件の作成時に最も正確な遅延設定を見つけるのに役立ちます。

エンティティの健全性の維持

当社は、信号を使用して、エンティティの健全性とアラート範囲を推測します。アラート条件の結果に1つのエンティティからのデータのみが含まれている場合、New Relicはそのエンティティの健全性に関連付け、New Relic UIのコンテキストでこれらのイベントを表示します。

ほとんどの条件では、信号の存在を維持することを推奨します。信号がない場合、New Relicが一部のエンティティの稼働ステータスをグレー（不明）に表示したり、これらのエンティティを対象外のエンティティのリストに追加したりする可能性があります。

条件のwhere句がすべてのデータを除外する場合、データは残りません。これはNew Relicの信号損失であり、どの閾値に対してもアラート条件を評価できません。つまり、NRQLクエリの結果にデータがないことを意味しますが、New Relicがデータを受信していないということではありません。通知を受信するには、信号損失の閾値を追加する必要があります。

whereセクションで最も汎用的なフィルターを使用し、selectセクションで最も具体的なフィルターを使用します。フィルター機能を使用すると、関心対象を正確に測定できます。例：

Select filter(count(*), where ErrorCode=123) from Transaction where AppName='Application1' and Environment='Production'

アラート遅延またはタイマーの持続時間

データの動作に合わせて遅延/時間を調整してみてください。不完全なデータが原因で、短い遅延が誤アラートをトリガーし、大幅な遅延により通知を受け取るまでの時間が長くなる場合があります。New Relicは、予想されるデータ量も、またそのデータがNew Relicのエンドポイントに到達するするまでの時間も把握できません。ログの荷送人と設定によっては、ログデータがバッチ処理されて、少量のログで大幅な遅延が発生することがあります。

条件閾値の設定

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

アクション	推奨事項
閾値のレベルの設定	閾値を低く設定しすぎないようにしてください。たとえば、CPUの条件の閾値を本稼働サーバーで5分間75%に設定すると、日常的にそのレベルを超え、対応できないアラートや誤検知が増加します。
設定の試行錯誤	ファイルの編集やソフトウェアの再起動は必要ないため、必要に応じて閾値のレベルを気軽に変更し、調整できます。
設定の調整	徐々に条件を調整していく。 New Relicを使用してパフォーマンスの改善に遅れを取らない程度に、閾値を絞り込みます。一定期間、パフォーマンスに悪影響を及ぼすことがわかっているものを配備する場合は、これを許容するように閾値の条件を緩和してください。
設定の無効化	必要であれば、ポリシー内のdisable any condition条件を無効化できます。これは、たとえば他のメトリクスや閾値を試しながら、そのポリシーに対する他の条件を使い続けたい場合に便利です。

New RelicのUI内の稼働ステータスインジケーターの色は、アラートの閾値を超えた際や正常状態に復帰した際に変わります。これによって、クリティカルな閾値になる前に所定の通知を受信することなく、UIで状況をモニターすることができます。インシデントの閾値には、クリティカル（赤）と警告（黄）の2つがあります。上記の提案を念頭に置いて、これらの閾値を異なる基準で定義します。

日次バッチジョブが実行されていることを確認する

バッチジョブの実行に失敗した場合に通知を受け取るアラート条件を設定できます。

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

イベントに単純なカウントクエリを設定

SELECT count(*) FROM MyBatchEvent

信号損失を設定して、24時間30分後に新しいインシデントを開きます。これは調整できますが、後で実行されるバッチジョブを許可することをお勧めします。
イベントタイマーストリーミング集計方法を使用してください。24時間ごとに1つのデータポイントしか取得できないため、タイマーを最短設定の5秒に設定することができます。

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

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

重要

ギャップフィリングを設定しても、「信号損失」のトリガーを避けられません。

イシュー作成のプリファレンスを定義

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

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

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

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

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

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

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

次のステップ

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

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