elk笔记8--index

昕光xg

已于 2024-03-11 14:32:49 修改

阅读量1.7k

点赞数

分类专栏： Bigdata 文章标签： elk 索引 es常见错误处理方法 elasticsearch

于 2020-06-21 12:58:54 首次发布

本文链接：https://blog.csdn.net/u011127242/article/details/106883754

版权

Bigdata 专栏收录该内容

49 篇文章 2 订阅

订阅专栏

elk笔记8--index

1. index 创建的几种方式
2. 索引的常见设置
3. 说明

1. index 创建的几种方式

1.1 直接创建index

第一种方式最普通，此类index 写入时在logstash中直接指定index01即可；
其缺点是当日志量大的时候，会影响性能。

PUT index01
{}
out:
{
  "acknowledged" : true,
  "shards_acknowledged" : true,
  "index" : "index01"
}

1.2 按照当前日期创建索引

该方式创建日志，写入时候每天会创建一个带日期的index，此类写入时在logstash中配置如下：
index => “index02-%{+YYYY.MM.dd}”

PUT /%3Cindex02-%7Bnow%2Fd%7D%3E
{}
out:
{
  "acknowledged" : true,
  "shards_acknowledged" : true,
  "index" : "index02-2020.06.21"
}

1.3 创建带有rollover功能的索引

该方式新建一个index带日期和序号，并设置一个_write别名；
每次执行rollover的时候，会按照当前日期和和序号+1的方式生成新索引，并将_write别名指向最新索引；
因此实际写入的时候直接使用_write索引即可，该方式比较使用生产中使用；
实际使用的时候，若数据量过大，应该加一个cron定时按照策略进行rollover。

PUT /%3Cindex03-%7Bnow%2Fd%7D-000001%3E
{
  "aliases": {
  "index03_write": {}
  }
}
out:
{
  "acknowledged" : true,
  "shards_acknowledged" : true,
  "index" : "index03-2020.06.21-000001"
}
rollover:
POST index03_write/_rollover
out:
{
  "acknowledged" : true,
  "shards_acknowledged" : true,
  "old_index" : "index03-2020.06.21-000001",
  "new_index" : "index03-2020.06.21-000002",
  "rolled_over" : true,
  "dry_run" : false,
  "conditions" : { }
}

2. 索引的常见设置

2.1 基本设置

index.number_of_replicas 副本数量
index.routing.allocation.require.zone 索引存储的zone
index.routing.allocation.include._name 索引存储的节点名称
index.routing.allocation.include._ip 索引存储的节点ip
index.routing.allocation.total_shards_per_node 索引在每个节点上可以存储多少个分片

2.2 index 为unassigned的常见处理方式

当集群yellow时候，一般为分配未正常分配，包括如下常见4类处理方法：

zone限制

PUT index_name/_settings
{
  "index" : {
    "routing" : {
      "allocation" : {
        "require" : {
          "zone" : ""
        }
      }
    }
  }
}

include._ip 限制

PUT index_name/_settings
{
 "index" : {
 "routing" : {
   "allocation" : {
     "include" : {
       "_ip" : ""
        }
      }
    }
  }
}

include._name 限制

PUT index_name/_settings
{
 "index" : {
 "routing" : {
   "allocation" : {
     "include" : {
       "_name" : ""
        }
      }
    }
  }
}

total_shards_per_node 值过小导致shard无法分配到所有节点上

PUT index_name/_settings
{
  "index" : {
    "routing" : {
      "allocation" : {
        "total_shards_per_node" : "3" #此值根据节点数量和分片数量更改即可
      }
    }
  }
}

data 节点数量不够，导致主备shard无法分配
案例说明：
用户收到告警：集群为yellow
在集群中通过 GET _cluster/allocation/explain 查看结果如下，即同一个索引的副本和主分片不能出现在同一个节点中, 推测可能节点数量不够；

"explanation": "the shard cannot be allocated to the same node on which a copy of the shard already exists [[id5_equip_v1][1], node[Htz1RdjST-2gdvkti0xfCQ], [P], s[STARTED], a[id=NaGQ1AraS_SQwUKb-1j2xw]]"

继续 GET _cat/nodes?v ，发现集群中只有一个data节点，3个master节点，因此可以判断是集群节点数量少，而索引设置了非0副本导致yellow的。

解决方法1：
添加data节点，使其能够分配shard；
解决方法2:
用户可以接受的情况下，设置shard的副本为0，一般测试集群可以设置副本为0，正式集群建议设置1个副本
index_name
PUT index_name/_settings
{
  "index": {
    "number_of_replicas":"0"
  }
}

达到上限导致无法分配新的分片

报错信息：
"explanation": "reached the limit of incoming shard recoveries [2], cluster setting [cluster.routing.allocation.node_concurrent_incoming_recoveries=2] (can also be set via [cluster.routing.allocation.node_concurrent_recoveries])"
解决方法，适当提高node_concurrent_recoveries，默认为2
PUT _cluster/settings
{
   "transient": {
     "cluster.routing.allocation.node_concurrent_recoveries": 10
   }
 }

2.3 集群为red处理

笔者由于磁盘异常，且某些测试index没有设置副本，导致节点为red。
此时处理方法包括：
1）删除red的index
所有的数据都会丢失
2）通过reroute对red对应的index分配空的primary shard
丢失的分片数据丢失，没丢失的可以继续使用

GET _cluster/allocation/explain
{
  "index" : "dmesg001-2020.07.15-000003",
  "shard" : 1,
  "primary" : true,
  "current_state" : "unassigned",
  "unassigned_info" : {
    "reason" : "NODE_LEFT",
    "at" : "2020-07-15T15:27:55.563Z",
    "details" : "node_left [J2H0nVv9T-uH-ZymDUJ2yQ]",
    "last_allocation_status" : "no_valid_shard_copy"
  },
  "can_allocate" : "no_valid_shard_copy",
  "allocate_explanation" : "cannot allocate because a previous copy of the primary shard existed but can no longer be found on the nodes in the cluster",
  ......
  }
  
分配分片异常的，可以先通过reroute加retry_failed 参数来初步修复， 也可以尝试 _flush，无法修复的可以尝试分配空分片。
POST /_cluster/reroute?retry_failed=true

POST red_index_name/_flush

POST _cluster/reroute
{
"commands" : [ {
"allocate_empty_primary" : {
"index" : "dmesg001-2020.07.15-000003",
"shard" : 1,
"node" : "node-3",
"accept_data_loss" : true
}
}
]
}

例如，当出现如下报错，就可以考虑使用 reroute 操作，一般情况下可以正常分配shard
failed shard on node [j3qRTIRuR8ChEebKc6qCsw]: failed to create shard, failure IOException[failed to obtain in-memory shard lock]; nested: ShardLockObtainFailedException[[prediction-protobuf-portal-2023-02-03-00][9]: obtaining shard lock timed out after 5000ms, previous lock details: [shard creation] trying to lock for [shard creation]];

2.4 提高消费速度常见方法

适当增加分片数量
当logstash资源充足的时候，shard数量过少可能造成写入瓶颈，因此此时可以适当增加shard分片数据。
适当增加logstash数量
当shard分片数据比较多，logstash数量较少的时候，可能造成消费瓶颈，此时可以通过增加logstash数量来提高消费速率。
适当增加kafka topic partion数量
当分片数量和logstash数量充足的时候，若topic partion过低，也会导致logstash无法提高消费速率，此时可以适当提高topic的partion数量。
将索引写入到ssd节点
对于有一定规模的集群，可以设置hot、stale、freeze节点，hot节点用ssd节点，stale节点用普通的机械盘，freeze节点用最差的机械盘。
写入时候一般将重要的索引直接写入hot节点(保证最快的写入速率)，普通的索引写入到stale节点，冻结的索引保存在freeze节点。当stale节点中的索引写入速度无法提上去的时候，就可以通过rollover将起分配到hot节点中，从而提高起写入速率。
```
POST a01_logtail_write/_rollover
{
  "settings": {
  "index": {
  "number_of_shards" : "6",
  "routing": {
    "allocation": {
      "require": {
        "zone": "hot"
          }
        }
      }
    }
  }
}
```
去掉副本
去掉副本可以明显提高写入速率，但节点故障存在一定丢数据的风险；因此，当数据不太重要，紧急情况下可以通过去掉副本来快速提高写入速率，数据无lag的时候可以再恢复副本。
使用hangout代替logstash
在同等资源下，hangout的消费速率明显比logstash高一般是logstash的2-3倍的消费速率。

2.5 常见问题

index 创建了如何修改shard数量
正常情况是不允许修改的，对于可以rollover类型，或者按照日期的index，可以通过修改模板来更新shard数量，从而创建下一个index的时候就自动更新了shard数量;
如下创建模板后，更新settings的shard数据即可：
```
PUT _template/index_03
{
     "index_patterns": ["index03-*"], 
     "settings": {
       "number_of_shards": 2
     }
   }
```

判断集群状态常用的命令

GET _cluster/allocation/explain
GET _cat/health?v
GET _cat/indices?v&health=yellow
GET _cat/shards?h=index,shard,prirep,state,unassigned.reason
GET index_name/_setting
默认 explain 不会区分primary和非primary，且只能查看1个shard；所以，当有多个shard异常的时候，一般先用_cat/shards?v 查看哪些shard未分配且为主分片，然后再用条件式的explain查看具体原因
GET _cluster/allocation/explain
{
 "index": "my-index-000001",
 "shard": 0,
 "primary": true
}

结合以上命令，基本可以查找出集群异常状态原因。

curl 查询更新信息

无认证的集群: curl h01:9201/_cat/indices 
有认证的集群：curl -u elastic:elastic [-XGET可以省略] h01:9204/_cat/indices ，需要 -u 参数加入用户认证
使用curl put数据：curl -u elastic:elastic -H "Content-Type: application/json" -XPUT h01:9204/test1122/_settings -d '{"index": { "number_of_replicas": "0"}}' 
XPUT必须要加上，且需要加上-H "Content-Type: application/json"参数，否则会报如下406错误：
{"error":"Content-Type header [application/x-www-form-urlencoded] is not supported","status":406}

forcemerge 快速停用方法

 可以用如下命令查看当前正在执行的forcemerge任务，forcemerge 无法手动取消，要么等其自动完成，要么暴力重启节点
 GET _tasks?detailed=true&actions=*forcemerge
  查看各个节点forceMerge的线程数：
  GET _cat/thread_pool/force_merge?v&s=name