現場の「見えない」を可視化する――iptraf-ngでネットワークの深淵を覗く
システム運用で最も恐ろしいのは、「何が起きているか分からない」という状態だ。メトリクス監視ツールは確かに便利だが、CPU使用率やリクエスト数が跳ね上がったその瞬間、NIC（ネットワークインターフェース）の裏側で何が起きているのか？ どのTCPセッションが帯域を食いつぶし、どのパケットが「再送」という名の悲鳴を上げているのか？
そんな時、私は迷わずiptraf-ngを叩く。今日は、教科書には載っていない、現場で生き残るための「トラフィック可視化術」を伝授しよう。
なぜ今さらiptraf-ngなのか？
現代のインフラではebpfやprometheusが主流だが、緊急時の「現場力」において、対話型UIでパケットの流れを即座に確認できるiptraf-ngの右に出るものはない。特に、アプリケーション層のAPI設計者やバックエンドエンジニアにとって、自身の書いたコードがネットワーク層でどう振る舞っているかを知ることは、パフォーマンスチューニングの第一歩だ。
iptraf-ngのインストール
まずは手元の環境に入れよう。Debian/Ubuntu系なら以下の通りだ。
# パッケージのインストール
sudo apt update && sudo apt install iptraf-ng -y実践：パケットの「鼓動」を聴く
iptraf-ngを起動すると、ターミナル上にCUIベースのメニューが立ち上がる。私が現場で多用するのは「IP Traffic Monitor」だ。特定のインターフェース（eth0など）を指定することで、その瞬間に流れるパケットをリアルタイムで観測できる。
注目すべきは「TCPフラグ」と「サイズ分布」
単にログを眺めるのではない。ここで見るべきは以下のポイントだ。
1. セッションの生存時間: APIのKeep-Aliveが効いているか、余計なFINやRSTが飛び交っていないか。
2. パケットサイズ: 1500バイト（MTU上限）に近いか、あるいは小さなパケットが大量に発生する「Tiny Packet Problem」に陥っていないか。
3. TCP状態: SYN_SENTで止まっていないか、ESTABLISHEDが異常増殖していないか。
例えば、Pythonのrequestsを使ってAPIを叩く際、接続の挙動を追うにはこうする。
import requests
# 接続先APIエンドポイント
url = "https://api.example.com/data"
# 接続の挙動を確認するためにあえてセッションを生成
# iptraf-ngでこの時のSYN/ACKのやり取りを観察する
session = requests.Session()
response = session.get(url)
print(f"Status Code: {response.status_code}")このコードを実行している最中にiptraf-ngを起動し、対象のIPに対するトラフィックを監視すれば、三次ハンドシェイク（Three-way handshake）がいかにスムーズに行われているか（あるいは失敗しているか）が手に取るように分かるはずだ。
現場の知見：ボトルネックを見抜くためのTIPS
シニアエンジニアとして、後輩によく伝えている「トラブルシューティングの勘所」をいくつか共有しよう。
1. RSTパケットの急増は「不完全な切断」のサイン
APIサーバーがクライアントからのリクエストを待たずに切断している場合、iptraf-ng上ではRSTフラグが頻繁に観測されるはずだ。これは多くの場合、ロードバランサーのタイムアウト設定か、アプリケーションのコネクションプール設定が噛み合っていない時に起こる。
2. パケットサイズ分布とスループット
もし特定のAPIが極端に遅い場合、MTUサイズによるパケット分割（フラグメンテーション）が起きていないか確認してほしい。大きなJSONをやり取りする際、ネットワーク機器のPath MTU Discoveryがうまく機能していないと、パケットが断片化され、再送処理で遅延が激増する。
3. SSH接続を巻き込まないように
iptraf-ngのフィルタ機能で、自身の管理用セッション（SSHポート 22 など）を除外しておくのを忘れないように。さもないと、自分自身の監視パケットで画面が埋め尽くされてしまう。
# 特定のインターフェース(eth0)かつ、SSH以外のトラフィックを監視する場合のフィルタ設定例
# メニューから「Filters」を選択し、以下を定義する
# TCP Port: 22 (Exclude)最後に：ツールを使いこなす「目」を養え
iptraf-ngはただのツールだ。しかし、このツールを通して流れてくるパケットの列に、背後にあるアプリケーションのロジックや、ルーターの設定ミス、はたまた通信キャリアの障害の「兆候」を見出すのが、我々エンジニアの仕事だ。
「なぜこのパケットはここで再送されているのか？」
「なぜこの接続は確立にこれほどの時間を要しているのか？」
画面上に流れる数字やフラグに問いかけ続けること。その泥臭い積み重ねこそが、どんな難解な障害も解決できる「真の力」になる。
もし現在、原因不明のレイテンシに悩んでいるなら、まずはiptraf-ngで現場の空気を吸ってみてほしい。教科書には載っていない、リアルなネットワークの挙動が、必ずやヒントをくれるはずだ。
コメント