华为云用户手册

验证VPC访问IP绑定 当已经成功添加 域名 配置后，如图1 域名配置，可以使用与CAE环境所属VPC相同的E CS 访问，检查域名是否与VPC访问IP绑定。 图4 域名配置 登录ECS控制台，选择“弹性云服务器”。 在弹性云服务器列表中，选择连接到同一VPC下的ECS。 图5 选择同一VPC下的ECS（此处用vpc-demotest2演示） 从ECS上ping该内网域名（test18.com），验证网络是否连通。使用xshell可参考图6所示。 图6 ping内网域名 从ECS上使用wget命令访问内网域名（test18.com），验证组件是否正常运行。使用xshell访问可参考图7所示。 图7 访问内网域名

配置访问方式后，为什么实例异常了？ CAE 从环境外部访问本组件-负载均衡配置默认开启后端服务TCP健康检查，实质是进行TCP三次握手，正常的TCP三次握手后，会进行数据传输，但是在健康检查时会发送RST中断建立的TCP连接。该实现方式可能会导致您的组件认为TCP连接异常退出，并打印错误信息，如“Connection reset by peer”。解决方案如下： 关闭访问方式健康检查。 采用HTTP健康检查。 业务代码中忽略健康检查的连接错误。 图1 配置负载均衡访问方式的健康检查 父主题： 组件配置类

修改配置文件 编辑resources目录下的application.yml文件，修改actuator相关的配置来暴露Prometheus格式的指标数据。 management: endpoints: web: exposure: include: prometheus 配置完成后，此springboot项目可以通过/actuator/prometheus路径，9090端口暴露出Prometheus格式的监控指标。

在springboot项目中自定义监控指标 定义一个Counter类型的指标，每次前端点击时调用后端api，就自增1。 src\main\java\com\huawei\cae\controller\UserDataController.java中，定义如下字段和方法，并import所需类： 作用是定义了一个Counter类型的监控指标，名为"click_operated_total"。 import io.micrometer.core.instrument.Counter; import io.micrometer.core.instrument.MeterRegistry;import javax.annotation.PostConstruct;...@Autowired private MeterRegistry registry; private Counter visitCounter; @PostConstruct private void init() { visitCounter = registry.counter("click_operated_total", "click_operated_total",""); } 在前端调用访问的方法clientTest()第一行，添加如下代码： visitCounter.increment(); 这样，当每次访问该方法时，上面定义的“click_operated_total”就会增加1。 修改后的项目即可部署在CAE上，并监控自定义的Prometheus指标。

操作步骤 脚本报错，通常来说是用户侧问题。 用户自行修改了脚本，需要先核对脚本。 用户没有填写必填参数。 脚本分为软件包部署场景和镜像部署场景，用户填写场景错误。 咨询客户是否自行修改脚本内容，并核对脚本内容。 核对用户必填参数是否已经填写，并且场景正确。 其他场景导致的脚本执行后报错，比如脚本报CAE格式校验错误。 运行脚本的时候，加入参数 -x 。 bash -x deploy.sh 检查脚本信息，并检查是否符合预期。 修改脚本，重新运行即可。

解决方案 方案一：关闭或者删除不用的索引，减少shard数量。 方案二：修改节点的shard数量的限制，参数配置请参考max_shards_per_node。 PUT _cluster/settings{ "persistent": { "cluster": { "max_shards_per_node": 2000 } }} 修改节点的shard数量的限制属于临时规避方案，如果要长期解决，建议每GB的JVM堆内存小于等于20个shards（节点堆内存大小为节点内存规格的1/2，最大值为31GB），shard的建议数量详细请参见shard count recommendation。

操作步骤 若您使用的DNS服务商为华为云，您可通过如下步骤配置。 登录CAE控制台，选择“组件配置”。 在“组件配置”页面上方的下拉框中选择需要操作的组件。 在“访问方式”模块中如图1所示，获取公网地址和VPC访问地址。 图1 获取公网地址（“独享型”EIB需要先绑定EIP）和VPC访问地址 登录DNS控制台。 配置域名解析。 配置公网访问 选择“公网域名”，进入域名列表页面。 单击“创建公网域名”，输入自定义域名名称，下拉框选择“企业项目”，并单击“确定”。 在公网域名列表中，单击新创建的域名名称。 单击“快速添加解析”，在弹出界面中选择“网站解析”，“网站地址”选择“IP地址”。 图2 快速添加解析(公网IP) 将3获取的公网地址输入“值”一栏中。 配置vpc访问 选择“内网域名”，进入域名列表页面。 单击“创建内网域名”，输入自定义域名名称，选择组件所属环境相同的VPC，并单击“确定”。 图3 创建内网域名 在内网域名列表中，单击新创建的域名名称。 单击“添加记录集”，将3中获取的VPC访问地址输入“值”一栏中。 图4 内网域名与对应ip绑定 单击“确定”，完成添加。

集群一直处于快照中 集群一直处于快照中，有三个比较常见的原因： 集群数据量大或者集群压力大，备份快照耗时长。 单个节点的快照速度默认是40MB/s，同时，快照的性能还受集群情况影响，如果此时集群负载较高，耗时将会更久。可以通过上述章节的查询单个快照信息查询正在执行的快照情况。 执行GET _snapshot/repo_auto/snapshot-name，可以看到剩余还需要完成的shard个数，也可以通过删除快照接口提前终止。 解决方法：等待或者提前终止。 快照信息更新失败。 Elasticsearch将进行中的快照信息保存在cluster state中，快照完成后需要更新快照状态，由于Elasticsearch更新快照状态的接口没有加入重试或者容错机制，比如由于当时集群内存压力大，更新快照动作被熔断，那么这个快照将会一直处于快照中。 解决方法：调用快照删除接口。 临时AK、SK过期。 CSS 通过委托将Elasticsearch中的数据写入到用户的OBS中，快照仓库创建的时候，需要去使用委托获取临时的AK 、SK设置到仓库中。由于临时的AK、SK是有时效性的（24小时过期），如果一个快照超过24小时还未完成，那么这个快照将会失败。这种情况会有一个比较大的风险，因为此时仓库的AK、SK过期，无法对这个仓库进行更新、查询、删除操作，这种情况下cluster state信息将会无法清除，只能通过普通重启（滚动重启无法生效）集群来清除cluster state里面残留的快照信息。 解决方法：暂时只能通过普通重启集群来消除，后期CSS会提供终止接口，可以来解决这种无法消除状态的现象。 父主题： 功能使用类

排查是否有权限 登录 统一身份认证 服务管理控制台。 查看当前登录所用的账号或 IAM 用户所属的用户组。 具体操作请参见《统一身份认证服务用户指南》中的查看或修改用户信息章节。 查看用户组的权限中是否包含：“全局服务”中“ 对象存储服务 ”项目的“Tenant Administrator”权限、当前所属区域的“Elasticsearch Administrator”权限。 具体操作请参见《统一身份认证服务用户指南》中的查看或修改用户组章节。 如果用户组的权限中不包含以上两个权限，请执行4。 如果用户组的权限中包含以上两个权限，请联系人工客服协助解决。 为用户组添加：“全局服务”中“对象存储服务”项目的“Tenant Administrator”权限、当前所属区域的“Elasticsearch Administrator”权限。 具体操作请参见《统一身份认证服务用户指南》中的查看或修改用户组章节。

问题现象 ECS服务器部署logstash，然后推送数据到 云搜索服务 CSS，出现错误信息如下： LogStash::Outputs::ElasticSearch::HttpClient::Pool::BadResponseCodeError: Got response code '500' contacting Elasticsearch at URL 'https://192.168.xx.xx:9200/_xpack'。

为什么集群创建失败 集群创建失败原因有如下4种： 资源配额不足，无法创建集群。建议申请足够的资源配额，详情请参见如何申请扩大配额？。 如果集群配置信息中，“安全组”的“端口范围/ICMP类型”不包含“9200”端口，导致集群创建失败。请修改安全组信息或选择其他可用安全组。 7.6.2以及7.6.2之后的版本，集群内通信端口9300默认开放在用户VPC的子网上面。创建集群时需要确认所选安全组是否放通子网内的9300通信端口，如果未放通，请修改安全组信息或选择其他可用安全组。 权限不足导致集群创建失败。建议参考权限管理获取权限，然后创建集群。 父主题： 访问集群类

处理步骤 在集群管理页面，单击不可用的集群名称，进入集群基本信息页面。 单击“配置信息”中的安全组名称，进入当前集群所选安全组的基本信息页面。 分别查看“入方向规则”和“出方向规则”页签下，是否存在“策略”为“允许”，“协议端口”为“TCP : 9300”，“类型”为“IPv4”的安全组规则。 是，联系技术支持定位集群不可用问题。 否，执行下一步。 修改集群当前所选安全组信息，放通9300通信端口。 在当前集群所选安全组基本信息界面，选择“入方向规则”页签。 单击“添加规则”，在添加入方向规则对话框设置“优先级”为“100”，“策略”选择“允许”，“协议端口”选择“基本协议/自定义TCP”，端口填写“9300”，“类型”选择“IPv4”，“源地址”选择“安全组”下的集群当前安全组名称，即同安全组内放通。 图2 添加安全组规则 单击“确定”即可完成放通9300端口的设置。 同样的步骤，在“出方向规则”页签添加放通9300端口的设置。 安全组放通9300端口后，等待集群自动恢复可用状态。

问题现象 安装自定义插件后重启集群，“集群状态”变为“不可用”。 单击集群名称进入集群基本信息页面，选择“日志管理”，单击“日志查询”页签，可见日志内容存在明显的关于插件的报错“fatal error in thread [main], exitingjava.lang. NoClassDefFoundError: xxx/xxx/.../xxxPlugin at ...”。 图1 节点报错日志示例 CSS服务已下线自定义插件功能，但历史版本的集群可能还装有自定义插件，只有这类集群可能出现该故障。

问题现象 “集群状态”为“不可用”。 单击集群名称进入集群基本信息页面，选择“日志管理”，单击“日志查询”页签，可见日志内容存在警告“master not discovered or elected yet, an election requires at least 2 nodes with ids [xxx, xxx, xxx, ...], have discovered [xxx...] which is not a quorum”。 图1 节点报错日志示例

原因分析及处理方法 如果集群列表的任务状态显示“冻结”，可能是集群冻结状态导致集群不可用。 如果集群列表的任务状态显示“配置错误，重启失败”，可能是X-pack参数配置导致集群不可用。 如果集群节点的日志内容存在警告“master not discovered or elected yet, an election requires at least 2 nodes with ids [xxx, xxx, xxx, ...], have discovered [xxx...] which is not a quorum”，可能是安全组策略设置不合理导致集群不可用。 如果集群节点的日志内容存在明显的关于插件的报错“fatal error in thread [main], exitingjava.lang. NoClassDefFoundError: xxx/xxx/.../xxxPlugin at ...”，可能是插件不兼容导致集群不可用。 如果集群的健康状态为红色和且“unassigned shards”不为0，表示集群存在无法分配的索引分片，是分片未正常分配导致集群不可用。 如果集群进行备份恢复或集群迁移操作后，出现的不可用现象，可能是数据类型不兼容导致集群不可用。 如果集群节点的日志内容存在报错“OutOfMemoryError”和警告“[gc][xxxxx] overhead spent [x.xs] collecting in the last [x.xs]”，可能是集群负载过高导致集群不可用。

处理步骤 如果集群长期处于高负载状态，则集群会存在写入、查询缓慢等情形，建议根据业务需要升级节点规格或者对集群节点的数量和存储容量进行扩容，使集群更好的满足业务需求。升级节点规格、扩容节点数量和节点存储容量的指导请参见扩容Elasticsearch集群。 查询集群是否存在任务堆积。 方式一：在Kibana的“Dev Tools”页面，分别执行以下命令查询是否存在任务堆积。 GET /_cat/thread_pool/write?v GET /_cat/thread_pool/search?v 如下所示“queue”的值为非0，表示存在任务堆积。 node_name name active queue rejectedcss-0323-ess-esn-2-1 write 2 200 7662css-0323-ess-esn-1-1 write 2 188 7660css-0323-ess-esn-5-1 write 2 200 7350css-0323-ess-esn-3-1 write 2 196 8000css-0323-ess-esn-4-1 write 2 189 7753 方式二：在集群管理列表，单击集群操作列的“监控信息”查看监控指标，在集群监控信息页面查看集群的“Search队列中总排队任务数”和“Write队列中总排队任务数”，如果排队任务数值非0表示存在任务堆积。 图2 Write队列中总排队任务数示例 如果集群存在大量的任务堆积，则参考如下步骤优化集群。 在集群的“日志管理”页面查看节点日志，查看节点在OOM前是否存在大量慢查询日志记录，分析查询是否会对节点造成压力导致节点内存不足，如果存在则根据业务实际情况优化查询语句。 在集群的“日志管理”页面查看节点日志，查看节点日志是否有“Inflight circuit break”或“segment can't keep up”的报错信息，如果存在则可能是写入压力过大，对集群造成较大的压力导致熔断。需要查看监控信息，排查近期数据写入量（写入速率）是否存在激增，如果存在则根据业务实际情况合理安排写入高峰时间窗。 如果集群不存在任务堆积或者集群优化完依旧不可用，则执行下一步，查看集群是否压力过大。 查看集群是否压力过大。 在集群管理列表，单击集群操作列的“监控信息”查看监控指标，在监控信息页面查看CPU和堆内存相关指标，如“平均CPU使用率”和“平均JVM堆使用率”。如“平均CPU使用率”超过80%或“平均JVM堆使用率”高于70%，则说明集群当前压力较大。 图3 “平均CPU使用率”示例 如果集群压力过大，请降低客户端的请求发送速率或扩容集群。 如果集群压力正常或降低发送请求速率后集群依旧不可用，则执行下一步，查看集群是否存在大量缓存。 在Kibana的“Dev Tools”页面，执行以下命令查询集群是否存在大量缓存。 GET /_cat/nodes?v&h=name,queryCacheMemory,fielddataMemory,requestCacheMemory 如果返回结果中queryCacheMemory、fielddataMemory或requestCacheMemory的数值超过堆内存的20%，则表示缓存过大，可执行命令POST _cache/clear清除缓存。这些缓存数据是在数据查询时生成的，目的是为了加快查询速度，当缓存清除则可能使查询时延增加。 name queryCacheMemory fielddataMemory requestCacheMemory css-0323-ess-esn-1-1 200mb 1.6gb 200mb 每个节点的最大堆内存可以执行如下命令查询： GET _cat/nodes?v&h=name,ip,heapMax 其中，name为节点名称，ip为节点的IP地址。 如果排查优化后，集群依旧负载过高，则联系技术支持。

处理步骤 在Kibana的“Dev Tools”页面，执行命令GET _cluster/allocation/explain?pretty查看索引分片未分配的原因。 返回结果中显示索引名称“index” 和未分配解释“explanation” : “primary shard for this replica is not yet active”，表示分片副本未激活。 图1 索引分片未分配 尝试修改该索引的配置，执行命令将其副本数置为0。 PUT /index_name/_settings{ "number_of_replicas": 0} 返回信息“reason”中表示在恢复的数据中存在CSS集群不支持的数据类型。 图2 数据不兼容 根据问题根因，将数据中CSS集群不支持的数据类型删除或选择支持该数据类型的CSS集群版本，再进行备份恢复或数据迁移。

处理步骤 当出现9200端口访问失败错误时，且CSS集群状态为可用状态。执行步骤如下所示： 进入CSS服务管理控制台，在集群列表中，单击集群名称进入集群详情页面，查看此集群使用的VPC和子网。 进入VPC服务管理控制台，在虚拟私有云列表中，单击CSS集群使用的VPC名称，进入VPC详情页面。查看VPC和子网的网段信息。 如图1所示，VPC的网段信息，与子网的网段信息一致。在使用VPN专线访问或使用VPC对等连接访问时，会导致9200端口访问失败。 图1 查看网段信息 如果出现上述错误，请重新创建集群，并选择一个网段与VPC不同的子网，如不存在这样的子网，请在VPC管理控制台重新创建一个子网。 创建新的CSS集群后，将旧集群的数据迁移至新集群中，然后再通过VPN专线访问或使用VPC对等连接访问使用。 如果需要VPN专线访问或使用VPC对等连接访问CSS集群时，请务必保证，新创建的CSS集群，其VPC与子网，具备不同的网段信息。

原因分析 在“使用VPN专线访问CSS集群”或“通过VPC的对等连接访问CSS集群”场景下，其所在的客户端与CSS不在同一VPC下。因此，要求CSS集群的子网与其VPC具有不同的网段。 例如，某一CSS集群，选用的VPC为vpc-8e28，其网络配置为192.168.0.0/16。选用了此VPC下的子网subnet-4a81，subnet-4a81子网的网段与vpc-8e28一致，均为192.168.0.0/16。此时，如果使用VPN专线访问CSS集群或通过VPC的对等连接访问CSS集群，会导致此子网创建的机器内没有该VPC对应的网关，从而影响CSS服务的默认路由的设置，最终导致9200端口访问失败。

数据量很大，如何进行快照备份？ 如果快照数据量极大，快照备份要超过一天时，可参考如下方法进行优化。 快照备份的时候指定索引，比如先分批，默认是*，将会备份所有的索引。 使用自定义快照仓库。 创建自定义仓库。 除了使用 云搜索 服务提供的repo_auto之外，客户也可以自己创建一个仓库，接口见如下： PUT _snapshot/my_backup{ "type" : "obs", "settings" : { "bucket" : "css-backup-name", //桶名 "base_path" : "css_backup/711/", //备份路径 "chunk_size" : "2g", "endpoint" : "obs.xxx.com:443", //OBS域名地址 "region" : "xxx", //Region名称 "compress" : "true", "access_key": "xxxxx", //AK "secret_key": "xxxxxxxxxxxxxxxxx" //SK "max_restore_bytes_per_sec": "100mb", //OBS速度，默认是40MB,可以根据实际性能调大 "max_snapshot_bytes_per_sec": "100mb" }} 使用自定义仓库创建快照。 PUT _snapshot/my_backup/snapshot_name（快照名称）{ "indices": "*", //备份的索引，*表示索引，逗号分隔 "ignore_unavailable": true, //是否忽略单个index是否可用,true表示忽略 "include_global_state": false //默认false表示cluster state和其他的一些state不会保存下来} 查询快照状态。 GET _snapshot/my_backup/snapshot_name/_status 恢复自定义仓库中的索引。 POST /_snapshot/my_backup/snapshot_name/_restore{ "indices": "test-00000000000", "ignore_unavailable": true, "include_global_state": false, "rename_pattern": "(.+)", "rename_replacement": "$1"} 父主题： 功能使用类

参考 TCP长连接和短连接 TCP协议中有长连接和短连接之分。短连接在数据包发送完成后会自己断开，长连接在发包完成后， 会在一定的时间内保持连接，即通常所说的Keepalive（存活定时器）功能。 TCP保活机制 保活机制是由一个保活计时器实现的。当计时器被激发，连接一端将发送一个保活探测报文， 另一端接收报文的同时会发送一个ACK作为响应。 如果客户端无响应，服务器将中断连接，否则会重置保活计时器。 服务器端Keepalive设置时间30m，Linux有三个参数可以控制保活时间： tcp_keepalive_time（开启Keepalive的闲置时长）、 tcp_keepalive_intvl（Keepalive探测包的发送间隔）、tcp_keepalive_probes （如果对方不予应答，探测包的发送次数）。 http-keepalive http-keepalive是保证一个TCP连接尽可能传递多的报文，每次交互一个报文后就会更新http-keepalive时间。如果http-keepalive时间超时，意味这个这段时间client和server没有报文交互，本端会主动关闭释放连接。 tcp-keepalive是一种探测TCP连接状态的保活机制，TCP连接建立后如果不主动关闭，client和server没有发生异常，这个连接理论上是一直存在的，http-keepalive是保证一个TCP连接上尽可能传递更多的报文，如果http-keepalive时间内没有报文交互则会主动关闭连接。

问题现象 云搜索服务的Elasticsearch集群执行命令update-by-query，出现报错“Trying to create too many scroll contexts.” ，具体报错信息如下： {"error":{"root_cause":[{"type":"exception","reason":"Trying to create too many scroll contexts. Must be less than or equal to: [100000]. This limit can be set by changing the [search.max_open_scroll_context] setting."},{"type":"exception","reason":"Trying to create too many scroll contexts. Must be less than or equal to: [100000]. ......

处理步骤 执行如下命令，查看“open_contexts”的参数值即为当前scroll contexts的数目。 GET /_nodes/stats/indices/search 当数目达到最大值时，可以通过以下两种方式解决。 方式一：删除无用的scroll，释放scroll contexts的存储空间。 DELETE /_search/scroll{ "scroll_id" : "DXF1ZXJ5QW5kRmV0Y2gBAAAAAAAAAD4WYm9laVYtZndUQlNsdDcwakFMNjU1QQ=="} 方式二：调整“search.max_open_scroll_context”的值，增加scroll contexts的存储空间。 PUT /_cluster/settings{"persistent" : {"search.max_open_scroll_context": 2012345678},"transient": {"search.max_open_scroll_context": 2012345678}}

处理步骤 步骤一：确认集群不可用原因 通过Kibana接入故障集群，在Kibana的“Dev Tools”页面，执行命令GET /_recovery?active_only=true查看集群是否在进行副本恢复： 返回“{"index_name":{"shards":[{"id":25,"type":"...”，代表集群存在正在进行副本恢复的索引。等待副本恢复完毕，如果集群状态仍为“不可用”，则执行下一步。 返回“{ }”：代表集群未进行副本恢复，则执行下一步。 执行命令GET _cluster/allocation/explain?pretty查看索引分片未分配的原因，根据返回信息进行筛选。 表1 参数说明 参数 描述 index 索引名称 shard 分片标号 current_state 分片当前状态 allocate_explanation 分片分配解释 explanation 解释说明 表2 不同故障说明 现象 原因 处理步骤 “explanation”中存在“no allocations are allowed due to cluster setting [cluster.routing.allocation.enable=none]” 集群当前设置的allocation策略禁止所有分片分配。 参考“shard allocation策略配置错误”之▪cluster.routing.allocat... “explanation”中存在“too many shards [3] allocated to this node for index [write08]index setting [index.routing.allocation.total_shards_per_node=3]” 集群当前设置的单个索引的分片允许分配给每个数据节点的分片数值过小，不满足索引分片的分配要求。 参考“shard allocation策略配置错误”之▪index.routing.allocatio... “explanation”中存在“too many shards [31] allocated to this node, cluster setting [cluster.routing.allocation.total_shards_per_node=30]” 集群当前设置的集群所有索引分片允许分配给每个数据节点的分片数值太小。 参考“shard allocation策略配置错误”之▪cluster.routing.allocat... “explanation”中存在“node does not match index setting [index.routing. allocation. include] filters [box_type:"hot"]” 索引分片需要下发到标记为“hot”的数据节点，而集群中所有数据节点都没有打这个标记时，分片无法下发。 参考“shard allocation策略配置错误”之▪index.routing.allocatio... “explanation”中存在“node does not match index setting [index.routing. allocation. require] filters [box_type:"xl"]” 索引分片需要下发到特定标记的数据节点，而集群中所有节点都没有打这个标记时，分片便无法下发。 参考“shard allocation策略配置错误”之▪index.routing.allocatio... “explanation”中存在“[failed to obtain in-memory shard lock]” 这种情况一般出现在有节点短暂离开集群，然后马上重新加入，并且有线程正在对某个shard做bulk或者scroll等长时间的写入操作，等节点重新加入集群的时候，由于shard lock没有释放，master无法allocate这个shard。 参考•shardlock错误 “explanation”中存在“node does not match index setting [index.routing.allocation.include] filters [_tier_preference:"data_hot OR data_warm OR data_cold"]” 集群的某个索引设置的参数与版本不匹配。 参考•索引参数版本不匹配 “explanation”中存在“cannot allocate because all found copies of the shard are either stale or corrupt” 集群的索引分片数据被损坏。 参考“主分片数据损坏”•主分片数据损坏 “explanation”中存在“the node is above the high watermark cluster setting [cluster.routing. allocation. disk.watermark.high=90%], using more disk space than the maximum allowed [90.0%], actual free: [6.976380997419324%]” 节点的磁盘使用率已超过磁盘空间允许的最大值。 参考“磁盘使用率过高”•磁盘使用率过高 步骤二：根据不同的问题现象处理故障 shard allocation策略配置错误 cluster.routing.allocation.enable参数 返回结果中“explanation”如下，表示集群当前设置的allocation策略禁止所有分片分配导致。 图3 allocation.enable参数配置错误 在Kibana的“Dev Tools”页面，执行命令将“enable”设置为“all”，允许所有分片进行分配。 PUT _cluster/settings{ "persistent": { "cluster": { "routing": { "allocation.enable": "all" } } }} index级别会覆盖cluster级别配置，参数设置含义如下： all - (默认) 所有类型均允许allocation。 primaries - 只允许allocation主分片。 new_primaries - 只允许allocation新创建index的主分片。 none - 所有的分片都不允许allocation。 再执行命令POST _cluster/reroute?retry_failed=true手动进行分片分配，等待索引分片分配完成，集群状态变为可用。 index.routing.allocation.total_shards_per_node参数。 返回结果中“explanation”如下，表示设置的“index.routing.allocation.total_shards_per_node”值过小，不满足索引的分片分配要求。 图4 index total_shards_per_node设置错误 在Kibana的“Dev Tools”页面，执行命令修改索引在每个节点允许分配的分片数。 PUT index_name/_settings{ "index": { "routing": { "allocation.total_shards_per_node": 3 } }} “index.routing.allocation.total_shards_per_node”的值 = index_name索引分片数 / (数据节点个数 - 1) 参数值应设置稍微大一些，假设集群有10个节点，其中5个数据节点，2个client节点，3个master节点，有个索引的分片数为30，如果将total_shards_per_node值设为4，能分配的shard总数只有4*5=20，分片无法完全分配。5个数据节点，需要分配30个分片，每个节点应最少分配6个分片，防止某数据节点故障脱离，那最少应设置每个节点允许分配8个分片。 再执行命令POST _cluster/reroute?retry_failed=true手动进行分片分配，等待索引分片分配完成，集群状态变为可用。 cluster.routing.allocation.total_shards_per_node参数。 返回结果中“explanation”如下，表示集群允许分配给每个数据节点的分片数设置太小。 图5 cluster total_shards_per_node设置错误 “cluster.routing.allocation.total_shards_per_node”参数为限制集群每个数据节点可分配的分片数量，此参数默认设置为“1000”，在Kibana的“Dev Tools”页面执行如下命令设置“cluster.routing.allocation.total_shards_per_node”参数。 PUT _cluster/settings{ "persistent": { "cluster": { "routing": { "allocation.total_shards_per_node": 1000 } } }} 出现此场景大多数是参数使用错误，误将“index.routing.allocation.total_shards_per_node”参数设置为“cluster.routing.allocation.total_shards_per_node”参数。执行如下命令可以设置“index.routing.allocation.total_shards_per_node”参数： PUT index_name/_settings{ "index": { "routing": { "allocation.total_shards_per_node": 30 } }} 两个参数都是限制单个数据节点所能分配的最大分片数。 “cluster.routing.allocation.total_shards_per_node”是集群级别的分片限制。 “index.routing.allocation.total_shards_per_node”是索引级别的分片限制。 再执行命令POST _cluster/reroute?retry_failed=true手动进行分片分配，等待索引分片分配完成，集群状态变为可用。 index.routing.allocation.include参数。 返回结果中“explanation”如下，表示是将索引分片下发到标记为“hot”的数据节点，而集群中所有数据节点都没有打这个标记时，分片无法下发。 图6 include参数配置错误 在Kibana的“Dev Tools”页面执行命令取消该配置： PUT index_name/_settings{ "index.routing.allocation.include.box_type": null} 再执行命令POST _cluster/reroute?retry_failed=true手动进行分片分配，等待索引分片分配完成，集群状态变为可用。 index.routing.allocation.require参数。 返回结果中“explanation”如下，表示是将分片下发到特定标记的数据节点，而集群中所有节点都没有打这个标记时，分片便无法下发。 图7 require参数配置错误 在Kibana的“Dev Tools”页面执行命令取消该配置： PUT index_name/_settings{ "index.routing.allocation.require.box_type": null} 再执行命令POST _cluster/reroute?retry_failed=true手动进行分片分配，等待索引分片分配完成，集群状态变为可用。 shard lock错误 返回结果中“explanation”存在“[failed to obtain in-memory shard lock]”，这种情况一般出现在有节点短暂离开集群，然后马上重新加入，并且有线程正在对某个shard做bulk或者scroll等长时间的写入操作，等节点重新加入集群的时候，由于shard lock没有释放，master无法allocate这个shard。 此现象不会造成分片数据丢失，只需要重新触发一下分配即可。在Kibana的“Dev Tools”页面执行命令POST /_cluster/reroute?retry_failed=true手动对未分配分片进行分配，等待索引分片分配完成，集群状态变为可用。 索引参数版本不匹配 返回信息中的索引名称“index”和索引未分配解释“explanation ”: “node does not match index setting [index.routing.allocation.include] filters [_tier_preference:"data_hot OR data_warm OR data_cold"]”，表示集群的某个索引设置的参数与节点不匹配。 图8 索引参数不匹配 执行命令 GET index_name/_settings查看索引配置，返回结果中是否存在不符合自身版本的索引特性。 图9 索引设置 以index.routing.allocation.include._tier_preference特性为例，当前集群是7.9.3版本，这个索引特性是在7.10版本之后才支持的，低版本集群使用该特性将无法分配索引的分片，导致集群不可用。 确定集群是否必须使用该不匹配的特性。 是，创建与所需索引特性相匹配的版本集群，然后将老集群的数据通过备份恢复至新集群。 否，执行下一步。 执行命令去除索引中不符合集群版本的特性。 PUT /index_name/_settings{ "index.routing.allocation.include._tier_preference": null} 执行命令POST /_cluster/reroute?retry_failed=true手动对未分配分片进行分配，等待索引分片分配完成，集群状态变为可用。 主分片数据损坏 返回信息中的索引名称"index"、分片标号"shard"、分配解释"allocate_explanation" 和"store_exception":"type":"corrupt index exception"，表示集群的某个索引的某个分片数据被损坏。 图10 索引数据损坏 当索引数据被损坏或者某个分片的主副本都丢失时，为了能使集群恢复green状态，解决方法是划分一个空shard，执行以下命令划分空分片并指定分配的节点。 POST /_cluster/reroute{ "commands" : [ { "allocate_empty_primary" : { "index" : "index_name", "shard" : 2, "node" : "node_name", "accept_data_loss":true } } ]} 一定要谨慎该操作，会导致对应分片的数据完全清空。 索引分片重新分配后，集群状态恢复可用。 磁盘使用率过高 返回结果如下，其中“allocate_explanation”表示该索引的分片无法分配给任何数据节点，“explanation”表示节点磁盘使用率已超过磁盘空间允许的最大值。 图11 explain查询结果 磁盘使用率超过85%：会导致新的分片无法分配。 磁盘使用率超过90%：集群会尝试将对应节点中的分片迁移到其他磁盘使用率比较低的数据节点中。无法迁移时系统会对集群每个索引强制设置“read_only_allow_delete”属性，此时索引将无法写入数据，只能读取和删除对应索引。 磁盘使用率过高时可能会发生节点脱离，后续节点自动恢复后也可能会因为集群压力过大，监控调ES接口查询集群状态时无响应，无法及时更新集群状态导致集群状态为不可用。 增加集群可用磁盘容量。 在Kibana的“Dev Tools”页面，执行命令DELETE index_name清理集群的无效数据释放磁盘空间。 临时降低索引副本数，待扩容磁盘容量或扩容节点完成后改回索引副本数。 在Kibana的“Dev Tools”页面，执行命令临时降低索引副本数。 PUT index_name/_settings{ "number_of_replicas": 1} 如果返回结果如下： 图12 索引read-only-allow-delete状态 则是因为磁盘使用率已超过磁盘空间允许的最大值，集群所有索引被强制设置“read_only_allow_delete”属性，先执行命令将该属性值置为“null”，再执行2.a的命令降低索引副本数。 PUT /_settings{ "index.blocks.read_only_allow_delete": null} 参考扩容对集群进行节点数量或节点存储容量进行扩容。 待扩容完成后再执行2.a改回索引副本数，待索引分片完全分配后，集群状态变为可用。

原因分析 导致出现I/O Reactor STOPPED的原因，大致可以分为以下3类： 回调中抛出异常导致。 客户端并发太高导致。 在日志中发现异常后，查看ElasticSearch集群监控指标，如CPU使用率、网络连接数等。 当用户集群配置为5台16U128G的i3.4xlarge.8节点时，且每天上午5点左右会做大量bulk操作，写入大概100G-200G的数据，根据集群监控指标的CPU使用率、网络流入流出速率来看对ElasticSearch节点造成不了压力，网络连接数较高，其它节点情况也相同。但是，有的节点网络连接数高达近9000，5个节点瞬间有将近5万连接数，用户的代码大致是用同一个Rest Client多个线程并发且调用HLRC的bulkAsync接口。客户端一个节点，单是ES的连接就消耗了4-5万个连接数，这种情况很容易造成客户端节点句柄数耗尽，或者连接数耗尽。 ElasticSearch的Rest client导致。建议ElasticSearch完善Rest client，添加exception handler。 Apache（HLRC和LLRC都使用了Apache HTTPComponents Async Client）手册中提到，在与会话通道交互过程中有些I/O异常是可以预料的，这些异常可能会导致单个session终止，但不会影响I/O Reactor和其他session。但某些情况下，当I/O Reactor本身遇到内部问题时，例如底层NIO的一些类中的I/O异常或者没被handle的一些Runtime Exception。这些异常是致命的，会使I/O Reactor关闭。Apache官方建议重写IOReactorExceptionHandler接口。 图3 重写IOReactorExceptionHandler接口 但是尝试了重写ExceptionHandler并放到HLRC的配置中，并通过在回调中抛出异常来模拟异常场景，最后发现这种回调的异常并不会被IOReactorExceptionHandler捕获，运行脚本后也没有异常抛出，所以此处IOReactorExceptionHandler的实现并不好验证。通过ElasticSearch社区issue中其他开发者的验证，添加了IOReactorExceptionHandler后跑很久也不会有问题。所以建议添加IOReactorExceptionHandler，但是注意不要忽略所有异常。 Elasticsearch Rest Client需要有一个exception handler，而不是让用户通过设置IOReactorExceptionHandler来处理异常，且这种方式也不会解决所有的异常。

问题现象 “集群状态”为“不可用”。 在Kibana的“Dev Tools”页面，执行命令GET _cluster/health查看集群健康状态，结果中“status”为“red”，“unassigned_shards”不为0。或者在“Cerebro”可视化页面，单击“overview”查看索引分片在各数据节点的分配情况，可见集群状态为红色和“unassigned shards”不为0，表示集群存在无法分配的索引分片。 图1 集群健康状态 图2 cerebro可视化界面

I/O Reactor STOPPED是什么问题？ 首先根据调用栈可以定位到报错来自CloseableHttpAsyncClientBase中的90行，如下图所示： ensureRunning()方法是在每次请求执行开始的时候调用，用来确认client状态是否为ACTIVE，如果不是ACTIVE，则会报错。然后观察CloseableHttpAsyncClientBase中的status何时会变成STOPPED，发现有且仅有两处会set为STOPPED，如下图所示： 图1 第一处STOPPED 图2 第二处STOPPED 由于客户不会手动关闭客户端之后再调用接口，所以有且仅有第一处会导致status切换为STOPPED状态。 对于第一处STOPPED，reactorThread线程是用来在io events发生时调度io events，当内部抛出异常时，最终会将status改为STOPPED状态。然后在bulkAsync请求的回调中抛出异常验证status的状态切换，如下图所示： 当请求失败，status会切换为STOPPED且I/O Reactor将关闭，并使HLRC实例卡住。后续使用该HLRC实例调用任何请求都会失败。此处手动抛出异常是为了复现问题，生产环境中很难分辨是什么原因导致I/O Reactor关闭。

快照仓库找不到 在云搜索服务的“集群管理”页面上，单击集群“操作”列的“Kibana”访问集群。 在Kibana的左侧导航中选择“Dev Tools”，单击“Get to work”，进入Console界面。 Console左侧区域为输入框，右侧为结果输出区域，为执行命令按钮。 执行命令GET _snapshot/_all返回为空，或者执行命令GET _snapshot/repo_auto/_all返回如图1提示错误，这个表示没有设置快照。需要重新修改快照配置信息。 图1 返回信息 单击集群名称，进入集群基本信息页面，选择“集群快照”，进入集群快照页面。 单击“基础配置”后面的，修改基础配置。 修改完成后，单击“确定”。 如果保存后还不能生效，可以尝试修改下备份路径，换一个不一样的值保存然后再修改回来。 父主题： 功能使用类

解决方案 建议根据实际情况调整客户端的并发写入请求数（调整到一个合适的阈值），另外被rejected的http请求ES-Hadoop是有重试机制的，可修改以下参数: “es.batch.write.retry.count”：默认重试3次。 “es.batch.write.retry.wait”：每次重试等待时间10s。 如果对查询的实时性级别要求不高的话，可以调整下分片刷新的时间（默认是每秒刷新一次），提高写入速度。 PUT /my_logs{"settings": {"refresh_interval": "30s"}}

处理步骤 针对filebeat.yml配置文件做参数优化，调整input端配置： #根据实际情况调大harvester_buffer_size参数（该参数是指每个harvester监控文件时，使用的buffer大小）。harvester_buffer_size:40960000#根据实际情况调大filebeat.spool_size参数（该参数是指spooler的大小，一次Publish，上传多少行的日志量）。filebeat.spool_size:250000#根据实际情况调整 filebeat.idle_timeout参数（该参数是指spooler的超时时间，如果到了超时时间，不论是否到达容量阈值，spooler会清空发送出去）。filebeat.idle_timeout:1s 针对filebeat.yml配置文件做参数优化，调整output.elasticsearch端配置： #根据实际情况将worker参数调整为跟ES个数一致（该参数是指对应ES的个数，默认1）。worker:1#根据实际情况调大bulk_max_size参数（该参数是指单个elasticsearch批量API索引请求的最大事件数，默认是50）。bulk_max_size:15000#根据实际情况调整flush_interval参数（该参数是指新事件两个批量API索引请求之间需要等待的秒数，如果bulk_max_size在该值之前到达，额外的批量索引请求生效）。flush_interval:1s