CPU負荷が（通常）重大な警告であってはならない理由。

監視でよく発生する質問の1つは、警告レベルとエスカレーションをどのように定義するか、およびさまざまな警告を–Critical、Error、Warningに設定するレベルです。

エラーとクリティカルアラートがポケットベル/電話でチームに通知するように設定されていると仮定し、エスカレーション時間が短いクリティカルアラートがあると仮定すると、以下の簡単なガイドラインがあります。

クリティカルアラートは、すぐに顧客に影響を与える効果があるイベント用である必要があります。 たとえば、トラフィックをルーティングするための利用可能なサービスがないため、監視対象のロードバランサー上の実稼働仮想IPがダウンしています。 サイトがダウンしているので、みんなのページ。

エラー警告は、即時の注意を必要とするイベントに対するものでなければならず、未解決の場合は、生産に影響を与えるイベントが発生する可能性 ロードバランサーの例を続行するには、仮想IPにトラフィックをルーティングするために機能するバックエンドサーバーが一つしかない場合、エラーがトリガーさ

警告は、通常、電子メールのみで送信することをお勧めしますが、他のすべての種類のイベントのためのものです。 機能している20の他のサーバーがあるときに仮想IPから単一のバックエンドサーバーの損失は、誰もが夜に目覚めている保証するものではありません。

アラートを割り当てるレベルを決定するときは、デバイスの主な機能を考慮してください。 たとえば、NetAppストレージアレイの場合、デバイスの機能は、IO要求の読み取りと書き込みを処理することです。 したがって、Netappを監視するための主なものは、これらの読み取り要求と書き込み要求の可用性とパフォーマンス（待機時間）である必要があります。 ボリュームが書き込み要求あたり70msなどの待ち時間の長い要求を処理している場合は、エラーレベルアラートである必要があります(一部の企業では、クリティカルレベルアラートとして構成するのが適切かもしれませんが、通常、クリティカルパフォーマンスアラートは、エンドアプリケーションのパフォーマンスが許容できないほど低下した場合にのみトリガーされる必要があります。 ただし、NetAppのCPU負荷がある期間99％である場合は、驚くべきことに聞こえますが、警告レベルの警告としてのみ扱われることをお勧めします。 待ち時間が影響を受けない場合は、なぜ夜に人々を目覚めさせるのですか？ 問題を調査できるように電子メールアラートを送信しますが、デバイスの機能が損なわれていない場合は、過剰に反応しないでください。 （ご希望の場合は、アラートのエスカレーションを定義して、5時間以上訂正されていないか確認されていない場合など、このような条件がページになるようにすることができます。)

アラートの過負荷は、ほとんどのデータセンターにとって、ほとんどの人が認識するよりも大きな危険です。 思考は、多くの場合、”一つのアラートが良い場合は、より多くの方が良いでなければなりません。”代わりに、デバイスの主要な機能を特定することに焦点を当て、それらの機能にエラーレベルアラートを設定し、警告を使用してその機能を損なう可能性のある条件について通知したり、トラブルシューティングを支援したりします。 （NetAppのレイテンシが高く、CPU負荷も警告されている場合、異常なボリュームアクティビティを探すのではなく、明らかに問題の診断に役立ちます。)

システム全体のパフォーマンスと可用性のために重要なアラートを予約します。

LogicMonitor hosted monitorを使用すると、すべてのデータセンターデバイスのアラート定義には、上記の方法で事前定義されたアラートしきい値があります。