ELK 최적화_developdoc

ELK 최적화

2024-07-12

ELK 최적화는 다음 측면에서 수행될 수 있습니다.

리눅스 커널 최적화
JVM 최적화
ES 구성 최적화
아키텍처 최적화(filebeat/fluentd가 logstash를 대체하고 kafka를 메시지 대기열로 조인함)

로그 저장소로서 ES의 특징:

높은 동시 쓰기
덜 읽으세요
30초 이내에 지연을 수락합니다.
부분적인 로그 데이터 손실을 허용할 수 있습니다.

로그스태시 최적화

① 서버 메모리와 JVM 힙 메모리를 늘린다.

② 로드 밸런싱을 위해 여러 인스턴스를 사용합니다.

③logstash 대신 filebeat를 사용하여 로그 데이터 수집

엘라스틱서치 최적화

(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"

②새로고침 최적화


写入 Lucene 的数据，并不是实时可搜索的，ES 必须通过 refresh 的过程把内存中的数据转换成 Lucene 的完整 segment 后，才可以被搜索。
默认 1 秒后，写入的数据可以很快被查询到，但势必会产生大量的 segment，检索性能会受到影响。所以，加大时长可以降低系统开销。 对于日志搜索来说，实时性要求不是那么高，设置为 5 秒或者 10s；对于 SkyWalking，实时性要求更低一些，我们可以设置为 30s。
设置如下：
"index.refresh_interval":"5s"

③병합 최적화


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"

④설정 최적화

먼저 인덱스를 닫은 후 실행하고 마지막으로 성공 후 열어야 합니다.

색인 닫기

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) 스레드 풀 구성 최적화

쓰기 스레드 풀이 가득 차서 작업이 거부되고 일부 데이터를 쓸 수 없습니다. 위의 최적화 이후 거부 건수는 많이 줄어들었지만 여전히 채용 거부 사례가 발생하고 있습니다. 따라서 쓰기 스레드 풀도 최적화해야 합니다.

쓰기 스레드 풀은 고정된 유형의 스레드 풀을 사용합니다. 즉, 코어 스레드 수는 최대 스레드 값과 동일합니다. 스레드 수는 기본적으로 CPU 코어 수와 동일합니다. 설정할 수 있는 최대값은 CPU 코어 수에 1을 더한 값입니다. 예를 들어 16코어 CPU의 경우 최대 스레드 수는 17로 설정됩니다.

최적화

스레드 수는 총 CPU 코어 수에 1을 더한 17로 변경됩니다.
대기열 용량이 증가합니다. 이때 큐의 역할은 피크를 제거하는 것입니다. 그러나 큐 용량 자체를 늘리는 것은 처리 속도를 높이는 것이 아니라 버퍼 역할만 할 뿐입니다. 또한 대기열 용량이 너무 커서는 안 됩니다. 그렇지 않으면 많은 작업이 백로그될 때 너무 많은 힙 메모리를 차지하게 됩니다.

elasticsearch.yml 파일을 수정하여 구성을 추가하세요.


# 线程数设置
thread_pool:
  write:
    # 线程数默认等于cpu核数，即16  
    size: 17
    # 因为任务多时存在任务拒绝的情况，所以加大队列大小，可以在间歇性任务量陡增的情况下，缓存任务在队列，等高峰过去逐步消费完。
    queue_size: 10000

(3) 메모리를 잠그고 JVM이 Swap을 사용하지 못하도록 방지

스왑 스왑 파티션: 시스템의 물리적 메모리가 충분하지 않은 경우 현재 실행 중인 프로그램에서 사용할 수 있도록 물리적 메모리 공간의 일부를 해제해야 합니다. 해제된 공간은 오랫동안 작동하지 않은 일부 프로그램에서 발생할 수 있으며, 해제된 공간은 해당 프로그램이 실행될 때 Swap에서 메모리로 복원됩니다. 이런 방식으로 시스템은 물리적 메모리가 부족할 때 항상 Swap을 수행합니다.

스왑 스왑 파티션은 성능과 노드 안정성에 매우 해로우므로 비활성화해야 합니다. 이로 인해 가비지 수집이 밀리초가 아닌 몇 분 동안 지속되며 노드가 느리게 응답하거나 클러스터에서 연결이 끊어질 수도 있습니다.

ES 구현에는 스왑 파티션 방식을 사용할 수 없습니다.

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) 샤딩

인덱스의 크기는 샤드와 세그먼트의 크기에 따라 달라집니다. 샤드가 너무 작으면 세그먼트가 너무 작아서 샤드가 너무 크면 샤드가 자주 병합될 수 있습니다. 이로 인해 많은 수의 IO 작업이 발생하고 쓰기 성능에 영향을 미칩니다.
각 인덱스의 크기는 15G 미만이고, 기본 샤드가 5개이므로 그렇게 많이 필요하지 않기 때문에 3개로 조정했습니다.

"index.number_of_shards": "3"

2) 매수

클러스터 복사본 샤드 수를 줄이세요. 복사본이 너무 많으면 ES 내부 쓰기 확장이 발생합니다. 복사본 개수는 1개로 기본 설정되어 있습니다. 인덱스가 위치한 노드가 다운되면 복사본이 있는 다른 머신이 인덱스 백업 데이터를 갖게 되므로 인덱스 데이터를 정상적으로 사용할 수 있습니다. 그러나 복사본에 데이터를 쓰면 쓰기 성능에 영향을 미칩니다. 로그 데이터의 경우 사본 1개로 충분합니다. 데이터 양이 많은 인덱스의 경우 복사본 수를 0으로 설정하여 성능에 미치는 영향을 줄일 수 있습니다.

"index.number_of_replicas": "1"

요약하다

Logstash 최적화 방법: