トラフィックフロー

ヘルス監視は「このリンクの使用率は 80% です」と教えてくれます。フロー監視が教えてくれるのは、 そこに何が流れているのかです。

Yagra は、機器がもともとエクスポートできるフローのレコードを集めます。そしてそれを、トップトーカー、会話、ポートとプロトコルの内訳、AS 単位のビューに変えます。

これらは、すでにお使いのメトリクスやアラートと並べて見られます。ただし動作は完全に独立しています。フローを無効のままにしておけば、他には何も変わりません。

概要

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

NetFlow v5 と NetFlow v9
IPFIX
sFlow v5

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

フローのレコードは、専用の ClickHouse ストアに保存します。メトリクスの TSDB とも、メタデータのデータベースとも別です。

これはこの機能の必須条件です。有効にするには YAGRA_CLICKHOUSE_URL を設定します。設定しない場合、フロー収集は無効になり、フローの API は理由の分かる 503 を返します。ですから WebUI は、空のグラフを見せる代わりに「未設定」と表示できます。

単一ノードの compose スタックには、URL を設定済みの ClickHouse サービスが最初から入っています。ですからそこではフローがそのまま動きます。自分で組んだデプロイでは、このストアは自分で有効にします。

設定 ▸ Yagra ヘルスは、フローストアを他のバックエンドストアと並べて表示します。ですから 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 やトラップと違い、これらはもともと 1024 以上のポートです。ですからホストとコンテナのポートは同じで、転送ルールも要りません。

機器側では、フローエクスポートの送信先を <poller-host>:2055 に設定します（sFlow なら :6343）。この機能の呼び名はベンダーによって違い、NetFlow export、NetStream、IPFIX export、sFlow エージェントなどと呼ばれます。

最初のエクスポートが届いてから 1〜2 分すると、ノードの Flow タブに最初のデータが出ます。レコードは 60 秒ごとのまとまりに畳み込むので、画面はそのまとまり単位で埋まっていきます。

sFlow は、間引いて送るプロトコルです。1 つのサンプルが N パケットぶんを代表します。ですから Yagra は、バイト数とパケット数をそのサンプルの間引き率で割り戻し、実際のトラフィックを推定します。

sFlow の数値は「精度の高い推定値」であって、正確なカウンタではないと考えてください。これはプロトコルの性質であって、Yagra の制限ではありません。間引いて送られる NetFlow v5（エクスポートのヘッダーに間引きの間隔が入っているもの）も、同じやり方で割り戻します。

フローも、syslog やトラップと同じくポーラーが受け取ります。ですから追加の配線なしで、リモート拠点でも動きます。詳しくは後述のリモート拠点での収集にあります。

フローの保存方法

忙しい機器から出る生のフローエクスポートは、量が膨大です。しかもその大半は、細かいノイズです。そこで Yagra は、バスに何かが流れる前に、拠点側のポーラー上でまとめます。

レコードを 60 秒ごとのまとまりに畳み込みます（YAGRA_FLOW_BUCKET_SECS）。
そのまとまりの中で、ポーラーはエクスポーターごとにバイト数の多い上位 500 フローだけを残します（YAGRA_FLOW_TOP_N）。

これが、実質的な量の制御です。機器がどれだけエクスポートしても費用に上限を設けつつ、「このリンクに何が流れているのか」に答える重いフローは残します。
まとめたバッチはバスに乗ってコアへ届き、コアがそれを ClickHouse へ書き込みます。

この割り切りは意図的です。リンクを占有する重いフローは、そのまま正確に残ります。上位だけを残す処理が落とすのは、ごく小さなフローの集まりです。

「何がこのリンクを埋めているのか」「誰が誰と通信しているのか」を知りたいのなら、生のデータ量のごく一部で、これが正しい答えを出せるデータになります。

保存される 1 件のレコードには、会話の送信元と宛先のアドレスとポート、プロトコル、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 サイドカーが、決まった間隔（既定は週 1 回、 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 側のポート変数は設定リファレンスにあります。