Zabbixでコロナ禍おける在宅勤務環境のネットワークの遅延を計測し続ける

# はじめに

瀧澤です。2020年前半からのコロナ禍において、自宅で仕事をするにあたり、リモート会議やVDI（Virtual Desktop Infrastructure）などで会社のネットワークに接続したり、その他のサービスに接続したりすることも多いかと思います。昨今、ブロードバンド回線においては、帯域幅が問題になることはあまりないですが、ネットワークの遅延やその遅延の揺らぎは、リアルタイムな双方向通信を行うリモート会議システムやVDIにおいては影響するかもしれません。

この記事では、その遅延を日常的に計測する仕組みをZabbixで作ってみたいと思います。Pingを使って計測します。なので、正確には、往復のレスポンスタイム（Round Trip Time;RTT）になります。アウトプットは、下記のようなイメージです。
![zabbix2020-08-11 183407_LI.jpg](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/61619/9c1c75c6-64b7-11a9-9822-ebc290cdd043.jpeg)
余談ですが、Pingを開発したのは、故MIKE MUUSS氏です。彼のpingに関するブログはこちらにあるそうです。
https://ftp.arl.army.mil/~mike/ping.html

# 方法
Zabbixがインストール済みであるとしています。Zabbixの導入等は、公式のドキュメント等を参照ください。
https://www.zabbix.com/jp/download

ここでは、pingによる遅延（Round Trip Time;RTT）の計測方法とグラフ化について記載します。

## 環境の説明
私の自宅環境には常時起動しているサーバ関連はほとんどありません。VPN接続したAWSのVPCにAmazon EC2上に構築されたZabbix Server(Zabbix 5.0)があります。Zabbix Serverでは、Zabbix Agentも動いています。そして、VPCのPrivate SubnetはデフォルトルートがHomeのネットワークになっており、インターネットへもHomeのRouterでNATされてアクセスします。
下記の構成なのですが、このまま、Zabbix Serverからpingを打つと、VPNで接続したインターネット回線の遅延やVPNルータの暗号化等の処理時間までも含んでしまうことになります。そこで、VPNを経由した先のルータまでのRTT(= Destination A)と、実際に計測したい接続先までのRTT(= Destination B)を計測し、その差分(B-A)を家の環境からのRTTとして、その値を記録、可視化してみたいと思います。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/61619/2355569b-873d-a1ca-0036-863da688b426.png)

これは、企業のネットワークなどで、監視サーバ等がAWS上にあり、Direct Connectでオンプレミスのネットワークに接続されている場合等に、オンプレミス側の各拠点の遅延を測りたいときにも応用できると思います。

なお、以下に示す設定は、Zabbix Serverが自宅にあるなど、VPNがない環境にも対応可能です。

## 環境構築方法
### 1. zabbix_agentd.confを変更
まず、zabbix_agentd.confに下記を追加します。この環境構築のポイントは、基本的にこの1行だけです。

```config:/etc/zabbix/zabbix_agentd.conf
UserParameter=ping.remotelatency[*],echo `ping -c "$3" "$1" |grep rtt |awk -F'/' '{print $$5}'` - `ping -c "$3" "$2" |grep rtt |awk -F'/' '{print $$5}'` | grep -v '^-' | grep -v ' -$' | bc | grep -v '^-'
Timeout=30
```

第1引数がDestination Bの宛先、第2引数がDestination Aの宛先、第3引数がpingの回数になります。

エラー処理も含めて1行に収めたので長いですが、全体的には、大きく4つのブロックの処理になっています。少し解説してみたいと思います。

#### (1) echoでpingのRTTの結果をもとに、(Destination BのRTT) - (Destination AのRTT)の形式で出力

```処理:処理：(Ping宛先のRTT抽出)
`ping -c "$3" "$1" |grep rtt |awk -F'/' '{print $$5}'`
```

pingの出力結果から、rttの文字がある行をみつけます。そして、awkで必要なデータを抽出していきます。すなわち、下記のようになります。

- 最初の「grep rtt」で右記を抽出： rtt min/avg/max/mdev = 11.142/15.854/18.345/3.335 ms
- 次の「awk -F'/' '{print $$5}'」で「/」で区切られた5項目目を抽出: 15.854
    - (スペース区切りでパースしてから、「/」区切りでパースしたほうが美しいかもしれません。)

(Ping宛先2のRTT)も同様の処理です。


#### (2) エラー処理（先頭または末尾にマイナスがないかの確認）

```処理:（エラー処理）
grep -v '^-' | grep -v ' -$' 
```

pingの宛先A, Bからレスポンスがなかった時などは、結果が返ってきません。そうすると、先頭や末尾が「-」になるので、そうなっていないことを確認します。

#### (3) bcで引き算
#### (4) 結果のエラー処理（マイナスでないかの確認）

```処理:(エラー処理）
grep -v '^-'
```

計算結果は正であることを期待しています。Destination BのほうがDestination Aよりも遠いので。マイナスになると、Zabbixのグラフが汚くなるので、マイナスの値の場合は無視します。

### 2. Zabbix Agentをrestartします。

```Command:
$ sudo systemctl restart zabbix-agent
```

### 3. 動作確認します。

私の家と同じ構成で、自宅のインターネット接続用ルータのIPアドレスが「192.168.1.1」で、計測先が「8.8.8.8」の場合は下記のようにします。

```Command:
$ zabbix_get -s 127.0.0.1 -k ping.remotelatency[8.8.8.8,192.168.1.1,3]
4.875 (計測結果)
```

Zabbix ServerからVPNを経由していない場合は、下記のように、第2引数を「127.0.0.1」にします。

```Command:
$ zabbix_get -s 127.0.0.1 -k ping.remotelatency[8.8.8.8,127.0.0.1,3]
10.445 (計測結果)
```

### 4. Zabbixのアイテムの設定をします。

「設定」-「ホスト」を選択し、「Zabbix Server」をクリックします。そして、「アイテム」を選択し、右上の「アイテムの作成」をクリックします。そして、下記のように、Detination A, Bの情報を入力します。（VPNを使っていない場合はDestination Aに127.0.0.1を入力してください。）
**Destination A, Bなどの設定については見ず知らずの宛先にせず、自分が管理できる宛先にしてください。宛先にicmpパケットを送り続けることになるので。** 私の場合は、適当なregionにt3a.nanoのインスタンスを立ててみたりしています（ [t3a.nanoの利用料金](https://aws.amazon.com/jp/ec2/instance-types/t3/) )。
![Zabbix 2020-08-11 183621.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/61619/13d95a10-0d06-1b11-8640-3d0de04ace0e.png )


### 5. グラフを作成する。そして完成。

「設定」-「ホスト」を選択し、「Zabbix Server」をクリックします。そして、「グラフ」を選択し、右上の「グラフの作成」をクリックします。グラフで、このアイテムを選択します。
また、ダッシュボード上のウィジェットでグラフを作るのもよいでしょう。参考までにウィジェットでの設定例を示します。
以上で完成です。
そのほか、値を監視して、通知をしてもよいかもしれません。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/61619/8a390c3f-b02a-fcd8-ef1b-8466013be456.png)

# おわりに

これで、ネットワークの遅延を継続的に監視できる環境が構築できました。幸い、自宅のネットワーク環境の遅延は問題なさそうです。
ちなみに、音声品質における人間が許容できる遅延はEnd to Endで概ね150msまでと言われています。これを超えると、人間は遅延を意識したうえで会話をしようとします。しかし、遅延がゆらぐと、多くの人間は我慢ができなくなるようです。
日本国内においては、このような遅延になることは少ないと思いますが、海外に電話会議等のカンファレンスサーバがある場合はこの限りではないかもしれません。

# 免責
こちらの内容にもとづく環境の構築は、自己の責任でお願いします。Destination A, Bなどの設定については見ず知らずの宛先にせず、自分が管理できる宛先にしてください。また、ここに記載の全ての内容については、個人の意見で、所属する企業や団体は関係ありません。