監視でよく発生する質問のXNUMXつは、アラートレベルとエスカレーションを定義する方法と、さまざまなアラートをクリティカル、エラー、または警告に設定するレベルです。
ポケットベル/電話でチームに通知するように設定されたエラーとクリティカルアラート、およびエスカレーション時間が短いクリティカルアラートがある場合、いくつかの簡単なガイドラインを次に示します。
重要なアラートは、顧客にすぐに影響を与えるイベントに対して発生する必要があります。 たとえば、監視対象のロードバランサーの実稼働仮想IPは、トラフィックをルーティングするための利用可能なサービスがないため、ダウンしています。 サイトがダウンしているので、みんなにページングしてください。
エラーアラートは、早急な対応が必要なイベントに対応する必要があり、解決されない場合は、本番環境に影響を与えるイベントが発生する可能性が高くなります。 ロードバランサーの例を続けるには、仮想IPにトラフィックをルーティングする機能するバックエンドサーバーがXNUMXつしかない場合、エラーがトリガーされます。冗長性がなくなったため、XNUMXつの障害でサイトがオフラインになる可能性があります。
通常、電子メールでのみ送信することをお勧めする警告は、他のすべての種類のイベントに対するものです。 他に20台のサーバーが機能しているときに、仮想IPからXNUMX台のバックエンドサーバーが失われたとしても、夜間に誰も起こされる必要はありません。
アラートを割り当てるレベルを決定するときは、デバイスの主な機能を考慮してください。 たとえば、NetAppストレージアレイの場合、デバイスの機能は読み取りおよび書き込みIO要求を処理することです。 したがって、NetAppを監視するための主なものは、これらの読み取りおよび書き込み要求の可用性とパフォーマンス（待機時間）である必要があります。 ボリュームが書き込み要求あたり70ミリ秒などの高遅延の要求を処理している場合、それはエラーレベルのアラートである必要があります（一部の企業では、クリティカルレベルのアラートとして構成するのが適切な場合がありますが、通常、クリティカルパフォーマンスアラートはエンドアプリケーションのパフォーマンスが許容できないほど低下した場合にのみトリガーされます。）ただし、NetAppのCPU負荷が一定期間99％である場合は、警告のように聞こえますが、警告レベルのアラートとしてのみ扱うことをお勧めします。 待ち時間が影響を受けないのなら、なぜ夜に人々を起こすのですか？ 問題を調査できるように電子メールアラートを送信しますが、デバイスの機能が損なわれていない場合は、過度に反応しないでください。 （必要に応じて、アラートのエスカレーションを定義して、このような状態が5時間以上修正されていないか、確認されていない場合にページが表示されるようにすることができます。）
アラートの過負荷は、ほとんどの人が認識しているよりも、ほとんどのデータセンターにとって大きな危険です。 多くの場合、「XNUMXつのアラートが適切であれば、より多くのアラートが適切である必要があります」と考えられます。 代わりに、デバイスの主要な機能の特定に焦点を当てます。これらの機能にエラーレベルのアラートを設定し、警告を使用して、その機能を損なう可能性のある状態について通知したり、トラブルシューティングに役立てたりします。 （NetAppの待ち時間が長く、CPU負荷も警戒している場合は、異常なボリュームアクティビティを探す代わりに、明らかに問題の診断に役立ちます。）
システム全体のパフォーマンスと可用性に関する重要なアラートを予約します。
LogicMonitorがホストする監視では、すべてのデータセンターデバイスのアラート定義に上記の方法で事前定義されたアラートしきい値があります。これは、意味のある監視を数分で提供するのに役立つXNUMXつの方法です。