生产运维技巧

一起来玩Elasticsearch，加我微信：wx1250134974

Elasticsearch认证复习准备

 

 

生产运维技巧：

PUT _cluster/settings #设置整各类熔断器限制，避免发生OOM

{

  "persistent": {

    "indices.breaker.total.limit": "40%"

  }

}

 

 

PUT _cluster/settings #增加搜索队列，防止出现reject报错。有些版本不是动态的

{

  "transient": {

    "threadpool.search.queue_size":2000

  }

}

 

POST _cache/clear  #临时清空节点上的缓存，降低OOM概率

 

PUT _cluster/settings #再平衡移动分片的并发数，防止对集群性能的影响

{

  "transient": {

    "cluster.routing.allocation.cluster_concurrent_rebalance": 2

  }

}

PUT _cluster/settings #每个节点恢复的并发分片数控制，防止对集群性能影响

{

  "transient": {

    "cluster.routing.allocation.node_concurrent_recoveries": 5

  }

}

 

PUT _cluster/settings #分片恢复时每秒的最大字节数

{

  "transient": {

    "indices.recovery.max_bytes_per_sec": "80mb"

  }

}

 

 

PUT _cluster/settings  #单个节点上恢复的并发流，有些版本不支持动态修改

{

  "transient": {

    "indices.recovery.concurrent_streams": 6

  }

}

 

 

PUT _cluster/settings #下线某个节点或者维护某个节点前执行，可提前将该节点数据移走，防止集群变黄、红

{

  "transient": {

    "cluster.routing.allocation.exclude._ip": "127.0.0.1"

  }

}

 

 

POST _cluster/reroute  #热点分片移动

{

  "commands": [

    {

      "move": {

        "index": "index_name",

        "shard": 0,

        "from_node": "node_name_1",

        "to_node": "node_name_2"

      }

    }

  ]

}

 

POST _cluster/reroute # Fore the allocation of an unassinged shard with a reason

{

  "commands": [

    {

      "move": {

        "index": "index_name",

        "shard": 0,

        "from_node": "node_name_1",

        "to_node": "node_name_2"

      }

    }

  ]

}

 

 

POST _flush/synced # Force a synced flush

 

 

##full restart################################

暂停数据写入

关闭集群的shard allocation

PUT _cluster/settings

{

  "transient": {

    "cluster.routing.allocation.enable":"none" #关闭分片在分配

  }

}

 

手动执行 POST /_flush/synced

重启节点

重新开启集群的shard allocation

PUT _cluster/settings

{

  "transient": {

    "cluster.routing.allocation.enable":"all" #开启分片在分配

 

  }

}

等待recovery完成，当集群的health status是green后

重新开启数据写入

##full restart##########################

 

 

 

 

 

PUT _cluster/settings  #关闭自动映射

{

  "persistent": {

    "action.auto_create_index": false

  }

}

 

PUT _cluster/settings #可明确开启需要自动创建的索引

{

  "persistent": {

    "action.auto_create_index": ".monitoring-*,logstash-*"

  }

}

 

#ES7.x可以使用ES6.X的索引，ES5.X可以使用ES2.X的索引 。备份恢复的时候注意

 

GET _nodes/stats/breaker?  #查看集群当前熔断器的触发情况

 

 

#内存和存储比例建议，内存只得是jvm，因此最大是31G

1:16 搜索类应用 因此磁盘大约为500G性能最佳，若存储数据量1T，副本1T则2T/500 约5个节点

1:48~1:96  日志类应用 因此磁盘大约为 1600G性能最佳，若存储数据量1T，副本1T则2T/1600 约2个节点

 

#磁盘建议

推荐使用ssd，

推荐使用raid0,可以不用raid10

在旋转磁盘上建议设置index.merge.scheduler.max_thread_count:1

trim SSD硬盘:

https://www.elastic.co/cn/blog/is-your-elasticsearch-trimmed

 

#认证和授权

推荐搭建认证和授权功能x-package或者search_guard

如果内网使用ES可以不配置https及节点间加密通信

audit logs审计日志按需打开

 

#建议开启慢查询日志，支持索引模板统一设定、query和fetch分开定义

PUT twitter/_settings

{

  "settings": {

    "index.search.slowlog.threshold": {

      "query.warn": "10s",

      "query.info": "3s",

      "query.debug": "1s",

      "query.trace": "0s",

      "fetch.warn": "1s",

      "fetch.info": "600ms",

      "fetch.debug": "400ms",

      "fetch.trace": "0s"

    }

  }

}

 

 

############集群非绿色的处理方式#############

https://mp.weixin.qq.com/s/7pWdS_zPDNiXKzrUOCTVfg

#查看不同状态索引

GET _cat/indices?v&health=red

GET _cat/indices?v&health=yellow

GET _cat/indices?v&health=green

#查看所有索引分片或者指定索引分片的状态信息

GET /_cat/shards?v&h=node,index,shard,prirep,state,store,sc,unassigned.reason,unassigned.details&s=sto,index&index=chat,allfoods&

 

#查看某分片未正常分配的原因

GET /_cluster/allocation/explain

{

  "index": "chat",#索引

  "shard": 0, #分片

  "primary": false #不是主分片

}

 

#将副本设置为0。删除所有副本，针对场景：也许你无法修复副本或手动移动或分配它。

在这种情况下，只要拥有主分片（健康状态为黄色，而不是红色），就可以始终使用以下命令将副本数设置为0，等待一分钟，然后再设置为1或任意你业务场景需要设置的值。

PUT chat/_settings

{

  "index": {

    "number_of_replicas": 0

  }

}

 

#手动分配分片，借助 reroute API。move 移动分片 和 allocate_replica 分配副本两个操作。

POST /_cluster/reroute

{

  "commands": [

    {

      "move": {

        "index": "test",

        "shard": 0,

        "from_node": "node1",

        "to_node": "node2"

      }

    },

    {

      "allocate_replica": {

        "index": "test",

        "shard": 1,

        "node": "node3"

      }

    }

  ]

}

 

#设置分片优先分配到hot类型的 机器s 上去

PUT mytest

{

  "settings": {

    "number_of_shards": 2,

    "number_of_replicas": 1,

    "index.routing.allocation.require.box_type": "hot"

  }

}

 

 

 

 

#分片没有分配的一些原因

INDEX_CREATE：正在创建索引没有完成之前，会有短暂的red，其实没问题

CLUSTER_RECOVER:集群重启完成前，会有这个问题

INDEX_REOPEN:重新open一个之前close的索引

DANGLING_INDEX_IMPORTED:一个节点离开集群期间，有索引被删除，节点重返会会有Dangling问题，直接删除Dangling的索引即可

是否有节点离线，重启离线的节点即可

索引配置是否有问题，比如错误的box_type、错误的副本数等

磁盘空间是否过高，比如85%的使用率。增加节点或者调整下磁盘水位

是在找不到原因，重新导入数据

 

 

 

 

############集群非绿色的处理方式#############

 

 

 

#Elasticsearch监控实现参考

https://help.aliyun.com/document_detail/90391.html

 

 

#提高集群写入性能

1客户端：用bulk并且多并发，需要亲自测试并发线程数和bulk大小，并且需要处理失败的重试操作。同时轮询所有节点不要只用一个节点

2服务端：服务器硬件越好越快，一般瓶颈在磁盘，可使用ssd

3mapping：禁用动态mapping，防止不规范的mappint对性能影响大； 可参看“2-Elasticsearch基础入门-优化点”进行index属性设置、refresh、translog设置；

4尽量不用嵌套和父子关系提升读性能

5不使用script查询计算，可提前处理

6多使用filter避免算分

7聚合操作尽量降低聚合的文档数量

8尽量避免使用通配符查询

9避免分片过多

10控制单个分片大小20-40G

11基于时序的索引进行merge降低segment数量提升查询性能

 

#ES缓存类型

1. Node Query Cache

每个节点一个且所有shard共享，只缓存Filter Context，缓存采用LRU算法。缓存的是Segment的命中结果，Segment合并后失效，

静态配置参考:

indices.querys.cache.size:”10%”

index.queries.cache.enabled:true

 

 

1. Shard Query Cache

缓存每个分片的查询结果，之缓存size=0的结果，且使用LRU算法，以查询JSON为key。分片ReFresh时失效，因此对于实时性要求不高的场景，尽量降低ReFresh操作

静态配置参考：

indices.requests.cache.size:”1%”

 

1. Fielddata Cache

除了Text类型，默认都采用doc_values数据结构解决内存，Text只有打开Fielddata才能进行聚合操作。Segment合并后会失效

配置参考：

indices.fielddata.cache.size  尽量配置小写，防止出现GC（默认无限制）

 

 

#内存诊断

GET _cat/nodes?v  #查看内存cpu等使用情况

GET _cat/nodes?help #查看内存cpu等使用情况

 

#常见内存问题

1. Segments过多，导致full GC

现象：集群整体响应缓慢，但没有过多的读写操作，并且发现持续进行full GC

分析：查看ES内存使用情况，发现segments.memory占用空间大

解决：通过force merge，把segments合并成一个

建议：merge后问题未能解决，可以考虑扩容

merge操作：index没有写入操作后进行MERGE可提升查询速度减少内存开销

POST INDEX/_forcemerge?max_num_segments=1

GET _cat/segments/INDEX?v

index.merge.policy.max_merged_segment配置合理些默认5G超过大小后，不在进行merge，可以降低merge时间。

index.merge.policy.segments_per_tier,默认10，越小合并月频繁，增大可降低合并频率。

 

1. Field data cache 过大，导致full GC

现象：集群整体响应缓慢，读写不到，但节点持续FULL GC

分析：查看ES内存使用，发现fielddata.memory.size 占用空间很大

解决：将indices.fielddata.cache.size设小，重启节点，堆内存恢复正常

建议：Field data cache尽量设置小一些，如果业务有需要，可以通过库容解决

 

 

1. 复杂嵌套聚合，导致集群full GC

现象：节点响应缓慢，持续进行FUll GC

分析：Dump分析，发现内存中存在大量bucket对象，查看日志发现复杂嵌套聚合

解决：优化聚合

建议：尽量降低进行嵌套聚合的数据量。如果业务确实需要，则进行扩容并且设置熔断器和search.max_buckets的数值保证集群稳定性

 

 

#各种断路器设置，保证集群稳定性

1. Parent circuit breaker:设置所有熔断器可用内存总量
2. Fielddata circuit breaker:预加载fielddata所需内存
3. Request circuit breaker:请求内存限制，例如聚合
4. in flight circuit breaker:Request的断路器
5. Accounting request circuit breaker:请求结束后不能释放的对象所长用内存

 

 

 

 

#ES性能压测，附赠下方几个截图进行学些使用

 

 

 

 

一起来玩Elasticsearch，加我微信：wx1250134974