ELK优化
ELK优化可以从以下几个方面进行：
- linux内核优化
- JVM优化
- ES配置优化
- 架构优化（filebeat/fluentd代替logstash、加入kafka做消息队列）
ES 作为日志存储时的特性：
- 高并发写
- 读少
- 接受 30 秒内的延时
- 可容忍部分日志数据丢失
Logstash优化
①加大服务器内存和JVM堆内存
②用多实例做负载均衡
③使用filebeat替代logstash采集日志数据
Elasticsearch优化
（1）优化ElasticSearch的索引
①优化 fsync
为了保证不丢失数据，就要保护 translog 文件的安全: Elasticsearch 2.0 之后，每次写请求(如 index 、delete、update、bulk 等)完成时，都会触发fsync将 translog 中的 segment 刷到磁盘，然后才会返回 200 OK 的响应；或者: 默认每隔5s就将 translog 中的数据通过fsync强制刷新到磁盘。 该方式提高数据安全性的同时，降低了一点性能。 ==> 频繁地执行 fsync 操作，可能会产生阻塞导致部分操作耗时较久。 如果允许部分数据丢失，可设置异步刷新 translog 来提高效率，还有降低 flush 的阀值， 优化如下： "index.translog.durability": "async", "index.translog.flush_threshold_size":"1024mb", "index.translog.sync_interval": "120s"
②优化 refresh
写入 Lucene 的数据，并不是实时可搜索的，ES 必须通过 refresh 的过程把内存中的数据转换成 Lucene 的完整 segment 后，才可以被搜索。 默认 1 秒后，写入的数据可以很快被查询到，但势必会产生大量的 segment，检索性能会受到影响。所以，加大时长可以降低系统开销。 对于日志搜索来说，实时性要求不是那么高，设置为 5 秒或者 10s；对于 SkyWalking，实时性要求更低一些，我们可以设置为 30s。 设置如下： "index.refresh_interval":"5s"
③优化 merge
index.merge.scheduler.max_thread_count 控制并发的 merge 线程数，如果存储是并发性能较好的 SSD，可以用系统默认的 max(1, min(4, availableProcessors / 2))，当节点配置的 cpu 核数较高时，merge 占用的资源可能会偏高，影响集群的性能，普通磁盘的话设为1，发生磁盘 IO 堵塞。设置 max_thread_count 后，会有 max_thread_count + 2 个线程同时进行磁盘操作，也就是设置为 1 允许 3 个线程。 设置如下： "index.merge.scheduler.max_thread_count":"1"
④优化设置
需要先 close 索引，然后再执行，最后成功之后再打开
- 关闭索引
curl -XPOST 'http://localhost:9200/_all/_close'
- 修改索引设置
curl -XPUT -H "Content-Type:application/json" 'http://localhost:9200/_all/_settings?preserve_existing=true' -d '{"index.merge.scheduler.max_thread_count" : "1","index.refresh_interval" : "10s","index.translog.durability" : "async","index.translog.flush_threshold_size":"1024mb","index.translog.sync_interval" : "120s"}'- 打开索引
curl -XPOST 'http://localhost:9200/_all/_open'
（2）优化线程池配置
write 线程池满负荷，导致拒绝任务，而有的数据无法写入。而经过上面的优化后，拒绝的情况少了很多，但是还是有拒绝任务的情况。所以我们还需要优化 write 线程池。
write 线程池采用 fixed 类型的线程池，也就是核心线程数与最大线程数值相同。线程数默认等于 cpu 核数，可设置的最大值只能是 cpu 核数加 1，比如 16 核的 CPU， 能设置的线程数最大值为 17。
优化方案
- 线程数改为 17，也就是 cpu 总核数加 1
- 队列容量加大。队列在此时的作用是消峰。不过队列容量加大本身不会提升处理速度，只是起到缓冲作用。此外，队列容量也不能太大，否则积压很多任务时会占用过多堆内存。
修改 elasticsearch.yml 文件增加配置
# 线程数设置 thread_pool: write: # 线程数默认等于cpu核数，即16 size: 17 # 因为任务多时存在任务拒绝的情况，所以加大队列大小，可以在间歇性任务量陡增的情况下，缓存任务在队列，等高峰过去逐步消费完。 queue_size: 10000（3）锁定内存，不让 JVM 使用 Swap
Swap交换分区：当系统的物理内存不够用的时候，就需要将物理内存中的一部分空间释放出来，以供当前运行的程序使用。那些被释放的空间可能来自一些很长时间没有什么操作的程序，这些被释放的空间被临时保存到 Swap 中，等到那些程序要运行时，再从 Swap 中恢复保存的数据到内存中。这样，系统总是在物理内存不够时，才进行 Swap 交换。
Swap 交换分区对性能和节点稳定性非常不利，一定要禁用。它会导致垃圾回收持续几分钟而不是几毫秒，并会导致节点响应缓慢，甚至与集群断开连接。
实现 ES 不能使用 Swap 分区的方法
1）Linux 系统中的关闭 Swap (临时有效)
执行命令 sudo swapoff -a 可以临时禁用 Swap 内存，但是操作系统重启后失效
2）Linux 系统中的尽可能减少 Swap 的使用(永久有效)
执行下列命令 echo "vm.swappiness = 1" >> /etc/sysctl.conf 正常情况下不会使用 Swap，除非紧急情况下才会 Swap。
3）启用 bootstrap.memory_lock
config/elasticsearch.yml 文件增加配置 #锁定内存，不让 JVM 写入 Swap，避免降低 ES 的性能 bootstrap.memory_lock: true
（4）减少分片数、副本数
1）分片
索引的大小取决于分片与段的大小，分片过小，可能导致段过小，进而导致开销增加；分片过大可能导致分片频繁 Merge，产生大量 IO 操作，影响写入性能。
因为我们每个索引的大小在 15G 以下，而默认是 5 个分片，没有必要这么多，所以调整为 3 个。
"index.number_of_shards": "3"
2）副本数
减少集群副本分片数，过多副本会导致 ES 内部写扩大。副本数默认为 1，如果某索引所在的 1 个节点宕机，拥有副本的另一台机器拥有索引备份数据，可以让索引数据正常使用。但是数据写入副本会影响写入性能。对于日志数据，有 1 个副本即可。 对于大数据量的索引，可以设置副本数为 0，减少对性能的影响。
"index.number_of_replicas": "1"
总结
Logstash优化方法：
①加大服务器内存和JVM堆内存
②用多实例做负载均衡
③使用filebeat替代logstash采集日志数据
ElasticSearch优化方法：
①对索引进行优化：优化fsync，适当加大刷盘间隔时间
②优化write线程池配置，减少拒绝任务的情况：修改ES配置文件elasticsearch.yml，设置write线程为 CPU核数+1
③锁定内存，不让ES使用swap：swapoff -a ，关闭swap
④适当的减少索引的分片数、副本数
- 打开索引
- 修改索引设置
- 关闭索引
