(c)このウェブサイトではサイトの利便性の向上のためにクッキーを利用します。サイトの閲覧を続行されるには、クッキーの使用にご同意いただきますようお願いします。お客様のブラウザの設定によりクッキーの機能を無効にすることもできます。用いた異常検知(こちらのシリーズ)やどこでデータの加工を行うべきなのか(こちら)について紹介してきました。本コラムではデータの加工場所とそれにともなう検討事項について、もう少し掘り下げた内容を共有したいと思います。Stackを使いました。Stackの細かい説明は過去の匠コラム(こちら)をご覧ください。pluginを使っています。以前はSNMPTrapにのみ対応していましたが、2018年の10月頃にPollingもできるようになりました。ネットワーク機器にSNMPの設定を入れ、Logstashには以下のようにOIDやホストの情報を入れるだけで、データの取得が可能になります。}デフォルトのPolling間隔は30秒ですが、もちろん設定可能です。取得したデータは以下のようにElasticsearchに格納されます。いうvalueが格納されていることがわかります。次に、このデータを用いて加工、可視化を行います。今回はSNMPで取得できるインターフェースが受信した総バイト数(ifInOctets)を対象にデータの収集を行いました。ように、過去からの累積した値が取得されます。そのため、そのまま取得したデータの可視化を行うと常に上昇した(または変化がない)グラフが作られます。この値をそのまま使うと、特定の時間にどれだけのバイト数を受信したのか、についてはわかりにくい状態になってしまいます。そこで以下の2つのパターンでデータの加工、可視化を行い、それぞれでできることや課題を検討してみました。やりたいことは「累積していく値をそのまま使うのではなく、前回の値との差分を取った値を可視化したい」ということです。可視化するタイミングでデータを加工まず、Elasticsearchに入れたデータをKibanaで見せ方を変える方法を試してみました。Fieldという機能を使うこともできますが、時系列を跨いだ計算ができないため、今回はVisualizeのTimelionにあるsubtract関数を使いました。可視化のために記述したスクリプト(図の左側)の細かい解説はここでは省略しますが、「1つ前に取得した値と差分を取った値を可視化する」ことを実現しています。可視化の次のステップ(分析等)を考えたとき、この可視化方法はElasticsearchに格納されたデータの見せ方を一時的に変えているだけなので、ここで可視化した値(差分を取った値)自身の実体はありません。そのため値の二次利用を行うことはできません。転送するタイミングでデータを加工パターン2では1つ前に取得した値と差分を取った値をあらかじめ計算し、Elasticsearchに格納しています。pluginを使って、差分の計算を行いました。いうfieldに計算した値を格納しています。【図:差分を取った値もElasticsearchに格納】この値(requests)を使ってグラフを描くと、パターン1と同様の可視化を行うことができます。可視化したい値そのものがElasticsearchに格納されているので、可視化のためのスクリプトも非常に短くなります。※今回は比較のためTimelionでグラフを描いていますが、可視化したいデータそのものがElasticsearchに格納されていれば数クリックで同様のグラフを描くことができます。【図:差分を取った値の可視化】データを格納する前に加工しておくことで可視化を簡単に行うことができるようになりましたが、それと引き換えに新しくデータを生み出した分、格納するための保存領域を多く使っていることになります。そのため、生データは格納しない等のデータの取捨選択を行わないと、データ量が膨大になっていってしまいます。2つのパターンで差分を取った値の可視化を行いましたが、両方に共通した課題もあります。それは累積していく値そのものがリセットされる(32bitや64bitを超えると値が0に戻る)タイミングで一度負の値を取るため、意図したデータが取れずグラフも大きく崩れてしまうことです。これに対する対処をしないと、次のトピックである機械学習を使った異常検知をしようと思っても誤検知が生まれる可能性があります。今回は検証のため1台のルータの1つのインターフェースから、1つのメトリック(ifInOctets)を取ったため、可視化もそれほど大変な作業ではありませんが、これが1000台のルータの48のインターフェースから複数メトリックを取得するとなると、同じように可視化を行うのは現実的ではありません。この場合、field名の変更や新しくタグを付ける等、さらに加工やデータの付与が必要になると考えられます。データの加工にも計算リソースを使うので、そのリソースをどこにかけるか、という視点も必要になってきます。ここまでは可視化を目的にしてきました。Learningを使って分析した結果を共有します。Stackではこちらで紹介したように教師なし機械学習(ElasticMachineLearning)を行うことができます。この機械学習に使えるデータはElasticsearchに格納されているデータになるので、差分を取った値を使いたい場合は先ほどのパターン2でデータを取得する必要があります。今回は比較のために、累積していく値(生データ)と差分を取った値の2つで機械学習を行い、異常検知の結果を見てみました。以下の図が累積していく値に対して機械学習を行い、異常検知を行った結果です。青い実線が実測値、うすい水色の部分が機械学習が導き出した値の範囲(通常であればその中に値が収まる範囲)です。一部で異常が検知(グラフ内に印がついている点)されたように見えますが、実際にはまわりの値をそれほど変わりはなく、本当に異常であったかどうかは疑問が残ります。Learningにはあまり適していないデータであったことが推測されます。機械学習を行う際には、どのようなデータを扱うのかも重要な検討事項となります。Learningには値のforecast機能もあり、こちらを試してみると、精度の高い予測ができているように見えます。この機能を使えば、将来を見据えた設定変更やリソースの見直しができます。Learningを使う目的によっては、累積していく値をそのまま使うことも十分考えられます。差分を取った値に対して機械学習を行い、異常検知をした結果が以下の図です。機械学習が導き出した「いつもの値の範囲(うすい水色の部分)」がある程度の範囲に収まり、微小な変化でも異常として検知していることがわかります。今回は検証用に準備したルータからデータを取得しているため、差分を取った値がほぼ同じ値(同じペースで値が累積していく)です。微小な変化でも異常として検知していますが、日中はトラフィック量が多く、夜間は少ないといった周期性のあるデータであれば、それも加味して機械学習のモデルが作られるため、より異常を正しく検知してくれることが期待されます。実際はトライ&エラーを繰り返しながら検証を繰り返し、機械学習に使う値を決めていくことになりますが、上記のように、使う値によって実現できる内容が変わってくるため、データを格納する段階から先の分析について考えておく必要があります。おわりに本コラムではデータの加工場所と可視化、加工したデータの利用について紹介しました。一概に「ここでデータの加工を行うべきだ」と断定することはできませんが、検証を通してあらためて検討すべきことがいくつもあることがわかりました。ネットワンでは、ネットワークデータだけでなく様々なデータソースから生まれるデータをどこに、どのように貯めるべきか、アーキテクチャを検討しています。そちらに関しても今後ご紹介していければと思います。