ログを１箇所にまとめたいというニーズは、根強くあります。
クラウドだと数分でサーバが立ち上がって来るから、負荷に応じてサーバの数を変えよう！そうすればコスパもよくなる！
なんて話はよくあるし、実際、無駄がなくなるのでコストパフォーマンスもよくなります。
が。
それだけだと、ログの問題が残ってしまいます。
トラブルの原因調査のため、ログを調査することはよくあることです。しかし、負荷が下がってサーバを止めたら、ログはどうなります？
サーバ停止時にどこかに退避するという処理が、最低でも必要ですね。
また、ログは各サーバ毎に作られます。ということは、調査の際、1つずつサーバのログを見て回ることが必要になります。手間がかかりますね。どこかにまとまっていれば楽なのに…。
調査の他にも、ログをほぼリアルタイムで調べたいというニーズがあります。
こういったことを実現するため、Fluentdやlogstash、FileBeatといったツールが活躍しています。特に、日本ではFluentdが定番ですね。
こういったツールを使えば、ログを１箇所にまとめられるので、ログの調査がしやすくなります。
Fluentdは複雑、Fluent Bitはシンプル
Fluentdは、rubyで書かれたlog転送ツールです。ログを転送するだけでなく、ログを加工したり他のサーバからログを受け取ったりと、なんでもできます。
できることが多いと、それだけ設定も複雑になります。一度設定してしまえば変更することはほとんどないので、なかなか慣れないです。
一方、Fluent Bitは組み込み機器をターゲットに入れていることもあって、シンプルです。が、コンテナやオートスケールなど、起動時間が問題になってくる環境では、このシンプルさが利いてきます。
Fluent Bitはオープンソースでマルチプラットフォームなログパーサー・フォワーダーです。
https://fluentbit.io/
ログをパースして必要な情報を送るというのが、ほとんどのサーバで必要となるlog転送の機能でしょう。Fluent Bitは必要な機能をちゃんと押さえています。
Kubernetes対応
Kubernetesに対応しています。Kubernetesに関するドキュメントを見る限り、Dockerコンテナも用意されており、Elasticsearchにログを転送できるようにもなっています。
パッケージのダウンロード
各ディストリビューション向けのパッケージがtd-agent-bitという名で用意されています。
ソースからビルドする
対応するパッケージがない場合、ソースからビルドすることになります。
ダウンロードページからソース一式をダウンロードできます。含まれているREADME.mdにビルド方法が書いてありますが、GitHubでも見れます。
Debianでビルドする場合、
gcc-4.8 g++-4.8 cmakeを事前にインストールしておきます。
README.mdのビルド方法に従ってビルドしますが、
$ cd build
$ CXX=g++-4.8 cmake ..
$ makeのように、cmakeを実行する際、CXXを指定する必要があるかもしれません。
動作確認は
$ bin/fluent-bit -i cpu -o stdoutとして、cpuの利用率が1秒ごとに画面に表示されればOKです。
設定ファイル
動作確認のときのようにオプションを指定することもできますが、設定ファイルを使ったほうが楽です。
設定ファイルのサンプルはGitHubの fluent-bit/confにありますが、ちょっとわかりにくいかもしれません。
fluent-bit.confが基本型でしょう。cpuの利用率を取得して、画面に出力しています。
in_xxx.confは各種入力元のサンプルです。
out_xxx.confは出力先のサンプルです。
一番使いそうな、ログファイルを入力元とするサンプルが見当たりませんが、kube.confの[INPUT]の部分が参考になります。[SERVICE]でParsers_Fileの指定があり、parsers.confにログパースのルールを記述する必要があるので、注意です。
Elasticsearchへの出力は、kube_elasticsearch.confの[OUTPUT]が参考になります。
AWSのElasticsearch Serviceに出力する場合、
[OUTPUT]
Name es
Match *
Host YOUR_HOSTNAME_OF_ES.amazonaws.com
Port 443
Logstash_Format On
tls Onと記述します。
[FILTER] も便利です。詳しいことは、ドキュメントを見てみてください。
ログが集まると見えてくる
ログをElasticsearchに集めると、「あるトランザクションがいつどのサーバで処理したか」といったことを簡単に検索できるようになります。
また、GrafanaのデータソースとしてElasticsearchを使うことができるので、あるログパターンに一致する件数が時間とともにどう変化していったかを、簡単にグラフ化することができます。実際、これでグラフの形が違うサーバ群が明らかになり、ボトルネックだったことが判明しました。
ログ転送は多くのサーバにセットする必要があります。少しでも処理の軽いソフトウェアを使うことで、全体の負荷を小さくすることができます。Fluent Bitは、こういったニーズを満たしているログ転送ツールです。
コメント