帯域幅の占有とトラフィックスパイク：LogicMonitorのネットワークトラフィックフロー分析の使用

あなたが私たちの熱心な読者なら リリースノート および プレスリリース （そうでない場合は、それらをチェックする必要があります）、あなたは私たちがちょうど私たちの大きなアップグレードをリリースしたことをすでに知っています ネットワークトラフィックフロー分析 （以前はNetflowと呼ばれていました）新しいLogicMonitorUIのベータリリース。

あなたが知らないかもしれないことは、新しいネットワークトラフィックフローがあなたのネットワークトラフィックがどこから来ているのかを正確に決定するのをどのように助けることができるかということです。

• 最も使用頻度の高いデバイスからのフローデータを簡単に表示
• ビジーなデバイスメトリックにさらに細かくアクセスする
• 確立されたフィルターに基づいてポートデータにドリルインする
• 円グラフや時系列グラフなどの美しいグラフィカルウィジェットでネットワークフローデータを消費します。

信じられないかもしれませんが、私たちは実際にLogicMonitorを内部で使用して、独自のインフラストラクチャ（LogicMonitorプラットフォームを実行している機器を含む）のパフォーマンスを監視しています。 先週、IT運用チームはこれらの機能を使用して、オフィスネットワークのXNUMXつでネットワークの問題を調査しました。これを、皆さんと共有したいと思いました。

仕組み：

1）LogicMonitorがオフィスネットワークへの遅延のアラートをトリガーし、一部のユーザーはネットワークが遅いと不満を漏らしました（聞き覚えがありますか？）。

2）デバッグアクションとして、エンジニアはそのオフィスネットワークのネットワークトラフィックフローダッシュボードを開きました。

3）エンジニアは、帯域幅グラフで大きなトラフィックスパイクを発見しました。

4）エンジニアは、オフィスファイアウォールのトラフィックデータ（Netflow）を使用してさらに詳細にドリルダウンしました。 ここで彼はイベントの時間枠を分離し、トラフィックの詳細の内訳を見ました。

5）次に、エンジニアは上位のアプリケーションの詳細を確認し、帯域幅がAkamaiを介した同時の大規模なダウンロードによって引き起こされていることに気付きました。 さらに、彼は上位の内部ユーザーのIPを分離しました。

6）この情報から、彼はトラフィックの急増がAdobeから特定のユーザーへのいくつかの大規模なダウンロードによって引き起こされたことを学びました。 差し迫った問題を軽減するために、ユーザーはダウンロードを一時停止し、問題は解決されました。 （もちろん、基礎となる帯域幅容量は依然として問題です。）

LogicMonitorを介したネットワークトラフィックフローデータの迅速な可用性は、ネットワークの問題を修正するのに役立つことが多く、将来の問題を防ぐのに役立つ帯域幅使用率のポリシーと制御に関するユーザーとの話し合いの基礎となります。

詳細については、 ヘルプドキュメント.