数据流转路径如下：
filebeat --> logstash --> elasticsearch
在logstash中会进行如下处理：
输出到es的时候 index的命名是根据上面filter的index_date进行命名的，现在出现的问题就是：
一条在七点的数据，会出现在index为11点的索引中，在kibana查看监控，filebeat的每秒的输出事件和logstash这边接收的事件数目可以匹配上，现在不能确定问题是出在了 filebeat logstash es里面的哪里环节
filebeat高峰监控数据：
logstsh高峰监控数据
es高峰监控数据
各路大神给给排查意见，感谢
filebeat --> logstash --> elasticsearch
在logstash中会进行如下处理：
filter {
dissect {
mapping => {
"message" => "略。。。。"
}
}
geoip {
source => "ip"
}
ruby {
code => "event.set('index_date', event.get('@timestamp').time.localtime + 8*60*60)"
}
ruby { //新加测试字段
code => "event.set('index_date1', event.get('@timestamp').time.localtime + 8*60*60)"
}
mutate {
convert => ["index_date", "string"]
gsub => ["index_date", ":([\S\s]*?)Z", ""]
gsub => ["index_date", "T", "."]
}
date {
match => ["time", "dd/MMM/yyyy:HH:mm:ss Z"]
}
}
输出到es的时候 index的命名是根据上面filter的index_date进行命名的，现在出现的问题就是：
一条在七点的数据，会出现在index为11点的索引中，在kibana查看监控，filebeat的每秒的输出事件和logstash这边接收的事件数目可以匹配上，现在不能确定问题是出在了 filebeat logstash es里面的哪里环节
filebeat高峰监控数据：
logstsh高峰监控数据
es高峰监控数据
各路大神给给排查意见，感谢
1 个回复
ziyou - 一个学习ELK的Java程序员
赞同来自:
1、@timestamp 是毫秒为单位的，你直接加8*60*60，需要看一下是否正确。
2、日期数据，如果你不写明他的时区，默认都是零时区的，你下面的代码就没有注明时区
3、kibana会根据浏览器的时区和数据的时区来确定是否要加时间，一般都是ES存储零时区时间，kibana显示修正时间（时间都是加8个小时）。
综上几个问题
你要看你这边是不是在logstash里面修正时间以后又存为了零时区时间，然后kibana又加了8小时，并且你的修正时间是否正确也是需要验证的。