はじめに

たまにネットワークが遅いなと感じた時だったり、外出先のWiFiでどのくらいの通信速度が出ているか知りたい時、インターネットの通信速度をツールで計測することがあるかとおもいます。個人的にOokla社のSpeedtestを使うことが多いのですが、思い立った時に手動で計測するだけではなく、定常的に自動的に計測したいなと思っていました。

そんな時、このツールのコマンドライン版があることを知り、これならスクリプトで自動実行して通信速度を計測して、データを蓄積していくことができると考えました。

自動計測したデータをどのようにまとめるかは、Dynatraceに送って処理したいというのが今回の動機です。Dynatrace側ではOpenPipelineという仕組みを使って、統合的にデータの取得や操作を行います。

本記事は、これ👇を

これ👇にするステップバイステップです。

流れ

全体の流れは以下のようになります。1と2はLinux上、3以降はDynatrace上での作業です。

ネットワーク通信速度の計測
計測データをDynatraceに送信
ログから属性の取り出し
ログ属性のうち、速度データをメトリクスに変換
ダッシュボードの作成

ちなみに、計測に使用した回線はフレッツ光で、2つのISPを利用しています。マルチセッションの1つはIPoE接続、もう1つはPPPoE接続です。

ネットワーク通信速度の計測

Speedtest CLIの定期実行

早速Speedtest CLIを使ってネットワーク速度を計測します。インストールは以下のリンクから。私はUbuntu用のパッケージをダウンロードしてインストールしました。

さっそく実行してみると、おなじみの計測がテキストベースで行われました。

今回必要なのは、後々処理しやすいJSON形式のデータです。speedtest -hでコマンドラインオプションの一覧が表示されますので、その中から今回は出力形式を指定する-fを使います。

計測データをDynatraceに送信

DynatraceのログAPIにポスト

では計測データをDynatraceに送信します。そのためにはAPIを使用します。

Speedtest CLIの実行からDynatraceへのログのポストまでを1つのシェルスクリプトにまとめました。

#!/bin/bash

api_url="<Dynatrace API URL (ドキュメント参照)>"
api_token="<Dynatraec Access Token>"

speedtest_result=$(/usr/local/bin/speedtest -f json | jq '@json')

api_data=$(cat << EOT
[
    {
    "content": ${speedtest_result},
    "status": "info",
    "service.name": "speedtest",
    "service.network": "ISP_1"
    }
]
EOT
)

curl -X POST \
  ${api_url} \
  -H 'Content-Type: application/json; charset=utf-8' \
  -H "Authorization: Api-Token ${api_token}" \
  -d "${api_data}"

speedtest_result の行で、Speedtest CLIを実行し、JSON形式で結果を出力しています。そのまま jq '@json' につないで、別のJSON内に埋め込むためにエスケープ処理を行っています。

api_data はDynatraceのAPIにポストするデータで、JSON形式になっています。"content" にSpeedtest CLIの実行結果をセットし、その他の属性値もセットしています。"service.name": "speedtest" はこのログをフィルタリングするために使う識別子として、"service.network": "ISP_1" はこのLinuxマシンがつながっているISPを識別子として付加しています。別のLinuxマシンでも ISP_2 として同じスクリプトを実行しています。

最後に curl でDynatrace APIに対してポストします。このスクリプトを cron で定期実行します。

ログの確認

無事ログがポストできているようです。

OpenPipelineの活用

さて、Dynatraceの今年の新機能であるOpenPipelineは、データの取り込みからパイプラインへの振り分け、パイプラインによるデータの変換・抽出・保存を、データの種類によらず一元的に管理する仕組みです。

これまでは、データの種類によって設定方法が異なっていたり、各種設定がばらばらに散らばっていたりと、不便なこともあったのですが、1つにまとめられて使い勝手や見通しがとても良くなりました。

また、上図中のPipelineの部分に注目すると、さらに詳細が見えてきます。

Pipelineは入ってきたデータに対して、

データの処理
メトリクスの取り出し
データの取り出し
権限設定
ストレージ

を順次実施していきます。ストレージはBucketと呼ばれる単位で作成可能で、Bucketごとに保持期間やアクセス権限を設定できます。

ログから属性の取り出し

Pipelineの作成とルーティング

まずPipelineを新規作成し、どのデータがそのPipelineを通るのかを指定するルーティングを作成します。ルーティングは上の概念図の左から2番目の段階にあたります。SpeedtestというPipelineを作りました。

そのPipelineを通るデータは、APIでデータをポストしたときに付加した "service.name": "speedtest" があるものを対象とします。

JSONログの操作

では、Pipelineの中身を作っていきます。まずはProcessing（データの処理）の部分です。

左の + Processor でProcessorを追加します。1つのPipelineに複数のProcessorを持つことができます。

中央の部分でProcessorの設定を行います。ここで送られてきたログをパースするのですが、今回はJSONのログなのでパースは非常に簡単で、parse content, """JSON:result""" だけで完了です。その中から必要なデータだけ取り出して名前を付けておきます。

Speedtest CLIに同梱されているspeedtest.mdに、Mbps表記にするには元データを125,000で割るとよいとありますので、そのようにしています。

右側にサンプルログをペーストしてRun sample dataをクリックすると、パースの結果がその場で確認できますので、デバッグしながら整えていきます。

ログ属性のうち、速度データをメトリクスに変換

メトリクスへの変換

さらにPipelineの設定を進めます。次は取り出したログの属性値をメトリクスに変換します。さきほどのProcessorで取り出した、ダウンロード速度の download を log.speedtest_download というメトリクスに変換しています。ここでディメンジョンとして service.network を使用しています。つまり ISP_1 と ISP_2 というディメンジョンが付加されます。

同様に upload, ping のメトリクスも作成します。

ストレージの指定

今回のPipelineではData extraction, Permissionは設定していないので、最後にStorageを指定します。あらかじめSpeedtestというストレージを作ってありますので、それを使用します。これはログの保存先です。例として1,000日保存する設定にしています。

ダッシュボードの作成

これでデータが揃いましたので、あとはダッシュボードを作るだけです。すでに冒頭で紹介していますので少し違うビューをご覧ください。変数を導入して、downloadのグラフだけ表示しています。

上の通信速度グラフのクエリは以下のようになっています。

Pipelineで生成したメトリクス log.speedtest_download と log.speedtest_upload を表示しています。filter と fieldsKeep は、ダッシュボードの変数に応じて絞込をしています。

まとめ

ご覧のように、データの取得から操作、視覚化まで一気に構築できることを感じていただけたかと思います。特にOpenPipelineはシンプルでわかりやすく、しかも強力ですので、ぜひお試しいただければと思います。

ところで通信速度の定期測定ですが、もっと時間帯や曜日できれいに傾向がでるかと期待していましたが、夜中12時前後は速度が落ちる傾向にありますが、あとはバラバラです。うすうす予感はしていましたが、条件やタイミングによって大きく結果が変わるので、あまり傾向はわかりませんでした。今は1時間に1回測定なので、もっと細かく測定すればデータがこなれてくるかもしれません。また、現在は計測に使用するサーバーを指定してないのでランダムになっています。これをSpeedtest CLIのコマンドラインオプションで固定して試してみようと思っています。あとIPoEとPPPoEとでは、おおむねIPoEの方がダウンロードが速いですが、速度のばらつきはPPPoEの方が少なかったです。これも計測時の条件やISP次第なのであまり決定的なことは言えなさそうです。

Dynatraceフリートライアル → https://www.dynatrace.com/ja/trial/