1、问题描述
早上醒来发现手机有很多ES状态为red的告警，集群就前几天加了几个每天有十多亿记录的业务，当时估算过磁盘容量，应该是没有问题的，但是现在集群状态突然变成red了，这就有点懵逼了。
2、查找问题原因
没办法，问题出来了，只好查找问题的原因了。
先看看集群的状态
curl -XGET 'http://unknow.com/_cat/health?v&pretty'
epoch timestamp cluster status node.total node.data shards pri relo init unassign pending_tasks max_task_wait_time active_shards_percent
1504509540 15:19:00 xxx-es-cluster red xx xx xxxx xxxx 2 0 10 0 - 99.99%
从上可看出，集群状态为red，说明有primary shard丢失了，看后面显示有10个shards是unassign，看来问题就出在这里了。
再看看是哪些索引有问题
curl -XGET 'http://unknow.com/_cat/indices?v&pretty'
发现有几个索引的状态为red，明显是unassign shard导致的。
现在具体看看哪些shard是unassign
curl -XGET 'http://unknow.com/_cat/shards?v&pretty'
找到unassign的shard，再看unassign的原因，这个ES有个比较好的cluster allocation explain api，可以直接查看unassign的原因，通过该api查到：设备上没有空间
查看各结点的存储使用情况
现在只能看各结点的容量使用情况了，再来个api
curl -XGET 'http://unknow.com/_cat/allocation?v&pretty'
这个可以查看每个结点的磁盘使用情况，奇怪的是并没有结点的存储满了，最高的也使用不到70%。
至此，虽然shard unsigned的原因找到了，就是磁盘满导致的，但是深层次的原因还没有找到。
3、处理方案
既然原因找到了，那就先恢复吧，恢复很简单，可以参考ES提供的reroute api
因为这里主要是primary shard unassigned，恢复的命令如下：
curl -XPOST 'http://unknow.com/_cluster/reroute?retry_failed=5&pretty' -d '
{
"commands" : [ {
"allocate_stale_primary" : {
"index" : "myindex",
"shard" :0,
"node" : "node-ip",
"accept_data_loss" : true
}
}]
}'
注意：这里用的是allocate_stale_primary，官网描述如下：
Allocate a primary shard to a node that holds a stale copy. Accepts the index and shard for index name and shard number, and node to allocate the shard to. Using this command may lead to data loss for the provided shard id. If a node which has the good copy of the data rejoins the cluster later on, that data will be overwritten with the data of the stale copy that was forcefully allocated with this command. To ensure that these implications are well-understood, this command requires the special field accept_data_loss to be explicitly set to true for it to work.
4、深层原因
问题是解决了，集群状态也恢复成green了，但是最终原因还是没有找到，说不定明天又会收到一堆告警了
先看看ES的日志
跑到master结点上看了下日志，分别看到这种日志
[2017-09-03T02:52:58,609][WARN ][o.e.c.r.a.d.DiskThresholdDecider] [master-node] after allocating, node [szTykZvTTQ-8gskQMAK4UQ] would have more than the allowed 10% free disk threshold (4.7% free), preventing allocation
[2017-09-03T02:53:28,732][WARN ][o.e.c.r.a.DiskThresholdMonitor] [master-node] high disk watermark [90%] exceeded on [szTykZvTTQ-8gskQMAK4UQ][data-node][/data4/search/data/nodes/0] free: 0b[0%], shards will be relocated away from this node
[2017-09-03T02:54:58,659][WARN ][o.e.c.a.s.ShardStateAction] [master-node] [myindex][0] received shard failed for shard id [[myindex][0]], allocation id [xff7GrobTBuf6w3XplxR7Q], primary term [0], message [shard failure, reason [merge failed]], failure [NotSerializableExceptionWrapper[merge_exception: java.io.IOException: 设备上没有空间]; nested: IOException[设备上没有空间];
从上可以很清楚的看出，索引的shard做merge的时候，磁盘没有空间了，导致merge failed，最终导致shard failure，表现就是 shard unssigned
为啥会磁盘满？
按理说ES集群会自动做均衡的，不应该会出现某个盘满的情况，关于ES集群的Cluster Level Shard Allocation和Disk-Based Shard Allocation，大家可以自己看一下。
虽然ES集群有这些balance和rebalance的策略，但是都是基于shard的，shard是ES最基本单位，一个shard只能分配到一个磁盘上，那是不是shard的大小不均造成的呢？通过查看集群shard的api可以看到每个shard的存储大小：
curl -XGET 'http://unknow.com/_cat/allocation?v&pretty'
对结果进行排序后发现，还真的有一些索引的shard会很大，最大的已经达到了100多G，我的天啊，怎么会变这么大，之前都差不多只有10G，后面查看业务的数据量，原来是业务增长导致的。
这个其实还不至于使磁盘满，因为我当天的索引为了加快索引速度，都是设置的0副本，在第二天凌晨的时候会把它设置成1副本，由于结点的每个盘还不到300G（坑爹的机器配置），集群在复制那种100多G的分片的时候很容易就导致某个磁盘满了。
5、最终解决
增加shard数
道理很简单，增加shard后，使每个shard的大小减少到10G左右，由于ES集群是基于shard来进行balance和rebalance的，且shard不能再分，因此减小shard的大小可以减小磁盘满的概率。
先把大的分片移到剩余空间大的结点，再增加副本数
如果集群总的剩余空间很足，只是极个别的盘满了，可以把大的shard迁移到磁盘大、剩余空间多的结点上，这样来规避磁盘满的风险。
6、总结
通过这一折腾，了解了shard的allocation，同时随着集群的数据的增长，可以避免后面踩更大的坑。另外，集群的运营和监控也很重要。
文章可以转载, 但必须以超链接形式标明文章原始出处和作者信息