Partage de technologie

한어Русский языкEnglishFrançaisIndonesianSanskrit日本語DeutschPortuguêsΕλληνικάespañolItalianoSuomalainenLatina

L'optimisation ELK peut être réalisée sous les aspects suivants :

• optimisation du noyau Linux
• Optimisation JVM
• Optimisation de la configuration ES
• Optimisation de l'architecture (filebeat/fluentd remplace logstash, rejoint kafka en tant que file d'attente de messages)

Caractéristiques d'ES en tant que stockage de journaux :

• Écriture simultanée élevée
• Lire moins
• Acceptez le délai dans les 30 secondes
• Peut tolérer une perte partielle de données de journal

Optimisation du stockage de journaux

① Augmentez la mémoire du serveur et la mémoire du tas JVM

② Utiliser plusieurs instances pour l'équilibrage de charge

③Utilisez filebeat au lieu de logstash pour collecter les données du journal

Optimisation de la recherche élastique

(1) Optimiser l'index d'ElasticSearch

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

②Optimiser l'actualisation

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

③Optimiser la fusion

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"

④Optimiser les paramètres

Vous devez d'abord fermer l'index, puis l'exécuter et enfin l'ouvrir après succès.

• Fermer l'index

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

• Modifier les paramètres d'index

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

• index ouvert

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

(2) Optimiser la configuration du pool de threads

Le pool de threads d'écriture est plein, ce qui entraîne le rejet des tâches et certaines données ne peuvent pas être écrites. Après l'optimisation ci-dessus, le nombre de refus a considérablement diminué, mais il existe encore des cas de refus d'emploi. Nous devons donc également optimiser le pool de threads d’écriture.

Le pool de threads d'écriture utilise un type fixe de pool de threads, c'est-à-dire que le nombre de threads principaux est le même que la valeur maximale du thread. Le nombre de threads est égal au nombre de cœurs de processeur par défaut. La valeur maximale pouvant être définie ne peut être que le nombre de cœurs de processeur plus 1. Par exemple, pour un processeur à 16 cœurs, le nombre maximum de threads pouvant être définis. être réglé est 17.

Optimisation

• Le nombre de threads passe à 17, soit le nombre total de cœurs de processeur plus 1.
• La capacité de la file d’attente augmente. Le rôle de la file d’attente à ce moment est d’éliminer les pics. Cependant, l'augmentation de la capacité de la file d'attente en elle-même n'augmentera pas la vitesse de traitement, mais agira uniquement comme un tampon. De plus, la capacité de la file d'attente ne peut pas être trop grande, sinon trop de mémoire tas sera occupée lorsque de nombreuses tâches sont en retard.

Modifier le fichier elasticsearch.yml pour ajouter la configuration

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

(3) Verrouillez la mémoire et empêchez la JVM d'utiliser Swap

Swap swap partition : lorsque la mémoire physique du système n'est pas suffisante, une partie de l'espace dans la mémoire physique doit être libérée pour être utilisée par le programme en cours d'exécution. L'espace libéré peut provenir de certains programmes qui n'ont pas fonctionné depuis longtemps. L'espace libéré est temporairement enregistré dans Swap. Lorsque ces programmes sont sur le point de s'exécuter, les données enregistrées sont restaurées depuis Swap vers la mémoire. De cette manière, le système effectue toujours un Swap lorsque la mémoire physique est insuffisante.

La partition swap swap est très préjudiciable aux performances et à la stabilité des nœuds et doit être désactivée. Cela entraîne une durée de récupération de place de quelques minutes au lieu de quelques millisecondes, et peut entraîner une réponse lente des nœuds, voire une déconnexion du cluster.

La méthode de partition d'échange ne peut pas être utilisée pour implémenter ES

1) Désactivez Swap dans le système Linux (temporairement effectif)

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

2) Réduire autant que possible l'utilisation de Swap dans les systèmes Linux (efficace de manière permanente)

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

3) Activer bootstrap.memory_lock

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

(4) Réduire le nombre de fragments et de copies

1) Partage

La taille de l'index dépend de la taille des fragments et des segments. Si les fragments sont trop petits, les segments peuvent être trop petits, ce qui peut entraîner une augmentation de la surcharge. Si les fragments sont trop grands, les fragments peuvent être fusionnés fréquemment. ce qui entraîne un grand nombre d'opérations d'E/S, affectant les performances d'écriture.
Étant donné que la taille de chacun de nos index est inférieure à 15 Go et que la valeur par défaut est de 5 fragments, il n'est pas nécessaire d'en avoir autant, nous l'avons donc ajusté à 3.

"index.number_of_shards": "3"

2) Nombre d'exemplaires

Réduisez le nombre de fragments de copie de cluster. Un trop grand nombre de copies entraînera une expansion de l'écriture interne d'ES. Le nombre de copies est par défaut de 1. Si un nœud sur lequel se trouve un index tombe en panne, une autre machine avec une copie disposera des données de sauvegarde de l'index, afin que les données d'index puissent être utilisées normalement. Mais l'écriture de données sur une copie affecte les performances d'écriture. Pour les données de journal, 1 copie suffit. Pour les index contenant de grandes quantités de données, vous pouvez définir le nombre de copies sur 0 pour réduire l'impact sur les performances.

"index.number_of_replicas": "1"

Résumer

Méthode d'optimisation Logstash :

① Augmentez la mémoire du serveur et la mémoire du tas JVM

② Utiliser plusieurs instances pour l'équilibrage de charge

③Utilisez filebeat au lieu de logstash pour collecter les données du journal

Méthode d'optimisation ElasticSearch :

① Optimiser l'index : optimiser fsync et augmenter de manière appropriée l'intervalle de vidage du disque

② Optimisez la configuration du pool de threads d'écriture pour réduire le rejet de tâches : modifiez le fichier de configuration ES elasticsearch.yml et définissez le thread d'écriture sur le nombre de cœurs CPU + 1

③Verrouillez la mémoire et empêchez ES d'utiliser le swap : swapoff -a, fermez le swap

④Réduire de manière appropriée le nombre de fragments et de copies d'index