読者です 読者をやめる 読者になる 読者になる

Taste of Tech Topics

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

Elastic{ON} 2016レポート What's Brewing in Beats #elasticon

Elasticsearch elasticon Beats

1日目、最後のセッションはBeatsです。
BeatsはElasticsearchやLogstashにデータを転送するエージェントで、要するにtd-agentとか、Mackerelのエージェントのようなものです。
Go言語で書かれているので、僕もGoの勉強がてらBeatsを書いてみたこともありました。

Filebeatが想像以上にちゃんとしていた件

Beatsシリーズのうち、Topbeat/ Packetbeatは以前このブログでも紹介しました。
acro-engineer.hatenablog.com

簡単なセットアップで、サーバのCPU、メモリ、ディスクなどのリソース情報や、
パケットを流れる情報を元にSQLの内容や実行回数などを確認できるという、
なかなかインパクトあるプロダクトです。

f:id:acro-engineer:20160218195406j:plain:w480


これに加えてWinlogbeatが最近追加され、WindowsXP以降のWindowsイベントログを転送できるようになりました。

恐らくこれはセキュリティ監視などの用途で使われるものなのかなと思います。
ウィルスに感染したり外部からアタックを受けていることを、Windowsのイベントログから拾おうとするんじゃないかなと。


また、今回のセッションでかなり詳細に紹介されたのがFilebeatです。
Filebeatはログファイルのようなファイルを監視し、その内容を転送するプロダクトです。
Filebeat自体にはログを解釈するような仕組みはないため、そこはLogstashに任せることになります。
なので、Filebeat -> Logstash -> Elasticsearchという構成になるわけですね。

ここでFilebeat + Logstashの組み合わせで利用する場合、ファイルのデータを転送し損なわないよう、
バックプレッシャー的な手法を用いるそうです。

つまり転送先であるLogstashの方からFilebeatに対して「読み込めない」という通知が来ると、
Filebeatは転送対象のログファイルの読み込みをストップし(どこまで読み込んだかはFilebeat自身が保持しておき)
またLogstashから「読み込めるよ」という通知が来ると、転送を再開するそうです。

うん、これはバックプレッシャーでありリアクティブだ!(←言いたかっただけ)


またElasticsearch 5.0になれば、先に紹介したIngest Nodeという機能のおかげでLogstashなしでもログの解釈などができるようになるため、
Filebeatから直接Elasticsearchに転送することができるようになります。簡易的なログ分析であれば、そのような形式の方が楽でしょうね。

逆に、より規模が大きくなって、ログの転送し損ないが許されない状況下では、
Kafkaのようなバッファを挟んで過負荷に耐えられるようにしなくてはいけません(←しつこい)

その点も考慮して、Beats 5.0ではElasticsearch、Logstashに加えて、
Kafkaへの転送機能も付くそうです(っていう事をクラスメソッドさんのブログで知りました!)
dev.classmethod.jp

Create your own beat!

Beatsのようなプロダクトは、自分でエージェントないしプラグインのようなものを作りたくなるものです。
コミュニティベースのBeatsも既に14種類ほど作られており @ さんの作成したHsbeatもそのうちの一つとして紹介されていました。
f:id:acro-engineer:20160218195430j:plain:w480


Beatsは正式に作り方が公開されており、Generatorも提供されています。
github.com


またBeats Packerというビルドツールも提供されています。
これは自作したBeatsを各プラットフォーム用のバイナリをクロスコンパイルして作成したうえ、
RPMDEBも作ってくれるスグレモノです。
github.com
Beats PackerはTravis CIからも実行できるようにしているなど、至れり尽くせりなようです。
なるほどですね。


ただBeatsは今後コミュニティベースでどんどん数が増える一方で、よくある放置状態になるのではないか、という懸念も湧いてきますよね。
そこに対する解の一つが、Metricbeatだと思います。

きちんと管理されるMetrisbeat

Metricbeatは様々なミドルウェアの情報を収集するモジュールでありライブラリです。
最初にApache / Redis / MySQL / Golangに対応させようとしているようです。

f:id:acro-engineer:20160218195659j:plain:w480

こちらはElastic社が管理するプロダクトになり、Metricbeatに対する拡張を作りたい場合は、Elasticのgithubにプルリクする形になります。


そんなMetricbeatですが、そもそもミドルウェアの情報はどうやって取ってくるの? というのが当然の疑問になります。
セッション後にスピーカーに聞いてみたところ、それぞれのミドルウェアに定期的にメトリクス情報を取りに行く形を採用しているとのこと。
ソースも合わせて確認してみたら、Apacheならserver-status?autoを叩くとか、Goならexpvarのmetricsを使うとか、そういう形になっていました。なるほどですね。


なんか全体を通じて、なるほど感のあるセッションでした。変に奇をてらわずに、実直にデータを集める、抜けを防ぐ、そして管理する。
Beatsは今後も安定したエージェントとして活躍してくれそうな予感がします。


それでは本日のセッションレポートは以上になります。
また明日のレポートも楽しみにしてください。

Stay elastic, see you!