エージェント概要 - Kibanaを立ててみた
データ収集の先鋒をどうするか
概要のところで説明したとおり、エージェント経由でElasticsearchに情報を収集するのですが、選択肢が結構多いですね。
よくある事例、記事だと、日本ではFluentdが圧倒的に多くて、次にLogstash。
FluentdもLogstashも、ファイルへの出力をリアルタイム監視して、設定ファイルにもとづいて変換して、Output先に送り届ける、ってのは同ですね。
CloudwatchLogsに慣れている身としては、awslogsと同じだなーとか思いつつ。
どちらもプラグインがたくさんあって、Input元、Output先との接続のコネクターがたくさんあるようなので、どっちを使っても出来ることに違いはなさそう。
シェアだとFluentdのほうがありそうなんですけど、elastic社「ELK Stack」って呼んでアピールしてます。「E=Elasticsarch、L=Logstash、K=Kibana」です。
これに倣って、日本で人気の高いFluentdを使った構成を「EFK」って呼ぶ人もいる模様。
なお、LogstashとElastic社が提供するスタック図において、Logstashと同じレイヤーに、Beatsというものがあります。
一概に説明しにくいのですが、「Logstashと同様にElasticsearchにデータ転送するだけでなく、Logstashに転送して、Logstashで加工・フィルタリングしてからElasticsearchに転送することも可。」というツールでした。
- Logstash:フィルタ、加工など柔軟な設定が可能なエージェント。
- Beats:あらかじめ用意されたセットにもとづいて情報収集、転送するエージェント。複雑な処理が必要な場合、Logstash経由で転送させる。Kibana上で表示させるためのテンプレートも含んでいる。
といった感じでしょうか。
同じレイヤといいつつ、中間レイヤとしても機能するので、Elastic社の図を鵜呑みにするとちょっとつまづきますね。
次回以降、Beats、LogstashといったElastic公式のスタック準拠で挑戦した後、人気の高い人気のFluentd、Fluentdと同じTresure Dataが提供するEmbulkも扱ってみたいと思います。
まとめ
Elasticsearch+Kibanaを使う際の、クライアントサイドモジュール
- Beats:Elastic社が提供。「データシッパー(Data Shipper)」と呼ばれ、Elasticsearchに対するシンプルなデータ転送を行うエージェント。フィルタリングや加工など複雑な処理を施す場合、Logstashを間に噛ませる。
- Logstash:汎用的なデータ収集エージェント。Elastic社が提供。
- Fluentd:汎用的なデータ収集エージェント。Input-Output双方をプラグイン形式で拡張できる。TresureData社が提供。日本ではLogstashより人気が高い模様。
- Embulk:バルクインサート用エージェント。TresureData社が提供。
サーバ/インフラエンジニア養成読本 ログ収集〜可視化編 [現場主導のデータ分析環境を構築!] Software Design plus
- 出版社/メーカー: 技術評論社
- 発売日: 2014/08/14
- メディア: Kindle版
- この商品を含むブログを見る