1、使用 Elasticsearch 快照功能 安装 COS 插件（如果自建 ES 未安装）： 下载腾讯云提供的 Elasticsearch COS 插件。 在自建的 Elasticsearch 集群中安装插件： bin/elasticsearch-plugin install file:///tmp/elasticsearch-cos-x.x.zip 重启 Elasticsearch 服务，确保插件生效。 2、注册快照仓库： 在自建的 Elasticsearch 集群中注册腾讯云 COS 作为快照仓库： PUT /_snapshot/my_backup_repo { "type": "repository-cos", "settings": { "bucket": "your-bucket-name", "access_key_id": "your-access-key-id", "secret_access_key": "your-secret-access-key", "endpoint": "cos.xx.tencentcos.cn" } } 确保替换 your-bucket-name、your-access-key-id 和 your-secret-access-key 为实际的 COS 信息。 3、创建快照： 在腾讯云在线的 Elasticsearch 中创建快照： PUT /_snapshot/my_backup_repo/snapshot_1?wait_for_completion=true 确保快照创建成功后，数据会备份到 COS 中。 4、恢复快照： 在自建的 Elasticsearch 集群中恢复快照： POST /_snapshot/my_backup_repo/snapshot_1/_restore 等待恢复完成，数据将迁移到自建的 Elasticsearch 中。... 展开详请

登录 Kibana 控制台，在开发工具中执行以下命令，查看索引的 shard 信息，确认索引的 shard 在负载高的节点上呈现的数量较多，说明 shard 分配不均。GET _cat/shards?vGET _cat/indices?v 登录 Kibana 控制台，在开发工具中执行以下命令，查看索引信息。结合集群配置，确认存在节点 shard 分配不均的现象。 重新分配分片，合理规划 shard，确保主 shard 数与副 shard 数之和是集群数据节点的整数倍。!Elasticsearch 在检索过程中也会检索 .del 文件，然后过滤标记有 .del 的文档，这会降低检索效率，耗费规格资源，建议在业务低峰期进行强制合并操作，具体请参见 force merge。 shard 规划建议 Shard 大小和数量是影响 Elasticsearch 集群稳定性和性能的重要因素之一。Elasticsearch 集群中任何一个索引都需要有一个合理的 shard 规划。合理的 shard 规划能够防止因业务不明确，导致分片庞大消耗 Elasticsearch 本身性能的问题。以下是 shard 规划时的几个建议： 尽量遵循索引单分片20g - 50g的设计原则。 索引尽量增加时间后缀，按时间滚动，方便管理。 在遵循单分片设计原则的前提下，预测出索引最终大小，并根据集群节点数设计索引分片数量，使分片尽量平均分布在各个节点。 !主分片不是越多越好，因为主分片越多，Elasticsearch 性能开销也会越大。建议单节点 shard 总数按照单节点内存×30进行评估，如果 shard 数量太多，极易引起文件句柄耗尽，导致集群故障。... 展开详请

在查询 body 中添加 "profile": true，检查 test 索引是否存在某个 shard 查询时间比其他 shard 长。GET _cat/segments/index?v&h=shard,segment,size,size.momery,ip GET _cat/shards?v 查询中分别指定 preference=_primary 和 preference=_replica，在 body 中添加 "profile": true，分别查看主副 shard 查询消耗的时间。检查较耗时的 shard 主要体现在主 shard 上还是副 shard 上。 登录 Kibana 控制台，在开发工具中执行以下命令，查看 shard，并根据其中 segment 信息分析问题所在，确认负载不均与 segment 大小不均有关。 参考以下两种方法其中一种解决问题： 在业务低峰期进行强制合并操作，具体请参见 force merge，将缓存中的 delete.doc 彻底删除，将小 segment 合并成大 segment。 重启主 shard 所在节点，触发副 shard 升级为主 shard。并且重新生成副 shard，副 shard 复制新的主 shard 中的数据，保持主副 shard 的 segment 一致。... 展开详请

父熔断器（Parent circuit breaker） 父熔断器限制所有子熔断器上使用的内存总量，当触发父熔断器熔断时，可能的日志信息如下： Caused by: org.elasticsearch.common.breaker.CircuitBreakingException: [parent] Data too large, data for [<transport_request>] would be [1749436147/1.6gb], which is larger than the limit of [1622605824/1.5gb], real usage: [1749435872/1.6gb], new bytes reserved: [275/275b] Field data 熔断器（Field data breaker） 当对 text 字段聚合或排序时，会产生 Field data 数据结构。Field data 熔断器会预估有多少数据被加载到内存中。当预估的数据占用内存到达 Field data 熔断器阈值时，会触发 Field data 熔断器熔断。此时可能的日志信息如下： org.elasticsearch.common.breaker.CircuitBreakingException: [fielddata] Data too large, data for [_id] would be [943928680/900.2mb], which is larger than the limit of [255606128/243.7mb] In flight 请求熔断器（In flight requests circuit breaker） In flight 请求熔断器限制了在 transport 和 HTTP 层的所有当前传入的请求所使用的内存。当触发 In flight 请求熔断器时，可能的日志信息如下： [o.e.x.m.e.l.LocalExporter] [1611816935001404932] unexpected error while indexing monitoring document org.elasticsearch.xpack.monitoring.exporter.ExportException: RemoteTransportException[[1611816935001404732][9.10.153.16:9300][indices:data/write/bulk[s]]]; nested: CircuitBreakingException[[in_flight_requests] Data too large, data for [<transport_request>] would be [19491363612/18.1gb], which is larger than the limit of [17066491904/15.8gb]];... 展开详请

官方熔断机制的一个不足是仅跟踪那些经常会出问题的请求来预估内存的使用，而无法根据当前节点的实际内存使用状态，来限制请求的内存使用或触发熔断。在腾讯云 ES 中，开发了针对 JVM OLD 区内存使用率的自研熔断器来解决这个问题。 腾讯云 ES 的自研熔断器监控 JVM OLD 区的使用率，当使用率超过85%时开始拒绝写入请求，若 GC 仍无法回收 JVM OLD 区中的内存，在使用率到达90%时将拒绝查询请求。当请求被拒绝时，客户端将收到如下的响应： { "status": 403, "error": { "root_cause": [{ "reason": "pressure too high, (smooth) bulk request circuit break", "type": "status_exception" }], "type": "status_exception", "reason": "pressure too high, (smooth) bulk request circuit break" } }... 展开详请

查看索引情况，并根据返回找到状态异常的索引。 GET /_cat/indices [3e6d4efed0f7e807292af5c955178aac.png]... 展开详请

GET /_cluster/allocation/explain [bdb53f699cc543c72d0dbeab86433937.png] 这里通过异常信息可以看出： 主分片当前处于未分配状态（current_state），发生这个问题的原因是因为分配了该分片的节点已从集群中离开（unassigned_info.reason）。 上述问题发生后，分片无法自动分配分片的原因是集群中没有该分片的可用副本（can_allocate）。 同时也给出了更详细的信息（allocate_explanation）。 这种情况发生的原因是因为集群有节点下线，导致主分片已没有任何可用的分片数据，当前唯一能做的事就是等待节点恢复并重新加入集群。 !某些极端场景，例如单副本集群的分片发生了损坏，或是文件系统故障导致该节点被永久移除，而此时只能接受数据丢失的事实，并通过 reroute commends 来重新分配空的主分片。为了尽量避免这种极端的场景，建议合理设计索引分片，不要给索引设置单副本。这里所谓的单副本，指的是索引有主分片，但没有副本分片，或称之为0副本。合理设计索引分片，可以将集群的总分片控制在一个很健康的规模，可以在保证高可用的情况下更加充分地利用集群分布式的特性，提高集群整体性能。... 展开详请

可通过如下分析方式初步判断集群产生未分配分片的原因，一般都可以在 allocation explain api 中得到想要的答案。 ?集群状态如果长时间未自动恢复，或是无法解决，则需要通过 售后支持 联系腾讯云技术支持。 reason 原因 INDEX_CREATED 索引创建，由于 API 创建索引而未分配的 CLUSTER_RECOVERED 集群恢复，由于整个集群恢复而未分配 INDEX_REOPENED 索引重新打开 DANGLING_INDEX_IMPORTED 导入危险的索引 NEW_INDEX_RESTORED 重新恢复一个新索引 EXISTING_INDEX_RESTORED 重新恢复一个已关闭的索引 REPLICA_ADDED 添加副本 ALLOCATION_FAILED 分配分片失败 NODE_LEFT 集群中节点丢失 REROUTE_CANCELLED reroute 命令取消 REINITIALIZED 重新初始化 REALLOCATED_REPLICA 重新分配副本 ... 展开详请

通过监控来观察到 CPU 飙高与写入相关，然后开启集群的慢日志收集，确认写入慢的请求，进行优化。也可以通过获取hot_threads信息来确认什么线程在消耗 CPU： curl http://9.15.49.78:9200/_nodes/hot_threads [b44d79ae65813f73f26b9ae1c2bc0d81.png] 例如，这里发现的是有大量 ingest pipeline 操作，而 ingest 操作是十分消耗资源的。 [98aa569f971fabb4ad525720a0c16b57.png]... 展开详请

这种情况比较常见，可以从监控上找到线索。通过监控可以发现，查询请求量的波动与集群最大 CPU 使用率是基本吻合的。 [bafe9cb014018950aaca8ee964c2110d.png] 进一步确认问题需要开启集群的慢日志收集，具体可参考 查询集群日志。从慢日志中，可以得到更多信息，例如引起慢查询的索引、查询参数以及内容。... 展开详请

问题现象 集群在某些情况下会出现写入拒绝率增大（bulk reject）的现象，具体表现为 bulk 写入时，会有类似以下报错： [2019-03-01 10:09:58][ERROR]rspItemError: {"reason":"rejected execution of org.elasticsearch.transport.TransportService$7@5436e129 on EsThreadPoolExecutor[bulk, queue capacity = 1024, org.elasticsearch.common.util.concurrent.EsThreadPoolExecutor@6bd77359[Running, pool size = 12, active threads = 12, queued tasks = 2390, completed tasks = 20018208656]]","type":"es_rejected_execution_exception"} 可在云监控看到集群写入拒绝率增大。 [998766e0b7117412fb13fd7ca37b2f35.png]GET _cat/thread_pool/bulk?s=queue:desc&v一般默认队列是1024，如果 queue 下有1024，说明这个节点有 reject 的现象。 [c31a56cabaa51518be460baa338e5521.png] 也可在 kibana 控制台，通过命令查看正在拒绝或者历史拒绝的个数。 问题定位 引起 bulk reject 的大多原因是 shard 容量过大或 shard 分配不均，具体可通过以下方法进行定位分析。 检查分片（shard）数据量是否过大 分片数据量过大，有可能引起 Bulk Reject，建议单个分片大小控制在20GB - 50GB左右。可在 kibana 控制台，通过命令查看索引各个分片的大小。GET _cat/shards?index=index_name&v[551e6cb4aaccd8391f619f0ecef0129d.png] 2. 检查分片数是否分布不均匀 集群中的节点分片分布不均匀，有的节点分配的 shard 过多，有的分配的 shard 少。curl "$p:$port/_cat/shards?index={index_name}&s=node,store:desc" | awk '{print $8}' | sort | uniq -c | sort结果如下图（第一列为分片个数，第二列为节点 ID），有的节点分片为1，有的为8，分布极不均匀。 [62d75ef4823d87934ab64a9eb243a556.png] 可在 ES 控制台集群详情页的【集群监控】>【节点状态】查看，具体操作可参见 查看监控。 也可通过 curl 客户端，查看集群各个节点的分片个数。 解决方案 设置分片大小 分片大小可以通过 index 模版下的 number_of_shards 参数进行配置（模板创建完成后，再次新创建索引时生效，老的索引不能调整）。 调整分片数据不均匀 临时解决方案 如果发现集群有分片分配不均的现象，可以通过设置 routing.allocation.total_shards_per_node 参数，动态调整某个 index 解决，参考地址。 !total_shards_per_node 要留有一定的 buffer，防止机器故障导致分片无法分配（例如10台机器，索引有20个分片，则 total_shards_per_node 设置要大于2，可以取3）。 参考命令： PUT {index_name}/_settings { "settings": { "index": { "routing": { "allocation": { "total_shards_per_node": "3" } } } } } 索引生产前设置 通过索引模板，设置其在每个节点上的分片个数。 PUT _template/｛template_name｝ { "order": 0, "template": "｛index_prefix@｝*", //要调整的 index 前缀 "settings": { "index": { "number_of_shards": "30", //指定 index 分配的 shard 数，可以根据一个 shard 30GB左右的空间来分配 "routing.allocation.total_shards_per_node":3 //指定一个节点最多容纳的 shards 数 } }, "aliases": {} }... 展开详请

Elasticsearch 5.6.4版本没有磁盘容量阈值以防止磁盘被写满，因此，如果您使用 Elasticsearch 5.6.4版本请关注磁盘使用量情况，及时删除无用索引或扩容磁盘。 Elasticsearch 6.4.3版本设置了磁盘水位（watermark）阈值，当磁盘使用率到达99%时，在该磁盘上有分片的索引将变为 readonly 状态，此时无法向这些索引写入数据。因此，我们建议当您发现磁盘使用率较高的时候就及时地清理索引或扩容磁盘。 产生原因 创建 index pattern 超时 当您的集群磁盘状态变为 readonly 时，将无法在 kibana 上创建 index pattern。这是因为当集群磁盘写满时，ES 会自动把索引设置的 block 级别设为 readonly_allow_delete 状态。Elasticsearch exception [ type=cluster_block_exception, reason=blocked by: [FORBIDDEN/12/index read-only / allow delete (api)]; ]Elasticsearch exception [ type=cluster_block_exception, reason=blocked by: [FORBIDDEN/13/cluster read-only / allow delete (api)]; ] 写入索引出错 当您的集群磁盘状态变为 readonly 时，清理索引或扩容磁盘仍无法将数据写入索引，错误如下： 索引只读错误： 集群只读错误： 解决办法 您需要先清理无用索引释放空间或扩容磁盘，然后在 Kibana 界面的【Dev Tools】中使用如下命令： 关闭索引只读状态： PUT _all/_settings { "index.blocks.read_only_allow_delete": null } 关闭集群只读状态： PUT _cluster/settings { "persistent": { "cluster.blocks.read_only_allow_delete": null } }... 展开详请

官方熔断机制的一个不足是仅跟踪那些经常会出问题的请求来预估内存的使用，而无法根据当前节点的实际内存使用状态，来限制请求的内存使用或触发熔断。在腾讯云 ES 中，开发了针对 JVM OLD 区内存使用率的自研熔断器来解决这个问题。 腾讯云 ES 的自研熔断器监控 JVM OLD 区的使用率，当使用率超过85%时开始拒绝写入请求，若 GC 仍无法回收 JVM OLD 区中的内存，在使用率到达90%时将拒绝查询请求。当请求被拒绝时，客户端将收到如下的响应： { "status": 403, "error": { "root_cause": [{ "reason": "pressure too high, (smooth) bulk request circuit break", "type": "status_exception" }], "type": "status_exception", "reason": "pressure too high, (smooth) bulk request circuit break" } } 上面的错误提示表明当前 JVM OLD 区负载较高，需要清理 JVM 中部分内存后重试。... 展开详请

清理 fielddata cache：在 text 类型的字段上进行聚合和排序时会使用 fileddata 数据结构，可能占用较大内存。可以在 Kibana 界面的【Dev Tools】中使用如下命令查看索引的 fielddata 内存占用：GET /_cat/indices?v&h=index,fielddata.memory_size&s=fielddata.memory_size:desc若 fielddata 占用内存过高，可以在 Kibana 界面的【Dev Tools】中使用如下命令清理 fielddata：POST /${fielddata占用内存较高的索引}/_cache/clear?fielddata=trueGET /_cat/nodes?v&h=segments.count,segments.memory&s=segments.memory:desc若 segment 占用内存过高，可以通过删除部分不用的索引，关闭索引，或定期合并不再更新的索引等方式缓解。 清理 segment：每个 segment 的 FST 结构都会被加载到内存中，并且这些内存是不会被 GC 回收的。因此如果索引的 segment 数量过大，也会导致内存使用率较高。可以在 Kibana 界面的【Dev Tools】中使用如下命令查看各节点的 segment 数量和占用内存大小： 扩容集群：如果您清理内存后，仍频繁触发熔断，说明您的集群规模已经不匹配于您的业务负载，最好的方式是扩大集群规模，您可以参考 扩容集群。... 展开详请