エージェント概要 - 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を間に噛ませる。
  • Filebeat：（ログ）ファイル
  • Metricbeat：システムや各種ミドルウェアのリソースメトリクス
  • Packetbeat：ネットワークパケット
  • Winlogbeat：Windowsイベントログ
  • Heatbeat：稼働状況監視

• Logstash：汎用的なデータ収集エージェント。Elastic社が提供。

• Fluentd：汎用的なデータ収集エージェント。Input-Output双方をプラグイン形式で拡張できる。TresureData社が提供。日本ではLogstashより人気が高い模様。

• Embulk：バルクインサート用エージェント。TresureData社が提供。

サーバ／インフラエンジニア養成読本 ログ収集〜可視化編 [現場主導のデータ分析環境を構築！] Software Design plus

• 出版社/メーカー:技術評論社
• 発売日: 2014/08/14
• メディア:Kindle版
• この商品を含むブログを見る