要点 

自宅ネットワークのネットワークが不調だったため、ログ収集を行い、Elasticsearchにログを蓄積し、Grafanaで可視化しました。

下記の画像が完成したダッシュボードです。

Grafana、Kibana初心者がそれぞれを使用した所感は以下のとおりです。

• とりあえず可視化してみたい！グラフをイジるのは面倒でただ表示だけしたい！
  • KibanaでもGrafanaでも差はあまりないです。
• とりあえず可視化してみたい！グラフに情報が書き込まれてないと気になるからある程度は作り込みたい！
  • Grafanaのほうが良かったです。
    • ElasticsearchのフィールドをGUIから書き換えたいならば、Kibanaを併用すればいいのかなと感じました。

はじめに 

自宅の回線会社とルーター変更してからネットワークが不調でインタネットに一時的に接続出来なくなったりした。最初はあまり気にせずにWifiの手動ON、OFFで直していましたが、意外と不調が発生するために徐々に不満が溜まりました。回線速度は良かったものの、安定してインターネットに接続出来ないのは辛いものがあります。だんだんと新しい回線環境がどの程度の品質なのか知りたくなりました。

というわけで回線状態を取り敢えず可視化することにしました。

ログ系の時系列データを可視化というと、Elasticsearch、Grafana、Kibanaがあります。それぞれ使用経験がなかったものの、今回使用してみることにしました。3つの役割は同一ではなく、Elasticsearchはデータストア、可視化のダッシュボードを担うのがGrafana、Kibanaとなります。

Grafanaは汎用的に作られており、Elasticsearchに限らず、様々なデータソースに対して可視化することが出来ます。その点KibanaはElasticsearchのみにしか対応していません。今回の可視化のデータソースは1種類なので、Grafanaの汎用性はそこまで優位点にはなりませんので、逆にKibanaの方がElasticsearchに特化していて使いやすいのでは？というのが最初の印象でした。 またKibanaはElastic Stackに同梱されているため、そもそも公式としてKibana推しです。

可視化の文脈でlogstashやfluentdなどのデータ収集ソフトウェアが登場しますが今回は使用していません。スクリプトを書いてログ収集を行いました。

よってデータの流れのイメージは下記のようになります。

コマンドで定期的にネットワーク状態を調べる => jsonに整形する => Elasticsearchに保存 => Grafanaで可視化

今回の記事ではElasticsearch、Grafana、Kibanaに対し初心者視点からサクッと利用する上で使用感がどうだったかの所感を書き留めます。

versions 

• elasticsearch
  • 6.8.2
• grafana
  • 6.3.3
• kibana
  • 6.8.2

Githubのリポジトリ情報 

使用感 

学習コストをあまり払わずに、ちょっとした開発にどの程度使えるかを観点とします。 長期的にソフトウェアを運用し、しっかりとした開発を行う観点ではない事に注意してください。

Elasticsearch 

RESTfulAPIを理解していれば学習コストはほぼありません。 今回のユースケースでいえば、可視化するためのデータ選択・処理はUI上でポチポチすればいいだけなので、Elasticsearchに意図的にクエリーを発行する必要もありません。

1Index, 1種類のデータとしてデータにタイムスタンプを付けてElasticsearchに投入しておけば簡単に保存も出来ます。

https://www.elastic.co/guide/en/elasticsearch/reference/6.7/removal-of-types.html#_alternatives_to_mapping_types

ありそうなハマりポイントはタイムスタンプの扱いで、一応カスタム出来るみたいですが、Elasticsearchがタイムスタンプとして解釈できる日付フォーマットを使用することぐらいです。

https://www.elastic.co/guide/en/elasticsearch/reference/current/mapping-date-format.html

可視化 

今回ネットワークの不調を可視化するにあたって、最も時間が取られた可視化フェーズ。ログ収集やElasticsearchの時間は微々たるものでした。 というのも可視化用のGUI操作に慣れて画像のようなダッシュボードを作るのに半日以上掛かりました。 段々楽しくなってきて、後から後からグラフを修正したくなってしまい、結果として全体の7,8割ぐらいの時間を割いていました。 半日以上と言いましたが、データを流し込んで特にグラフを修正しない下記のような単純な物ならKibana, Grafanaどちらでも直ぐに出来ますので、初心者でもあまり怖くは無いです。

最初はKibana、途中からGrafanaに切り替えて最後まで可視化したので、主にGrafanaに対する印象が強いです。 ざっくり比較すると、Grafanaは多用なデータソースに対して可視化するため、可視化ノウハウがあるのか可視化周りの操作が優秀です。KibanaはElasticsearch専用のためGUI上からElasticsearchを操作することに長けていますが、可視化周りのノウハウ不足感が操作感に出ていた印象でした。慣れた今の状態でKibanaを触り直したら印象が変わる可能性はありますが、それぞれについて下記に記します。

Kibana 

• Pros
  • Elasticsearchにのみ対応しているため、Elasticsearchに対して出来る機能が多い
    • 例えばElasticsearchのFieldのFormat定義をGUI上で変更する事ができる
  • Panelの中でGraphを複数設定できる。すごい( ・∀・)ｲｲ!!
  • 最初から使える可視化の種類が豊富
    • Tag Cloudとかまである
• Cons
  • 線グラフにおいて、欠損値があってもデフォルトでは線を引いてしまうため(Interpolation)、欠損状態がわかりにくい
    • Interpolationをしないようにする設定が不明
  • グラフ作成時の各設定項目がデフォルトで折りたたまれており、わざわざ広げないと情報を確認出来ない
    • グラフ設定画面で設定項目よりもグラフ表示を重視した結果のUI？操作のムダが多く発生してしまっている
  • Kibana単体ではおそらくAlertが作成できない(SIEMが必要？)

若干、複数のIndexを同時に表示する方法を見つけるのに時間がかかったので、そのグラフ作成方法を共有しておきます。

Management設定から対象のIndexを網羅する形でIndexパターンを登録しておきます。 登録したIndexパターンを利用してグラフを作成し、SplitChartでIndex毎にグラフを分割します。そうすると下記のようなグラフになります。

Grafana 

• Pros
  • Pluginが豊富
  • 見た目が最の高
  • グラフの設定項目が豊富で挿入したい情報を反映しやすい
    • 例えばKibanaはScaleを対数にした時に底を選べないが、Grafanaは2,10,32,1024と選べる。
    • 例えば単位も付与できる
• Cons
  • 最初から使えるグラフの種類がKibanaより少ない
    • 例えば単純なPie ChartでもPluginで導入する必要があるので、設定画面でいくら探しても出ては来ない
    • Pluginの人気・品質がPlugin追加画面で確認できず、Githubの評価ベース
  • 見た目がカッコ良すぎてつい楽しくなってしまい、時間を浪費する

若干、複数のIndexを同時に表示する方法を見つけるのに時間がかかったので、そのグラフ作成方法を共有しておきます。

Elasticsearchに限らず複数のデータソースにアクセスして1つのグラフを作成出来るため、グラフ作成画面でデータソースをElasticsearchではなくMixedを選びます。 後はAdd Queryでいつも通りに作成します。

おわりに 

まとめ 

今回、自宅ネットワークの不調に対して実際の状態を知るためにログ収集をし、可視化を行いました。

時系列データを収集し、取り敢えず可視化したいという目的では、Grafana、Kibanaの使い分け基準はグラフの情報をどのぐらい編集したいかだと思いました。本当にシンプルなグラフでいいのなら、正直使い勝手はどちらでも構わないでしょう。

目盛りや単位、そういった部分にも拘りたいのであれば様々なデータソースに対して可視化を行い可視化ノウハウが強くあり、グラフに対してConfigurableなGrafanaの方が良いのかなという印象でした。なので私はGrafanaを利用しました。

完成したダッシュボードを見ると、ただネットワークが不調というわけでなく、どの程度不調なのかがはっかりと分かるようになりました。

例えばWifiの手動再接続をせずに放置し続けると非常に回線状態が悪化していたことがわかります。ヒートマップのGoogleが回線の不調状態を分かりやすく表しており、色が濃いタイミングでは接続不良となっています。

つまり下記の時間帯は接続不良がひどく半分以上の時間が接続できていません…。

また別の時間帯で過去に遡って見てみると、30分程度の周期性が確認できます。なお、このときはRouterに関しては接続確認をしていなかったので、ヒートマップ等が非接続状態で表示されています。

両画像ともRSSIとNoiseから導出されるSNRの値が正常なのでルーターの信号が弱くなったり、またAndroidへの接続が出来ているためルーターが死んでいるわけではないとわかります。

なお手動で切り替えた直後は下記のような状態でした（表示期間：12時間）。Pingグラフの紫色のアノテーションが手動Wifi切替時で、1300頃がPC、1345頃がAndroidです。切り替え後はとても元気ですね…。

今回やってみて一番つらかったことは、そもそも回線が不安定なので情報にアクセスできなかったり、コマンドが失敗したことでした。

今後 

今回は可視化に焦点を置いた内容を書きました。

文量が増えてしまったので具体的にどのようなコマンドでネットワークの情報を取得したのか、どのようにデータ整形したのか、どのように各グラフを作ったのか、その後どうしたのかといった事については言及しませんでした。

ログ収集については途中まで書いてしまったので、どこかしらに公開しようと思います。