まずは各技術の紹介を行います。

1. xFlow

xFlowとは、NWに流れるトラヒックをフロー単位で監視・分析する為の技術です。
フローとは同じような通信をまとめる単位で、一般的には5tuple(送信元IPアドレス/宛先IPアドレス/送信元ポート番号/宛先ポート番号/プロトコル種別)が同一の通信を1フローとします(※)。
これにより、どこからどこにどのような通信がどれぐらい流れたかがわかるようになります。
　※ 実装や設定により異なる単位でフローを識別する場合もあります。

SNMP(Polling)やTelemetryでNW機器のIFカウンターを取得することで、全体の流量は掴めますが、その用途や内訳までは追えず、できる分析にも限りが生じます。
つまりはフロー毎の分析や確認により、全体の流量から一段解像度を上げた、より細かな確認ができるようになることがxFlowを活用するメリットと言えます。

図2 xFlow利用のメリットイメージ

では、トラヒックの解像度を上げられると何が嬉しいのでしょうか。
主な利点として「利用通信量の説明性の向上」や「平時と比較した際の異常通信の発見可能性の向上」があげられます。

例えば平時では、ある送信元からある宛先(Webサイト)への通信はあまり起きていないが、突然短い期間で急激に通信量が上がったとします。
この場合はDoS攻撃に使われている可能性があるかもしれません。

図3 フロー確認のイメージ(DoS想定)

別の例として、一部の通信で突発的なパケットロスが発生した場合を考えてみます。
この場合には「特定のサービスの通信量が急増し、他の通信に影響を与えている」といった根本原因まで特定できる可能性もあります。

前述の通り誰がいつ、どこにどれだけ通信したかを明らかにできる為、通信サービス利用量の説明やNW管理/設計改善(設備増強などの判断)にも利用できるかもしれません。

このような使い方はセキュリティ観点での導入目的とも親和性が高く、通信事業者に限らず一般企業でも導入・活用しやすい点も特徴です。

なお、通信量は利用サービスや利用方法など、様々な条件に応じて変化します。
例えば動画サービスや会議システムなどでは、同じ送信元から宛先まで連続的にトラヒックが流れる一方、シンプルなWebアクセスであればトラヒックはそこまで多くならないでしょう。
したがって「平常時はどういう傾向なのか」を把握しておくことが重要です。

xFlowという言葉はフローを見る為の技術群の総称でもあります。
以下に代表的な技術を記載します。

技術名	概要
NetFlow	Cisco社が開発した技術。 v9がメジャーで、RFC 3954にてCategory: Informationとして定義されている。
IPFIX	NetFlow v9をもとにIETFにより定義された技術。 RFC 7011にてCategory: Standards Trackとして定義されている。
sFlow	InMon社が開発した技術。 全体から一部を抽出（サンプリング）してデータ生成する。 RFC 3176にてv4レベルはCategory: Informationとして定義されているが、メジャーであるv5レベルはsFlow.org上に文書にて定義している。

それぞれは「フローを分析する」為の技術を提供する点は共通していますが、微妙にパケット構造や仕組み、使う言葉は異なります。

xFlowを用いる場合は、xFlow情報を出力するNW機器(エクスポータ)と、その情報を受け取り保存するコレクタ、分析を行うアナライザーが必要です。

図4 xFlowを扱う場合のコンポーネントについて

利用する際にはNW機器やフローコレクタ/アナライザーがどのxFlow技術(NetFlow/IPFIX/sFlowなど)に対応しているか確認し、それぞれが対応可能な技術を使いましょう。
基本的にはIPFIXやsFlowが多くのベンダーで実装されたものとなっています。
NetFlowはCisco由来ではありますが、他ベンダーでも利用できることもあります。

xFlow技術を活用する場合には「サンプリング」という考え方も当てはめられます。
全ての通信を対象に分析を行おうとした場合、NW機器/コレクタ/アナライザーの処理、通信路の負荷が上がり、必要なストレージ容量も増えることになります。
そこで例えば10パケットきたら1つだけを処理の対象とする(サンプリングレートを1/10とする)、というように一部のみを抽出することで負荷を下げることができます。
これにより負荷を下げつつ、統計的に概ねの傾向を掴むことができます。

図5 xFlowにおけるサンプリングイメージ

ただし全てのパケットを対象としていない為、少ない通信は取りこぼす可能性もあり、厳密な通信チェックには利用できなくなるデメリットもあります。
このようなデメリットの大きさはサンプリングレートの数値により変化します。（例: 1/10と1/1000では、取りこぼす通信パターンも変わる）

また、xFlowの出力はNW機器ごととなる為、どこで取得するか検討することも重要です。
基本的にはフロー情報をみて何がしたいか、という目的を整理してから、その目的を達成する為にどこで取得するべきなのか整理できると良いでしょう。

なお、NetFlow v9やIPFIXはテンプレート方式により、出力する情報を一定レベルで変える事ができます。

図6 テンプレート方式のイメージ図

また、最初にフローは一般的に5tupleで判断されると記載しましたが、フローの判断基準も5tuple以外に変更できることもあります。
どこまでできるかはNW機器/NOSバージョンによります。

最後にフローの情報送信タイミングについて説明します。
同じような通信を1フローとして分析するということは、パケットが来たらそのタイミングで常に送信するような形式ではないと想像がつくかと思います。（1パケットずつ送信していたら同じような通信を1フローとしてまとめる意味がない為）
方式は技術によっても異なりますが、NetFlow/IPFIXを例に説明すると一定期間分析して、その時間が経過したらそのフローがどういうものだったか送信するという形式になります。

一定期間の経過という点においては以下の2つの概念があります。
　① active timeout: 当該フローを連続で受信している(inactive timeoutの条件に載らない)状態で、最初のフロー受信から一定時間たった場合
　② inactive timeout: 最後に当該フローを受信して一定期間たった場合

図7 active timeoutとinactive timeoutの違い

2つ概念はあるものの、概ね当該フローを受信してから一定時間たったら送信、という形になります。
したがってNW機器にフローが通った時間とNW機器がフロー情報を送信した時間、コレクタ/アナライザーにフロー情報が到達した時間はズレますが、一般的にはコレクタ/アナライザー側にてズレを吸収して表示・分析してくれます。（※）
　※ コレクタ/アナライザーの仕様によります。

2. Streaming Telemetry (Telemetry)

TelemetryはNW機器から定期的、かつ高頻度で情報を取得することができる技術です。
xFlowはフロー情報を収集・取得していましたが、TelemetryはNW機器の設備情報やルーティング情報を取得する事に強みがあります。
またxFlowは特定パケットが来たタイミングを起点に一定時間たったら情報を送信しますが、TelemetryはPub-Subモデルであるため、定期周期（例：60秒ごとに送信）となります。

詳細はこちらもご確認ください。
[参考] Telemetryとは (https://www.ntt-tx.co.jp/column/241223/)

3. In-band Network Telemetry (INT)

INTはデータプレーン(D-Plane, ASICなど)にてNW情報を取得する技術で、トラヒックベースで情報を見ることができます。
また、D-Planeでパケット処理を行う為の言語であるP4言語やその関連技術を扱うP4.org上にて仕様が公開されています。
この技術にも「Telemetry」という言葉が入っていますが、Streaming Telemetryとはもはや別の技術と考えた方が理解しやすいかと思います。

INTには大きく以下3つの動作モードがあります。

モード	説明
INT-XD	各NW機器(INTノード)が設定に従ってデータを出力する。 実際に流れるパケットに変更はしない。
INT-MX	実際に流れるパケットに指示文(指示ヘッダ)を埋め込んで、 区間内のNW機器はその指示文にしたがって情報を出力する。
INT-MD	実際に流れるパケットに指示文と情報を詰め込んでいき、 区間内最後のNW機器で情報を出力する。

ポイントは実パケットベースで情報を見れる点と、モードによっては実パケット（※）にデータを埋め込む点です。
　※ 使い方次第で検証用パケットやミラーパケットにも適用可能です。

各モードの違いは説明だけだとわかりづらい為、以下の図も確認ください。

図8 INT-XDの動作イメージ

INT-XDのイメージはわかりやすいかと思います。
なお、NWの入り口/出口にいるNW機器をエッジルータと呼び、間にいる機器を中継ルータと呼んだりもしますが、INTの始点/終点を必ずしもエッジルータとする必要はありません。
データを取りたい区間にあわせて設定するのが良いかと思います。

図9 INT-MXの動作イメージ

INT-MXは始点となるNW機器（ソースノード）で、当該パケットに指示文となるinstruction headerを追加します。
また、終点となるNW機器（sinkノード）でinstruction headerを除去します。

図ではパケットの末尾に追加データを入れているように見えるかもしれませんが、実際はinstruction headerの名前が示す通り、headerを追加します。

図10 ヘッダ追加の概要図

なお、上の図はあくまでヘッダ追加のイメージ概要となる為、細部は動作条件に応じて変わる点はご承知おきください。

図11 INT-MDの動作イメージ

INT-MDは、INT-XDやINT-MXのように区間内のNW機器がすべてデータを監視基盤に送るのではなく、終点となる機器(sinkノード)がまとめて監視基盤にデータ送信を行います。
sinkノードがまとめて送信を行えるようにするために、始点となる機器(ソースノード)や中継機器(transitノード)は実際のパケットに自身が取得したデータを積み上げていく形で追記を行います。
なお、各ノードで追加する情報をmetadataと呼びます。

モードのメリット/デメリットの概要は以下の通りです。

モード	メリット	デメリット
INT-XD	・実パケットを変更しない。	・各ノードにそれぞれデータ収集対象とするパケット条件(flow watchlist)などの設定が必要となる。 ・同一トラヒックの情報が各ノードから別々に送られてくる為、監視基盤側で紐づけが必要。
INT-MX	・実パケットへの変更を最小限に抑える。 ・各ノードに設定は一定必要だが、中継機はinstruction headerでデータ収集を判断する為、必要な設定は減少。	・最小限ではあるが、実パケットの加工が発生する。 ・同一トラヒックの情報が各ノードから別々に送られてくる為、監視基盤側で紐づけが必要。
INT-MD	・同一トラヒックの情報がsinkノードからまとめて送られる為、監視基盤側でのチェックがしやすい。	・実パケットへの変更が大きい（ノード通過ごとに追記されていく） ・sinkノードの処理が大きくなりやすい。

INT-MXやINT-MDはU-Plane、すなわちユーザ通信パケットそのものに加工を加える為、注意が必要です。
また条件によっては処理が重くなる可能性もある事から、ユーザ通信に影響を与えないようにCPUなどではなく、D-Plane(ASICなど)で処理をすることが強く意識されています。

どのような仕組みで動くかが見えたところで、次はINTで取得できるデータについて説明します。
INTの仕様では以下が取得できるとされています。

概要	取得できる情報
機器レベル	機器ID
Ingress (入力側)	IF-ID
	timestamp
Egress (出力側)	IF-ID
	timestamp
	hop latency (転送処理にかかった時間)
	tx link utilization (出力ポートの使用率)
	queue occupancy (キュー滞留数)
	buffer occupancy (バッファ領域の滞留数)

当該パケットが通った時間やその時の条件などがわかる、ということですね。
したがって実際のユーザ通信の経路情報やどの区間で遅延が起きているか、などがわかるようになると言えます。

図12 INTの活用イメージ

このような情報は、「繋がらない」と連絡がきた後に、切り分け方法の1つとして活用することで原因特定を早めたり原因の絞り込みに繋げられる可能性もあります。

疎通確認や経路確認であれば、pingやtracerouteで十分なのでは？と思う方もいるかもしれません。
しかしパケットによって通るルートが異なる場合（例えばECMPにより通信経路が分散される（ロードバランスされる）環境）、必ずしもping/tracerouteとユーザ通信が同じ経路を通るとは限りません。
また、pingやtracerouteではNW機器自体の処理時間や滞留情報も表示されない為、ユーザ通信の実態をより正確に把握する目的/手段としてはINTに軍配が上がります。

図13 ping/tracerouteとユーザ通信の経路が異なる場合

ユーザトラヒックをベースに情報を見ていく、かつD-Planeでの処理を強く意識している点がINTの機能的特徴といえます。
　※ 似たような技術にIOAMがあります。

ここまで紹介してきた各技術を活用できるかどうかは、各NW機器の実装状態によります。
一般的には xFlow > Streaming Telemetry > INT の順で普及が進んでいる印象です。

さて、各技術の使い分けを改めておさらいしましょう。

観点	xFlow	Streaming Telemetry	INT
特徴(強み)	・NWに流れるトラヒックをフロー単位で情報収集 ・通信の全体傾向を掴むことに向いている	・高頻度で情報を出力可 ・幅広い情報の取得範囲	・D-Planeにて高速処理 ・実トラヒックベースに情報収集
監視対象	NW機器に流れたフロー情報。	NW機器の設備情報やルーティング情報など。	NW機器に流れてきたパケットに関連する情報。
ユースケース例	実パケットの通信内訳確認(用途やユーザごと)や流量分析、NW設計改善	リソース状態監視や通信状態の時系列/傾向分析	対象トラヒックごとの通信経路や遅延状態の確認
単体運用時の課題例	NW機器内部の情報や通信経路情報がわからない。	パケットカウンター(dropカウンターなど)が上がった場合にどのようなパケットが影響を受けたのかわからない。	パケットロスや遅延の原因を深堀りする際の対応範囲が限定的。(滞留数などとなる)

　※ 各技術はどれも特定ベンダーでしか使えない技術というよりは、共通的な技術です。したがってマルチベンダーで対応可能なものもありますが、どこまでできるかや細かい仕様・実装はベンダー差分がある可能性があります。

このように各技術見ている範囲が異なることがわかるかと思います。
「単体運用時の課題」も、他技術と併用することで対処できるものもあるように見え、それぞれが補完関係にあることがわかるかと思います。

図14 各技術の補完イメージ

したがって、併用して活用する事で相乗効果を生むことができるかと思います。

また、これらの技術は「はじめに」節で紹介したような従来の監視技術と比較して新しいものであり、従来技術を一部代替できる点はあっても完全に置き換えるものでもありません。
以下に参考として、今回紹介した技術と従来技術(代表的な手法)の強み/弱みも記載したいと思います。

技術・手法名	強み/特徴	弱み/注意点
xFlow	・NWに流れるトラヒックをフロー単位で情報収集 ・通信の全体傾向を掴むことに向いている	・パケット単位レベルの細かな分析には向かない ・サンプリングを行う場合は、統計的な傾向の取得となり、分析対象外となるフローが発生する
Telemetry	・高頻度で情報を出力可 ・幅広い情報の取得範囲	・取得データ量が増加する傾向にあり、ストレージや監視用の通信帯域の利用量/負荷も増える ・マルチベンダーに対応できるOpenConfigであっても、どこまで対応しているかは機種/NOSバージョン次第であり、NW機器差分が大きい
INT	・D-Planeにて高速処理 ・実トラヒックベースに情報収集	・新しめの技術で対応機器が少ない ・ユーザトラヒックを加工するモードは商用導入ハードルが高い。加工しないモードは監視基盤での紐づけが必要 ・サンプリングを行う場合はxFlow同様、対象外となるものが発生する
SNMP Polling	・最も普及した監視技術で多くの機器が使える ・技術的に成熟している	・機器に与える負荷が高めで高頻度取得には向かない
SNMP Trap	・問題発生時や警告状態に入ったことをトリガーとした、早期の情報送信	・問題や警告状態にならないと通知されない ・SNMPはUDPベースの為、ロスした場合再送されない
Syslog	・イベントやログとして情報出力されるため、障害理由や周辺イベントを追いやすい ・人が読みやすい形式である ・Syslogにしか表示されないものの存在	・イベント契機で出力されるため、情報が出たときには異常が起きている場合がある ・ベンダーや機種/OSごとに出力が異なる場合がある ・非構造化データ
パケットミラーリング ＋パケットキャプチャ	・ある通信処理でどの処理まで進んだか/どこで詰まったか、といった詳細な通信の流れを追えることや実パケットの詳細な構成を確認可能	・情報量が多い。 ・NW機器でミラーリングする(SPAN)場合、負荷が大きくなる可能性あり
CLIやAPIによる情報収集	・他の方法(例:SNMPやTelemetry)では取れない情報の確認	・確認する内容によっては重く、NW機器に影響を与える可能性がある ・CLIの場合、非構造化データ
ping	・簡易/軽量にL3レベルのEnd to End(E2E)/特定区間の疎通確認が可能 ・保守者やシステムトリガーで自由なタイミングで確認できる ・RTT確認となる為、往復路の状態確認も可	・複数のhopを重ねる場合、ユーザトラヒックと異なる経路で動く場合がある ・往路と復路のどちらに問題があるかが切り分けしづらい ・途中経路が見えない(tracerouteで代用可)

以下の図はNW機器Aに関連した監視情報を取得する際に、それぞれの技術はどう異なるのか（どう使うか）を示したものです。

図15 NW機器Aに関連した監視情報を取得する際のイメージ例

監視のフェーズには大きく「定常監視」「異常の発生」「異常の原因調査」があるかと思います。
いずれの監視技術から取得した情報もすべてのフェーズで活用できますが、それぞれに強みを発揮しやすいフェーズがあります。
以下の図にその関係を示します。

図16 各監視フェーズと活用する情報例

「定常監視」のタイミングで異常の予兆を見つけて、事前に先回りして対処できることが理想かと思います。
従来技術でもルールベース(例: SyslogのWARNをチェックする)やAIといった仕組みを活用すれば予兆の発見は可能かと思いますが、xFlowやINTを使うことでより幅を広げられたり、Telemetryによる高頻度な収集でより細かな予兆や変動にも気づける可能性を上げられます。

また「異常の原因調査」は、いわばIT/NW監視における総合格闘技のような状態で、あらゆる監視情報を活用して原因の特定を目指します。
その点で情報は多ければ多いほど原因特定や深堀りの助けとなるでしょう。

このようにNW監視技術は多様化していますが、それぞれに強み・弱みがあるため、使い分けを意識して活用・設計することが重要です。

また多くの技術を並列で動かした場合には、必然的に異常や警告状態を示すアラートが増えることが考えられます。
一方で、それぞれのアラートは関連するもの（例えば同一の異常事象を複数の技術で検知しているケース）も多くあるかと思います。
したがって各監視技術/活用技術を1つの監視基盤で統合管理し、様々なアラームを事象ごとに関連付けていく（＝アラームコリレーション）事が理想です。
NWの場合はある事象が他の事象を誘発することもあるため、同じ事象をまとめるだけでなく、事象と事象を紐づけていくことも検討できると、なお良いでしょう。
関連付けにあたっては、ルールベースで整理していくことも重要ですし、昨今では生成AIを活用することで整理していく方法も期待できます。

なお、多くの仕組みを動かせばそれだけNW機器/管理NW/監視基盤への負荷も上がっていきます。
特にNW機器に関してはユーザ通信に影響がない範囲に留める必要性があることは言うまでもありません。
複数のNW機器を管理しているOpSやEMSがいる場合や既に特定技術で監視情報を管理しているシステムがいる場合は、監視情報の統合管理を行うために追加でNW機器から収集するのではなく、システム間連携で対応するという案も取りえます。