Ciscoモニタリングによるネットワーク停止の回避

LogicMonitor意見投稿

昨夜、私たちのopsチーム(私がメンバーです)は、深夜に新しいデータセンターのCisco3560スイッチのCPU負荷についてポケットベルを受け取りました。 私の最初の反応は、「このアラートをポケットベルや電話にエスカレーションする必要はありません。ハードウェアで3560のスイッチとルートを使用するため、CPUの負荷は関係ありません。」 もう少し目を覚ますと、当然の結果として、このスイッチをCPUレベルにしてエラーアラートをトリガーする方法はありません。

幸いなことに、その頃、LogicMonitorのエスカレーションシステムから、他の誰かが問題を認識して所有権を取得しているという自動フォローアップページを受け取ったので、読みに戻りました。

この問題に対処したメンバーは、新しいデータセンターに導入したこのスイッチが再利用され、「sdmrefervlan」に設定されているという解決策を教えてくれました。 CPU。

これは、「show running config」コマンドに表示されないファンキーなIOSコマンドの3つであるため、データセンターで使用するためにスイッチを再構成するタイミングは明らかではありませんでした。 このスイッチにはいくつかのBGPセッションがあり、実際にはレイヤーXNUMXルーティングを実行していたため、事実上すべてのトラフィックがCPUに到達していました。 また、このデータセンターでアカウントをオンラインにしたときに、CPU使用率のしきい値に達しました。

したがって、このスイッチをすばやく再構成して再起動した後(すべてのトラフィックが冗長スイッチを介して流れる)、sdmテンプレートが適切にリセットされ、CPUが期待されるレベルに低下しました。

方法のちょうど別の例 インテリジェントな監視(デフォルトのしきい値、適切なアラートエスカレーション) このデータセンターでパケット損失やサービスの低下に遭遇した場合に問題が発生するのを防ぎました。 そして、私たちのopsチームの素晴らしいメンバーと、LogicMonitorのアラートエスカレーションおよび確認システムのおかげで、私は自分で応答する必要がありませんでした。 🙂

スティーブ·フランシス

創業者

スティーブはLogicMonitorの創設者です。

LogicBlogを購読して、LogicMonitorの最新の開発に関する最新情報を入手し、ITエキスパートとエンジニアのワールドクラスのチーム、およびITプロフェッショナルが愛する製品。

LogicBlogの他の記事

アンペアロボット 影

お店の話をしましょう。

STARTED GET