これは実装ガイドの 4 番目で最後の部分です。
前の実装段階では、スタックを計測し、New Relic プラットフォームに精通しました。今こそ、問題を早期に通知し、最悪のシナリオを回避するのに役立つプロアクティブなソリューションについて考える良い機会です。この段階では、次のような、この分野におけるいくつかの重要なソリューションについて学習します。
- アラート
- 合成モニター
- エラーの受信トレイ
アラート戦略について考える
新しい遺物 UI では、アカウント内のアラート条件の状態を表示できます。
アラートを設定する前に、アラートの目標と戦略について検討することをお勧めします。組織が大きくなればなるほど、その重要性は増します。
アラート戦略がなく、1 回限りの問題を解決するためにアラートを迅速かつ無計画に設定すると、アラート通知が大量に送信される可能性があります。そうなると、チームはアラート疲労に悩まされ、アラートを無視し始めます。アラート戦略について時間をかけて検討することで、組織の成長や New Relic へのデータの追加に合わせて拡張できるスマートな方法でアラートを設定できるようになります。
アラート通知メッセージをユーザーにルーティングするには、 ワークフロー (インシデントが通知を作成する方法とどのデータが送信されるかのルール) と 通知先 (通知の送信先) を使用します。組織全体で一貫性があり、保守可能となるようにこれらをどのように設定するかを計画することをお勧めします。Slack や PagerDuty などの別のサービスと統合している場合は、長期的にこれらの統合をどのように制御および維持するかを検討してください。
アラート疲労を回避することは、アラート戦略の中心的な目標である必要があります。適用できる戦略の 1 つは、ビジネスへの影響の重大度によってアラートを分類することです。より重大または重大な問題は、最も大きな音を立てて、対応できる立場にある利害関係者に配信する必要があります。一方、ビジネスへの影響が少ないものは、「影響範囲」を小さくして、より静かに配信する必要があります。
たとえば、組織全体に適用できるいくつかのアラート重大度プロトコルを定義し、ワークフローを使用してアラートが正しくルーティングされるようにすることを検討できます。チームは重大度ごとにわずかに異なるルーティングを適用する場合がありますが、共通言語を導入し、組織全体の影響を理解することで、アラートの取り組みが拡大するにつれて利益を得ることができます。
重大度 | 影響 | 観客 | インテグレーション |
|---|---|---|---|
重大度 1 / P1 | 致命的 | オンコール SRE、C レベル マネージャー / インシデント コマンダー /、関連するプロダクト オーナーおよび DevOps チーム | Pagerduty、Slack、メール |
重大度 2 / P2 | 高 | 関連するプロダクト オーナーと DevOps チーム | Pagerduty、Slack |
重大度 3 / P3 | ミディアム | DevOps チーム | スラック |
サンドボックス / 重大度 4 / P4 | 低 / なし | DevOps チーム | サンドボックス Slack |
組織がアラート セキュリティ プロトコルを定義する方法の例。
アラートの品質を長期的に確保するために、アラート条件の定期的なレビューを計画して、アラート疲労に対処し、アラートが正しく分類されていることを確認することを検討してください。これには、アラートが発生する頻度と、応答時間と解決時間の分析が含まれます。
アラートを開始する方法:
- アラート条件と通知先の設定をすぐに開始するには 、最初のアラートの作成に関するドキュメントを参照してください。
- アラート戦略の計画と実装に関する詳細なガイダンスについては、 アラート品質管理ガイドを参照してください。
アラートの自動化に関するドキュメントを次に示します。
合成モニタリング
当社の合成モニタリングは、Web サイト、重要なビジネス トランザクション、および API エンドポイントを監視するための自動化されたスクリプト可能なツールのスイートを提供します。これらのツールを使用すると、単純なモニターを実行して稼働時間と基本機能を確認したり、実際のユーザーのアクションとワークフローを模倣する複雑なスクリプトを作成したりできます。
合成をうまく使用するには、チームはビジネスに不可欠なカスタマー ジャーニーと依存 API を特定し、それらを追跡するための合成モニターを設定する必要があります。合成モニター レポートは、ワークロードまたは他のダッシュボードの一部にすることができます。
モニターのインデックスを使用して、モニターのステータスとメトリックを確認できます。
合成を開始するには、合成の概要とモニターの作成を参照してください。
エラーの受信トレイ
当社のエラー インボックス機能は、エラーがエンド ユーザーに影響を与える前に、プロアクティブにエラーを検出し、優先順位を付け、対処するのに役立ちます。Slack などの優先通信チャネルを介して、顧客に影響を与える重大なエラーが発生するたびにアラートを受け取ります。
エラー インボックス UI を使用すると、ワークロードのエラーを簡単に確認できます。
エラー インボックスを使用するには、いくつかのワークロードを設定する必要があります。開始するためのリソース:
次は何ですか？
このガイドは、強力なオブザーバビリティの基盤を構築するのに役立ちましたが、それはオブザーバビリティの卓越性に向けた最初のステップにすぎません。次に、New Relic の細かい点を学び、セットアップを最適化することに集中したいと思うかもしれません。次のステップのアイデア:
- さらにインストルメンテーションが必要だと思われる場合は、より多くのオブザーバビリティ ツールを参照してインストールしてください。
- 使用しているツールと機能のドキュメントを読んで、構成とカスタマイズのオプションについて学んでください。
- データの取り込みを理解して最適化します。
- データのクエリに関する New Relic University のクラスを修了し、他のクラスを受講してください。
- オブザーバビリティの目標を計画し、オブザーバビリティの卓越性を達成する方法について詳しくは、オブザーバビリティの成熟度シリーズを参照してください。これには、最適なインストルメンテーション、 コードとしての可観測性、 アラート品質管理などを確保するためのガイドが含まれています。