PRTGでトラフィック調査： どんなトラフィックが帯域幅を占有しているのか？ 後編

本記事は2018年1月19日に公開したものをアップデートしたものです。

以前「だれが帯域幅を消費しているのか?」というブログでトラフィックの現状を調査する手法を概説いたしました。その中ではIP層のトラフィック量をSNMPで把握することやネットワーク機器のフロー情報やポートミラーリングを利用してトラフィックの状況を把握することをご紹介いたしました。

今回のテーマではより具体的な例を挙げて、トラフィックの中身をPRTGのフロー系センサーを使用して調査する方法をご紹介いたします。

前編ではフローデータに関連するセンサーとその機能をご紹介しました。後編ではより実践的な使い方をご紹介いたします。

以下sFlow、NetFlowなどを総称してxFlowと表記します。

PRTGのxFlowセンサー、設定のポイント

フローデータ送信側の設定（ネットワーク機器）

マニュアルにしたがって、xFlowエージェントの設定でPRTGのIPアドレスと宛先UDPポートを指定します。
…またみなさまに怒られそうなことを書きましたが、世の中には多くの機器がありますので、私どもも全てについて把握できておりません。申し訳ございませんが個別の機器の設定についてはマニュアルで調べてください。

ただし「フロー収集」の方針についてはあらかじめ検討をしてください。設定によってはトラフィックのダブルカウントが発生して何を計測しているのかわからなくなってしまうからです。

インターフェースで計測できるフロー情報

インターフェースで計測できるフロー情報には2つの向きがあります。

  • 機器に入ってくる通信を計測したもの　<ingress>
  • 機器から出ていく通信を計測したもの　<egress>

一般に<ingress>についてはどのフローデータでも使用できます。<egress>あるいは<ingress, egress両方>が使用できるかは機器により異なります。

目的によりますが、以下の図のようにどちらかの方法で統一して設定するとわかりやすくなります。

≪方針A：全てのインターフェースのフローを<ingress>で測定する≫
「Ingress」のフロー計測例

一見すると全トラフィックが把握できないようにみえます。しかしフローデータはIPのEnd to Endの情報ですので、全部のトラフィックについて計測していることになります。（入るもの≒出るもの）

≪方針B：特定のインターフェースのフローを<ingress, egress両方>で測定する≫
「Ingress, Egress」のフロー計測例

「方針B」は測定の対象を限定できる場合に使用します。例えば、サーバーとの通信やインターネットとの通信について、インターフェースを指定して設定します。

計測箇所が明確なので取得したデータがわかりやすいのが利点です。ただし使用する機器によってはこの選択肢は選べないことがあります。またこの図の例ではクライアントPC同士の通信は計測されません。

フローデータ受信側の設定（PRTG）

xFlowセンサーは、どの「デバイス」に追加しても動作します。機能検証時は、ポーリング系のセンサーと異なることをはっきりさせるために、プローブデバイス※にセンサーを追加してもよいでしょう。※プローブデバイスはPRTG自体を疑似的なデバイスとしてPRTGの中で表示したものです。

設定のポイント

以下、よく使われるNetFlowセンサーとsFlowセンサーを例に、設定のポイントのみ書きます。

≪NetFlowとsFlow共通の設定≫
設定項目NetFlow V5,V9sFlow V5
受信するIPアドレスエージェントの送信先IPと一致させるエージェントの送信先IPと一致させる
受信UDPポートエージェントの設定と一致させる(デフォルト値なし)エージェントの設定と一致させる(デフォルト値6343)
送信元IP※１※１
ストリームデータをディスクに記録 （デバッグ用）「その他」チャンネルのみ※２「その他」チャンネルのみ※２

※１：正常にフローデータが受信できるまでは「送信元IP」を設定しない方が確認が容易です。実運用ではフローデータを送信したエージェントを特定するために設定することをお勧めします。設定した場合は他のエージェントのデータを受信しません。後述するデバッグログに記録された「SenderIP」を確認して設定する方法が確実です。
※２：推奨設定値は『なし』です。今回のブログでは『「その他」チャンネルのみ』を利用する例を紹介しています。

≪NetFlow固有の設定≫
設定項目NetFlow V5,V9備考
アクティブフロータイムアウト（分単位）NetFlowエージェント側の設定＋1分例：エージェントの設定がアクティブフロータイムアウト300秒(5分)なら「6分」にします。
※注
サンプリングモード通常オフ

※注：エージェントの設定がデフォルト値1800秒(30分)のとき、通信が継続している場合は30分経過しないとフローデータが送信されません。送信されるまでの間のトラフィックはPRTGで表示されません。⇒それまでデータが見えません。

フローデータがうまく受信できない場合

フローデータがうまく受信できない場合がありますが、単純な設定ミスなのか、ネットワーク経路上のファイアウォールの影響なのか判別しにくいことがあります。

メーカー提供のWindows用ツールを使用すると原因を特定しやすくなります。

ここでは詳細に解説いたしませんが、基本的な使い方は、PRTGを停止し替わりにツールを動作させて、フローデータの受信確認をします。

  • PRTGのPCの上でツールを動作させて、全く何も受信できない場合は、(Windows)ファイアウォールのルールを追加する必要があるかも知れません。設定したUDPポートへの通信が受信ルールで許可されているか確認してください。
  • エージェントがあるネットワークセグメントと同一セグメントのWindows PCが利用できる場合は、そのPCでツールを動作させて受信できるか確認します。受信できる場合はエージェントとPRTGの間のファイアウォールの設定を確認します。
    ※テストする間はエージェントのデータ送信先IPをツールが動作するPCのIPへ暫定的に変更します。

xFlowセンサーのチャンネル定義

うまく設定ができたでしょうか？データが受信できるようになると前編のような画面が表示されます。

sFlowセンサーの全般タブのデータテーブル

このようなデータテーブルが表示されて値が確認できたでしょうか。

チャンネル構成

今回は受信ができていることを前提に先の説明をいたします。
センサーの設定を見ていただくと、次の「チャンネル構成」セクションがあります。

チャンネル構成

「グループ」には”Intrastructure”など、やや大まかな内容を示す語が使用されており「内容」はもう少し詳細な”DHCP”などの語が使用されています。

「チャンネル構成」では”DHCP”,”DNS”など詳細に分けたものをチャンネルとするか、”Intrastructure”のようにそれらを合計したグループをチャンネルとするかを、選択することができます。

このグループや内容（チャンネル）には、次のような分類ルールの定義がされています。

≪xFlowセンサーで表示されるチャンネルの定義≫
グループ チャンネル ルール
WWW
(Web)
 HTTP Protocol[TCP] and ( SourcePort[80] or DestinationPort[80] or SourcePort[8080] or DestinationPort[8080])
HTTPS Protocol[TCP] and (SourcePort[443] or DestinationPort[443])
FTP/P2P
(File Transfer)		 FTP (Control) Protocol[TCP] and (DestinationPort[20-21] OR SourcePort[20-21])
Mail
 IMAP Protocol[TCP] or Protocol[UDP]) and ( DestinationPort[143] or SourcePort[143] or DestinationPort[220] or SourcePort[220] or DestinationPort[993] or SourcePort[993])
POP3 Protocol[TCP] and (SourcePort[110] or DestinationPort[110] or SourcePort[995] or DestinationPort[995])
SMTP Protocol[TCP] and (SourcePort[25] or DestinationPort[25])
Chat
 IRC Protocol[TCP] and (SourcePort[6667] or DestinationPort[6667])
AIM Protocol[TCP] and (SourcePort[5190] or DestinationPort[5190])
Remote Control
 RDP Protocol[TCP] or Protocol[UDP]) and (SourcePort[3389] or DestinationPort[3389])
SSH Protocol[TCP] and (SourcePort[22] or DestinationPort[22])
Telnet Protocol[TCP] and (SourcePort[23] or DestinationPort[23])
VNC Protocol[TCP] and (SourcePort[5800] or DestinationPort[5800] or SourcePort[5900] or DestinationPort[5900])
Infrastructure
 DHCP Protocol[UDP] and ((SourcePort[68] and DestinationPort[67]) or (SourcePort[67] and DestinationPort[68]))
DNS Protocol[TCP] or Protocol[UDP]) and (SourcePort[53] or DestinationPort[53])
Ident Protocol[TCP] and (SourcePort[113] or DestinationPort[113])
ICMP Protocol[ICMP]
SNMP Protocol[UDP] and (SourcePort[161-162] or DestinationPort[161-162])
NetBIOS NETBIOS Protocol[TCP] OR Protocol[UDP]) AND (DestinationPort[137-139] OR SourcePort[137-139])
Citrix Citrix Protocol[TCP] and (Port[1494] or Port[2598] or Port[2512])
Various
 OtherUDP Protocol[UDP]
OtherTCP Protocol[TCP]

受信したフローデータの評価は上の定義から順番にされます。
最後の”Various”グループにはOtherUDPとOtherTCPがあります。それより上の定義でマッチしなかったUDPやTCPはここで集計されます。
さらに、この定義のすべてに当てはまらなかったフローデータは「その他」チャンネルで集計されます。「その他」はセンサーが上の定義とは別に提供するチャンネルです。

「Various」と「その他」という似たような意味のチャンネルが、それぞれある理由がおわかりいただけましたでしょうか。

チャンネル定義についての詳しい説明は以下のURLを参照してください。
ｘFlowセンサーで使用できるフィルタールール(英文)

xFlow カスタムセンサーの活用

上記のチャンネル定義は一般的なものになっておりますので、環境によっては期待しているデータが計測できないことがあります。計測できないフローデータの内訳を確認する方法についてこれからみていきます。

計測できないフローデータの内訳を確認する方法

前述の標準xFlowセンサーの定義はXMLファイルで設定されています。カスタマイズしてチャンネル定義を変更できますが※、次の場合は「xFlow （カスタム）」センサーを使うと便利です。

  • トラフィックの調査のために頻繁にチャンネル定義を変更したい
  • センサー毎にチャンネルの定義を変更したい

※XMLファイル:FlowRules.osrをコピーしてCustomFlowRules.osrを作成します。CustomFlowRules.osrファイルを編集してチャンネル定義を変更するとそちらが優先されます。詳細は次のURLのナレッジベース(英文)をご確認ください。

「xFlow （カスタム）」センサーのチャンネル定義

「xFlow （カスタム）」センサーの設定には「チャンネル定義」のセクションがあります。そのほかの設定は、名前にカスタムが付かない標準xFlowセンサーと同じです。

≪標準のセンサーの定義をカスタム付きセンサー用の定義に変換したもの≫

#1001:HTTP
Protocol[TCP] and ( SourcePort[80] or DestinationPort[80] or SourcePort[8080] or DestinationPort[8080])

#1023:HTTPS
Protocol[TCP] and (SourcePort[443] or DestinationPort[443])

#1024:FTP (Control)
Protocol[TCP] and (DestinationPort[20-21] OR SourcePort[20-21])

#1006:IMAP
(Protocol[TCP] or Protocol[UDP]) and ( DestinationPort[143] or SourcePort[143] or DestinationPort[220] or SourcePort[220] or DestinationPort[993] or SourcePort[993])


#1008:POP3
Protocol[TCP] and (SourcePort[110] or DestinationPort[110] or SourcePort[995] or DestinationPort[995])

#1011:SMTP
Protocol[TCP] and (SourcePort[25] or DestinationPort[25])

#1007:IRC
Protocol[TCP] and (SourcePort[6667] or DestinationPort[6667])


#1025:AIM
Protocol[TCP] and (SourcePort[5190] or DestinationPort[5190])


#1009:RDP
(Protocol[TCP] or Protocol[UDP]) and (SourcePort[3389] or DestinationPort[3389])

#1014:SSH
Protocol[TCP] and (SourcePort[22] or DestinationPort[22])

#1016:Telnet
Protocol[TCP] and (SourcePort[23] or DestinationPort[23])

#1017:VNC
Protocol[TCP] and (SourcePort[5800] or DestinationPort[5800] or SourcePort[5900] or DestinationPort[5900])

#1003:DHCP
Protocol[UDP] and ((SourcePort[68] and DestinationPort[67]) or (SourcePort[67] and DestinationPort[68]))

#1004:DNS
(Protocol[TCP] or Protocol[UDP]) and (SourcePort[53] or DestinationPort[53])

#1005:Ident
Protocol[TCP] and (SourcePort[113] or DestinationPort[113])

#1018:ICMP
Protocol[ICMP]

#1012:SNMP
Protocol[UDP] and (SourcePort[161-162] or DestinationPort[161-162])

#1019:NETBIOS
(Protocol[TCP] OR Protocol[UDP]) AND (DestinationPort[137-139] OR SourcePort[137-139])

#1026:Citrix
Protocol[TCP] and (Port[1494] or Port[2598] or Port[2512])

#1021:OtherUDP
Protocol[UDP]

#1022:OtherTCP
Protocol[TCP]

既に見ていただいたチャンネル定義とほとんど同じです。

  • 「#」に続く数字はチャンネルIDです。
  • コロンの後はチャンネル名です。

必要がないのでカスタム付きのセンサーにはグループはありません。

今までのおさらい

ここで今までのおさらいをしたいと思います。

  • チャンネルの定義は上から順番に評価されます。
  • 定義に当てはまらないフローデータは「その他」チャンネルに分類されます。
  • 「その他」チャンネルはデバッグログに書き出すことができます。

そこで上記のカスタム付きセンサー用のチャンネル定義から次の２つの定義

#1021:OtherUDP
    Protocol[UDP]

    #1022:OtherTCP
    Protocol[TCP]

を抜くと不明なTCPとUDPの通信は「その他チャンネル」に分類されてから、デバッグログに書き出すことができます。デバッグログはCSV形式ですのでExcelやテキストエディタで内容を確認することができます。

デバッグログ

デバッグログには次のような情報が記録されます。※この例はHTTPS通信です。

≪sFlow V５センサーの例≫
sFlow V5Example
Now2018/1/12 16:18:01
FromDateTime2018/1/12 7:18:01
ToDateTime2018/1/12 7:18:01
EthernetType
Protocol6
SourceIP173.194.22.231
SourcePort443
SourceMAC00-23-5E-80-87-0E
DestinationIP192.168.120.9
DestinationPort64868
DestinationMAC00-1A-EB-96-93-1D
Size1344000
ChannelID1023
ToS0
SenderIP192.168.120.254
InboundInterface5002
OutboundInterface0
≪NetFlow V9センサーの例≫
NetFlowExample
Now2018/1/12 16:18:10
FromDateTime2018/1/12 7:17:47
ToDateTime2018/1/12 7:17:54
EthernetType
Protocol6
SourceIP216.58.197.238
SourcePort443
SourceMAC00-00-00-00-00-00
DestinationIP192.168.81.199
DestinationPort52563
DestinationMAC00-00-00-00-00-00
Size1988
ChannelID1023
ToS64
SenderIP192.168.110.199
InboundInterface2
OutboundInterface1
SourceASI0
DestinationASI0
SourceMask0
DestinationMask24
NextHop192.168.110.254
SourceVLAN0
DestinationVLAN0
FlowID0

センサーの種類によってログに記録される内容が若干異なります。また全ての項目に常に値が入るとは限りません。太字の個所はNetFlow固有の項目です。

このように、カスタム付きxFlowセンサーとデバッグログを利用すると、受信したフローデータを確認することができます。

チャンネル定義のリファイン

次のようなサイクルでチャンネル定義をリファインしていくことができます。

０．xFlow（カスタム）センサーを作成する。

１．デバッグログを確認する。
２．チャンネル定義を変更してxFlow（カスタム）を再作成する。
　　１．と２．を必要なだけ繰り返す

３．（必要な場合）標準のxFlowセンサーの定義をカスタマイズする。

その他の機能

説明していないxFlowセンサーの機能についていくつかご紹介いたします。

フィルタリング

フィルタリング設定

センサーの設定の「フィルタリング」セクションに２つの入力項目があります。

  • 包含フィルター：条件に一致するフローデータをセンサーのデータとします。
  • 除外フィルター：条件に一致したフローデータを除外します。

このセクションでセンサーのチャンネル定義とは別にフィルタリングの設定ができます。例えば、特定のIPレンジとの通信のみを記録する、宛先がプライベートIPは除外するなど絞り込むこんでデータを記録させることができます。

条件の書式は前掲したｘFlowセンサーで使用できるフィルタールール(英文)と同じです。

カスタムトップリスト

前編で見ていただいたトップリストについての補足です。
トップトーカーやトップコネクションのグラフはIP通信の両端を示すために独特な表現になっています。

トップトーカー

しかしIPアドレスごとの通信量の上位を確認できれば良いケースでは、次のような単純な円グラフの方が見やすいかもしれません。

カスタムトップリスト


PRTGのトップリストは追加することができます。次の4種類から選択できます。

  • トップトーカー
  • トップコネクション
  • トッププロトコル
  • カスタム

先程の単純な円グラフはカスタムのトップリストで実現できます。

トップリスト

トップリスト設定

このトップリストの設定は次の通りです。

  1. xFlowセンサーの全般タブでトップリストを追加
  2. タイプの「カスタム」を選択。 
  3. トップリストフィールドで「IP（統合）」のみを選択します。

トップリストの設定には次の項目もあります。
デフォルト値と備考については以下の通りです。

設定項目デフォルト値備考
期間（分）15分長くすると必要なメモリが増えます
トップカウント(上位)100大きくするとメモリ、パフォーマンスに影響します。
リバース DNSリバース DNS を行う「リバース DNS を行う」ためにDNSの逆引きを実行します。「行わない」に変更するとパフォーマンスが向上します。またIPアドレスでのみ表示したい場合も「行わない」に変更してください。
メモリ使用限度10MBデータ受信時にメモリに関するエラーが表示される場合は増やしてください。プローブサービスのメモリ使用量が増えます。

後編のまとめ

前編に引き続き後編ではPRTGのxFlowセンサーの実践的な使用方法について解説をしてきました。いかがでしたでしょうか。フローデータを監視したことのない方に興味を持っていただけましたらうれしいです。

PRTGはフローコレクター専用のソフトウェアではありませんので、トップリストデータのエクスポートや検索ができません。機能として少しもの足りないところがあるかもしれません。
しかしフリー版でこの機能が使用できるのは大きなメリットです。プロトコルごとのトラフィックについて今まで気になっていた方が最初に使用するフローコレクターとしてはベストかもしれません。また商用ライセンスをご利用の方が、L2レベルのトラフィックと違った視点でネットワーク状況を把握したい場合に、追加コストなしで始められるのもメリットとなるでしょう。

実感していただくためにはPRTGを実際に使っていただくのが一番です。

PRTG Network Monitorは、100センサーまで無料で使用でき、30日間は無制限に評価できます。ぜひ、PRTGのネットワークトラフィック監視機能をお試しください。　

PRTG Network Monitorが提供するトラフィック監視機能は以下のリンクを参照してください。

PRTG Network Monitor 製品ページはこちら
PRTG フリー版ダウンロードはこちら

最後まで読んでいただいてありがとうございました。
以下は補足として、本文で触れなかった注意事項を挙げておきます。

補足：注意事項など

  • xFlowセンサーはIPv4のみ対応しています。
  • xFlowセンサーのプローブ当たりの推奨最大使用数は５０センサーです。
  • xFlowセンサーは使用状況によってPRTGシステムに大きな負荷を与えます。負荷分散が必要になった場合はリモートプローブを増設してしてください。（追加ライセンスコストはありません）
  • xFlowセンサーのデバッグログは 「データファイルパス」の下のStreamLogフォルダに出力されます。最大サイズは64MBでStreams Sensor XXXX (1).csv、Streams Sensor XXXX (2).csv の2つのファイルでローテーションします。※「データファイルパス」はサーバーにインストールされているPRTG Administration Toolで確認できます。ファイル名のXXXXの個所はセンサーIDです。
  • xFlowセンサーの受信性能はCPU速度よりもコア数に比例します。
  • sFlow V5センサーは以下のデータにのみ対応しています。
    • sFlowバージョン5のデータグラムのみ
    • IPv4のTCPとUDPのみ
    • フローフォーマットのみ（カウンターフォーマットは処理できません）
    • RAWパケットヘッダーのみ
  • 大量のフローデータを受信する場合は、PRTGのコアサーバが動作するPCに高速なハードディスク(SSD)が必要になります。またプローブが動作するPCには高性能なネットワークカードが必要になります。

こんな記事も読まれています

最新記事

おすすめ記事

  1. 「リモートデスクトップの操作が遅い！」の原因を高速特定！ntopngによる輻輳原因の究明アプローチを実例でご紹介

  2. フリーWi-Fiに潜む悪魔の双子（エビルツイン）とは。加害者・被害者にならないために知るべきこと

  3. 「疑わしい」Windowsイベントログを抽出して、イベントログを活用する

製品カテゴリー

NetFlow ntop sFlow SNMP SSB Syslogサーバー シスログサーバー セキュリティブログ トラフィック監視 ネットワークモニター ネットワーク監視 ログ保存 ログ管理 ログ管理ブログ 機器・サーバー監視のへや

JTC IT用語集
TOP