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 均可,这样才能正常处理。包括在收集端已经切割好的字段,也可以直接带入手机端使用了。
*******