ELK optimointi_kehitysdoc

ELK-optimointi

2024-07-12

ELK-optimointi voidaan suorittaa seuraavista näkökohdista:

Linux-ytimen optimointi
JVM-optimointi
ES-kokoonpanon optimointi
Arkkitehtuurin optimointi (filebeat/fluentd korvaa logstashin, liittyy kafkaan viestijonoon)

ES:n ominaisuudet lokivarastona:

Korkea samanaikainen kirjoitus
Lue vähemmän
Hyväksy viive 30 sekunnin sisällä
Kestää osittaisen lokitietojen katoamisen

Logstash optimointi

① Lisää palvelimen muistia ja JVM-keon muistia

② Käytä useita esiintymiä kuormituksen tasapainottamiseen

③Käytä filebeatia logstashin sijaan lokitietojen keräämiseen

Elasticsearch-optimointi

(1) Optimoi ElasticSearchin hakemisto

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

②Optimoi päivitys


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

③Optimoi yhdistäminen


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"

④Optimoi asetukset

Sinun on ensin suljettava hakemisto, suoritettava se ja avattava se lopuksi onnistumisen jälkeen.

Sulje hakemisto

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

Muokkaa hakemistoasetuksia

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

avaa hakemisto

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

(2) Optimoi säikeen kokoonpano

Kirjoitussäievarasto on täynnä, minkä vuoksi tehtäviä hylätään, eikä kaikkia tietoja voida kirjoittaa. Yllä olevan optimoinnin jälkeen hylkäysten määrä on vähentynyt paljon, mutta silti on tapauksia, joissa tehtäviä hylätään. Joten meidän on myös optimoitava kirjoitussäiepooli.

Kirjoitussäikevarasto käyttää kiinteää säievarastotyyppiä, eli ydinsäikeiden lukumäärä on sama kuin säikeen enimmäisarvo. Säikeiden lukumäärä on oletuksena yhtä suuri kuin suorittimen ytimien lukumäärä. Suurin asetettava arvo voi olla vain CPU-ytimien lukumäärä plus 1. Esimerkiksi 16-ytimisessä CPU:ssa voi olla säikeiden enimmäismäärä. määrä on 17.

Optimointi

Säikeiden lukumäärä muutetaan 17:ksi, mikä on suorittimen ytimien kokonaismäärä plus 1
Jonokapasiteetti kasvaa. Jonon tehtävänä on tällä hetkellä eliminoida piikit. Itse jonokapasiteetin lisääminen ei kuitenkaan lisää käsittelynopeutta, vaan toimii vain puskurina. Lisäksi jonokapasiteetti ei voi olla liian suuri, muuten liian paljon muistia varataan, kun monet tehtävät ovat ruuhkautuneita.

Muokkaa elasticsearch.yml-tiedostoa lisätäksesi määritykset


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

(3) Lukitse muisti ja estä JVM:ää käyttämästä Swapia

Vaihda swap-osio: Kun järjestelmän fyysinen muisti ei riitä, osa fyysisen muistin tilasta on vapautettava käynnissä olevan ohjelman käyttöön. Vapautunut tila voi olla peräisin joistakin ohjelmista, jotka eivät ole toimineet pitkään aikaan. Vapautunut tila tallennetaan väliaikaisesti Swap-ohjelmaan. Tällä tavalla järjestelmä suorittaa aina Swap-toiminnon, kun fyysinen muisti ei riitä.

Swap-swap-osio on erittäin haitallinen suorituskyvylle ja solmun vakaudelle, ja se on poistettava käytöstä. Se saa roskien keräämisen kestämään minuutteja millisekuntien sijasta ja voi saada solmut reagoimaan hitaasti tai jopa katketa klusterista.

Swap-osiomenetelmää ei voida käyttää ES:n toteuttamiseen

1) Poista Swap käytöstä Linux-järjestelmässä (voimassa väliaikaisesti)


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

2) Vähennä Swapin käyttöä niin paljon kuin mahdollista Linux-järjestelmissä (voimassa pysyvästi)


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

3) Ota bootstrap.memory_lock käyttöön


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

(4) Vähennä sirpaleiden ja kopioiden määrää

1) Jakaminen

Indeksin koko riippuu fragmenttien ja segmenttien koosta. Jos fragmentit ovat liian pieniä, segmentit voivat olla liian pieniä. tuloksena on suuri määrä IO-toimintoja, jotka vaikuttavat kirjoitussuorituskykyyn.
Koska jokaisen indeksimme koko on alle 15 Gt ja oletusarvo on 5 sirpaletta, niin montaa ei tarvita, joten muutimme sen 3:ksi.

"index.number_of_shards": "3"

2) Kopioiden lukumäärä

Vähennä klusterin kopiosirpaleiden määrää Liian monta kopiota aiheuttaa ES:n sisäisen kirjoituslaajennuksen. Kopioiden oletusmäärä on 1. Jos solmu, jossa hakemisto sijaitsee, menee alas, toisella koneella, jolla on kopio, on indeksin varmuuskopiotiedot, jotta indeksitietoja voidaan käyttää normaalisti. Mutta tietojen kirjoittaminen kopioon vaikuttaa kirjoitussuorituskykyyn. Lokitiedoille riittää yksi kopio. Jos hakemistossa on suuria tietomääriä, voit asettaa kopiomääräksi 0 vähentääksesi vaikutusta suorituskykyyn.

"index.number_of_replicas": "1"

Tee yhteenveto

Logstash-optimointimenetelmä: