首页
学习
活动
专区
工具
TVP
发布
社区首页 >专栏 >谈谈最近ES运维中遇到的几个有意思的问题<一>

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

原创
作者头像
南非骆驼说大数据
修改2021-01-31 17:22:28
2K1
修改2021-01-31 17:22:28
举报

一、新旧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数据
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选择节点标记部分设置
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问题,跟进耗时比较长,这里一并记录共享。后续将持续更新有意思的运维问题。

原创声明:本文系作者授权腾讯云开发者社区发表,未经许可,不得转载。

如有侵权,请联系 cloudcommunity@tencent.com 删除。

原创声明:本文系作者授权腾讯云开发者社区发表,未经许可,不得转载。

如有侵权,请联系 cloudcommunity@tencent.com 删除。

评论
登录后参与评论
0 条评论
热度
最新
推荐阅读
目录
  • 一、新旧ES集群数据按时间字段排序不生效的问题
  • 客户情况:
  • 二、冷热集群索引生命周期策略不生效问题
  • 客户问题:
  • 三、客户不同logstash进程却输出相同日志文件的问题
  • 客户问题
  • 四、客户将mysql中的数据经JAVA转换后导入ES中数据解析失败问题
  • 问题描述:
  • 五、总结
相关产品与服务
Elasticsearch Service
腾讯云 Elasticsearch Service(ES)是云端全托管海量数据检索分析服务,拥有高性能自研内核,集成X-Pack。ES 支持通过自治索引、存算分离、集群巡检等特性轻松管理集群,也支持免运维、自动弹性、按需使用的 Serverless 模式。使用 ES 您可以高效构建信息检索、日志分析、运维监控等服务,它独特的向量检索还可助您构建基于语义、图像的AI深度应用。
领券
问题归档专栏文章快讯文章归档关键词归档开发者手册归档开发者手册 Section 归档