Linux環境におけるHost sFlow設定ガイド：ネットワークトラフィックとKVM仮想マシンのリアルタイム監視 - ITFROMZERO - Share tobe shared! Host sFlowは、Linux向けの極めて軽量なネットワークトラフィックおよびサーバーメトリクス収集ソリューションです。本記事では、hsflowdのインストールからCollectorの設定、物理サーバーおよびKVM仮想マシンの監視方法まで詳しく解説します。

Table of Contents

背景：サーバーをダウンさせずにトラフィックを漏れなく把握する

社内ネットワークをラッシュアワーの交差点に例えてみましょう。渋滞が発生した際、通過するすべての車両のナンバープレート、車体色、速度を記録する人員を配置したとすれば、数分で限界を迎えてしまいます。さらに恐ろしいのは、確認のために車を停止させる行為自体がさらなる大渋滞を引き起こす点です。高負荷状態にある10 Gbpsのネットワークポートで安易にtcpdumpを実行した場合にも、まさにこれと同じ事態が発生します。

全車両を逐一確認する代わりに、例えば車両が400台通過するごとにランダムで1枚写真を撮影し、同時に20秒ごとに交通密度を記録するアプローチをとれば、はるかにスマートです。過積載のタンクローリーが存在するか、どの分岐路からの流入が最も多いかといった全体像の95〜99%を正確に把握でき、システムのリソースを無駄に浪費することもありません。これこそが、sFlow（Sampled Flow）の運用思想です。

筆者がかつて運用していた従業員50名規模のオフィスネットワークとKVMサーバー環境では、ネットワーク遅延のトラブルが日常茶飯事でした。ある日の午後2時、バックアップ用仮想マシンが突然大量のトラフィックを放出し、メイン回線を圧迫する事態が発生しました。その場での反射的な行動としてSSH経由でtcpdumpを実行したところ、CPUの1コアが100%に達し、わずか10分で.pcapファイルが40 GBものディスク容量を食いつぶしたにもかかわらず、根本原因は即座に特定できませんでした。

sFlowは、以下のように機能を完全に分離した仕組みによって、この課題を根本から解決します。

Packet sampling（パケットサンプリング）: 通過するN個のパケットごとに、1パケットのヘッダーをランダムに抽出します（通常は1/400または1/1000）。
Counter polling（カウンターポーリング）: ハードウェアおよびシステムの各種メトリクス（インターフェースの送受信バイト数、CPU負荷、メモリ使用量など）を定期的に読み取ります。

収集されたデータはすべて非常にコンパクトなUDPパケットにカプセル化され、中央の管理サーバー（Collector）へ送信されます。純粋なC言語で記述されたHost sFlow（hsflowd）デーモンは、Linux上で極めて安定して動作し、CPU使用率が1%を超えることはめったにありません。

LinuxへのHost sFlowのインストール

hsflowdは、UbuntuやDebianからRocky Linux、AlmaLinuxに至るまで、主要なディストリビューションのほとんどで軽快に動作します。重い依存関係が存在しないため、インストール作業は2分もかからず完了します。

1. Ubuntu / Debianへのインストール

近年のUbuntuバージョンでは、公式リポジトリにhsflowdがあらかじめ収録されています。

sudo apt update
sudo apt install -y hsflowd

最新ビルドが必要な場合やデフォルトのリポジトリにパッケージが存在しない場合は、プロジェクトのGitHubリポジトリから.debファイルを直接ダウンロードしてインストールしてください。

# Ubuntu 22.04 LTS環境におけるバージョン2.0.51の例
wget https://github.com/sflow/host-sflow/releases/download/v2.0.51-1/hsflowd-ubuntu22_2.0.51-1_amd64.deb
sudo dpkg -i hsflowd-ubuntu22_2.0.51-1_amd64.deb

2. RHEL / Rocky Linux / AlmaLinuxへのインストール

Enterprise Linux系のディストリビューションでは、EPELリポジトリからパッケージをインストールします。

sudo dnf install -y epel-release
sudo dnf install -y hsflowd

Host sFlowの詳細設定

Host sFlowのすべての設定は/etc/hsflowd.confに集約されています。このデーモンはDNS-SD（DNS Service Discovery）によるCollectorの自動検出にも対応していますが、本番環境ではCollectorの静的IPアドレスを明示的に指定する構成が最も安全かつ制御しやすい選択肢となります。

1. 単体サーバー向けの標準設定ファイル

管理者権限（root）で設定ファイルを開きます。

sudo nano /etc/hsflowd.conf

注目すべき基本パラメータは、Collectorのアドレス、サンプリングレート、メトリクスの送信周期の3点のみです。

sflow {
  # CollectorサーバーのIPアドレスと受信ポート（デフォルトはUDP 6343）
  collector {
    ip = 192.168.10.50
    udpport = 6343
  }

  # 400パケットごとに1パケットをランダムサンプリング
  sampling = 400

  # 20秒ごとにCPU、メモリ、ディスク、インターフェースカウンターを送信
  polling = 20
}

2. KVM / Libvirt仮想マシンの監視設定

ハイパーバイザーとシームレスに連携できる点は、hsflowdの最大の強みです。libvirtと連携させることで、エージェントは稼働中の仮想マシンを自動検出し、VM名を取得した上で、各仮想NIC（vnetX）を通過するトラフィックを監視できます。ゲストOS側に追加のエージェントを導入する必要は一切ありません。

/etc/hsflowd.confにlibvirtブロックを追加します。

sflow {
  collector {
    ip = 192.168.10.50
    udpport = 6343
  }

  sampling = 400
  polling = 20

  # libvirtハイパーバイザーからメタデータとメトリクスを自動同期
  libvirt {
  }

  # Linux Bridgeの代わりにOpen vSwitchを使用する場合はコメントアウトを解除
  # ovs {
  # }
}

3. systemdによるサービスの有効化と起動

新しい設定を反映し、OS起動時にデーモンが自動起動するよう有効化します。

sudo systemctl daemon-reload
sudo systemctl enable --now hsflowd

# プロセスの稼働状態を確認
sudo systemctl status hsflowd

ステータスに緑色でActive: active (running)と表示されていれば、エージェントが正常にデータ収集を開始したことを意味します。

データフローの確認とCollectorの実践的な構築

エージェント起動後は、監視ダッシュボードを構築する前に、UDPパケットが対象ホストから実際に送出されているかを確認します。

1. サーバーからの送信UDPパケットをキャプチャ

hsflowdをインストールしたホスト上で、以下のコマンドを実行します。

sudo tcpdump -n -i any udp port 6343

実行結果は次のように出力されます。

14:25:01.120450 IP 192.168.10.15.42150 > 192.168.10.50.6343: UDP, length 1412
14:25:02.135112 IP 192.168.10.15.42150 > 192.168.10.50.6343: UDP, length 1380

パケットが定期的に送出されていれば、sFlowエージェントが意図した通りに動作している証拠です。

2. Dockerを使用したsFlow-RT Collectorのクイック構築

Collectorサーバー（本記事では192.168.10.50）側でリアルタイム分析を行うには、sFlow-RTが最も手軽で便利です。Dockerを利用すれば、30秒ほどでテスト用インスタンスを起動できます。

docker run -d --name sflow-collector \
  -p 6343:6343/udp \
  -p 8008:8008 \
  sflow/sflow-rt

起動完了後、ブラウザからhttp://192.168.10.50:8008/html/index.htmlへアクセスします。sFlow-RTのWeb UIでは、以下のような主要メトリクスを即座に確認できます。

Top Talkers: 最もトラフィック量の多い内部IPアドレスや、異常な帯域消費を行っている外部IPアドレスを一覧表示します。
Top Protocols & Ports: 各種サービス（HTTP/S、SSH、DNS、MySQLなど）のトラフィック比率を可視化します。
System Metrics: CPU負荷、メモリ使用量、および物理NICやKVM仮想NICごとの詳細な帯域幅のリアルタイムグラフを表示します。

3. 本番環境導入における3つの重要ポイント

実環境でsFlowを運用するにあたり、データの欠落やインフラのボトルネックを防ぐために押さえておくべき極めて重要なポイントが3点あります。

適切なUDPポートの開放: ポート6343で使用されるプロトコルはTCPではなくUDPです。ホスト側ファイアウォール（sudo ufw allow 6343/udpなど）でのUDP許可ルールの追加漏れや、クラウドのセキュリティグループの設定不備により、データが届かないケースが多発しています。
回線帯域に応じたサンプリングレートの選定: 1 Gbps回線の場合、sampling = 400または500に設定することで、ネットワークに過度な負荷をかけることなく高い精度が得られます。しかし、10 Gbpsや40 Gbpsのアップリンクポートを管理する場合は、この値を1000や2500に引き上げてください。広帯域回線でサンプリング頻度を高くしすぎると、Collectorのメモリバッファがオーバーフローする原因になります。
自動アラートとの連携: sFlow-RTは、メトリクスをPrometheusへエクスポートするための標準REST APIを備えています。さらにGrafanaと連携させることで、大規模なポートスキャンやDDoS攻撃の発生時、あるいは特定のKVM仮想マシンが外部回線の帯域を突然占有した際に、即時アラートを発報する体制を構築できます。