• /
  • ログイン

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

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

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

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

推奨アラート

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

ポリシーを整理する

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

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

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

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

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

たとえば、

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

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

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

アクション

推奨事項

閾値のレベルの設定

低すぎる閾値を設定することは避けて下さい。たとえば、CPUの条件の閾値を本稼働サーバーで5分間75%に設定すると、日常的にそのレベルを超え、対応に困るアラートや誤検知が増加します。

設定の試行錯誤

ファイルの編集やソフトウェアの再起動は必要ありません。このため、必要に応じて閾値のレベルを気軽に変更し調整できます。

設定の調整

徐々に条件を調整していく。

  • New Relicの製品を使用してエンティティのパフォーマンスを最適化しながら、パフォーマンスの向上に合わせて閾値を厳しくしていくことができます。
  • 一定期間、パフォーマンスに悪影響を及ぼすことがわかっているものを配備する場合は、これを許容するように閾値の条件を緩和してください。

設定の無効化

ポリシー内の条件は無効化できます。これは、たとえば他のメトリクスや閾値を試しながら、そのポリシーに対する他の条件を使い続けたい場合に便利です。

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

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

重要

警告違反ではインシデントは開きません。重大な違反はインシデントを開くことができますが、その決定はインシデントプリファレンスで定義する必要があります。

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

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

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

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

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

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

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

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

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

通知チャネルを選択する

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

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

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

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

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

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

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

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

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

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

次のステップ

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

その他のヘルプ

さらに支援が必要な場合は、これらのサポートと学習リソースを確認してください:

問題を作成するこのページを編集する
Copyright © 2020 New Relic Inc.