エージェント概要 - 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：稼働状況監視