【実務・中級編】 iftopによるリアルタイム帯域使用状況のホスト別可視化 – トラブルシューティング&ネットワーク運用監視実践ガイド

「なぜか遅い」を秒殺する。iftopで帯域の「犯人」を特定する現場の技術

ネットワーク運用に携わっていると、必ず一度は遭遇する「ネットワーク全体が重い」という悲鳴のようなアラート。ZabbixやPrometheusのグラフを見れば確かに負荷は高い。だが、その負荷が「必要なトラフィック」なのか、それとも「どこかのサーバーが暴走しているのか」を判断するのは、高度な推論と調査能力を要する仕事だ。

そんな時、僕らNOCの人間がまず叩くコマンドが iftop だ。これは単なる帯域測定ツールではない。ネットワークの「今、この瞬間」を可視化する、現場の最強の武器だ。

—

なぜ iftop なのか?――パケットキャプチャの「次」の一手

netstat や ss がサーバー自身のソケット状態を示す「静的なスナップショット」だとすれば、iftop はそのパケットがネットワークインターフェースを通過する様子を、動的に、かつホスト別に切り分ける「動的な顕微鏡」だ。

RFC 791(IP)や RFC 793(TCP)の仕様を語るまでもなく、ネットワーク上ではパケットがひっきりなしに行き交っている。iftop は libpcap ライブラリを使い、カーネルレベルでパケットをスニッフィングすることで、どのホスト間(src と dst)で、どのポート番号(sport / dport)を使って、どれだけのバイト数が流れているかをリアルタイムに集計する。

実務で使うべき鉄板のコマンドオプション

ただ iftop を実行するだけでは、IPアドレスの逆引きでリソースを食いつぶしたり、ポートが見えなかったりと不便なことが多い。現場で最も使うのは以下の組み合わせだ。

# -n: DNS逆引きを無効化(パフォーマンス低下を防ぐ)
# -P: ポート番号を表示(重要!どのサービスが動いているか特定するため)
# -i eth0: 監視対象のインターフェースを指定
sudo iftop -n -P -i eth0

この画面が開いた瞬間、あなたはネットワークの「交通整理官」になる。上部に表示される 2s, 10s, 40s の平均値は、スパイク(突発的な負荷)を特定する重要な指標だ。

—

帯域の「犯人」を特定するロジック

もし、特定のAPIサーバーが異常なトラフィックを吐いているなら、iftop 上でその dst アドレスが異常に突出しているはずだ。

例えば、Web APIが curl や Fetch API を使って外部のストレージに巨大なバイナリを垂れ流している場合、iftop には以下のようなフローが如実に現れる。

# 疑わしい通信の確認例(通信フローのイメージ)
# 192.168.1.10 (API Server) -> 10.0.0.50 (Storage)
# ポート 443 (HTTPS) で大量のデータが流れていることが特定できる

開発・運用で意識すべきデバッグの視点

API開発者が「レスポンスが遅い」と言ってきた時、それがアプリケーションのロジック(DBクエリの遅延など)なのか、ネットワーク帯域の飽和なのかを切り分ける必要がある。Pythonで書かれたバックエンドが帯域を食い潰していないか、以下のスクリプトのような挙動を疑うべきだ。

import requests

# 異常なトラフィックを発生させている可能性のあるコード例
def upload_large_file(url, file_path):
    with open(file_path, 'rb') as f:
        # この通信が帯域を占有していないか、iftopでポートを監視する
        response = requests.post(url, data=f, stream=True)
    return response.status_code

# もしこれがループ内で無制限に実行されれば、iftopに顕著な負荷が現れる

—

現場で生き残るための「Tips」

1. フィルターの活用:
特定のサブネットやポートだけに絞り込みたい場合は、iftop 起動後に f キーを押してフィルタ式を入力する。dst port 80 と打てば、HTTP通信だけのランキングが手に入る。
2. プロミスキャスモードの罠:
iftop を実行するとインターフェースがプロミスキャスモードになることがある。高負荷環境ではCPU負荷が急増するため、調査が終わったら速やかに停止(q キー)させるのが鉄則だ。
3. ロングラン監視:
「数時間後に発生する謎のスパイク」を追うなら、iftop の出力をファイルにリダイレクトして後から眺めるという荒業もある。

sudo iftop -t -n -s 3600 > network_log_$(date +%Y%m%d).txt

※ -t (text mode) と -s (seconds) を組み合わせることで、レポート形式でログが残せる。

最後に:ツールは嘘をつかない

ネットワークトラブルの現場では、往々にして「感」や「推測」がエンジニアを迷走させる。しかし、iftop が表示するバイト数は紛れもない現実だ。

「誰が」「どこへ」「どれだけ」データを送っているか。この問いに対する答えを即座に引き出せる能力は、インフラエンジニアとしての寿命を延ばすだけでなく、あなたの設計するシステムをより堅牢なものにする。

さあ、次のアラートが鳴った時、慌てずに iftop を叩いてみてほしい。パケットが語る真実が、そこには必ずあるはずだ。

コメント

タイトルとURLをコピーしました