Taste of Tech Topics

Acroquest Technology株式会社のエンジニアが書く技術ブログ

Elastic{ON} 2016レポート What's the Latest in Logstash #elasticon

世界の皆さん、おはようございます @ です。
今日も一日、elastic{ON}でがんばります。

2日目最初のセッションは、Logstashのプロダクト紹介を選びました。
f:id:acro-engineer:20160219055533j:plain:w480

Logstashの現在

まずはLogstashの歴史から。
f:id:acro-engineer:20160219055929j:plain:w400
Logstashは2009年に初めてリリースされ、その後、Logstashにデータを転送するLogstash-forwarderやPacketbeatなどが開発され、それらがまとめてBeatsシリーズとして整理されました。

また5.0シリーズではElasticsearchにLogstashのFilterを機能を移植して、Ingest Nodeという形で提供されることになりました。


LogstashはJenkinsできちんとテストサイクルを回しています。こんな画面も共有されました。
f:id:acro-engineer:20160219055903j:plain:w400
Java7/8でテストしているそうです。

またキーノートでも触れられていた通り、Logstash自身の性能もバージョンを追うごとに改善しています。
f:id:acro-engineer:20160219060008j:plain:w400

データを決してロストしないLogstashに向けて

Logstashはマシンリソースやネットワークリソースが不足した程度では情報を失わないのですが、Logstash自身のプロセスが止まるような状況では情報をロストしてしまいます。
f:id:acro-engineer:20160219060219j:plain:w400

というのもInput、Filter、Outputの間でそれぞれキューを持っており、プロセスが落ちた時点でその情報が失われてしまうためです。
f:id:acro-engineer:20160219055717j:plain:w400


LogstashのInputは、現時点でもKafkaやRabbitMQのAcknowledgeに対応していてInput処理の成功したときだけ、キューから要素を削除するようになっています。要するにトランザクション的なあれです。
f:id:acro-engineer:20160219055949j:plain:w400
ただしFilterやOutputまでは含めたAcknowledgeはまだサポートされておらず、これは今後の対応になります。
f:id:acro-engineer:20160219055626j:plain:w400

Logstash 2.2.0ではバッチ処理もサポートされました。
f:id:acro-engineer:20160219060134j:plain:w400

また、Javaをシリアライゼーションに用いることができるようになるようです。ちょっとよく分かりませんでした。
f:id:acro-engineer:20160219055556j:plain:w400


今後の一番大きな目玉は、キューの永続化でしょう。Logstashに入った情報をディスクなどに永続化することができるようになります。
f:id:acro-engineer:20160219060239j:plain:w400
また デッドレターキューも実装され、Outputで失敗したものはデッドレターキューに入る形になります。


ということでLogstash 5.x系では、Logstashのプロセスが停止しようが、OSごと落ちようが、情報が残ることになります。Logstash最高かよ!
f:id:acro-engineer:20160219055744j:plain:w400

Logstashの管理も改善

後半は、Logstashの管理について。

現行のLogstashでもREST APIを用いてステータスや、重いスレッドの情報などを取得することができるそうです。知らなかった。
f:id:acro-engineer:20160219055803j:plain:w400
f:id:acro-engineer:20160219060044j:plain:w400


また、 次のバージョンではこれらの情報を可視化することが計画されています。もうこの辺りは必須になっていますね。
f:id:acro-engineer:20160219060109j:plain:w400


また、設定周りの改善も計画されています。まずは設定ファイルの自動リロード
f:id:acro-engineer:20160219060259j:plain:w400
ファイルの更新をチェックして、自動的にリロードして、パイプライン処理を新しく始めるというもの。プロセスを再起動する必要はありません。
(うーん、別に自動ではなく、reloadをコマンドでできれば良いと思うんですけど・・・)

なおデモを見る限り、ファイルの更新が検出されてからパイプライン処理が再開されるまでは一瞬で、Logstashの起動時のあの待たされる感じはありませんでした。それは嬉しいところ。


次は、設定の中央管理。
f:id:acro-engineer:20160219055839j:plain:w400
Logstashのクラスタリングを始めたり、Logstashを多段構成で使うようになると、どうしても設定の管理が煩雑になります。その改善として、設定をElasticsearchに集約して、ElasticsearchからLogstashに設定を送りこむことができるようになります。


そして、ノードの管理。
Logstashの各ノードが生きているかどうかの管理をElasticsearchで行えるようになります。f:id:acro-engineer:20160219055649j:plain:w400

Elasticsearch側に、Logstashの管理APIも追加されるようです。
f:id:acro-engineer:20160219060153j:plain:w400

Logstashの管理についてはElasticsearchに集約するという方針が示されています。Beatsシリーズも同様の中央集約を検討していると聞いたことがありますので、Elasticスタック全体として、設定や管理が中央集約されていくようですね。


ということで、Logstashのキュー周りの改善による安定化と、設定・管理の中央集約という大きな方向性が示されています。
キューについてはこれまでKafkaなどに頼ることで解決してきたと思うのですが、ここをLogstashを強化することでKafka不要とするのか、あるいは、引き続きやはりキューの強力な機能はKafkaに任せるのか、注目したいと思います。