2016-02-19

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

世界の皆さん、おはようございます @cero_t です。
今日も一日、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はまだサポートされておらず、これは今後の対応になります。

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に任せるのか、注目したいと思います。

レポート一覧

AcroquestではElasticsearch、Logstash、Kibanaの無償ハンズオンセミナーを開催致します。

当社公認エンジニアがELKの基礎から、商用プラグインの利用、
実データを用いた可視化・分析までを、ハンズオン形式で説明致します。
可視化・分析の題材には、当社がミャンマーにて収集したビッグデータを用います。

詳細・参加応募はこちらからお願いします。
www.acroquest.co.jp

2016-02-19

Elastic{ON} 2016レポート My own google? FaceChimpを見せてもらいました。 #elasticon

Elasticsearch elasticon Kibana FaceChimp

お昼前に、Elasticの方から興味深いデモを見せてもらいました。
FaceChimpという検索エンジン系のKibanaアプリです。
f:id:acro-engineer:20160219084134p:plain:w480

KibanaのFaceChimpアプリで、検索対象のindex（複数指定可能）や、検索対象のフィールド、
検索結果に表示するフィールドなどを選択すると、GoogleライクなUIを生成できるというものです。
f:id:acro-engineer:20160219084214p:plain:w480

通常のキーワード検索に加えて、画像検索や地図検索での結果も表示できます。
また、キーワードのサジェストもあれば、Did you mean? 機能もあります。
f:id:acro-engineer:20160219084200p:plain:w480

簡単ですが、アクセス統計などが見られるダッシュボードも用意されています。
f:id:acro-engineer:20160219084244p:plain:w480

Elasticsearchって検索のバックエンドのエンジンとして利用できるのですが、検索用のUIは（Sense以外には）用意されていませんでした。
そこにFaceChimpを使うことで、検索用のUIも提供できるようになったということですね。
~~これで完全にSolrの息の根が止まりますよね~~

FaceChimpはまだ公開されていませんが、いずれTimelionなどと同じくオープンソースで提供される模様です。なかなか助かりそうに思うので、こちらもいち早く使ってみたいですね。

レポート一覧

1日目

2日目

3日目

Elastic{ON} 2016レポート AMA = Ask Me Anything! #elasticon - Taste of Tech Topics
Elastic{ON} 2016レポートいよいよクロージング！ #elasticon - Taste of Tech Topics

AcroquestではElasticsearch、Logstash、Kibanaの無償ハンズオンセミナーを開催致します。

当社公認エンジニアがELKの基礎から、商用プラグインの利用、
実データを用いた可視化・分析までを、ハンズオン形式で説明致します。
可視化・分析の題材には、当社がミャンマーにて収集したビッグデータを用います。

詳細・参加応募はこちらからお願いします。
www.acroquest.co.jp

2016-02-19

Elastic{ON} 2016レポート Ingest Node: Enriching Documents within Elasticsearch #elasticon

Elasticsearch elasticon

Elasticsearch 5.0の目玉機能の一つである、Ingest Nodeのセッションに参加しました。
Ingest Nodeとは、Logstashが持つ加工機能をElasticsearchに移植したものです。
f:id:acro-engineer:20160219104038j:plain:w480

セッションは少し小さめの部屋で行われたのですが、立ち見まで出る満席っぷり。
かなり注目の機能ですし、実際、インパクトのあるデモも見られました。今日イチのセッションですね。

ユースケースは2種類

Ingest Nodeのユースケースとして2種類紹介されました。

FilebeatからLogstash経由せずに、直接Elasticsearchにデータを送り込む
Reindex APIと組み合わせて使う

f:id:acro-engineer:20160219104225j:plain:w400

前者は、これまでFilebeat（転送） → Logstash（加工） → Elasticsearch（保存）としていたところを、
Filebeat（転送） → Elasticsearch（加工＆保存）とできるようなる、というパターンです。
また後者は、Elasticsearchに投入済みのデータを取り出しながら加工し、別のindexに投入するというパターンです。

いずれもありそうなシチュエーションですね。

なおElasticsearch 5.0では、デフォルトでIngest Nodeが有効になるように設定されているとのことです。

パイプラインの作り方

Ingest Nodeで行われる個別の処理はプロセッサと呼ばれ、それらを組み合わせたものをパイプラインと呼びます。
パイプラインの作成、更新、取得、削除はREST API経由で行います。

PUT _ingest/pipeline/pipeline-name
GET _ingest/pipeline/pipeline-name
GET _ingest/pipeline/*
DELETE _ingest/pipeline/pipeline-name

PUTするJSONはこんな感じ。

{
  "description": "mysql pipeline",
  "processors": [
    {
	  "grok": {
	    "field": "message",
		"pattern": "..."
	  }
	},
	{
	  "remove": {
	    "field": "message"
	  }
	}
  ]
}

Logstashの設定は独自の文法で行うものでしたが、Ingest Nodeのパイプラインは普通にJSONで記述するようですね。

このパイプライン用に利用できるプロセッサは、mutate、grok、geoipなど、LogstashにあるFilterはだいたいあります。
f:id:acro-engineer:20160219104702j:plain:w400

というかむしろIngest NodeのプロセッサはLogstashのFilterと相互に互換性があるそうです。こういうものって得てして別物になりがちなので、これは嬉しいところですね。

エラーが発生した時の処理は、プロセッサの on_failure で記述できます。
次のJSONは、bytesという名前のフィールドを数値（integer）に変換し損ねた場合には、値を0にするという例です。

{
  "convert": {
    "field": "bytes",
	"type": "integer",
	"on_failure": [
	  {
	    "set": {
		  "field": "bytes",
		  "value": 0
		}
	  }
	]
  }
}

なるほど、違和感ないですね。

またテストのためにSimulate APIが用意されており、実際にindexを行わずに、ドキュメントを試しに投入するテストを行えます。
最初からこういうものが用意されているのは、ありがたいところ。

Simulate APIは、こんな形をしています。

POST _ingest/pipeline/pipeline-name/_simulate
POST _ingest/pipeline/_simulate
POST _ingest/pipeline/_simulate?verbose

verboseオプションをつけることで、最終的な結果だけでなく、パイプラインの途中の処理結果を確認することができるようになります。

パフォーマンスは？

パフォーマンスは、平たく言えば、いつものマジックワード「depends on」です。プロセッサの内容、プロセッサの数、追加/削除するフィールドの数、などなど。
ベンチマーク結果も示されていましたが、あまりピンと来ませんでした。
f:id:acro-engineer:20160219105747j:plain:w400

ただどうあれ、このような加工処理がindexに影響を与えることは間違いありません。それでパフォーマンス問題が起きるようなことを想定して、
通常のノードとは別に、Ingest専用のノード（dedicated ingest nodes）を作るというパターンも紹介されていました。
f:id:acro-engineer:20160219105927j:plain:w400
masterノードからingest nodeに行って来いする形ですね。

デモがやばい。

パイプラインを実際に作成するデモも行われました。って、このデモが想像以上でした。

Elasticsearch 5.0 + Kibana 4.4の組み合わせでしょうか、Kibana上のindicesのsettingsに「Tail a File」というオプションが追加されており、
ここからパイプラインを作成したり、ファイルを流し込んだりできるようでした。

デモでは、実際にTail a Fileが行われました。まずはテキストエリアに、読み込み対象となるファイルのサンプルを適当に貼り付けます。
f:id:acro-engineer:20160219110314j:plain:w480

そうすると、パイプラインの処理結果としてどういうJSONが得られるかというサンプルが表示されます。
この例ではまだ何のプロセッサも設定していないため message というフィールドに、貼り付けたログの1行が表示されるだけになっています。
f:id:acro-engineer:20160219110153j:plain:w480

その後、プロセッサを追加してパターンなどを設定すると、どんどんOutputの形が変わっていきます。
この写真の例では（すごく見えにくいですが）最終結果のOutputが、source、message、contentの3フィールドが出力されることや、プロセッサの結果として、sourceとcontentが取得できることが分かります。
f:id:acro-engineer:20160219110127j:plain:w480

実際にファイルのサンプルを使いながら、トライ＆エラーで設定を変更できるのは、本当にありがたい機能です。Logstashにはこの機能がないために、
ちょっと修正してはLogstashプロセスを再起動して、試しにデータを流し込んでみて、また修正してはプロセスを再起動して・・・という作業を繰り返さざるを得ませんでした。
（Logstash 5.0では設定が自動でリロードされるようになり、少しは楽になりますけども）

このパイプラインの作成の手軽さを考えると、もうLogstashなんて使っていられないな・・・と思うほどです。

まとめと、今後？

という感じで、Ingest Nodeをとても使いたくなるセッションでした。むしろこれから先、Logstashがどういう位置づけになるのか、微妙だと思います。
まず、小さな規模であれば、Logstashを完全に省いて、Filebeat（や他のBeats）とElasticsearchだけで運用することができるようになるのは間違いないでしょう。

問題は、規模が大きくなってきた時。今の標準的な構成としてはKafkaを挟んだ形になります。

Filebeat → Logstash（加工） → Kafka（キュー） → Logstash（転送） → Elasticsearch（保存）
※それとは別に、Kafka or Logstash からファイルサーバに転送

これが、FilebeatがKafka出力に対応し、ElasticsearchがIngest Nodeを持つことになると、こうなります？

Filebeat → Kafka（キュー） → Logstash（転送） → Elasticsearch（加工＆保存）
※それとは別に、Kafka or Logstash からファイルサーバに転送

Logstashは転送の役割だけで、むしろKafkaからElasticsearchが直接繋がれば、Logstashは完全に要らなくなるのに・・・と思ってしまいます。
この辺りがどうなるのか、今後の動向も含めて数ヶ月ぐらいはウォッチしたいと思います。

いやー、Ingest Node、便利ですよ！

レポート一覧

1日目

2日目

3日目

Elastic{ON} 2016レポート AMA = Ask Me Anything! #elasticon - Taste of Tech Topics
Elastic{ON} 2016レポートいよいよクロージング！ #elasticon - Taste of Tech Topics

AcroquestではElasticsearch、Logstash、Kibanaの無償ハンズオンセミナーを開催致します。

当社公認エンジニアがELKの基礎から、商用プラグインの利用、
実データを用いた可視化・分析までを、ハンズオン形式で説明致します。
可視化・分析の題材には、当社がミャンマーにて収集したビッグデータを用います。

詳細・参加応募はこちらからお願いします。
www.acroquest.co.jp