この記事では、前回（第4回）で学んだFlow分析の理論を基に、実際に、私たちのパートナーであるKentik社が開発したオープンソースのツール「ktranslate」とオブザーバビリティプラットフォーム「New Relic」を連携させ、ネットワークトラフィックを可視化するまでの一連の手順をハンズオン形式で具体的に解説します。
こんにちは！NPM連載企画、第5回へようこそ。
前回は、「ネットワークが重い」という漠然とした問題の"犯人"を特定するための強力な手法、「Flow分析」の理論について学びました。トラフィックを「量」だけでなく、「誰が」「誰と」「どのような会話を」しているのかという「質」で捉えることの重要性をご理解いただけたかと思います。
しかし、どれほど優れた理論も、実践で使えなければ意味がありません。そこで今回は、いよいよ手を動かしていく【実践編】です。理論を具体的な「見える化」に繋げることで、日々の業務で直面する課題解決の強力な武器を手にしていきましょう。
今回のゴール
今回のハンズオンでは、以下の状態を目指します。
- Flowデータの収集: ネットワーク機器から出力されるNetFlowやsFlowといったFlowデータを、エージェントを使って受信できる状態にする。
- データの転送と可視化: 収集したFlowデータをNew Relicに転送し、誰が・どのアプリケーションが帯域を消費しているかを直感的に把握できるダッシュボードを構築する。
ステップ1: 準備するもの
ハンズオンを始める前に、以下の3つをご用意ください。
- New Relic アカウント:
- まだお持ちでない方は、無料のFree Tierアカウントを作成できます。
- アカウントの Ingest-Licenseキー と Account ID が必要になります。これらは後ほど設定で使用します。
- Flowデータをエクスポートできるネットワーク機器:
- CiscoやJuniperなどのルーターやスイッチが対象です。NetFlow v5/v9, IPFIX, sFlowのいずれかに対応している必要があります。
- ご自身の管理下にある実機、もしくは検証環境の機器をご利用ください。
- エージェントを稼働させるサーバー:
- ネットワーク機器からFlowデータを受信するためのサーバーです。今回は、環境構築が容易な Docker がインストールされたLinuxサーバーを想定して進めます。
準備はよろしいでしょうか？それでは、早速エージェントのセットアップから始めましょう。
ステップ2: ktranslateエージェントのセットアップ
本連載でSNMPやSyslogのデータ収集に活用してきたエージェント「ktranslate」を、今回はFlowデータの収集に用います。
ここで、第3回のSyslog編でも触れた、重要なアーキテクチャ上の原則を改めて確認しましょう。それは、ktranslateエージェントは、1つのコンテナ（プロセス）で1つの役割しか担えない、という点です。つまり、SNMPのポーリングを行うコンテナと、今回のようにFlowデータを受信するコンテナは、必ず分離して実行する必要があります。
では、プロセスを分離した場合、どうやってSNMPとFlowのデータをNew Relic上で同じデバイスに紐づければ良いのでしょうか？設定ファイルが2つに増えると、管理が煩雑になり、device_nameの不一致など、ミスの原因にもなりかねません。
そこで、第3回のSyslog編でご紹介したアプローチを、ここでも活用します。 マスターとなるsnmp-base.yamlから、FlowのIPアドレスとデバイス名を紐付けるためだけのシンプルな設定ファイルを自動生成するのです。
ステップ2.1: Flow用の設定ファイルを自動生成する
まず、マスターとなるsnmp-base.yamlから、Flow用のflow-devices.yamlを生成します。このファイルには、Flowデータの送信元IPアドレスとdevice_nameをマッピングする情報だけが含まれます。
Linuxサーバー上で、yqコマンドを使って以下のコマンドを実行してください。
# snmp-base.yaml から devices セクションを抽出し、
# device_name と device_ip のみを持つ flow-devices.yaml を生成する
yq '.devices | with_entries(.value |= {"device_name": .device_name, "device_ip": .device_ip})' snmp-base.yaml > flow-devices.yamlこれにより、snmp-base.yaml内のdevices定義と完全に同期が取れた、Flow用のマッピングファイルが作成されます。
ステップ2.2: 役割を分離して各コンテナを起動する
次に、役割を明確に分離した2つのktranslateコンテナを起動します。
1. SNMPポーリング用コンテナ (ktranslate-snmp)
これは第2回で構築したものと同じです。すでに稼働している場合はそのままで問題ありません。
docker run -d --name ktranslate-snmp --restart always --pull always \
-v $(pwd)/snmp-base.yaml:/snmp-base.yaml \
-v $(pwd)/profiles:/profiles \
-e NEW_RELIC_ACCOUNT_ID="<YOUR_ACCOUNT_ID>" \
-e NEW_RELIC_API_KEY="<YOUR_LICENSE_KEY>" \
kentik/ktranslate:v2 \
-snmp /snmp-base.yaml2. Flowリスニング用コンテナ (ktranslate-flow)
こちらが今回新たに追加するコンテナです。先ほど生成したflow-devices.yamlをマウントし、Flowデータを受信するポートを公開します。
docker run -d --name ktranslate-flow --restart always --pull always \
-v $(pwd)/flow-devices.yaml:/flow-devices.yaml \
-p 2055:2055/udp \
-e NEW_RELIC_ACCOUNT_ID="<YOUR_ACCOUNT_ID>" \
-e NEW_RELIC_API_KEY="<YOUR_LICENSE_KEY>" \
kentik/ktranslate:v2 \
-netflow5.listen=0.0.0.0:2055 \
-snmp /flow-devices.yamlコマンドの解説:
--name ktranslate-flow: SNMP用とは明確に異なるコンテナ名を指定します。-v $(pwd)/flow-devices.yaml:/flow-devices.yaml: 生成したFlow用設定ファイルをマウントします。-p 2055:2055/udp: NetFlow v5データを受信するためのポートを公開します。-netflow5.listen=...: Flowデータの待ち受けを指示します。-snmp /flow-devices.yaml: これが非常に重要です。 ktranslateに、Flowデータの送信元IPアドレスをdevice_nameにマッピングするための情報として、このファイルを読み込ませます。これにより、Flowデータはsnmp-base.yamlで定義された正しいデバイス名でNew Relicに送信されます。
このアーキテクチャにより、ktranslateの原則を守りつつ、設定の一元管理とデータの正確な紐付けを両立できました。これこそが、スケール可能で堅牢なネットワーク可観測性基盤のアーキテクチャと言えるでしょう。
ステップ3: ネットワーク機器の設定
次に、ネットワーク機器側で、Flowデータのエクスポート先を先ほどセットアップしたktranslateエージェントに向ける設定を行います。
この設定はベンダーや機種によってコマンドが大きく異なるため、ここでは一般的な設定項目の概念を説明します。
一般的な設定項目:
- Flowエクスポートの有効化: まず、機器全体でFlowのエクスポート機能を有効にします。
- コレクターの設定:
- 宛先IPアドレス: ktranslateエージェントが稼働しているサーバーのIPアドレスを指定します。
- 宛先ポート: ktranslateで待ち受けているポート番号（今回は
2055）を指定します。
- 監視対象インターフェースの指定: どの物理/論理インターフェースを通過するトラフィックを監視対象とするかを指定します。
例えば、Cisco IOSルーターであれば、以下のような設定になるでしょう。
! グローバルコンフィギュレーションモードで
ip flow-export version 5
ip flow-export destination <ktranslateサーバーのIP> 2055
! 監視したいインターフェースで
interface GigabitEthernet0/0
ip flow ingress
ip flow egress重要な注意点: 具体的なコマンドについては、必ずお使いのネットワーク機器の公式ドキュメントや設定例をご確認ください。設定を誤ると、意図せず機器に高い負荷をかけてしまう可能性もあります。
ステップ4: New Relicで"見える化"を確認
設定が完了し、ネットワークにトラフィックが流れると、数分でデータがNew Relicに届き始めます。データが正常に転送されているか確認し、トラフィックの内訳を可視化してみましょう。
- New Relicにログインし、画面上部のナビゲーションバーから [All capabilities] をクリックします。
- 左側のメニューから [Network] -> [NetFlow] を選択します。
ここにデータが表示されていれば、成功です！
このダッシュボードでは、以下のような情報を直感的に把握できます。
- Top Conversations: どのIPアドレス間の通信量が最も多いか。
- Top Sources / Destinations: 最も多くデータを送信・受信しているのはどのIPアドレスか。
- Top Applications: どのポート番号（アプリケーション）が帯域を最も消費しているか。（例: 443/HTTPS, 53/DNSなど）
これまでブラックボックスだったネットワークの使用状況が、明確なデータとして可視化されているのがお分かりいただけるかと思います。もし想定外のIPアドレスやアプリケーションが上位に表示されていたら、それが「ネットワークが重い」原因、つまり"犯人"である可能性が高い、ということになります。
まとめ
今回は、Flow分析の実践編として、ktranslateエージェントとNew Relicを使ってネットワークトラフィックを「見える化」するまでの一連の手順を体験しました。
ktranslateをSNMP用とFlow用でコンテナを分離して実行するアーキテクチャを構築snmp-base.yamlをマスターとして、設定ファイルを自動生成し、管理を効率化- ネットワーク機器からFlowデータをエクスポート
- New Relicのダッシュボードで通信の内訳を可視化
第4回で学んだ理論が、実際に動くシステムとして形になりました。これであなたは、「誰が、いつ、どこからどこへ、どのくらいの通信をしているか」を具体的に把握するための強力な基盤を手に入れたことになります。
次回予告
オンプレミスのネットワークトラフィックを可視化できるようになった今、次に目を向けるべきはどこでしょうか。そうです、現代のITインフラに欠かせないクラウドです。
次回、第6回は「【応用②】クラウドネットワーク監視の実践」と題し、AWSやGCPといったクラウド環境に特有のネットワーク監視（VPC Flow Logsなど）に焦点を当て、そのデータをどのように可視化していくかを解説します。どうぞお楽しみに！
本ブログに掲載されている見解は著者に所属するものであり、必ずしも New Relic 株式会社の公式見解であるわけではありません。また、本ブログには、外部サイトにアクセスするリンクが含まれる場合があります。それらリンク先の内容について、New Relic がいかなる保証も提供することはありません。
