トラフィックフロー

ヘルス監視は「このリンクの使用率は 80% です」と教えてくれます。フロー監視が教えてくれるのは そこに何が流れているのかです。Yagra は、機器がもともとエクスポートできるフローレコードを収集し、トップトーカー・会話・ポートとプロトコルの内訳・AS 単位のビューに変換します。すでにお使いのメトリクスやアラートと並べて見られますが、動作は完全に独立しています。フローを無効のままにしておけば、何も変わりません。

概要

Yagra は主要なフローエクスポートプロトコルを解釈します。

NetFlow v5 と NetFlow v9
IPFIX
sFlow v5

ルータ、ファイアウォール、スイッチのフローエクスポートをポーラーへ向ければ、Yagra はフローデータだからこそ答えられる問いに答えます。誰が誰と通信しているのか、どのホストとポートがトラフィックを担っているのか、プロトコルの内訳はどうなっているのか、そして AS 補完を使えば、自分のトラフィックがどの自律システムへ広がっているのか。

フローレコードは専用の ClickHouse ストアに保存されます — メトリクスの TSDB ともメタデータデータベースとも別です。これはこの機能の必須要件で、有効化するには YAGRA_CLICKHOUSE_URL を設定します。設定しない場合、フロー収集は無効になり、フロー API は型付きの 503 を返します。そのため WebUI は空のグラフを見せる代わりに「未設定」と表示できます。

単一ノードの compose スタックには URL 設定済みの ClickHouse サービスが最初から含まれているため、そこではフローがそのまま動きます。自前で組んだデプロイでは、このストアはオプトインです。 設定 ▸ システムヘルスはフローストアを他のバックエンドストアと並べて表示するので、 ClickHouse の障害が「なぜかフロービューが空」という形ではなく一目で分かります。

収集の有効化

フローのリスナーはポーラー上にあり、他のパッシブリスナーと同じくオプトインです。各リスナーは、対応するバインド変数が設定されている間だけ存在します。

YAGRA_FLOW_BIND=0.0.0.0:2055     # NetFlow v5/v9 + IPFIX — set by default in compose
YAGRA_SFLOW_BIND=0.0.0.0:6343    # sFlow v5 — off by default

リスナー	変数	ポート	compose 既定
NetFlow v5/v9 / IPFIX	`YAGRA_FLOW_BIND`	`2055/udp`	有効
sFlow v5	`YAGRA_SFLOW_BIND`	`6343/udp`	無効（ホスト側のポートマッピングは存在しますが、バインドを設定するまで何も待ち受けません）

compose ではホスト側ポートを YAGRA_FLOW_PORT（既定 2055）と YAGRA_SFLOW_PORT（既定 6343）でマップします。syslog やトラップと違ってこれらはもともと非特権ポートなので、ホストとコンテナのポートは一致し、リダイレクトルールは不要です。

機器側では、フローエクスポート — ベンダーによって NetFlow export、NetStream、IPFIX export、 sFlow エージェントなどと呼ばれます — の送信先を <poller-host>:2055（sFlow なら :6343）に設定します。最初のエクスポートが届いてから 1〜2 分後に、ノードの Flow タブに最初のデータが現れます。レコードは 60 秒のバケットに畳み込まれるため、ビューはバケット単位で埋まっていきます。

sFlow はサンプリングプロトコルです。各サンプルは N パケットに 1 つを代表するため、Yagra はバイト数とパケット数をそのサンプルのサンプリングレートでスケールして実トラフィックを推定します。 sFlow の数値は「精度の高い推定値」であって正確なカウンタではないと考えてください — これはプロトコルの性質であり、Yagra の制限ではありません。サンプリングされた NetFlow v5（エクスポートヘッダーにサンプリング間隔が入っているもの）も同じ方法でスケールされます。

フローは syslog やトラップと同様にポーラーが受信するため、追加の配管なしでリモート拠点でも機能します — 後述のリモート拠点での収集を参照してください。

フローの保存方法

多忙な機器からの生のフローエクスポートは膨大で、その大半はロングテールのノイズです。Yagra はバスに何かが流れる前に、エッジすなわちポーラー上で集約します。

レコードは 60 秒のバケットに畳み込まれます（YAGRA_FLOW_BUCKET_SECS）。
各バケット内で、ポーラーはエクスポーターごとにバイト数上位 500 フローを保持します（YAGRA_FLOW_TOP_N）。これが実質的なカーディナリティ制御です。機器がどれだけエクスポートしようとそのコストに上限を設けつつ、「このリンクに何が流れているのか」に答える重いフローは残します。
集約されたバッチはバスに乗ってコアへ届き、コアがそれを ClickHouse へ書き込みます。

このトレードオフは意図的なものです。リンクを占有する重いフローはそのまま正確に保たれ、top-N の切り詰めが畳み落とすのは微小なフローのロングテールです。「何がこのリンクを飽和させているのか」「誰が誰と通信しているのか」に対しては、生のデータ量のごく一部でこれが正しいデータになります。保存される各レコードは、会話の送信元・宛先のアドレスとポート、プロトコル、AS 番号、そのバケットでのバイト数とパケット数を持ち、それを報告したエクスポーターに紐づけられます。

保持期間は ClickHouse の TTL で適用され、既定は 30 日、YAGRA_FLOW_RETENTION_DAYS で 1〜3650 日の範囲で設定できます。フローストアは意図的に損失に寛容です — これはトラフィック分析のデータであって課金記録ではなく、失っても監視やアラートには一切影響しません。

AS 補完

フロービューは自律システム単位でのグルーピングとフィルタができ、「203.0.113.7 宛のトラフィック」を「AS15169 宛のトラフィック」に変えます。AS 番号は次の 2 か所から、この順で得られます。

エクスポーター自身。 BGP を話す機器はフローレコードに送信元・宛先の AS をエクスポートします。その値が常に優先されます。
オフラインの IP→ASN データセット。 BGP を話さない機器の多くは AS 0 をエクスポートします。 YAGRA_IPASN_DB を iptoasn.com の TSV データセットに向けると、Yagra が書き込み時に欠けている AS 番号を補完します。未設定なら補完は無効で、エクスポーターが提供した AS 値だけが現れます。

YAGRA_IPASN_DB=/path/to/ip2asn-combined.tsv
YAGRA_IPASN_RELOAD_SECS=21600   # re-read the file every 6 h; 0 = load once at startup

compose ファイルは、スタック全体にインターネットアクセスを与えることなくデータセットを最新に保ちます。ipasn-updater サイドカーがスケジュール（既定は週次、YAGRA_IPASN_REFRESH_SECS）に従って共有ボリュームへ取得し — この機能で外向き通信を必要とする唯一のコンテナです — コアがそのファイルを定期的に（YAGRA_IPASN_RELOAD_SECS）ホットリロードします。再起動は不要です。

AS の名前は保存レコードに焼き込まれるのではなく読み取り時に解決されます — そのため、データセットが名前を更新すると、過去の履歴にも現在の名前が表示されます。

フローの探索

すべてのノードの詳細ページに Flow タブが付きます。

トップトーカー、トップポート、トッププロトコル — そのノードのトラフィックのランキングカード。
Top AS — トラフィックの背後にある自律システム。ドリルダウンできます。
会話 — 誰が誰と通信しているかの表と、同じ会話の Sankey 図。アドレスと並べて送信元・宛先の AS も表示されます。

これらのビューはインタラクティブです。任意のトーカー、ポート、プロトコル、AS をクリックするとタブ全体をそれで絞り込めますし、プロトコル・ポート・ピア・AS のフィルタを組み合わせて特定の問いを追いかけられます。

ノードごとのタブ以外にも次があります。

ダッシュボードにはフリート全体のトラフィックフローウィジェットのセクションがあります — トップトーカー、Top AS、トップポート、プロトコルの内訳、会話 Sankey、トラフィックのトレンド — 1 ノードずつではなくすべてのエクスポーターを横断して読み取ります。
Troubleshoot 画面にはフローに基づく分析（トラフィック異常、トーカーの変化、新規宛先、スキャン検知）と、メトリクス・イベント・フローをまとめて読むクロスシグナルの分析が含まれます。
AI クライアントは MCP ツール top_flows と flow_fanout から同じデータを取得できます。

リモート拠点での収集

拠点は中央の ClickHouse へのトンネルを必要としません。拠点の機器をその拠点自身のポーラーに向けてください。ポーラーがローカルでエクスポートを受信して集約し、フローバッチは 1 本の外向き TLS バス接続に乗って本社へ届きます — ポーリングのジョブと結果をすでに運んでいるのと同じ接続です。拠点側のインバウンドポートは不要で、中央のファイアウォールにも新しい穴は要りません。

ただしフローはリモートポーラーにとって実際の WAN トラフィックを増やします。ポーラーは元のデータグラムも原本のまま運ぶからです（それがバイト単位で正確な転送を可能にしています）。エクスポーターがどれだけ密にデータグラムを詰めるかにもよりますが、おおよそ 1,000 flows/s あたり 0.4–1.0 Mbit/s を見込んでください — 帯域見積りの詳しい議論はポートとファイアウォールにあります。

レート制限とチューニング

フロー受信には syslog/トラップの予算とは別のトークンバケット制限があり、データグラム単位で数えられます（レコード単位ではありません — 1 つの NetFlow データグラムは数十のレコードを運べます）。

制限	既定	変数
送信元（エクスポーター）ごと	`1000` データグラム/秒	`YAGRA_FLOW_RATE_PER_SOURCE`
グローバル（全エクスポーター）	`20000` データグラム/秒	`YAGRA_FLOW_RATE_GLOBAL`

いずれも持続レートの最大 2 倍までのバーストを許容します。制限を超えたデータグラムはリスナーで破棄されます。エッジがバスとストアを守るので、暴走した 1 台のエクスポーターが他を締め出すことはありません。そもそも統計的なデータであれば、最も声の大きい送信元のサンプルを落とすのが、いちばんましな壊れ方です。

フロー関連のつまみの一覧です。

変数	既定	制御対象
`YAGRA_CLICKHOUSE_URL`	未設定（フロー無効）	ClickHouse のフローストア — 必須
`YAGRA_FLOW_BIND`	compose で設定（`0.0.0.0:2055`）	NetFlow/IPFIX リスナー
`YAGRA_SFLOW_BIND`	未設定（無効）	sFlow リスナー
`YAGRA_FLOW_BUCKET_SECS`	`60`	集約バケットの幅（秒）
`YAGRA_FLOW_TOP_N`	`500`	エクスポーターごと・バケットごとに保持するフロー数
`YAGRA_FLOW_RATE_PER_SOURCE`	`1000`	エクスポーターごとのデータグラムレート上限
`YAGRA_FLOW_RATE_GLOBAL`	`20000`	グローバルのデータグラムレート上限
`YAGRA_FLOW_RETENTION_DAYS`	`30`	ClickHouse の保持期間（1–3650）
`YAGRA_IPASN_DB`	未設定（補完無効）	IP→ASN データセットのパス
`YAGRA_IPASN_RELOAD_SECS`	`0`（起動時に 1 回）	データセットのホットリロード間隔

非常に流量の多いエッジでは、共有のリスナー設定 — YAGRA_LISTENER_WORKERS（リスナーごとの並列読み取りソケット数。既定はホストの並列度、上限 4）と YAGRA_LISTENER_RCVBUF_BYTES（ソケットごとの受信バッファ、既定 4 MiB）— を引き上げることもできます。これらはフローだけでなく、すべてのパッシブリスナーに適用されます。

詳細と compose 側のポート変数は設定リファレンスにあります。