• /
  • EnglishEspañol日本語한국어Português
  • ログイン今すぐ開始

この機械翻訳は、参考として提供されています。

英語版と翻訳版に矛盾がある場合は、英語版が優先されます。詳細については、このページを参照してください。

問題を作成する

実装パート 4: アラートおよびその他のプロアクティブなソリューション

これは実装ガイドの 4 番目で最後の部分です。

前の実装段階では、スタックを計測し、New Relic プラットフォームに精通しました。今こそ、問題を早期に通知し、最悪のシナリオを回避するのに役立つプロアクティブなソリューションについて考える良い機会です。この段階では、次のような、この分野におけるいくつかの重要なソリューションについて学習します。

  • アラート
  • 合成モニター
  • エラーの受信トレイ

アラート戦略について考える

Alerts UI

New Relic UI では、アカウント内のアラート条件の状態を確認できます。

アラートを設定する前に、アラートの目標と戦略について検討することをお勧めします。組織が大きくなればなるほど、その重要性は増します。

アラート戦略がなく、1 回限りの問題を解決するためにアラートを迅速かつ無計画に設定すると、アラート通知が大量に送信される可能性があります。そうなると、チームはアラート疲労に悩まされ、アラートを無視し始めます。アラート戦略について時間をかけて検討することで、組織の成長や New Relic へのデータの追加に合わせて拡張できるスマートな方法でアラートを設定できるようになります。

集計 通知 メッセージをお客様にルーティングするために、 workflows ( 通知 を作成する方法と送信されるデータのルール) とnotification destinations ( 通知 が送信される場所) を使用します。 組織全体で一貫性と保守性を保つために、これらをどのように設定するかを計画することをお勧めします。 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 を特定し、それらを追跡するための合成モニターを設定する必要があります。合成モニター レポートは、ワークロードまたは他のダッシュボードの一部にすることができます。

Synthetic monitoring - Monitors index

モニターのインデックスを使用して、モニターのステータスとメトリックを確認できます。

合成を開始するには、合成の概要とモニターの作成を参照してください。

エラーの受信トレイ

当社のエラー インボックス機能は、エラーがエンド ユーザーに影響を与える前に、プロアクティブにエラーを検出し、優先順位を付け、対処するのに役立ちます。Slack などの優先通信チャネルを介して、顧客に影響を与える重大なエラーが発生するたびにアラートを受け取ります。

This is an image of the main errors inbox UI

エラー インボックス UI を使用すると、ワークロードのエラーを簡単に確認できます。

エラー インボックスを使用するには、いくつかのワークロードを設定する必要があります。開始するためのリソース:

次は何ですか?

このガイドは、強力なオブザーバビリティの基盤を構築するのに役立ちましたが、それはオブザーバビリティの卓越性に向けた最初のステップにすぎません。次に、New Relic の細かい点を学び、セットアップを最適化することに集中したいと思うかもしれません。次のステップのアイデア:

Copyright © 2024 New Relic株式会社。

This site is protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply.