スマートファクトリー スマート工場 IoT時代を強力にサポートする ITインフラ監視の方式とは？～MQTT編

弊社が販売するドイツPaessler社のPRTG、イタリアntop社のntopngは製造業向けのクローズドネットワーク監視や分析を実現する機能を近年精力的に開発しております。

所謂IoT対応ですが、今回のブログ記事では軽量なメッセージ配信プロトコルであるMQTT(Message Queue Telemetry Transport)の監視とそのトラフィック分析を実現する方法をご紹介します。

文：ジュピターテクノロジー　よしひろ

自社やお客様環境で、MQTTを利用しているスマートファクトリーやこれから採用を計画している方がいらっしゃいましたら、是非本ブログ記事を紹介して頂けますと幸いです。

MQTTテスト環境

今回準備したMQTT環境は、MQTTのオープンソース実装であるEclipse Mosquitto(以降、Mosquitto)を採用しました。
また、導入したMosquittoはDockerコンテナとして稼働しており、パブリッシャー、サブスクライバー、ブローカーを各１コンテナずつ起動しております。
MQTTトラフィックの分析を担うntopngは、Dockerホスト(Ubuntu 18.04LTS)にインストールされており、Dockerブリッジを監視します。
一方、PRTGはDockerホストとは別のネットワークに存在するWindows10ホストにインストールします。
DockerホストのTCPポート1883へのアクセスをDockerのポートマッピング機能が中継することによって、Mosquittoブローカーを監視します。
※本ブログで掲載している図は、サイズが小さいのでそれぞれの図をクリックして内容をご覧ください。

図1 検証環境

Mosquittoコンテナの起動

Mosquittoコンテナの設定と起動に関しては、本記事が目的とするところではないので詳細な説明は避けますが、別ホストに存在するPRTGからMosquitto ブローカーを監視する為に、-pオプションでポートマッピングしていることに注意してください。
コンテナの起動に関しては、以下のコマンドを参考にしてください。
 $sudo docker network create -d bridge mbd1  #ブリッジの作成
 $sudo docker run -d –name broker01 -p 1883:1883 –hostname=”broker01″ –net=mdb1 eclipse-mosquitto　#ブローカーコンテナの起動
 $sudo docker run -d –name pub01 –hostname=”pub01″ –net=mdb1 eclipse-mosquitto　#パブリッシャーコンテナの起動
 $sudo docker run -d –name sub01 –hostname=”sub01″ –net=mdb1 eclipse-mosquitto　#サブスクライバーコンテナの起動

 

MQTT通信の開始 サブスクライバー側

$ sudo docker exec -it sub01 sh
/ # mosquitto_sub -h 172.20.0.2 -t jupiter

MQTT通信の開始 パブリッシャー側

$sudo docker exec -it pub01 sh
/# mosquitto_pub -h 172.20.0.2 -t jupiter -m “MQTT_TEST”
MQTTの通信が正常に動作していれば、サブスクライバーの標準出力に”MQTT_TEST”と表示されます。
次にPRTGでメッセージの統計データを持続的に表示するために、パブリッシャー側で以下のようなシェルを作成し、実行してください。
#!/bin/sh
while true
do
   mosquitto_pub -h 172.20.0.2 -t jupiter -m “MQTT_TEST”;
   sleep 1;
done
シェルが実行されている間、サブスクライバーの標準出力に”MQTT_TEST”と表示されることを確認してください。

PRTGのMQTT監視センサーの追加

PRTGのMQTT関連センサーは、2021年2月現在で3種類リリースされております。
  1. MQTTラウンドトリップセンサー
  2. MQTT統計センサー
  3. MQTTサブスクライブカスタムBetaセンサー
本記事では、Betaセンサー以外のMQTTラウンドトリップセンサー、統計センサーを設定していきます。

事前確認

センサー登録前に、センサーを追加するデバイスのMQTT資格情報を確認してみましょう。
MQTT資格情報のデフォルト設定は、ローカルプローブが引継ぎ元となっています。
したがって、資格情報を確認するにはローカルプローブの設定を確認する必要があります。
ローカルプルーブをクリックし、「設定」を選択してください。
以下図2でデフォルト設定を確認できます。
図2 ローカルプローブのMQTT用資格情報
ポートが図1やMosquittoコンテナ起動で設定した1883になっていることを確認してください。
ここでは確認だけで、何も変更していないことに注意してください。

MQTT統計センサーの追加と確認

MQTT統計センサーは任意のTopicを設定し、MQTTブローカーにアクセスしダウン時間、受信メッセージ数、受信ペイロード(バイト)の統計データを生成するセンサーです。
センサーの追加は、PRTGの一般操作となりますので、ここでは説明を省きます。
MQTT統計センサーで設定が必須なのが、センサー名とTopic設定のみです。
図3ではTopicに、「jupiter」と設定しています。
図3 MQTT統計センサー設定

値を設定し、保存ボタンを押せば完了です。

更新ボタンを押して直ぐにポーリング実行か、もしくは一定時間ポーリングの実行をまって、センサーの色が正常を示す緑になることを確認してください。
図4の全般メニューでは、以下3つのチャネルを確認することができます。
  1. ダウン時間
  2. ブローカーの受信メッセージ数
  3. ブローカーの受信ペイロード数(バイト)
図4 MQTT統計センサー全般メニュー
図5では、それぞれのチャネルの統計グラフを確認することができます。
これでMQTTブローカーの監視は、万全です。
図5 MQTT統計センサー ライブデータ

MQTTラウンドトリップセンサーの追加と確認

MQTTラウンドトリップセンサーは、PRTG自身がパブリッシャー、サブスクライバーとなりMQTTブローカーのダウン時間、パブリッシャーコネクション時間、RTT、ステータス、サブスクライバーコネクション時間の統計データを生成するセンサーです。
センサーの追加は、PRTGの一般操作となりますので、ここでは説明を省きます。
MQTTラウンドトリップセンサーで設定が必須なのは、センサー名だけです。
PRTGがMQTTブローカーとメッセージの送受をするトピック名は、デフォルトで「PRTG/roundtrip/%sensorid」となります。
変更の必要はありません。
図6 MQTTラウンドトリップセンサーの設定
値を設定し、保存ボタンを押せば完了です。

更新ボタンを押して直ぐにポーリング実行か、もしくは一定時間ポーリングの実行をまって、センサーの色が正常を示す緑になることを確認してください。
図7の全般メニューでは、以下5つのチャネルを確認することができます。
  1. ダウン時間
  2. パブリッシャーコネクション時間
  3. RTT
  4. ステータス
  5. サブスクライバーコネクション時間
図7 MQTTラウンドトリップセンサー全般メニュー
図8 MQTTラウンドトリップセンサーライブデータ
図8では、それぞれのチャネルの統計グラフを確認することができます。
これでMQTTブローカーのRTTを常に計測し、ネットワークやブローカーの処理時間に問題が発生した場合に、直ぐにアクションを起こすことが可能です。

ntopngによるMQTTトラフィック監視・分析

最後にntopngでDockerホスト上でデバイスとして表示されるブリッジ(本環境では、mbd1)を設定ファイルに追加し、MQTT通信を見える化してみましょう。
※ntopngの設定ファイルの編集と適用に関しては、「コンテナ時代もお任せあれ。Dockerコンテナ監視とトラフィック分析の実現方法」の「ntopng設定ファイルの編集」を参考に設定してください。
ntopngにログインすると図9のトラフィックダッシュボード画面が表示されます。
このダッシュボードは、監視対象としたインターフェイスのアプリケーションごとのトラフィック量、ネットワークの帯域を利用しているホスト情報をリアルタイムで表示してくれます。
図9の通り、ntopngはMQTTを認識し、パブリッシャー、サブスクライバー、ブローカーの3つのコンテナの通信を収集できています。
また、PRTGをインストールしたホスト192.168.93.64も確認することができます。
ntopngは定義したサブネット内の全ホストのトラフィック情報を収集、分析するため3つのコンテナ及びPRTGホストの短/中長期分析を実現することができます。
図9 リアルタイムトラフィックダッシュボード
次にフロー情報を確認するために、ntopng画面左のメニュー「フロー」をクリックします。
アプリケーションは、MQTTでパブリッシャーからブローカー(TCP:1883)、サブスクライバーからブローカー(TCP:1883)への通信が発生していることが分ります。
こちらもMQTTの環境通りの動きであることが分ります。

図10 アクティブフロー
最後にトラフィックグラフを見てみましょう。
whileループでサブスクライブ、パブリッシュを繰り返しているので約12kbit/sで安定したトラフィック量の通信を確認できますが、1分ごとに39.22Kbit/sまで定期的にグラフが増加しています。
こちらの通信は何でしょうか？

図11 インターフェイス統計グラフ
ntopngのWeb画面で1分ごとにやまになっている部分でマウスオーバーし、対象の時間を絞ります。
図12の画面のようになりますので、赤枠のノートアイコンをクリックしてテキストファイルをダウンロードしてください。
図12 フローダンプ、テキストファイルのDL
DST2SRC_BYTES|DST2SRC_DSCP|DST_COUNTRY_CODE|DST_LABEL|FIRST_SEEN|FLOW_TIME|INFO|INTERFACE_ID|IPV4_DST_ADDR|IPV4_SRC_ADDR|IPV6_DST_ADDR|IPV6_SRC_ADDR|IP_DST_PORT|IP_PROTOCOL_VERSION|IP_SRC_PORT|L7_PROTO|LAST_SEEN|NTOPNG_INSTANCE_NAME|PACKETS|PROFILE|PROTOCOL|SRC2DST_BYTES|SRC2DST_DSCP|SRC_COUNTRY_CODE|SRC_LABEL|STATUS|TOTAL_BYTES|VLAN_ID
342|0|0||1612223898|1612223898||27|172.20.0.2|172.20.0.3|::|::|1883|4|51846|222|1612223898|ntop|12||6|533|0|0||0|875|0
342|0|0||1612223899|1612223899||27|172.20.0.2|172.20.0.3|::|::|1883|4|51852|222|1612223899|ntop|12||6|533|0|0||0|875|0
342|0|0||1612223900|1612223900||27|172.20.0.2|172.20.0.3|::|::|1883|4|51858|222|1612223900|ntop|12||6|533|0|0||0|875|0
342|0|0||1612223901|1612223901||27|172.20.0.2|172.20.0.3|::|::|1883|4|51862|222|1612223901|ntop|12||6|533|0|0||0|875|0
1561|0|0||1612223899|1612223901||27|172.20.0.2|192.168.93.64|::|::|1883|4|4801|222|1612223901|ntop|18||6|565|0|0|PC37-yoshihiro-i.dom1.jtc-i.co.jp|0|2126|0
398|0|0||1612223899|1612223901||27|172.20.0.2|192.168.93.64|::|::|1883|4|4802|222|1612223901|ntop|16||6|1585|0|0|PC37-yoshihiro-i.dom1.jtc-i.co.jp|0|1983|0
342|0|0||1612223902|1612223902||27|172.20.0.2|172.20.0.3|::|::|1883|4|51864|222|1612223902|ntop|12||6|533|0|0||0|875|0
342|0|0||1612223903|1612223903||27|172.20.0.2|172.20.0.3|::|::|1883|4|51866|222|1612223903|ntop|12||6|533|0|0||0|875|0
342|0|0||1612223904|1612223904||27|172.20.0.2|172.20.0.3|::|::|1883|4|51868|222|1612223904|ntop|12||6|533|0|0||0|875|0
「|」で区切られたテキストファイルをダウンロードします。
1行目にあるように各フィールドは、フローのフィールドに対応しています。
右から２番目のTOTAL_BYTESに注目すると、192.168.93.64(PRTG)と172.20.0.2(ブローカー)の通信量がこのグラフの形成に関わっていることが分ります。
PRTGに追加した２つのセンサーが１分ごとに監視しているところまで見える化できました。

如何でしたでしょうか？
PRTGとntopngを組み合わせれば、MQTTの監視やネットワークトラフィックの可視化を簡単に実現できることが分っていただけたかと思います。

PRTGのお問い合わせ

新しくなったPRTGの日本語インターフェイスをぜひお試しください！

ntopngのお問い合わせ

本記事で扱っているntop社のnProbe, ntopng製品にご興味のある方は、以下のリンクから弊社までお問い合わせください！

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

最新記事

おすすめ記事

  1. 産業スパイを発見し、防ぐ方法とは

  2. Flexible NetFlowとは?を5分で理解する

  3. WinSyslog 使い方ガイド#2 受信時刻とデバイスタイムスタンプ両方を出力する

製品カテゴリー

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

JTC IT用語集
TOP