Alertsでは、カスタマイズされたアラートソリューションを作成することで、ご利用システムのモニタリングが可能となります。この文書では、以下のポイントを扱います：
重要なコンセプトの紹介
アラートを使いこなすことで、作成した条件およびポリシーが違反と通知にどのようにつながるかという基本的なワークフローを理解できるようになります。
アラートを使いこなすことで、当社の使用する以下のような用語を理解できるようになります：
アラートの用語 | コメント |
|---|---|
ポリシー | ポリシーとは、1つ以上のアラート条件のグループを指します。条件をポリシーに追加する前にポリシーを作成しなければなりません。 ポリシーには、全ての条件に適用される2つの設定があり、インシデントプリファレンスと通知チャネル（以下で詳細に説明）。 |
条件 | 条件には、次のものが含まれます: a）モニターされるデータソースと、b）違反と見なされる挙動を定義する閾値。 たとえば、特定の条件は次のように記載されます：「私のアプリのページ読み込みのレスポンスタイムが8秒を超えて5分以上続く場合、これは違反となる。」 |
閾値 | 閾値は、条件の一部を構成しており、違反と見なされる行動を定義するものです。条件を作成すると、必須のクリティカルレベルの閾値を設定します。オプションとして、二次的な警告レベルの閾値も設定できます。 |
違反 | 違反とは、データソースの値が条件の閾値を超えた場合に発生します。これにより違反イベントが作成され、これを使用して重要な情報を川下に伝えます。 違反は、直接的には通知を生成することはなく、インシデントにつながる場合があり、これが通知を生成します。 |
インシデント | 通知は、インシデントによって生成されます。ポリシーレベルでは、インシデントプリファレンスによって、違反をどのように処理・組み合わせてインシデントを生成するのかを決定できます。 例えば、ひとつひとつの違反がインシデントを生成するように設定（通知数が多くなる）するか、アラートポリシー全体を通じて単一のインシデントのみを開くよう設定（通知数が最低になる）できます。インシデントプリファレンスを設定することで、通知の作成方法を管理でき、通知疲れも予防できます。 |
通知 | ポリシーレベルでは、インシデント発生時にどのチームメンバーが、どのように連絡を受けるのかを選択できます。当社は、WebhookやSlackルーム、メールなどを含む、いくつかの通知チャネルを提供します。状況を提供するためインシデントについてのチャートを含め、そのチャートをチームの通知と共有することができます。 |
これらおよびその他の用語の詳しい定義に関しては、用語集をご覧ください。
基本ワークフロー
基本コンセプトと用語を理解したところで、今度はポリシーならびに関連する条件の作成に関する一般的なプロセスを見てみましょう：
ポリシーを作成する。ポリシーを作成する際は：
- 意味のある名前を付けましょう。例えば：グループまたはチームの名称、あるいはそのポリシーが対象とするリソースとサービス一式などになります。
- インシデントプリファレンスを設定して、違反がどのような方法でインシデントになるかを決定します。
- 通知チャネルを設定します。
そのポリシーに付属する条件を作成します。条件を作成する際のステップには、以下が挙げられます：
- 監視対象となるデータソースを選択します（たとえば、APMメトリックもしくはNRQLクエリ）。
- どの行動が違反を生成するのかを定義した閾値を設定します。
- オプション：runbook URLを含めます。これは、アラート通知の処理方法に関する標準的な手順を共有する際に用います。
オプション：同じポリシーに条件をさらに追加します。
通知を受信する以外に、New Relic Oneでアラートインシデントもしくはイベント詳細を確認できます。
次のステップ
アラートの使用方法に関する詳細をご希望の場合：
その他のヘルプ
さらに支援が必要な場合は、これらのサポートと学習リソースを確認してください：
- Explorers Hubを参照して、コミュニティから支援を受け、ディスカッションに参加してください。
- 当社のサイトで回答を見つけ、サポートポータルの使用方法について学びます。
- Linux、Windows、およびmacOSのトラブルシューティングツールであるNew Relic Diagnosticsを実行します。
- New Relicのデータセキュリティとライセンスドキュメントを見直してください。