Boring Days as tech

金に生きるは下品にすぎる、 恋に生きるは切なすぎ、 出世に生きるはくたびれる。 とかくこの世は一天地六。 命ぎりぎり勝負をかける。 仕事はよろず引き受けましょう。 大小遠近男女は問わず、委細面談、仕事屋稼業。

素のfluent-plugin-elasticsearch使ってkibanaで描画するだけではちょっと使うの難しい

"実践"としてかっちょいい監視ツールを利用したい

かっちょいい監視ツールにあこがれて fluentd - elasticsearch - kibana を使ってみたので実際に使えるようになるまでのポイントを幾つか。

そんなtype想定してない

fluent-plugin-elasticsearchだと読み込んだログを基本的に全部文字列として構造化してしまうので、各所最適化されたmappingができない。type:integerで入って欲しいが、文字列なのでtype:stringでmappingされたりする。そこでplugin自体をカスタマイズして数値型としてmappingすると、今度はtype:longでmappingされてしまう。type:ipとかを利用したくても同様の結果になる。

勝手にexpireして欲しい

ログ監視なので一定期間過ぎたindexは自動で消えてくれるといいんだけど、なかなかそういう設定ができない。なのでelasticsearchのTTL機能などを使おうとする。しかしfluent-plugin-elasticsearchはmappingが自動的にされるので各documentやindexに対してTTLを設定することができない。また、設定してもdocumentにTTLに設定してもindexのmappingを_ttl:{enabled:true}にしなければTTLは動かない。

http://www.elasticsearch.org/guide/en/elasticsearch/reference/current/mapping-ttl-field.html

加えて、このelasticsearchのTTL機能についてはパフォーマンスが落ちるので好ましくないとのことが公式で以下に載っている。なのでcronで定期的にindexを削除するといいよ、という話。結局cron頼みになるのかな?

http://www.elasticsearch.org/tutorials/using-elasticsearch-for-logs/

検索パフォーマンス

analyzerちゃんと設定しないといけませんよね?
documentを構成するデータに合わせたanalyzerを設定できてる?

elasticsaerch自体のパフォーマンス

デフォルト設定ではそもそも性能に限界がある。
その辺りのパフォーマンスチューニングはデータストアとして切っても切れないので、
利用用途と現状に合わせたチューニングが必要。

template機能

fluentdでデータを投げる前にちゃんとデータ構造を定義して明示的に最適化されたmappingでelasticsaerchにdocumentを保持するべき。analyzerも設定しなければならない。そのためにtemplate機能。これを設定すると指定の条件のindexに対して設定したtemplateをベースにdocumentを生成保存してくれる。結局全く何も考慮せずにデータを突っ込むといのは危険ということ。

http://www.elasticsearch.org/guide/en/elasticsearch/reference/current/indices-templates.html

まとめ

素のプラグインでlogを収集して素で突っ込むだけでは結局使えない。
要は実践で使うにはやはり色々考慮しないといけない。まる。
特にmappingはきっちりやること。そのためのtemplate。
analysisとかtokenizerととelasticsaerch自体のパフォーマンスチューニングはまた今度。