运维小任务 001:分析elk中kibana查询数据返回为空

我们公司处理用户报来的问题时，一般都是值班人员先根据用户提供的相关信息在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的备份是必要的，要不然排查追溯问题很不方便。