elk示例-精简版2

作者：Danbo 时间：2016-03-13

1.保存进Elasticsearch

Logstash可以试用不同的协议实现完成将数据写入Elasticsearch的工作，本节中介绍HTTP方式。

配置示例：

output {
elasticsearch {
hosts => ["192.168.0.2:9200"]
index => "logstash-%{type}-%{+YYYY.MM.dd}"
document_type => "%{type}"
workers => 1
flush_size => 20000
idle_flush_time => 10
template_overwrite => true
}
}

解释：

批量发送

flush_size 和 idle_flush_time 共同控制Logstash向 Elasticsearch发送批量数据的行为。上面的示例说明：Logstash会将数据攒到20k条数据然后一次性发送出去，并且设置最大老化时间为10s。

默认情况下：flush_size 是500条，idle_flush_time是1s，注意，这点也是很多人单改大flush_size 也没能提高ES性能的原因。

索引名

写入的ES索引的名称，这里可以使用变量。为了更贴合日志场景，Logstash 提供了%{+YYYY.MM.dd} 这种写法。在语法解析的时候，看到以+号开头的，就会自动认为后面是时间格式，尝试用时间格式来解析后续字符串。

索引名中不能有大写字母，否则ES在日志中会报错InvalidIndexNameException，但是Logstash不会报错。

模板

Elasticsearch支持给索引预定义设置和mapping。logstash自带有一个优化好的模板。内容如下：



其中的关键设置包括

template for index-pattern

只匹配logstash-* 的索引才会应用这个模板。有时候我们会变更Logstash的默认索引名称，记住也得通过PUT方式上传可以匹配你自定义索引名的模板。当然，更建议的做法是，把自定义的名称放在"logstash-"后面，变成index => "logstash-custom-%{+yyyy.MM.dd}"

refresh_interval for indexing

Elasticsearch 是一个近实时搜索引擎。它实际上是每1s 刷新一次数据。对于日志分析应用我们用不着那么实时，所以logstash自带的模板修改成了5s，其实还可以继续提高这个刷新间隔以提高数写入性能。

multi-field with not_analyzed

Elasticsearch 会自动使用自己的默认分词器（空格，点，斜线等分隔）来分析字段。分词器对于搜索和评分是非常重要的，但是大大降低了索引写入和聚合请求的性能。所以logstash模板定义了一种叫“多字段”（multi-field）类型的字段，并给这个字段设置为不启用分词器。也就是当你想获取url字段的聚合结果的时候，不要直接用“url”，而是用“url.raw”作为字段名。

geo_point

Elasticsearch 支持geo_point 类型，geo distance 聚合等等，比如说，你可以请求某个geo_point 点方圆10km内的数据点的总数。

doc_values

doc_values 是Elasticsearch 1.0版本引入的新特性。启用该特性的字段，索引写入的时候回在磁盘上构建fielddata。doc_values 只能给不分词（对于字符串字段就是设置了 “index ”）

2.标准输入（Stdout）

output {
stdout {
codec => rubydebug
workers => 2
}
}

输出插件同一具有一个参数是workers。logstash 为输出做了多线程的准备。

其次是codec 设置。P39。可能除了 codecs/multiline，其他codec 插件本身并没有太多的设置项。所以，上面的示例配置我们可以写成：

output {
stdout {
codec => rubydebug {
}
workers => 2
}
}

单就 outputs/stdout 插件来说，其最重要和常见的用途就是调试。

3.发送网络数据（TCP）

配置示例如下：

output {
tcp {
host => "192.168.0.2"
port => 8888
codec => json_lines
}
}

在收集端采用TCP方式发送给远端的TCP端口。这里需要注意的是，默认的codec 选项是json。而远端的Logstash::Inputs::TCP 的默认codec 选项却是 line！ 所以不指定各自的codec，对接肯定是失败的。

另外，由于IO BUFFER 的原因，即使是两端共同约定为json 依然无法正常运行，接收端会认为一行数据没有结束，一直等待直到自己OutOfMemory！

正确的做法是：发送端指定codec 为json_lines，这样每条数据后面会加上一个回车，接收端指定codec 为json_lines或者json 均可，这样才能正常处理。包括在收集端已经切割好的字段，也可以直接带入手机端使用了。

*******