我们公司处理用户报来的问题时，一般都是值班人员先根据用户提供的相关信息在elk中搜索相关服务日志 (包括nginx 日志，各个app服务日志)，然后分析问题原因。不过最近kibana总是查不到数据，返回结果为空，并且没有任何新数据显示。我们运维人员只好手动查询了几个问题。
闲下来之后就开始排查问题了。
排查问题步骤
1. 查看ES集群状态
通过kopf界面看到ES集群状态是健康的
2. 查看数据是不是在ES集群中
在kopf中监控doc的总数，数值确实是实时增加的，通过api也查看了最新数据，数据格式和数值都是对的
3. 重启大法
上面2个步骤没有任何发现后，只好先重启kibana, ES了， 结果还是一样，kibana返回为空。
4. 从kibana发出请求分析
在kibana上查询了各个时间段的数据，发现nginx的日志8点之前的数据是存在的，之后就是一片空白，从es日志中发现8点的时候新创建了index,logstash-2016.06.03, 从kibana发出的请求elasticsearch/logstash-*/_field_stats?level=indices应答中发现timestame,min_value和max_value显示的都是UTC时间，怀疑是没有配置为当前时区，后来经确认kibana默认会和浏览器时区保持一致，ES后端也是用的UTC时间，所以才会有8点新建的index logstash-2016.06.03.
这个时候就怀疑index的mapping有问题了。
5. 分析index mapping和 index template
在kopf中把logstash-2016.06.02的mapping和logstash-2016.06.03新生成的index mapping做了对比，发现mapping发送了变化，配置发送了变更。经过对比排查和确认是@timestamp字段定义发生了变化，从
"@timestamp": {
"format": "strict_date_optional_time||epoch_millis",
"type": "date"
}变成了
"@timestamp": {
"index": "not_analyzed",
"type": "date"
},
猜测是因为调优把很多不查询的字段改为了not_analyzed, 最好把老的mapping更新到了index template, 然后删除了已有的index logstash-2017.06.03 (因为当前的index日志不多，重要性没那么高，所以没有做alias来reindex), 之后新的index template创建的index logstash-2017.06.03。 之后再kibana里重现添加了这个index pattern, 数据正常显示了。
分析和总结为什么@timestamp这个字段不能改为not_analyzed
kibana都是基于时间来查询过滤数据的，如果@timestamp不做分词的话，kibana的各种时间段查询肯定不会生效的，必须把各个时间段分词后才能比较查出结果。
经过这次事件后，我们发现index template的备份是必要的，要不然排查追溯问题很不方便。
