Prelertでプログラミングレスな異常検知に挑戦！ Part2

こんにちは！@tereka114です。

前回はPrelertを使って、簡単に異常検知を行ってみました！
Prelert自身の説明や画面の説明はまず、こちらを読んでみてください！
acro-engineer.hatenablog.com

前回の記事ではPrelertの基本的な使い方を紹介しましたが、
紹介しきれなかった魅力的な機能があります。それがinfluencer検出機能です。
今回は公式サイトのサンプルを使い、このinfluencer検出機能を実際に使ってみます。

influencer検出機能とは

influencer検出機能はデータ群の異常とその要因を示す機能です。
この機能のうれしいところを、考えられるユースケースと共に紹介します。

Case1 不正取引の検出

次のようなニュースがありました。

www.itmedia.co.jp

1日の中で数多くの取引がある中、不正な取引を見つけることは非常に難しいです。

Prelertのinfluencer機能を利用することで、
その膨大な取引データの中から異常な取引があったことを検知するだけでなく、
異常を起こしたデータ（もしくはデータ群）を見つけ出すことができそうです。

Case2　システムの監視

システムの障害が発生すると損失が発生します。
次の記事によれば、国内企業一社あたり約2億1900万円の損失がシステム障害により発生しています。

www.ipa.go.jp

取得できる全ての情報を監視することは非常に難しいです。
システムから取得できる情報が膨大であることがその要因の一つとして、挙げられます。

Prelertのinfluencer検出機能を使えば、収集したメトリクスから、
システムの異常をいち早く見抜くことができそうです。

Case3　テレマティクス

自動車盗難の被害者に10件中2件しか自動車が戻ってこないことについて次の記事に掲載されています。

STOP THE 自動車盗難 自動車盗難の現状

自動車が盗難されるとGPSデータは通常の利用時に取得できるデータと
異なる傾向のデータを取得できそうです。
Prelertのinfluencer検出機能を使って、普段と異なる振る舞いの検知をし、
盗難車を発見することができそうです。

Influencer検出機能を使ってみる

データの説明

今回、利用するのは公式サイトのWebサービスのログデータになります。

ログの例は次のとおりです。

2016/04/04 00:00:00 INFO  [http-8680]: FareQuoteImpl - FareQuoteImpl.getFare(AAL): exiting: 132.2046
2016/04/04 00:00:00 INFO  [http-8680]: FareQuoteImpl - FareQuoteImpl.getFare(JZA): exiting: 990.4628
2016/04/04 00:00:00 INFO  [http-8680]: FareQuoteImpl - FareQuoteImpl.getFare(JBU): exiting: 877.5927

今回、サーバのアクセスが急増していると仮定します。このアクセス急増の原因は複数、考えられます。
例えば、キャンペーンを打って同じページにアクセスが集中した、
あるいは、同じ人が目的を持って攻撃してきたのか、更に、特定のサーバにアクセスが偏ってしまったのか・・・。

このデータからアクセスの急増があるのかどうか、
そして、もし急増しているなら、その要因まで辿ってみたいと思います！

データの投入方法

データの入手方法を説明します。

公式サイトからデータをダウンロードして入手します。
ダウンロードしたファイルの中にLogstashとその設定ファイルが含まれています。
それを使うことで、Elasticsearchに投入できます。

データの投入はダウンロードファイルに含まれている「README.TXT」の指示に従ってできます。
「README.TXT」のcurlコマンドのポート番号や「logstash-farequote.conf」の
Elasticsearchのポート番号が9400番になっていることに注意が必要です。

Elasticsearchをデフォルトの設定で起動するとポート番号が9200番で起動します。
そのため、Elasticsearchのポート番号がcurlやLogstashで使用するポート番号と合わず、投入が失敗します。

また、Logstashの設定に書いてあるファイルパスを自分の環境に合わせて書き換える必要があります。

Jobの設定

Prelertのinfluencer検出機能を使って要因を調査しましょう。
まずは検索対象のindexとして「farequote」を選択します。

次の画面の「name」と「description」は今回のindexと同じ「farequote」を入力します。

「function」の項目は「count」、「byFieldName」の項目は「airline」を選択します。
これは、「airline」ごとに異常検知を行う設定です。
このように設定することで、どの「airline」のアクセス回数が急激に変化したかわかります。

次に「bucketspan」を30minutesに設定します。
そしてここが今回の肝です！influencersを設定します。
今回は@version以外を選択します。

最後にjobをSaveし、起動します。

Influencer検出機能の結果

Summary View

画像にある赤色のセルは異常度が高い箇所を示しています。

また、次の画像はinfluencer検出機能の結果を示しています。
赤いセルが画像内の「AAL」、「American Airlines」の4月6日の12:00過ぎに見られます。
これは「AAL」、「American Airlines」の値が4月6日12:00過ぎに異常の要因として
検知されていることを示しています。

Exproler

「Exproler」画面はSummaryで確認した異常傾向の詳細を確認できます。

「Anomalies」の項目は検出された要因（found for、influenced by）やその時間を
ジャーナル形式で表示できます。
「Anomalies」からは、「airline」と「name」属性ともに同じ箇所で判定できていることを確認できます。

では、「AAL」と「American Airlines」のアクセス回数が実際にどうだったかを見てみましょう。

実際にどうだったのか

kibanaのVisualizationを使って次のグラフを書いてみました。
横軸を時刻（「@timestamp」）、縦軸がデータ数、それを「airline」属性で分割したグラフです。

「AAL」が16:00付近に増加していることがグラフを見てわかります。

また、「American Airlines」も同様に可視化してみました。
「name」属性でアクセス数を表示してみます。

あ、あれ、名前が違うだけで同じグラフが見えますね。
そして、Prelertの検知がこれらのグラフから正しそうに見えますね！

もしかしたら、検出時刻付近で「American Airlines」、「AAL」に関係する
利用者に魅力的なキャンペーンを打ったのかもしれませんね！

このようにKibanaを使って目でも確かに確認ができますが
アラートの仕組み（Watcher）と組み合わされば、Prelertで自動で検出し、
通知する仕組みが作れるかもしれません！

最後に

Prelertを使って要因の調査をExampleから試してみました。
異常要因の調査に非常に役立つ感じがし、これがプログラミング不要で
挑戦できるのかが良い感じです！

Acroquest Technologyでは、キャリア採用を行っています。

• ビッグデータ（Hadoop/Spark、NoSQL）、データ分析（Elasticsearch、Python関連）、Web開発（SpringCloud/SpringBoot、AngularJS）といった最新のOSSを利用する開発プロジェクトに関わりたい。
• マイクロサービス、DevOpsなどの技術を使ったり、データ分析、機械学習などのスキルを活かしたい。
• 社会貢献性の高いプロジェクトや、顧客の価値を創造するようなプロジェクトで、提案からリリースまで携わりたい。
• 書籍・雑誌等の執筆や、対外的な勉強会の開催・参加を通した技術の発信、社内勉強会での技術情報共有により、エンジニアとして成長したい。

　
少しでも上記に興味を持たれた方は、是非以下のページをご覧ください。

【Elastic search 関連】
Elasticsearchを仕事で使いこみたいデータ分析エンジニア募集中！ - Acroquest Technology株式会社のエンジニア中途・インターンシップ・契約・委託の求人 - Wantedlywww.wantedly.com

【データ分析】
データ分析案件の急増に伴い実践的なデータ分析エンジニアWanted！ - Acroquest Technology株式会社のエンジニア中途・インターンシップ・契約・委託の求人 - Wantedlywww.wantedly.com

Elastic Stack 5.1.1がリリースされました！

こんにちは@shin0higuchiです。

つい先日、Elastic Stack 5.1.1がリリースされました。
バージョン5.0.0が出たばかりだというのに、凄まじいスピード感です.....

今回のバージョンも新機能の追加がいくつかありました。
早速さわってみたので、主なものをいくつか紹介していこうと思います。

新機能1．新たなVisualization「Tag cloud」が追加

データ数やその他のパラメータの大きさを、文字サイズで表現する機能です。
例えば上の画像では、売り上げが多かったお菓子の名前を大きく表示するということができます。
上手く使えばビジュアル的に面白い画面を作ることができそうです。

新機能2．クエリのキャンセル機能がついた

task management APIを通じて、検索クエリをキャンセルすることができるようになりました。
POST _tasks/task_id:1/_cancel のようにtask_idを指定することでクエリをキャンセルします。

他にも、特定の処理をまとめてキャンセルすることも可能です。
例えば下記のクエリのようにすれば2つのノードで走っているreindex処理をキャンセルすることができます。
POST _tasks/_cancel?nodes=nodeId1,nodeId2&actions=*reindex
うっかり処理が重くなるようなクエリ投げてしまった場合でも、この機能があれば安心です(笑)

新機能3．Graphで複数indexを指定できるようになった

以前はGraphでindexを指定する際は、単一のindex名を指定することしかできませんでした。今回のバージョンからは他のvisualizationと同じように、”logstash-*”のような形式で複数のindexを分析対象にすることができます。

新機能4．クエリの実行時間を確認できるProfiler機能

X-Packの機能になるようですが、クエリの実行時間を確認できるProfilerという機能が追加されました。

上の画像のように、どのシャードに対してどれくらいの時間がかかったかということが一目でわかります。
また、queryとaggregationを別々に確認することができるので、どの部分が重い処理なのかを簡単に確認することができます。

Elastic Cloud便利

余談になりますが今回バージョンアップする時に、Elastic Cloudを使っていて、すごい便利だなぁと感じました。
Web上でボタンをワンクリックするだけで、Elastic Stack全体のバージョンアップが完了して使えるようになります。

Windowsのローカルマシンでのバージョンアップも同じくらい楽にできるようになって欲しいものです。

3月のElastic{on}で発表された機能で、実装されていないものも数多くあるので、今後に期待したいところですね^^

以上、@shin0higuchiがElastic Stack 5.1.1の新機能について紹介しました。

Acroquest Technologyでは、キャリア採用を行っています。

• ビッグデータ（Hadoop/Spark、NoSQL）、データ分析（Elasticsearch、Python関連）、Web開発（SpringCloud/SpringBoot、AngularJS）といった最新のOSSを利用する開発プロジェクトに関わりたい。
• マイクロサービス、DevOpsなどの技術を使ったり、データ分析、機械学習などのスキルを活かしたい。
• 社会貢献性の高いプロジェクトや、顧客の価値を創造するようなプロジェクトで、提案からリリースまで携わりたい。
• 書籍・雑誌等の執筆や、対外的な勉強会の開催・参加を通した技術の発信、社内勉強会での技術情報共有により、エンジニアとして成長したい。

　
少しでも上記に興味を持たれた方は、是非以下のページをご覧ください。
www.wantedly.com

Elasticsearchのデータを別のElasticsearchに入れるいくつかの方法

こんにちは、 @snuffkin です。

この記事は、Elastic stack Advent Calendar 2016の8日目です。
qiita.com

皆さんは、Elasticsearchのデータを、別のElasticsearchに入れたいことってありませんか？
私は実際に、

1. 各自がアドホックに分析するため、個人用のElasticsearchを立てているので、そこにコピーしたい
2. 遠隔地にあり、直接アクセスできないElasticsearchのデータを確認したい

ということをしたい場合があります。
今回は、このようなケースで使える方法をいくつか紹介します。

正攻法はsnapshot機能を利用することかもしれませんが、ちょっとしたコピーをしたいときには敷居が高いのではないかと思います。
ここでは、もう少し簡易に実行する方法を紹介します。

(方法1) Logstashでコピーする

まずは、

各自がアドホックに分析するため、個人用のElasticsearchを立てているので、そこにコピーしたい

のようなケースで使い勝手が良いコピー方法です。

コピー元とコピー先のElasticsearchが同一ネットワークにあることが前提になりますが、LogstashのElasticsearchプラグインを利用してコピーするのが便利です。
具体的な方法については、こちらを参考にすると良いと思います。
stackoverflow.com

(方法2) コピー元で取得したJSONをコピー先に入れる

次は、

遠隔地にあり、直接アクセスできないElasticsearchのデータを確認したい

のようなケースで使い勝手が良いコピー方法です。

遠隔地で別の人がKibanaを操作していて、見ているデータを自分でも確認したくなるケースがあります。
この場合、KibanaのDiscover機能でデータを取得し、コピー先に入れるのが便利です。
具体的には、次の方法でコピーすることができます。

コピー元でデータを取得する

まずは、コピー元でElasticsearchに入っているデータを次の手順で取得します。

1.メニューから「Discover」をクリックし、Discover画面を表示する

2.コピーしたい時刻に合わせ、グラフ左下の上矢印をクリックする

3.テーブルの上にある「Response」をクリックする

4.表示されるJSONをコピーし、ファイルに保存する(ここでは、Response.jsonに保存するものとします)

コピー先にデータを登録する

次に、コピー先のElasticsearchに入っているデータを登録します。
私はちょっとしたPythonスクリプトを使っています。

1.Pythonがインストールされていない場合は、以下のサイトからダウンロードし、インストールする
www.python.org

2.Python用Elasticsearchクライアントがインストールされていない場合は、インストールする

pip install elasticsearch

3.次のPythonスクリプトを実行する

#!/usr/bin/env python
# -*- coding: utf-8 -*-
import json
from elasticsearch import Elasticsearch

es = Elasticsearch('192.168.0.1')

file = open('Response.json', 'r')
json_data = json.load(file)

for data in json_data['hits']['hits']:
    es.index(index=data['_index'],
             doc_type=data['_type'],
             body=data['_source'],
             id=data['_id'])

※'192.168.0.1'のところには、コピー先のElasticsearchを指定してください。

これで、コピー先のElasticsearchにデータが入ります。

私の場合、遠隔地のデータを確認したいケースがあるため、これで重宝しています。
この方法が、同じような状況の方に役立てば幸いです。

Acroquest Technologyでは、キャリア採用を行っています。

• ビッグデータ（Hadoop/Spark、NoSQL）、データ分析（Elasticsearch、Python関連）、Web開発（SpringCloud/SpringBoot、AngularJS）といった最新のOSSを利用する開発プロジェクトに関わりたい。
• マイクロサービス、DevOpsなどの技術を使ったり、データ分析、機械学習などのスキルを活かしたい。
• 社会貢献性の高いプロジェクトや、顧客の価値を創造するようなプロジェクトで、提案からリリースまで携わりたい。
• 書籍・雑誌等の執筆や、対外的な勉強会の開催・参加を通した技術の発信、社内勉強会での技術情報共有により、エンジニアとして成長したい。

　
少しでも上記に興味を持たれた方は、是非以下のページをご覧ください。
www.wantedly.com

大規模サーバ更改でServerspecを使ってみました

こんにちは、おじさん技術者の iga です。

とあるサーバ更改のプロジェクトで、「Serverspecを使った設定チェック」を実施しましたので、その時のノウハウを共有したいと思います。

設定チェックの対象となるサーバが全部で約600台あり、あるサーバ種別で最大282台と大規模なため、人力でのチェックはあきらめていました。
そこで利用したのが、Serverspecです。

Serverspecとは

Serverspecは、サーバの状態をコードにより自動的にテストするためのツールです。
公式サイトはこちらです。
http://serverspec.org/

Ruby製のテストフレームワークRSpecがベースになっていて、抽象化したコードによってサーバの状態を確認するようになっています。

システム構成の概要

今回のテスト対象のシステム構成は、次の図のようになっています。

メンテナンス端末にServerspecをインストールして、メンテナンス端末からテスト対象のサーバにsshで接続できるようになっています。

今回のカスタマイズ方針

サーバの台数は多いのですが、同じ役割のサーバが数十台で構成されるとなっているため、Serverspec標準のテスト方法だと、同じチェック内容を大量に複製する必要があります。
標準のフォルダ構成だと、以下の図のようになります。

「websvr001」と「websvr002」に同じテストを適用していますが、台数が少ない間はファイルのコピーやシンボリックリンクで対応できますが、台数が増えると管理しきれなくなります。

そこで、複数サーバでテストを共有するため、公式サイトにも記述されている「How to share Serverspec tests among hosts」という手法を取りました。

サーバ種別ごとにテスト対象を配置することで、同じサーバ種別で台数が増えても、管理できるようになりました。

ただ、サンプルで記述されている内容だと、以下のような問題があってそのまま適用できませんでした。
1) 対象サーバが固定で記述されている。
→台数が多いので、テスト時間短縮のためあるサーバ種別だけテストしたい、ということができない。
2) サーバ種別（Role）をサーバ名から取得するようになっている。
→サーバ名が命名規則に沿ってつけられているが、サーバ種別が分かりやすい名前になっていない。
→記述ミスがあると実行の無駄になってしまうので、分かりやすい記述にしたかった。

今回対応するカスタマイズ内容

今回の対応（以降、Role対応 と記載します）では、以下のことを行いました。
1) 対象サーバとサーバ種別は、JSON形式の外部ファイルに用意しておく。
2) サーバ種別は、分かりやすい名前にしておく。

具体的なカスタマイズ内容

Role対応するため、Rakefileを次のように修正しました。
Rakefileは、Serverspecが自動生成した、テストを実行する処理が記述されたファイルになります。

まずは実行対象のサーバ情報を取り出すところです。

標準のRakefile

  targets = []
  Dir.glob('./spec/*').each do |dir|
    next unless File.directory?(dir)
    target = File.basename(dir)
    target = "_#{target}" if target == "default"
    targets << target
  end

標準ではspecフォルダ配下のフォルダが実行対象サーバ名（またはIPアドレス）になっているので、それを読み込んで実行対象（target）に保存しています。

Role対応版Rakefile

  # 環境変数から使用するIPアドレスリストを取得
  rolePath = ENV['SERVERSPEC_ROLE']

  # specフォルダ配下のrole名を取得する
  roles = []
  Dir.glob('./spec/*').each do |dir|
    next unless File.directory?(dir)
    target = File.basename(dir)
    roles << target
  end

  # role別のIPアドレスリストをjsonファイルから読み込む
  all_addrs = []
  targets = []
  roles.each do |role|
    ip_addrs = get_ipaddr(rolePath, role)
    if ip_addrs
      all_addrs.concat(ip_addrs)

      ip_addrs.each do |ip_addr|
        targets << {:role => role, :addr => ip_addr}
      end
    end
  end

Role対応では、specフォルダ配下のフォルダがサーバ種別になっているので、それを読み込みます。
そして、JSONファイルからサーバ種別と実行対象サーバ名を読み込んで、specフォルダ配下にサーバ種別が定義されている場合に、サーバ種別と実行対象サーバ名をtargetに保存しています。
読み込むJSONファイル名は、環境変数「SERVERSPEC_ROLE」から取得しています。

JSONファイルのフォーマットは、次のようにしています。
サーバ種別をキーとして、実行対象サーバ名を配列として定義しています。

  {
    "websvr" : [
      "websvr001",
      "websvr002"
    ],
    "appsvr" : [
      "appsvr001"
    ],
    "dbsvr" : [
      "dbsvr001"
    ]
  }

テストの実行部分は次のようになります。

標準のRakefile

  targets.each do |target|
    original_target = target == "_default" ? target[1..-1] : target
    desc "Run serverspec tests to #{original_target}"
    RSpec::Core::RakeTask.new(target.to_sym) do |t|
      ENV['TARGET_HOST'] = original_target
      t.pattern = "spec/#{original_target}/*_spec.rb"
    end
  end

標準では、targetに入っているサーバ分、テストを実行しています。

Role対応版Rakefile

  targets.each do |target|
    original_role = target[:role]
    original_target = target[:addr]
    begin
      desc "Run serverspec tests to #{original_target}"
      RSpec::Core::RakeTask.new(original_target.to_sym) do |t|
        ENV['EXEC_TIME'] = Time.now.strftime("%Y%m%d_%H%M%S").to_s
        ENV['SERVER_KIND'] = original_role
        ENV['TARGET_HOST'] = original_target
        t.pattern = "spec/#{original_role}/*_spec.rb"
        t.fail_on_error = false
      end
    rescue => ex
      puts ex.message
    end
  end

Role対応では、標準と同じくtargetに入っているサーバ分、テストを実行しています。その際、specフォルダ配下のサーバ種別をtargetに格納したroleから決定するようにしています。

Role対応の結果、サーバ種別「websvr」に対してテストする場合、次のように実行します。

  $ export SERVERSPEC_ROLE=addr/websvr.json
  $ rake spec

まとめ

今回、初めてServerspecを利用しましたが、その威力に感動しました。
これまでは、サーバの設定確認といえば目視やdiffを使った差分確認など、人の注意力に頼った作業をやっていました。
それでは設定ミスを見落としたことが、後になって見つかって大変になる、ということをやってきました。

Serverspecを利用すると、設定のOK／NGが分かりやすく出てくるため、NG理由を確認するのも設定ミスなのかテスト内容のミスなのか、切り分けが容易になりました。

それでは！

Acroquest Technologyでは、キャリア採用を行っています。

• ビッグデータ（Hadoop/Spark、NoSQL）、データ分析（Elasticsearch、Python関連）、Web開発（SpringCloud/SpringBoot、AngularJS）といった最新のOSSを利用する開発プロジェクトに関わりたい。
• マイクロサービス、DevOpsなどの技術を使ったり、データ分析、機械学習などのスキルを活かしたい。
• 社会貢献性の高いプロジェクトや、顧客の価値を創造するようなプロジェクトで、提案からリリースまで携わりたい。
• 書籍・雑誌等の執筆や、対外的な勉強会の開催・参加を通した技術の発信、社内勉強会での技術情報共有により、エンジニアとして成長したい。

　
少しでも上記に興味を持たれた方は、是非以下のページをご覧ください。
　
急増するDevOps案件の中でスキルを活かしたいエンジニア募集！ - Acroquest Technology株式会社のインフラエンジニア中途・インターンシップ・契約・委託の求人 - Wantedlywww.wantedly.com

「Jupyter Notebookを納品した話」で発表しました

こんにちは@tereka114です！
先日、社内勉強会がありました。
今回、私は「Jupyter Notebookを納品した話」で、発表しました。

普段、Jupyter Notebookをデータ分析や機械学習を取り組む中で使います。
このJupyter Notebookを案件の中で使ってみた時に感じたことを発表しました。

実際のスライドはSlide Shareにアップロードしました。

Jupyter Notebookを納品した話 from Hiroki Yamamoto

www.slideshare.net

Jupyter Notebook一つでドキュメンテーション、コード、図を書き、分析過程を見せられます。

実際の仕事で使うと自分の考えや分析の過程、そして、結果を説明する場面は必ず遭遇します。
そんな時に非常に重宝しました。

また、仕事を通してJupyter Notebookの良かった点、悪かった点、難しかった点、
そして、それをどう回避すればよかったのかといったことを話し、ディスカッションしました。

発表内容の詳細はスライドを見てください。

分析結果の共有やレポートの作成にぜひ、Jupyter Notebookを使ってみてください！
Jupyter Notebook 最高！

Acroquest Technologyでは、キャリア採用を行っています。

• 日頃勉強している成果を、AWS、Hadoop、Storm、NoSQL、Elasticsearch、SpringBoot、HTML5/CSS3/JavaScriptといった最新の技術を使ったプロジェクトで発揮したい。
• 社会貢献性の高いプロジェクトに提案からリリースまで携わりたい。
• 書籍・雑誌等の執筆や対外的な勉強会の開催を通した技術の発信や、社内勉強会での技術情報共有により、技術的に成長したい。
• OSSの開発に携わりたい。

　
少しでも上記に興味を持たれた方は、是非以下のページをご覧ください。
　
データ分析で国内に新規市場を生み出す新サービス開発者WANTED！ - Acroquest Technology株式会社の新卒・インターンシップ - Wantedlywww.wantedly.com

Prelertでプログラミングレスな異常検知に挑戦！

こんにちは！
@tereka114です。

最近、データの中から特異点や異常な箇所を発見したいニーズが高まっています。

そんななか、先日、Elastic社が行動分析技術の大手プロバイダPrelertを買収したとのニュースがありました。

ちなみにPrelert社とは異常検知を自動化するため、データの知識が不要なアプリケーションをエンドユーザーに提供していた企業です。

Prelertのサイトを確認すると、Elasticsearchに入れたデータに対して異常検知することができそうです。
これは面白そう！　ということで、Prelertを使って異常検知を行ってみました。

今回は、次の流れで説明していきます。

Prelertとは

PrelertはITセキュリティと運用チームのための行動分析ツールです。公式サイトは次のとおりです。

公式サイトに掲載されている特徴として、次の3つがあります。

1. 脅威を早期に検出・・・リアルタイムに近いデータ処理でユーザがレポートを出す前に検知する。
2. より高速な原因の発見・・・環境の学習を行い、より高速に原因を分析できる。
3. 少ない偽陽性の検出・・・データのコンテキストを理解し、偽陽性の検出を減らす。

いくつか魅力的な特徴が上がっています。
しかし、私の考える最も良い点はプログラミングレスであり、かつ数式を意識する必要がない点だと思います。
そのため、なんとなく異常検知に取り組みたいと考えている人も、複雑な数式を学ぶ必要はなく、Prelertを使って異常検知できます。
また、Prelertは教師なし学習のため、予め教師データの異常をラベリングする必要がないことも特筆すべき点だと思います。

Prelertでは、次のような画面で異常を検知することができます。
後ほど詳細を記載しますが、白 → 青 → 黄 → オレンジ → 赤と、赤に近いほど異常度合いが高いことを示しています。

Prelertのインストール

公式サイトからのダウンロード

PrelertのBeta版を公式サイトからダウンロードすることができます。
Prelert behavioral analytics platform: Home

今回はトップページにあった「Behavioral Analytics for the Elastic Stack Beta」のFree Trialを試します。
Free Trialを行なうにあたって登録が必要となります。登録するとインストーラがダウンロードでき、また14日間の試用ライセンスキーがメールで届きます。

インストール

Prelertのインストールは、基本的にインストーラーに従うだけで完了しました。
途中ライセンスキーを求められるため、メールで届いているものを利用します。

このインストーラによりインストールされるプロダクトは次の通りです。

• Prelert Engine API version: 2.1.2
• Prelert analytics version: 6.3.1
• Kibana version: 4.6.1
• Elasticsearch version: 2.4.0

ちなみにPrelertをインストールすると、OS起動時にこれらのプロダクトが起動します。
私は別のElasticsearchを起動していて、うっかり同じポート番号を使ってしまっており、起動に失敗しました。
Windows環境では自動起動のサービスを「Shutdown Prelert Engine Service」でOFFにすることができます。

起動確認

Windows環境では「Start Prelert Engine Service」を実行すると、elasticsearch、kibanaが起動します。
kibanaの画面を見てみましょう。
「http://localhost:5601/」へアクセスをすると、PluginにPrelertがあることが分かります。

Prelertを開くと、次のような画面になります。

無事にインストールできているようです。

実際に異常検知をやってみる。

データ投入

では実際に異常検知をやってみましょう。
今回は異常検知の対象データとして、Numenta Anomaly Benchmark（NAB）にある、CPU使用率のデータを利用しました。

次のようなデータです。時間とCPU使用率が列挙されています。

timestamp	value
2014-05-14 01:14:00	85.835
2014-05-14 01:19:00	88.167
2014-05-14 01:24:00	44.595

このデータをKibanaで可視化すると、次のようになります。

あぁなんか見るからに異常値が・・・みたいなことは、気づかないのが大人です。

NABのデータはcsv形式で提供されているため、logstash2.4.0を使ってElasticsearchに投入しました。
参考までに、Elasticsearch上に作ったマッピング定義と、Logstashの設定を掲載しておきます。

マッピング定義

データを投入する前に、Elasticsearch上でマッピング定義を作っておきました。

{
  "mappings": {
    "_default_": {
      "_all": {
        "enabled": true,
        "norms": {
          "enabled": false
        }
      },
      "properties": {
        "timestamp": {
          "type": "date",
          "format": "YYYY-MM-dd HH:mm:ss"
        },
        "value": {
          "type": "double"
        }
      }
    }
  },
  "settings": {
    "index.refresh_interval": "5s"
  },
  "template": "cpu_utilization_asg_misconfiguration"
}

Logstashを使ったデータ投入

Logstashのconfファイルは次の通りです。

input {
   stdin{}
}

filter {
    csv {
        columns => ['timestamp', 'value']
    }

    date {
        match => [ "timestamp", "YYYY-MM-dd HH:mm:ss" ]
        timezone => "UTC"
    }
}

output {
    elasticsearch {
        hosts => ["localhost:9200"]
        index => "cpu_utilization_asg_misconfiguration"
    }
}

この設定とtypeコマンドを使ってデータを流し込みました。

Prelertを使った異常検知の実行

ではPrelertで異常検知を行なってみます。

Jobの作成

まず異常検知するためのJobを作成します。最初にデータソースを選択します。
今回はElasticsearchにデータを保存しているので「Elasticsearch server」を選択しました。

次にindexやtype、日付フォーマットなどを指定します。

indexは一つしか選べませんば、typeは複数選べますね。

Jobの詳細設定

続いてJobの詳細を設定します。
タブの中から「Analysis Configuration」を選んで異常検知の設定をします。

まずbucketSpanは「5minutes」とします。
bucketSpanは集約期間を示しており、たとえば5minutesとした場合は、5分間での平均や合計を用いて検知することになります。

次に「Add Detector」から、異常検知のルールを追加します。
今回はfunctionにmean（平均）、fieldNameにvalueを設定しました。

それぞれのパラメータの意味は次の通りです

1. function: 検知に用いる集計関数（平均や合計）
2. fieldName: 検知の対象となるフィールド

これで、5分間の平均値が異常な値になった場合に検知できるようになります。
ここまでで、異常と判断する閾値や、アルゴリズム、パラメータなどを設定していないあたりがポイントですね。

これで、Saveを押すと異常検知アルゴリズムの設定は完了です。
保存時に「No Influencers」と警告が現れますが、今回は設定しないので、力強く「OK」を押しました。

そして「Start Scheduler」を押して、検知の対象とするデータの範囲（開始時間、流量時間）を指定します。

これでStartを押すとJobが動き出し、異常検知のスコアが計算されます。
しばらく待って完了したら、異常検知の処理は完了です。

今回のデータ量であれば、数秒程度で処理は終わりました。

Prelertの画面説明

それでは異常検知の結果を見てみましょう。

画面の上の方にタブがありますが、それぞれのタブでは次のような情報の閲覧、管理ができます。

画面	機能概要
Jobs	異常検知タスクを管理する画面
Summary View	異常検知の概要を見る画面
Explorer	詳細に異常検知の概要を見る画面
Connections	Exploere画面に出ているアラート一覧を、influencerごとにまとめた画面
Supports	ElasticsearchのVersion、サポート情報が書いてある画面

それぞれの画面を見ていきましょう。ただしConnectionsは今回は扱いません

Jobs

Jobsは、Jobに対する操作や情報を確認することができる画面です。

それぞれのカラムは、次のことを示しています。

カラム	概要
Search Name	設定したJobの名前
Description	設定したJobの説明
Processed records	どのくらいのデータを処理したか
Memory status	メモリの状態
Job Status	Jobの状態
Latest timestamp	処理完了したデータで最も遅い時間
Actions	Jobに対するアクションが記載されています。 左から順番に、Jobの開始、結果確認、Exprolerの確認、Jobの編集、複製、削除となっています。

Summary View

Summary Viewは、結果の概要を色分けして示す画面です。
時間ごとの異常度合いを色で示しており、白 → 青 → 黄 → オレンジ → 赤 と、赤に近いほど異常度合いが高いことを示しています。

Explorer

Explorerは詳細を確認する画面です。
Explorer画面のAnomaly timelineでは、Detectorの集約期間ごとの異常値を表示します。
また、Anomaliesは画面に表示されている異常検知の値をジャーナル形式で表示しています。
このジャーナル形式から具体的な値や検出位置を確認することができます。

今回投入したデータは、NAB/known_labels_v1.0.json at master · numenta/NAB · GitHub の情報によると、「2014-07-12 02:04:00.000000」と「2014-07-14 21:44:00.000000」に異常があるようです。
さて、Prelertの実行結果はと言うと、Summary ViewやExplorerの図で分かる通り、2014年7月15日付近（右端）の色が変わっており、うまく検知できているようです。

このように、Prelertを使うと簡単な操作でデータから異常を検知することができます。

最後に

Prelert、いかがでしたでしょうか？
Prelertを使うと、Elasticsearchに入っているデータに対し、プログラミングレスで異常検知と可視化ができます。
これで、Elasticsearchがますます便利になりますね！

Acroquest Technologyでは、キャリア採用を行っています。

• 日頃勉強している成果を、AWS、Hadoop、Storm、NoSQL、Elasticsearch、SpringBoot、HTML5/CSS3/JavaScriptといった最新の技術を使ったプロジェクトで発揮したい。
• 社会貢献性の高いプロジェクトに提案からリリースまで携わりたい。
• 書籍・雑誌等の執筆や対外的な勉強会の開催を通した技術の発信や、社内勉強会での技術情報共有により、技術的に成長したい。
• OSSの開発に携わりたい。

　
少しでも上記に興味を持たれた方は、是非以下のページをご覧ください。
　
データ分析で国内に新規市場を生み出す新サービス開発者WANTED！ - Acroquest Technology株式会社の新卒・インターンシップ - Wantedlywww.wantedly.com

SORACOM Beam のアノ機能追加に感動しました！

これはSORACOMリリース1周年記念リレーブログ10/31分です。

blog.soracom.jp

山下@YamaHaruka925です。
10月に開催されたSORACOM UG#4に参加した、SORACOMさんのソリューションパートナーであるAcroquestで働く女性エンジニアで、IoTプラットフォーム開発やってます。
お酒をこよなく愛するリケジョです。（リケジョブログも書いてます^^）
SORACOM UGで熊崎さんとお話ししてたら、楽しくお酒を飲んで酔った勢いで、リレーブログ参戦が決定！

今回は、最近体験した「え！？こまった！」を解決してくれたSORACOMさんのアップデートについて書いてみようかなと。

SORACOM Beamがつながらないが原因不明。。。

AcroquestではIoTアプリケーションプラットフォーム「Torrentio」を提供してるわけですが、相談に来られる方々は、やっぱり、センサーからデータ分析・可視化まで一貫して提供してほしい！！という人が多いので、SORACOMさんやその他パートナー企業さんのお力を借りて、トータル提供する流れになります。

そんなある日。
SORACOMのBeamも使用した実証検証を実施することに。

いざ、設定も完了し、データ送信検証開始！

・・・つながらない。

通信できていないようすだけど、エラーも出力されない。
Beamの設定が悪いのか？
はたまたデータ受付側が悪いのか？
送っているデータに不備があるのか？

・・・さっぱりわからない。

手探りでデバッグ、、、なかなか大変でした(^^;

そんなとき、新機能追加の朗報が！

「新機能：SORACOM Beam / Funnel のエラーログが確認できるようになりました」

blog.soracom.jp

ということで、

SORACOM Beamでエラーログの確認、やってみた

構成

OpenBlocks IoT EX1に、SORACOM SIMを挿して、
SORACOM Beamを利用してAWS API Gatewayに転送します。
AWS API Gatewayからは、受け取ったデータをそのまま返却します。

AWS API Gatewayの設定は、POSTメソッドで簡単にするために認証なしを採用。

AWS API Gatewayの後段には、Lambdaを置き、うけとったデータをそのまま返却するスクリプトを書く。

設定ができたら、ステージにデプロイし、URLをgetします。
このURLが、SORACOM Beamの転送先に設定するURLになります。

SORACOM Beamの設定はこんな感じ。

エントリポイントは、「http://beam.soracom.io:8888/test」
転送先には、上記で作成したAWS API GatewayのURLを指定しています。

エラーログ確認方法

エラーログは、SORACOMコンソールのサイドメニュー「ログ」から確認できます。

SIMのIMSIを入力することで、エラーログを絞り込んで表示することができます。

通信して検証

まずは、Beamを使って正常に通信。

$ curl -XPOST http://beam.soracom.io:8888/test -d '{"key":"value"}'
{"key":"value"}

API Gatewayから、送ったデータがそのまま返ってきます。
このとき、エラーは発生していないので、SORACOMコンソールのログ表示を見ても、空っぽ。

つぎに、誤ったURLで送信してみましょう。

$ curl -XPOST http://beam.soracom.io:8888/xxxx -d '{"key":"value"}'
{"message":"Beam configuration for http://beam.soracom.io:8888/xxxx is not found"}

エラーメッセージが返ってきて、「URLがみつからない」ということが一目瞭然。
SORACOMコンソールのログを確認してみると、

エラーログが表示されている！！
これがあれば、リモートで実施している検証でも、エラーをトレースしてデバッグできる！

「便利！！！」

他のエラーも同様に、レスポンスでエラーメッセージが返ってくるとともに、
SORACOMコンソールからログが確認できます。

【メッセージのフォーマット謝り】

$ curl -XPOST http://beam.soracom.io:8888/test -d 'test message'
{"message":"Could not parse request body into json: Unrecognized token \'test|' was expecting\'null\',\'true\',\'false\' or NAN\n at [Source: [B@c9e04ec; line: 2, column: 6]"}

【認証不正】

$ curl -XPOST http://beam.soracom.io:8888/test -d '{"key":"value"}'
{"message":"Missing Authentication Token"}

SORACOMコンソールのログはこんな感じ。

エラーコードがコンソールから確認できるので、リモートでも何が悪いかの推測が立ちますね。

要望に迅速に対応してもらえるのはありがたい！

このBeamのエラーログ取得機能も、ユーザーからの声を聞いて、
機能追加となったとのこと。

私自身、新機能追加の1週間ほど前に苦労していた内容でした。
実際にBeamを設定し、デバイスにSIMを挿して検証しましたが、実はデバイス側での送信先指定が誤っており、通信ができていなかった。。。
なんてミスをして、検証やり直し。。。なんて苦い思い出が。

なので、今回の機能追加はとてもとてもありがたい。

なので、メジャーなA～Gのサービス追加のような機能追加ではありませんが、このようなユーザの要望に迅速に対応して、サービスに反映している部分こそ、SORACOMさんの素晴らしさだと思いました。

バックエンドで対応してくださっているSORACOMのエンジニア/サポートのみなさん、ありがとうございます！！！

Acroquest Technologyでは、キャリア採用を行っています。

• 日頃勉強している成果を、AWS、Hadoop、Storm、NoSQL、Elasticsearch、SpringBoot、HTML5/CSS3/JavaScriptといった最新の技術を使ったプロジェクトで発揮したい。
• 社会貢献性の高いプロジェクトに提案からリリースまで携わりたい。
• 書籍・雑誌等の執筆や対外的な勉強会の開催を通した技術の発信や、社内勉強会での技術情報共有により、技術的に成長したい。
• OSSの開発に携わりたい。

　
少しでも上記に興味を持たれた方は、是非以下のページをご覧ください。
　
データ分析で国内に新規市場を生み出す新サービス開発者WANTED！ - Acroquest Technology株式会社の新卒・インターンシップ - Wantedlywww.wantedly.com