《Elastic Stack 实战手册》——四、应用实践——4.2 可观测性应用场景 ——4.2.2.Elasticsearch智能巡检开发设计实践(1) https://developer.aliyun.com/article/1226096
指标分析
cluster 层面指标分析
cluster status
集群健康状态，检测到集群状态非 green，则说明巡检异常结果未处理，或者突发情况导致，此时巡检的意义是快速的给出推荐解决方案，让运维、集群 owner（开发）能够有处理的方案，并非一味依赖告警等待运维处理，最大限度的减少异常带来的影响；
非 green 状态下，首先检查的是节点个数是否符合预期，节点数量正常情况下，通常通过
explain API进行分析。
GET /_cluster/allocation/explain { "index":"index_name", "shard": 1, "primary":false }
分片 allocation 是通过分配器和决策器来决定的，explain API 通过决策器的信息来体现
unassigned shard 的异常原因，allocation 原理图如下：
详细流程图链接：https://www.processon.com/view/link/5f43b268e401fd5f24852544
该部分只要非 green 状态即为异常，智能巡检系统会分析出异常原因，并给出推荐解决方案到最终的报告中，如果是出现 red 场景或者 OOM 导致掉节点场景，则会由告警平台即时通知到用户和 OPS，用户和 OPS 可以通过在 PAAS 平台记录的报告，快速查看状态异常的分析；由于巡检系统非实时，可以手动触发智能巡检系统，快速得到最新分析报告与推荐解决方案。
推荐解决方案由两部分组成：
1、一些特定场景分析后的经验建议。
2、该集群所有unassigned shard通过explain API的查到的结果集。
pengding_task
pending_task 反应了 master 节点尚未执行的集群级别的更改任务（例如：创建索引，更新映射，分配分片）的列表。pending_task的任务是分级别的（优先级排序：IMMEDIATE>URGENT>HIGH>NORMAL>LOW>LANGUID），只有当上一级别的任务执行完毕后，才会执行下一级别的任务，即当出现 HIGH 级别以上的 pending_task 任务时，备份和创建索引等低级别任务将延迟执行。
pending_task 过多会给 master 节点造成压力，大集群（大数据量、高并发）情况下，容易造成节点被踢出集群，甚至集群不响应的情况。pending_task 积压的场景一般出现在大集群中，由于 task 不能快速处理完，会长时间处于积压状态，且会越积压越多，所以异常阈值可以设置一个较大值，根据经验值，设置 pending_task 数量大于 100 为异常；
GET _cat/pending_tasks
节点最大 cpu_util 与最小 cpu_util 之差（极差）
cpu_util 是判断 Elasticsearch 集群健康程度的重要指标，直接影响集群的吞吐量、请求的响应时间。一般情况下集群各个节点 cpu_util 普遍过高的场景比较好处理，增加配置即可让集群恢复健康状态。
而单节点/部分节点出现 cpu_util 过高的情况则不容易定位，如 shard 分配不均匀、routing 设置不合理、宿主机异常都有可能引发该现象，且可能在程序上线一段时间后才出现，这时巡检结果对预警与分析有重大意义。
GET _cat/nodes?h=ip,cpu
为了能够有效起到预警作用，cpu_util 极差的阈值不宜过大，同时应该考虑到角色分离、冷热分离等场景，将极差的计算范围限制到同角色节点之间。
data节点最大 qps 与最小 qps 之差（极差）
节点 qps 指标受到 shard 分配、routing 的影响，极差过大代表集群数据分配不均，或有参数干预，集群负载不均衡。
为该指标设置阈值时，同样需要考虑到角色分离场景，同时由于业务的不同，不同集群 qps 相差巨大，可以通过换算成瞬时流量的百分比来做极差计算。
GET /_nodes/stats/indices,ingest/search
一次 bulk 请求的数量
bulk 请求适用于大写入场景，由于减少了大量的连接，bulk 的效率远高于单条 index。一次 bulk 请求涉及到的 doc 数量对性能有较大影响，过小容易造成线程池堆积，过大容易造成超时。
该指标的阈值设置，仅针对写入/更新频率较大的集群，由于集群配置的差异，可给每个配置区间内设置一个最小值作为巡检的阈值。
node 层面指标分析
uptime
集群节点重启往往是对集群性能有着较大影响，接收到的流量会异常，同时减少了一部分吞吐量，对于大集群而言，重建缓存、shard allocation 会对集群的响应造成影响。集群重启的原因以及重启带来的影响对于集群都是一个隐患。
GET _cat/nodes?h=ip,name,node.role,master,uptime
如果启动时间距离当前时间 1h 以内，则节点发生重启，提示用户检查重启原因、评估带来的影响。
free_disk
磁盘剩余空间最直观的就是影响数据写入，到达水位线（默认95%）后会进入 read only 状态，其次磁盘空间还会带来其他隐患，比如无法操作 forcemerge、甚至 deleteByQuery 也无法完成等。
GET _cat/allocation
出于成本与利用率的考虑，预期状态磁盘占比不应过低，一般 50% 以内为安全值，由于不同集群的特性可能会有差异，可以设置 70% 作为异常阈值。
cpu_util
CPU 对集群性能影响极大，高 CPU 的场景下，响应时间增加，可能出现大量超时（读写异常）。所以需要平衡 cpu 利用率（一般通过超分、调整配置两种方式）。
GET _cat/nodes?h=ip,name,cpu
出于成本与利用率的考虑，预期状态磁盘占比不应过低，一般 50% 以内为安全值，由于不同集群的特性可能会有差异，可以设置 70% 作为异常阈值。
cpu_util
CPU 对集群性能影响极大，高 CPU 的场景下，响应时间增加，可能出现大量超时（读写异常）。所以需要平衡 cpu 利用率（一般通过超分、调整配置两种方式）。
GET _cat/nodes?h=ip,name,cpu
由于业务流量存在周期性波峰波谷，所以阈值需要在安全范围内尽量设置大一点，例如设置阈值为 "cpu_util = 90%"。
node上shard数
节点未分配 shard，则需要确认资源容量分配是否合理，该指标主要针对分片设置不合理导致的资源浪费。一般发生在分片数量设置不合理、迁移过程（存在 exclude）的场景下。故阈值可以设置为 "count(shard) = 0"。
GET _cat/allocation
shard层面指标分析
number
过多或过少的 shard 在一定场景下都会影响查询和写入性能。官方建议的合理的设置数量：每GB 的 heap 不超过 20个 shards; 比如 20GB heap，400个 shards, 30GB heap，不超过 600个shards。Elasticsearch 7.0 版本开始，集群中每个节点默认限制 1000个shard。
阈值按照官方建议值设定即可。
GET _cat/shards?h=index,shard,prirep,state,docs,store,ip,node
size of per shard
大量的小 shard 会影响写入和查询性能，且在同数据量情况下占用更多的内存和磁盘。单
shard 过大则有更多的弊端，例如查询耗时变长、不易于恢复、迁移、容易造成集群压力不均衡等。
通常单个 shard 的大小建议在 10GB - 65GB 之间 （经验值参考：搜索类控制在 20GB，日志类控制在 50BG），查询 API 同上。
官方建议shard size、count值参考：
https://www.elastic.co/guide/en/elasticsearch/reference/current/size-your-shards.html
《Elastic Stack 实战手册》——四、应用实践——4.2 可观测性应用场景 ——4.2.2.Elasticsearch智能巡检开发设计实践(3) https://developer.aliyun.com/article/1226092
