ELK optimization_developdoc

Ottimizzazione ELK

2024-07-12

L'ottimizzazione ELK può essere effettuata dai seguenti aspetti:

Ottimizzazione del kernel Linux
Ottimizzazione JVM
Ottimizzazione della configurazione ES
Ottimizzazione dell'architettura (filebeat/fluentd sostituisce logstash, si unisce a kafka come coda di messaggi)

Caratteristiche di ES come archivio di log:

Scrittura simultanea elevata
Leggi di meno
Accetta il ritardo entro 30 secondi
Può tollerare la perdita parziale dei dati di registro

Ottimizzazione logstash

① Aumentare la memoria del server e la memoria heap JVM

② Utilizza più istanze per il bilanciamento del carico

③Utilizza filebeat anziché logstash per raccogliere i dati di registro

Ottimizzazione elasticsearch

(1) Ottimizza l'indice di ElasticSearch

①Ottimizza 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"

②Ottimizza l'aggiornamento


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

③Ottimizza l'unione


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"

④Ottimizza le impostazioni

È necessario prima chiudere l'indice, quindi eseguirlo e infine aprirlo dopo il successo.

Chiudi indice

curl -XPOST 'http://localhost:9200/_all/_close'

Modifica le impostazioni dell'indice

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"}'

indice aperto

curl -XPOST 'http://localhost:9200/_all/_open'

(2) Ottimizza la configurazione del pool di thread

Il pool di thread di scrittura è pieno, pertanto le attività vengono rifiutate e alcuni dati non possono essere scritti. Dopo l'ottimizzazione di cui sopra, il numero di rifiuti è diminuito notevolmente, ma ci sono ancora casi in cui le attività vengono rifiutate. Quindi dobbiamo anche ottimizzare il pool di thread di scrittura.

Il pool di thread di scrittura utilizza un tipo fisso di pool di thread, ovvero il numero di thread principali è uguale al valore massimo del thread. Per impostazione predefinita, il numero di thread è uguale al numero di core della CPU. Il valore massimo che può essere impostato può essere solo il numero di core della CPU più 1. Ad esempio, per una CPU a 16 core, il numero massimo di thread che può essere impostato. essere impostato è 17.

Ottimizzazione

Il numero di thread viene modificato in 17, ovvero il numero totale di core della CPU più 1
Aumenta la capacità della coda. Il ruolo della coda in questo momento è eliminare i picchi. Tuttavia, l'aumento della capacità della coda non aumenterà la velocità di elaborazione, ma fungerà solo da buffer. Inoltre, la capacità della coda non può essere troppo grande, altrimenti verrà occupata troppa memoria heap quando molte attività vengono accumulate.

Modifica il file elasticsearch.yml per aggiungere la configurazione


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

(3) Blocca la memoria e impedisce alla JVM di utilizzare Swap

Scambia partizione di swap: quando la memoria fisica del sistema non è sufficiente, una parte dello spazio nella memoria fisica deve essere rilasciata per essere utilizzata dal programma attualmente in esecuzione. Lo spazio liberato potrebbe provenire da alcuni programmi che non sono stati utilizzati per molto tempo. Lo spazio liberato viene temporaneamente salvato in Swap Quando tali programmi stanno per essere eseguiti, i dati salvati vengono ripristinati da Swap nella memoria. In questo modo il sistema esegue sempre lo Swap quando la memoria fisica è insufficiente.

La partizione di swap è molto dannosa per le prestazioni e la stabilità del nodo e deve essere disabilitata. Fa sì che la garbage collection duri minuti anziché millisecondi e può causare una risposta lenta dei nodi o addirittura la disconnessione dal cluster.

Il metodo della partizione di scambio non può essere utilizzato per implementare ES

1) Disattiva lo scambio nel sistema Linux (temporaneamente efficace)


执行命令 sudo swapoff -a
可以临时禁用 Swap 内存，但是操作系统重启后失效

2) Ridurre il più possibile l'uso di Swap nei sistemi Linux (efficace in modo permanente)


执行下列命令
echo "vm.swappiness = 1" >> /etc/sysctl.conf
正常情况下不会使用 Swap，除非紧急情况下才会 Swap。

3) Abilita bootstrap.memory_lock


config/elasticsearch.yml 文件增加配置
#锁定内存，不让 JVM 写入 Swap，避免降低 ES 的性能
bootstrap.memory_lock: true

(4) Ridurre il numero di frammenti e copie

1) Frazionamento

La dimensione dell'indice dipende dalla dimensione dei frammenti e dei segmenti. Se i frammenti sono troppo piccoli, i segmenti potrebbero essere troppo piccoli, il che potrebbe comportare un aumento del sovraccarico. Se i frammenti sono troppo grandi, i frammenti potrebbero essere uniti frequentemente. con conseguente numero elevato di operazioni di I/O, che influiscono sulle prestazioni di scrittura.
Poiché la dimensione di ciascuno dei nostri indici è inferiore a 15G e il valore predefinito è 5 shard, non ce n'è bisogno per così tanti, quindi l'abbiamo regolata a 3.

"index.number_of_shards": "3"

2) Numero di copie

Ridurre il numero di frammenti di copia del cluster. Troppe copie causeranno l'espansione della scrittura interna di ES. Il numero predefinito di copie è 1. Se un nodo su cui si trova un indice va giù, un'altra macchina con una copia avrà i dati di backup dell'indice, in modo che i dati dell'indice possano essere utilizzati normalmente. Ma la scrittura dei dati su una copia influisce sulle prestazioni di scrittura. Per i dati di registro è sufficiente 1 copia. Per gli indici con grandi quantità di dati, è possibile impostare il numero di copie su 0 per ridurre l'impatto sulle prestazioni.

"index.number_of_replicas": "1"

Riassumere

Metodo di ottimizzazione logstash: