elasticsearch 运维中遇到的问题

1、elastic 异常关机 后日志不消费

[2020-12-22T16:28:07,485][INFO ][logstash.outputs.elasticsearch][main][7a9bd902efcf008d8e54ca5c1eae1bb97fe2712e0be94b53b9e2a59022ef3172] retrying failed action with response code: 503 ({"type"=>"unavailable_shards_exception", "reason"=>"[log-app-tcloud-account-2020.12.21][0] primary shard is not active Timeout: [1m], request: [BulkShardRequest [[log-app-tcloud-account-2020.12.21][0]] containing [34] requests]"})

启动那些异常关机的节点就行了 关机之后主分片连不上了

2、[ERROR][o.e.x.m.c.i.IndexStatsCollector] [zpFrL81] collector [index-stats] failed to collect data
org.elasticsearch.cluster.block.ClusterBlockException: blocked by: [SERVICE_UNAVAILABLE/1/state not recovered / initialized];

path: /.kibana/doc/config%3A6.3.0, params: {index=.kibana, id=config:6.3.0, type=doc}
org.elasticsearch.action.NoShardAvailableActionException: No shard available for [get [.kibana][doc][config:6.3.0]: routing [null]]
 

访问 health 都无法响应 

等了一会之后发现报了一些red 的index转yellow的信息 想到是不是正在恢复数据  于是等了1个多小时之后es集群恢复正常

这个报错看来不是什么问题 只是在恢复数据而已

3、cluster_block_exception TOO_MANY_REQUESTS/12/index read-only / allow delete (api)

当linux磁盘空间不够情况后，这个阈值是90% ES集群为了保护数据，会自动把索引分片index置为只读read-only

删除掉一些索引 ，或者增加磁盘空间

4、retrying failed action with response code: 429 
({"type"=>"es_rejected_execution_exception", "reason"=>"rejected execution of processing of [12373521]
[indices:data/write/bulk[s][p]]: request: 
BulkShardRequest [[suricatadns140][97]] containing [2] requests, 
target allocation id: -erjXlg0RjeETfZKXokiiQ, 
primary term: 1 on EsThreadPoolExecutor[name = node-1/write, queue capacity = 200, 
org.elasticsearch.common.util.concurrent.EsThreadPoolExecutor@139538e0[Running, 
pool size = 8, active threads = 8, queued tasks = 200, completed tasks = 179152]]"})

因为导入的数据和ES写入的数据速度不匹配，ES为了保护自己，产生了拒绝
在ES的配置yml文件中添加:

thread_pool.write.queue_size: 10000

5  [ElasticsearchException[Elasticsearch exception [type=cluster_block_exception, reason=blocked by: [FORBIDDEN/12/index read-only / allow delete (api)];]]]

某个节点磁盘满了 。需要注意的是磁盘扩容之后还要手动解开index的只读保护 

 curl -XPUT -H "Content-Type: application/json" http://es78:9200/_all/_settings -d '{"index.blocks.read_only_allow_delete": null}'

这个是解开所有的 ，也有单个解开的 ，但是这种场景下没必要，返回ackge 是false也没关系  实际上是解开了 

6 、 "error"=>
{"type"=>"validation_exception", "reason"=>"Validation Failed: 1: this action would add [2] total shards, but 
this cluster currently has [999]/[1000] maximum shards open;"}}}}

es7默认1000分片上限

curl -XPUT -H "Content-Type:application/json" http://localhost:9200/_cluster/settings -d '{ "persistent": { "cluster": { "max_shards_per_node": 10000 } } }'

设置成10000  也可以设置的更高。比如elk场景 

7、system call filters failed to install; check the logs and fix your configuration or disable system call filters at your own risk

在阿里云上可能出现的问题

解决方法：在es配置中加入下面命令即可

bootstrap.system_call_filter: false
注意要在Memory下面

这是因为操作系统不支持SecComp，而ES5.4.1默认bootstrap.system_call_filter为true进行检测，所以导致检测失败，失败后直接导致ES不能启动。 

8、 java.lang.UnsupportedOperationException: seccomp unavailable: CONFIG_SECCOMP not compiled into kernel, CONFIG_SECCOMP and CONFIG_SECCOMP_FILTER are needed

解决方法：在es配置中加入下面命令即可

bootstrap.system_call_filter: false
注意要在Memory下面

在centos7 以下版本会出现的问题

这是因为操作系统不支持SecComp，而ES5.4.1默认bootstrap.system_call_filter为true进行检测，所以导致检测失败，失败后直接导致ES不能启动。 

什么是seccomp

seccomp（全称securecomputing mode）是linuxkernel从2.6.23版本开始所支持的一种安全机制。

在Linux系统里，大量的系统调用（systemcall）直接暴露给用户态程序。但是，并不是所有的系统调用都被需要，而且不安全的代码滥用系统调用会对系统造成安全威胁。通过seccomp，我们限制程序使用某些系统调用，这样可以减少系统的暴露面，同时是程序进入一种“安全”的状态。

9、启动es时报错 OutOfMemoryError: unable to create new native thread

修改  /etc/security/limits.d/20-nproc.conf

追加或者修改

*          soft    nproc  65536   #限制单个进程最大文件句柄数

10、通过应用程序写入没有问题，通过hive同步mysql到es库的时候会出现时区问题，mysql时间字段类型是datetime

原因：ES默认存储的是UTC时间，比北京时间晚8h；

解决方案：
1、将时间写入ES中string类型字段；
2、将时间以时间戳的形式存入ES中long类型字段；
3、ES默认是UTC时间，将时间+8h后存入ES中date类型字段；
4、写入时间数据时，指定时区，eg：“time”: “2016-07-15T12:58:17.136+0800” //东八区时间
 

11、mapping set to strict, dynamic introduction of [new_conf_tags] within [conference] is not allowed

往es中存储数据，严格模式
日志记录 mapping set to strict, dynamic introduction of [new_conf_tags] within [conference] is not allowed

原因：严格模式下禁止往es的mapping中新增字段，需要提前设置好mapping

查看索引的mapping结构：

curl -XGET 'http://localhost:9200/索引名/_mapping/类型名'

发现conference嵌套结构内缺少new_conf_tags字段

解决方案：
重新创建索引结构，增加new_conf_tags字段