ELK获取json格式日志 (一)

近日在尝试搭建elk,前天搭建了一个elasticsearch集群,模拟宕机的情况,刚开始分片都相对均匀地分布到3个节点里面:

  1. 经过第一个节点停止后,主分片被自动分配到剩余的两个节点里。
  2. 经过第二个节点停止后,全部主分片只分配到剩余的1个节点里
  3. 之后重新启动几次,主分片都只在那1个节点里。

这样会不会达不到分布式搜索的作用呢?后面继续查资料理解一下...

今日尝试配置logstash, 从filebeat里面获取json格式的日志,遇到一点小问题:

1. input

输入的字段字符串放到message字段里面,codec是json格式,另外会有字段:@version, @timestamp, offset, path等等,如果想将获取的message字段值转为json格式,要在filter里面使用json插件了,我的input配置比较简单,在同一个系统里面运行filebeat和logstash,所以没有考虑证书的情况:

input {
    beats {
        host => "localhost"
        port => "5044"
    }
}

2. filter

  • json插件

This is a JSON parsing filter. It takes an existing field which contains JSON and expands it into an actual data structure within the Logstash event.

By default it will place the parsed JSON in the root (top level) of the Logstash event, but this filter can be configured to place the JSON into any arbitrary event field, using the target configuration.

由于我要将message字段的值转换成json格式,而json插件就是将某个字段转换成json格式的数据值,然后放到target字段那一层里,默认是root level

注意: 如果input部分使用了 codec => "json" , 则这个json插件的使用就捉不到message字段

  • date插件

The date filter is used for parsing dates from fields, and then using that date or timestamp as the logstash timestamp for the event.

应该是可以将时间值设置到另外的字段,而不只是 @timestamp 字段

我就是设置@timestamp字段,因为后面我在输出到elasticsearch的时候,设置index的名称要与时间相关

filter {
    json {
        source => "message"
        remove_field => ["message", "fields", "input_type", "beat", "count", "tags", "source"]
        add_field => {"catch_time" => "%{[@timestamp]}"}
    }
    date {
        match => ["time", "ISO8601"]
        target => "@timestamp"
        remove_field => ["time"]
    }
}

3. output

一般logstash的输出就是elasticsearch了吧,而我这里也是用于搜索,所以输出到es,其中网上看到一些用法如:

index => "filebeat-%{+YYYY.MM.dd}"

其中%{+YYYY.MM.dd}这个获取的时间值是字段@timestamp的时间值,好像目前暂时没有使用其他时间字段的相似的格式化用法。目前我的es数据库也是没有设置密码的:

output {
    elasticsearch {
        action => "index"
        # yourip 是你的es数据库ip
        hosts => ["yourip:9200"]
        index => "log-%{+YYYY.MM.dd}"
        document_type => "%{[type]}"
    }
}

参考:http://blog.csdn.net/u010917843/article/details/49950913