ログ収集分析基盤 Rsyslog + Elasticsearch + Kibana その３ (設定小ネタ)
はじめに
かくかくしかじかでログ収集基盤を作っている．
今回は細かい設定について適当にメモしておく．
Rsyslog の設定
インデックスを分ける
インデックスは，データをまとめておく入れ物のようなもの． 用途や期間でインデックスを小分けにするといい．
omelasticsearch: Elasticsearch Output Module - searchIndex
データが無限に生成されようが，ストレージは有限． いずれデータを捨てるときのために，小分けでかつ簡単に管理出来る単位に分けておく． またインデックスのライフサイクルポリシーという仕組みで勝手に削除するようにもできる．
ドキュメントのタイプを指定する
インデックスは複数のタイプを内包出来る．
Elasticsearch index,typeについて - Qiita
マッピングのテンプレートを作成するとデフォルトで _doc タイプになる．
{
"_doc": { # これ
"properties": {
"field_name": {
"type": "keyword",
"ignore_above": 256
},
...
けれど Rsyslog ではデフォルトで events となる．
omelasticsearch: Elasticsearch Output Module - searchType
タイプの異なるテンプレートにはデータを格納出来ないようなので，Rsyslog と Elasticsearch のどちらかに設定を合わせる必要がある．
ログの時刻は UTC を指定する
Elasticsearch に投げ込むデータのタイムスタンプは UTC で統一したほうがいい．
タイムゾーンは扱えるようなので rfc3339 とかでデータを投げるといい．
property(name="timereported" dateFormat="rfc3339")
この辺りのサンプルを参考にするといい．
omelasticsearch: Elasticsearch Output Module - How Retries Are Handled
ちなみに rfc3339 は
2020-04-01T12:34:56+09:00
rfc3164 は
Apr 1 12:34:56
こんなフォーマット．
Elasticsearch の設定
マッピングテンプレートを作る
Elasticsearch は適当にデータを投げつけるだけでデータが入る． これは Elasticsearch が勝手に型をあてがってくれているだけで，型の概念は存在する． 事前に型を定義しておくことで，Kibana で適切に分析するのに役立つ． またマッピングテンプレート自体は変更可能だが，インデクスに適用されているマッピングは後から変更出来ない仕様らしいので注意が必要．
Put index template API | Elasticsearch Reference [7.6] | Elastic
Field datatypes | Elasticsearch Reference [7.6] | Elastic
例えば Geo-point という型を定義しておけば，Kibana の Maps 機能で座標を表示出来る．
Geo-point datatype | Elasticsearch Reference [7.6] | Elastic
レプリカを設定する
Kibana の Management からインデクスを見ると Health が yellow になっている場合がある． Replicas はデフォルトで 1 になっており，レプリカを用意していないけど yellow が気になる場合はレプリカの設定を 0 に変更するといい．
{
"number_of_shards": "1",
"number_of_replicas": "0"
}
}
Kibana の設定
Kiabana は．．．まぁ．．．思いついたら書く．．．と思う
おわりに
今回はちょっとした設定について書いた．
あれ．今更だけどこれは Big な Data なのか？まぁいいか．
次回は Kibana でできることか，Elasticsearch の REST API について書こうかと思う．たぶん
