【速報】Elastic Stack 5.0.0-alpha1がリリースされました

※ 現在、α版のため、GAまでに実装が変わる可能性があることはご了承ください。

はじめに

藤本です。

遂に来ました！！Elastic{ON}2016で発表されて一ヶ月半！！

α版ですが、Elastic Stack 5.0.0がリリースされました。Elastic{ON}2016で発表されていたロードマップのあんな機能や、こんな機能が触れるようになりました。

• Elastic Stack Release - 5.0.0 alpha 1
• Elasticsearch 5.0.0-alpha1 released
• Logstash 5.0.0-alpha1 released
• Kibana 5.0.0-alpha1 released
• Beats 5.0.0-alpha1 released

既に日本語の記事は@johtaniさんが翻訳済みです。

• Elastic Stack 5.0.0 alpha 1 リリース

概要

本エントリではまずリリースされたことをお伝えするとともに私が注目する機能をご紹介します。
各種機能レビューは別途試して、エントリします。

Elasticsearch 5.0.0

• Elasticsearch 5.0.0-alpha1 released

Ingest Node

ElasticsearchはNodeの役割にData、Master、Client、Tribeがありましたが、5.0.0でIngestの役割が追加されました。
Ingest NodeはElasticsearchにIndexされるドキュメントに対してデータの加工を行うことができます。例えば、Logstashのgrok、split、dateといったFilterの作用をElasticsearchで動作させることができます。

現在、データの加工の種類（Processor）は以下がサポートされています。

• Append Processor
• Convert Processor
• Date Processor
• Fail Processor
• Foreach Processor
• Grok Processor
• Gsub Processor
• Join Processor
• Lowercase Processor
• Remove Processor
• Rename Processor
• Set Processor
• Split Processor
• Trim Processor
• Uppercase Processor

これにより特に期待することがBeatsから送られたデータの加工です。Beatsは現在、データ取得・送信だけに集中させることでサーバへの影響・負荷を限りなく低くし、動作するようになっています。そのため取得したデータを加工したい場合、LogstashやFluentdを経由させる必要がありました。LogstashやFluntdを経由する場合、加工用にサーバを立てなくてはいけなかったり、そのためにSPOFのポイントができ、可用性を下げたりが懸念されました。
それがIngest Nodeが加わることでデータを加工したい場合でもBeatsからLogstashを経由することなく、Elasticsearchへ直接データを送信し、ElasticsearchのIngest Nodeでデータを加工することが可能となりました。

またAWSで言えば、AWSのリソースがS3に出力するログファイルをKibanaで可視化したいユースケースがあります。その場合、私はS3 PutObjectイベントをトリガーに、AWS Lambdaでメッセージを取得、パース、Elasticsearchへの出力を実装しています。そのパース処理をElasticsearchへオフロードできれば、処理制限時間(5分間)や時間課金といった課題への有効な対策となります。

Painless Scripting

ElasticsearchはAPIにScriptを利用することが可能でした。
2.x系までは対応言語として、Goovy、Javascript、Pythonをサポートしていました。
5.0.0からは早い、安全、安心なElastic独自のPainless Scripting Languageが追加されました。構文はJavascriptやGroovyに似ているようです。

動的型付けで可読性の高いコードも書ければ、静的型付けで高速に動作するコードも書けます。動的型付けと静的型付けで10倍ぐらい処理速度が変わることがあるとのことなのでまずは動的型付けでプロトタイプを書いてみて、実運用時は静的型付けで書くのが良いようです。

Logstash 5.0.0

• Logstash 5.0.0-alpha1 released

Monitorig API

LogstashがAPIに対応しました。データ送信が役割のLogstash。止まったり、過負荷により落ちるとデータロストの危険がありますよね。そのために監視関連のAPIが実装されました。。

• Root Resource API
  Logstashノードの情報を取得します。Elasticsearchの/と同じような情報を取得できます。

• Plugins API
  Pluginの情報を取得できます。

• Stats Info API
  Logstashを起動してから発生したイベント数、jvmのステータスを取得することができます。イベントは入力、フィルタ、出力それぞれの数を取得することができます。jvmはJVM statsやGCの情報を取得することができます。

GET /_node/stats/events

{
    "events": {
        "in": 91,
        "filtered": 91,
        "out": 91
    }
}

GET /_node/stats/jvm

"jvm":{
   "timestamp":1453233447702,
   "uptime_in_millis":211125811,
   "mem":{
      "heap_used_in_bytes":58442576,
      "heap_used_percent":5,
      "heap_committed_in_bytes":259522560,
      "heap_max_in_bytes":1037959168,
      "non_heap_used_in_bytes":56332256,
      "non_heap_committed_in_bytes":57475072,
      "pools":{
         "young":{
            "used_in_bytes":41672000,
            "max_in_bytes":286326784,
            "peak_used_in_bytes":71630848,
            "peak_max_in_bytes":286326784
         },
         "survivor":{
            "used_in_bytes":260552,
            "max_in_bytes":35782656,
            "peak_used_in_bytes":8912896,
            "peak_max_in_bytes":35782656
         },
         "old":{
            "used_in_bytes":16510024,
            "max_in_bytes":715849728,
            "peak_used_in_bytes":16510024,
            "peak_max_in_bytes":715849728
         }
      }
   }

• Hot Threads API

curl localhost:9600/_node/hot_threads?human

Hot threads at 2016-03-30T20:08:22-07:00, busiestThreads=3:
     5.22 % of of cpu usage by waiting thread named '[main]>worker3'
        java.lang.Object.wait(Native Method)
        java.lang.Object.wait(Object.java:460)
        org.jruby.RubyThread$SleepTask.run(RubyThread.java:1050)
        org.jruby.RubyThread.executeBlockingTask(RubyThread.java:1066)
        org.jruby.RubyThread.wait_timeout(RubyThread.java:1414)
        org.jruby.ext.thread.Queue.pop(Queue.java:152)
        org.jruby.ext.thread.Queue.pop(Queue.java:127)
        org.jruby.ext.thread.SizedQueue.pop(SizedQueue.java:111)
        org.jruby.ext.thread.SizedQueue$INVOKER$i$pop.call(SizedQueue$INVOKER$i$pop.gen)
        org.jruby.runtime.callsite.CachingCallSite.call(CachingCallSite.java:134)
     2.44 % of of cpu usage by timed_waiting thread named '[main]-pipeline-manager'
        java.lang.Object.wait(Native Method)
        ....

そういえば、DeatLetterQueueやDiskバッファの機能もリリースに含まれているのかな。

Kibana 5.0.0

• Kibana 5.0.0-alpha1 released

A new design

画面UIのデザインが変わりました。一言で言うならば、ポップになりました。

新しいデザインに関してはKibana v5.0.0を触ってみた #elasticonのエントリをご参照ください。

Beats 5.0.0

• Beats 5.0.0-alpha1 released

Kafka output

Beatsは1.x系までは出力先にElasticsearch、Logstash、File、Consoleをサポートしていました。
Beats 5.0.0からはApache Kafkaへの出力をサポートしています。（Redisへの出力のDeprecatedも気づけば取りていました）
大規模環境ではElasticsearchがAPIを受け切れない問題が発生します。最悪データロストの危険性が発生します。Kafkaへの出力をサポートすることにより、Beatsからの出力にFast、Scalableが特徴のKafkaを挟むことで、データをロストしないようにします。KafkaからElasticsearchへはLogstashを並列実行などして、一定量のAPIをElasticsearchに送り続けることで安定したデータのインデックスが可能なのではないでしょうか？

Elastic{ON}2016の事例でもKafkaを利用しているケースは多いように見受けられました。

まとめ

いかがでしたでしょうか？気になる機能はありましたか？
新機能は多くありますので、リリースノートやドキュメントを眺めてみることをオススメします。