ELK突然没有数据提示No results match your search criteria的两种可能的结果

ELK正常使用，突然某天Kibana没有数据了。提示：No results match your search criteria。

1、首先进行刷新

系统管理-Kibana-索引模式-刷新字段列表尝试，发现提示：[FORBIDDEN/12/index read-only / allow delete (api)] – read only elasticsearch indices

经过尝试，执行一下代码好使：

PUT _settings { "index": { "blocks": { "read_only_allow_delete": "false" } } } PUT your_index_name/_settings { "index": { "blocks": { "read_only_allow_delete": "false" } } }

查询发现，配置read_only_allow_delete: false只是关闭只读模式而已。而导致只读模式的原因则是因为磁盘空间不足导致的。查看Monitoring，发现空间还剩余5%。而ELK的洪水水位线,默认为95%,当使用率达到这个值,ES会将对应的索引设为只读.这是最后一个保护措施.只读状态必须在有了足够空间后人工解除.

所以，需要可通过后台的console，DELETE部分无用数据。

2、elasticsearch报错

通过命令：

curl -XGET "http://localhost:9200/_cluster/allocation/explain"

{
	"index": "scoresystemprod-2024.01.01",
	"shard": 2,
	"primary": false,
	"current_state": "unassigned",
	"unassigned_info": {
		"reason": "CLUSTER_RECOVERED",
		"at": "2024-01-29T00:58:24.657Z",
		"last_allocation_status": "no_attempt"
	},
	"can_allocate": "no",
	"allocate_explanation": "cannot allocate because allocation is not permitted to any of the nodes",
	"node_allocation_decisions": [
		{
			"node_id": "tmJtYCiRT4mX3Btfo7icug",
			"node_name": "tmJtYCi",
			"transport_address": "127.0.0.1:9300",
			"node_attributes": {
				"ml.machine_memory": "50458259456",
				"xpack.installed": "true",
				"ml.max_open_jobs": "20",
				"ml.enabled": "true"
			},
			"node_decision": "no",
			"deciders": [
				{
					"decider": "same_shard",
					"decision": "NO",
					"explanation": "the shard cannot be allocated to the same node on which a copy of the shard already exists [[scoresystemprod-2024.01.01][2], node[tmJtYCiRT4mX3Btfo7icug], [P], s[STARTED], a[id=ksIiIycHTne8gmD-exODjw]]"
				}
			]
		}
	]
}

查看集群状态：

curl -XGET "http://localhost:9200/_cat/health?v"

可以看到其active_shards_percent为49.6%,elasticsearch健康状态为red,原因就是其存在UNASSIGNED shards的情况，而此时也影响到了es的正常使用。

二、分析原因：
如果我们只有一台机器,部署运行了es,但是却在index的settings中设置了replica为1,那么这个replica shard就会成为unassigned shards,因为分片不能分配到已经存在分片副本的同一节点.

而当我们在查看原因的时候就会如上图显示的那样：

the shard cannot be allocated to the same node on which a copy of the shard already exists
三、定位问题：
既然想到了，那肯定要验证一下。使用命令：

curl -XGET "http://localhost:9200/_cat/shards?h=index,shard,prirep,state,unassigned.reason" | grep UNASSIGNED

 四、解决问题：

以上的0 代表节点的编号，很清楚的可以看出 每个节点，都是r不能分配，证实了我们的分析原因。既然知道问题所在，就好解决，目前只有一个es节点，所以就直接更改副本数量。

4、更改副本数量

使用命令

根据索引名称更改副本数量

curl -X PUT http://localhost:9200/{index}/_settings --header 'Content-Type: application/json' -d '{"index":{"number_of_replicas":0}}'

或者

更改所有索引副本数量

curl -X PUT 'http://localhost:9200/_settings' -H 'Content-Type: application/json' -d '{"number_of_replicas":0}'

发现还是报错，报错原因依然是：

{
	"error": {
		"root_cause": [
			{
				"type": "cluster_block_exception",
				"reason": "blocked by: [FORBIDDEN/12/index read-only / allow delete (api)];"
			}
		],
		"type": "cluster_block_exception",
		"reason": "blocked by: [FORBIDDEN/12/index read-only / allow delete (api)];"
	},
	"status": 403
}

之所以会这样，是因为索引被锁住了，所以我们需要先解锁。

5、取消索引只读的锁

使用命令：

curl -X PUT http://localhost:9200/_all/_settings --header 'Content-Type: application/json' -d '{"index.blocks.read_only_allow_delete": null}'

返回结果：{"acknowledged":true}

然后继续执行上面更改副本数量的命令。

PS:谨慎使用_all

6、查看集群状态，已正常

此时我们在看状态，已经是green

8、当logstash在第二天创建新索引时，number_of_replicas设置为默认值。为新索引更新默认索引number_of_replicas设置为0

可以使用索引模板。 索引模板是为集群中创建的新索引设置默认设置(包括映射)的好方法

ES 6.0之前的版本:

curl -XPUT 'http://localhost:9200/_template/srmprod_template'  -H 'Content-Type: application/json' -d '{"template": "srmprod*","settings" : {"number_of_replicas" : 0 }}'

ES 6.0之后的版本:

curl -XPUT 'http://localhost:9200/_template/srmprod_template'  -H 'Content-Type: application/json' -d '{"index_patterns": ["srmprod*"],"settings" : {"number_of_replicas" : 0 }}'

请注意，这不会更改现有索引，只会更改新创建的索引。