谈谈最近ES运维中遇到的几个有意思的问题<一>

一、新旧ES集群数据按时间字段排序不生效的问题

客户情况：

客户有2个ES集群，索引mapping格式都一样，数据量不同。执行同样的API，一个集群可以基于时间字段排序并成功返回，一个集群却无法实现排序并成功返回。客户要执行的代码如下：

GET bbs/_search                                //同样的代码执行的结果不一样。
{
  "query": {"bool": {"must": [
    {"range": {
      "sync_es_time": {                       //时间戳字段排序过滤
        "gte": "2020-10-12 16:12:30",
        "lte": "2021-01-12 16:12:30"
      }
    }}
  ]}}
}

解决问题过程：

1，首先确定同样的API在旧集群上是不行，但是索引中确实是有数据。

2，其次我们确定2个集群的mapping是否有不一样或者非标的地方，发现其时间戳字段索引mapping，相同并且如如下所见：

时间戳字段类型定义

3，，为了验证字段类型是否有问题，我建立了一个discovery，发现同样没法展示数据：

通过上面的方法，我们可以判定，索引中的数据无法排序，应与时间戳字段定义有关系，我们去官网确定一下date类型如何定义：

发现官网中推荐的时间戳定义方法为如下：

PUT my_index
{
  "mappings": {
    "properties": {
      "date": {
        "type":   "date",
        "format": "yyyy-MM-dd HH:mm:ss||yyyy-MM-dd||epoch_millis"  //时间戳类型定义
      }
    }
  }
}

4，修改旧集群索引时间戳字段类型，然后再次reindex 索引，再次查看discovery结果，如下：

定义时间戳字段类型

Discovery数据

通过上面，我们就能正常的发现旧索引中的数据了。API排序也能正常返回。

GET bbs_test1/_search
{
  "query": {
    "bool": {
      "must": [
        {
          "range": {
            "sync_es_time": {
              "gte": "2020-10-12 16:12:30",
              "lte": "2021-01-12 16:12:30"
            }
          }
        }
      ]
    }
  },
  "sort": [
    {
      "sync_es_time": {
        "order": "asc"
      }
    }
  ],
  "size": 200
}

至此，客户的问题彻底解决。问题就出在时间字段类型定义不符合官方标准导致。

二、冷热集群索引生命周期策略不生效问题

客户问题：

申请了一个冷热集群，原意是热数据上的存储空间只能存1天，然后根据ILM自动挪动到warm节点上。但是发现索引生命周期策略生效了，但是索引并没移动到warm节点。热节点磁盘快满，影响集群写入。

解决过程：

1、确定ILM是否生效。通过GET indexname/_ilm/explain,可以查看索引生命周期策略是否生效，确定是生效成功。

节点已经标记成warm属性了。

又通过GET _cat/shard/indexname 可以查看分片在哪些节点上可知，分片还在hot节点上。也就是说，分片并未产生移动，但是策略却是已经生效了。于是我们去检查一下客户冷热集群的配置情况。发现客户在这里没有选参，导致分片在产生索引生命周期策略的时候并未将分片移动到warm节点，而仅仅将该索引标记为warm属性。这点尤为重要。

ILM选择节点标记部分设置

将其修改为warm节点后，问题即可解决。

注意：对于未生效的索引，我们先手动帮用户挪一下。以解决客户的磁盘燃煤之急。如下：

PUT index_name     //通配符手动降冷批量操作，立即生效
{
  "index.routing.allocation.require.temperature": "warm"
}

三、客户不同logstash进程却输出相同日志文件的问题

客户问题

客户在同一个节点上，运行了多个Logstash事件，一个接收filebeat发送过来的日志，然后过滤输出到ES，这个是正常的。另外一个仅仅在本机启动一个TCP监听端口，发现侦听到的数据跟另外一个事件文件完全相同。将事件文件分开到不同主机没问题。一旦合并到一起，就产生这样的现象。无论开多少个logstash进程就会重复多少个数据。

无监听源 logstash 配置文件如下：

经过各种测试排查，发现问题出在logstash，pipeline.yml配置文件定义部分。原因解析如下：

默认的pipelines.yml是包含/etc/logstash/conf.d下面的所有配置文件

- pipeline.id: main

path.config: "/etc/logstash/conf.d/*.conf"

把每个配置文件分开设置pipeline id就可以了

- pipeline.id: pppoe

path.config: "/etc/logstash/conf.d/pppoe.conf"

- pipeline.id: forward_log

path.config: "/etc/logstash/conf.d/forward_log.conf"

经过将配置文件目录分开，再次启动logstash进程，再也没出现用户那样的问题。

四、客户将mysql中的数据经JAVA转换后导入ES中数据解析失败问题

问题描述：

客户将mysql中的数据经JAVA转换后导入ES中存储，结果为0或者1的bool值结果，但是ES日志出现如下错误解析，导致数据写不进去。

Caused by: com.fasterxml.jackson.core.JsonParseException: Current token (VALUE_FALSE) not numeric, can not use numeric value accessors

大概的意思就是写进去的数值不被ES所识别，导致字段解析失败，写入失败。

默认，在ES中，数字都会被映射成Long类型，那客户这里为何报错呢？查阅文档：

https://elasticsearch.cn/question/3163

应该是客户业务代码侧数据类型转换错误。ES侧重新修改索引字段类型为byte,reindex数据后，问题解决。

五、总结

以上4个是最近遇到的比较奇葩的ES问题，跟进耗时比较长，这里一并记录共享。后续将持续更新有意思的运维问题。