ELK 5.X版本遇到的坑
一、Kafka ->logstash ->elasticsearch
logstash 5.X以上版本不兼容5.x以下版本，因此在升级logstash时会遇到很多坑。首先是配置的变化，可以参考如下配置：
input {
kafka {
bootstrap_servers => "XX:9092,YY:9093,ZZ:9094" 变化点：这里监听的是kafka的端口号
topics => "xxxlog"
group_id => "elasticconsumer"
max_partition_fetch_bytes=> "4194304" 处理消息过大的场景
codec => "json"
}
}
output {
elasticsearch {
hosts => ["XXX:9200"]
index => "logstash-%{+YYYY-MM-dd}"
codec => "json"
}
}
output {
file {
path => "/data01/logstash.log"
flush_interval => 0
}
}
完成配置后可以通过如下命令来检测配置文件是否有语法错误：
bin/logstash -t -f config/kafka-logstash-es.conf
另外，elasticsearch 5.X版本的集群安装请参见：http://www.jianshu.com/p/9e3749daeb93
二、elasticsearch数据丢失
通过kibana监控返回的数据时，无意中发现返回的数据存在数据丢失的现象。将input数据保存进elasticsearch的同时，通过写入log日志文件中。通过如下命令查询elasticsearch中保存的数据时，发现数据在保存进elasticsearch的时候就已出现丢失现象：
get _index/_type/_count?q=monitorId:XXX get logstash-2017-03-21/logs/_count?q=monitorId:XXX
编写测试配置，将出错的json直接通过屏幕输入：
input {
stdin {
codec => json
}
}
output {
stdout {
codec => rubydebug
}
}
又发现数据可以正常输出。那么问题出在哪一个环节呢？
通过查看elasticsearch中的日志，发现在解析json时系统偶尔会报String_Object 转化异常。是什么原因导致此问题的发生呢？
通过一步步追踪最终发现问题出在dynamic mapping环节。
ES如何对对动态类型字段做mapping的呢？ES在内部对一个index下的type会根据mapping来进行存储，所以要求type中的每个字段类型必须一致。例如对一个User表，如果有个name字段，那么一条user数据中的name为string类型的话，后续所有的user对象中的name都必须为string，否则做index时就会出错。
但是由于一些原因平台的数据在返回时，同一个type下的值，有的为String类型，有的却为Object对象，按照上面的逻辑在进行解析时异常是必然的了。
参见：http://jiangpeng.info/blogs/2014/11/24/elasticsearch-mapping.html
http://www.cnblogs.com/ningskyer/articles/5787702.html
http://blog.arganzheng.me/posts/datatype-in-elasticsearch.html
解决措施：统一平台返回的数据格式，将同一type下字段的值统一转化为String类型。
三、json长度过长elasticsearch存储异常
在解决问题二后发现kibana中依然有数据丢失的情况。分析elasticsearch的日志，发现平台返回的json长度过长导致elasticsearch在进行数据存储时异常。
那么针对此问题需要如何进行处理呢？下面给出实际的处理方案仅供参考：
A.logstash配置
input {
kafka {
bootstrap_servers =>"XXX:9092,YYY:9093,ZZZ:9094"
topics => "klog"
group_id => "elasticconsummer"
codec => "json"
}
output {
elasticsearch {
hosts => ["XXX:9200","YYY:9200"]
index => "logstash-%{+YYYY-MM-dd}"
codec => "json"
manage_template => true
template_overwrite => true
template_name => "kTemplate"
template => "/data01/xxx.json"
}
}
output {
file {
path =>"data01/logstash.log"
flush_interval =>0
}
}
}
B.模板的配置
{
"template" : "logstash*",
"settings" : {
"index.number_of_shards" : 5,
"number_of_replicas" : 1,
"index.refresh_interval" : "60s"
},
"mappings" : {
"_default_" : {
"_all" : {
"enabled" : true
},
"dynamic_templates" : [
{
"string_fields" : {
"match" : "*",
"match_mapping_type" : "string",
"mapping" : {
"type" : "string",
"index" : "not_analyzed",
"omit_norms" : true,
"doc_values": true,
"fields" : {
"raw" : {
"type": "string",
"index" : "not_analyzed",
"ignore_above" : 256,
"doc_values": true
}
}
}
}
} ],
"properties" : {
//定义长度
"callMethodResult": {
"type": "string",
"index": "not_analyzed"
"ignore_above" : 256
}
}
}
}
}
}
参见：http://m.blog.csdn.net/article/details?id=50823494
模板的配置参见:https://github.com/chenryn/ELKstack-guide-cn/blob/master/logstash/plugins/output/elasticsearch.md
其它坑请参见：http://www.jianshu.com/p/fa31f38d241e
四、离线环境下Kibana加载慢问题
在离线环境下发现kibana加载比较慢，跟踪定位后发现系统在离线环境上也会加载http://tiles.elastic.co/v2/manifest?my_app_version=5.2.0
将/kibana/src/server/config/schema.js中的manifestServiceUrl中的上述地址修改为http://localhost/即可
五、Kibana中文乱码
在实际使用过程中发现应用布署到生产环境后，在Kibana中的中文日志有乱码。将logstash采集的数据一份写入elasticsearch,另一份写入log，发现日志在写入log时已经是乱码。如果想要中文没有乱码，那么日志文件应该是UTF-8格式。我们可以用file命令查看日志的生成格式，如下：
[xxx@localhost logs]$ file app.log app.log: UTF-8 Unicode English text, with very long lines
log4j的配置参考如下:
<appender name="FILE" class="org.apache.log4j.DailyRollingFileAppender"> <param name="File" value="./logs/app.log"/> <param name="Encoding" value="UTF-8"/> <param name="DatePattern" value="'.'yyyy-MM-dd"/>
但最终定位生产环境出现此问题的原因是没有指定tomcat的编码格式.
六、logstash TCP指定端口监听
通过./logstash-plugin list 查看logstash安装的插件
input {
tcp {
host => "XXX"
port => "5000"
mode => "server"
type => "microwiki"
add_field => {
"name" => "Routh"
}
}
}
output {
file {
path => "/data01/XXX"
flush_interval => 0
}
}
