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

④适当的减少索引的分片数、副本数