データセンター監視のプロセス

たとえ 最高のデータセンターモニタリング システムが整っている場合、実装が成功するかどうかは、監視の周りで採用されているプロセスに大きく依存します。

理想は、包括的(注意が必要なすべての状態に警告する)でノイズのない(注意が必要でない状態に警告しない)監視システムです。ノイズの多い警告システムは、監視がないのとほぼ同じくらい悪いです-それは人々を訓練しますアラートを無視します。

これらの目標は正反対であり、監視のユーザーが異なれば、注意が必要なものやノイズであるものについて異なる基準があるという事実によってさらに複雑になります。 ただし、適切なアラートのエスカレーションとルーティング、およびいくつかの適切なプロセスが整っていれば、この状態に近づくことができます。

どのようなプロセスが役立ちますか?

スケジュールされたダウンタイムを使用する

これはおそらく、実施する最も重要なプロセスです。 誰かがシステムで作業する場合は、ダウンタイムをスケジュールしてください。 そもそもアラートが出ないようにします。 ホストのセットに対して定期的なメンテナンスウィンドウがある場合は、スケジュールされたダウンタイムが自動的に繰り返されるように設定します。 アラートを定期的にトリガーするプロセス(NetAppファイラーのディスクスクラブによってトリガーされるCPUアラートなど)がある場合は、そのアラートだけに繰り返しダウンタイムをスケジュールします。

不要なアラートを取り除く

受信したアラートごとに、モニタリングの初期展開中に評価を行う必要があります–アラートは必要でしたか? その場合は、アラートを確認して問題を修正してください。 そうでない場合、アラートの削除はどの程度一般的に行うことができますか? アラートがスイッチでのバッファ廃棄に関するものであるが、1Gbpsネットワークが100Mbpsアップリンクにリンクしているポートでのみ発生する場合、廃棄は正常で予想されるため、このXNUMXつの特定のポートに対してのみしきい値を調整する必要があります。 アラートがQAシステムで使用されるスワップスペースに関するものであり、QAがこれをトリガーするストレステストを定期的に実施している場合は、アラートを無効にするか、QAグループのしきい値を調整する必要があります。 (ストレージアレイボリュームなど、システムで共有されるリソースの場合、QAアラートを無効にするフィルターを追加するか、異なるしきい値を設定する必要があります。)

適切な場所にアラートを送信する

受信したすべての有効なアラートについて、適切な方法ですべての適切な人にのみ送信され、適切な期間にエスカレーションされていることを確認してください。 (不適切なエスカレーションの例は、ポケットベルではなく電子メールを介して本番システムに警告アラートを送信することですが、5分ごとにエスカレーションします。午前1.00時に8.00つの警告が発生し、午前250時まで誰も電子メールをチェックしない場合、全員がXNUMXになります。電子メールアラートが受信トレイを乱雑にします。)ネットワークの再送信について知りたい人のセットは、コマースサイトが完全にダウンしていることを知りたい人のセットとはおそらく異なります。

レビュー

上記の点を確認するために、特に監視システムの最初の展開中に、毎週レビューすることをお勧めします。

  • すべてのアラートが有効でした。 そうでない場合は、アラートを調整する必要がある方法とレベルについてコンセンサスが得られます。 アラートがスケジュールされたスタッフのアクションの結果であるが、スケジュールされたダウンタイムについて誰もモニタリングに通知しなかった場合は、手がかりスティック(またはより強力なアクション)を自由に使用することをお勧めします。
  • すべてのアラートは、正しい受信者だけに配信されました。
  • 各アラートのエスカレーションは有効で適切でした。
  • アラートを検出するアラートが作成されるまで、アラートが送信されなかったインシデントを閉じないでください。

プロセスを配置することは、監視展開が成功または失敗するための鍵となる可能性が高く、 SaaS監視サービス 前提ベースのシステムよりも優れている可能性があります。 SaaSサービスは、監視の継続的な使用と満足度に投資されます。SaaSサービスは前もってお金を稼ぐことはありません。 少なくともLogicMonitorでは、プロセスを含む実装全体でお客様を支援します。