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 中。... 展开详请

在查询 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副本。合理设计索引分片，可以将集群的总分片控制在一个很健康的规模，可以在保证高可用的情况下更加充分地利用集群分布式的特性，提高集群整体性能。... 展开详请

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

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

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 数量和占用内存大小： 扩容集群：如果您清理内存后，仍频繁触发熔断，说明您的集群规模已经不匹配于您的业务负载，最好的方式是扩大集群规模，您可以参考 扩容集群。... 展开详请