Akeh wong sing berjuang karo Elasticsearch. Nanging apa sing kedadeyan yen sampeyan pengin digunakake kanggo nyimpen log "ing volume sing gedhe banget"? Lan uga ora krasa lara ngalami kegagalan saka sawetara pusat data? Apa jenis arsitektur sing kudu sampeyan lakoni, lan pitfalls apa sing bakal sampeyan kesandhung?
Kita ing Odnoklassniki mutusake nggunakake elasticsearch kanggo ngatasi masalah manajemen log, lan saiki kita nuduhake pengalaman karo Habr: babagan arsitektur lan pitfalls.
Aku Pyotr Zaitsev, aku kerja minangka administrator sistem ing Odnoklassniki. Sadurunge, aku uga dadi admin, nggarap Manticore Search, Sphinx search, Elasticsearch. Mbok menawa, yen ... telusuran liyane katon, aku uga bakal nggarap. Aku uga melu ing sawetara proyek open source kanthi sukarela.
Nalika aku teka ing Odnoklassniki, aku ngomong kanthi sembrono ing wawancara yen aku bisa nggarap Elasticsearch. Sawise aku ngerti lan ngrampungake sawetara tugas sing prasaja, aku diwenehi tugas gedhe kanggo ndandani sistem manajemen log sing ana ing wektu kasebut.
syarat
Persyaratan sistem dirumusake kaya ing ngisor iki:
- Graylog bakal digunakake minangka frontend. Amarga perusahaan wis duwe pengalaman nggunakake prodhuk iki, programer lan tester ngerti, iku menowo lan trep kanggo wong-wong mau.
- Volume data: rata-rata 50-80 ewu pesen per detik, nanging yen ana sing rusak, lalu lintas ora diwatesi apa wae, bisa dadi 2-3 yuta baris per detik
- Sawise rembugan karo pelanggan syarat kanggo kacepetan pangolahan pitakon telusuran, kita nyadari yen pola khas nggunakake sistem kasebut yaiku: wong nggoleki log aplikasi sajrone rong dina pungkasan lan ora pengin ngenteni luwih saka a kapindho kanggo asil query dirumuske.
- Administrator negesake manawa sistem kasebut gampang diukur yen perlu, tanpa mbutuhake dheweke sinau kanthi jero babagan cara kerjane.
- Supaya mung tugas pangopènan sing sistem iki mbutuhake periodik kanggo ngganti sawetara hardware.
- Kajaba iku, Odnoklassniki nduweni tradhisi teknis sing apik banget: layanan apa wae sing diluncurake kudu slamet saka kegagalan pusat data (tiba-tiba, ora direncanakake lan pancen kapan wae).
Keperluan pungkasan ing implementasine proyek iki paling larang, sing bakal dakkandhakake kanthi luwih rinci.
Lingkungan
Kita kerja ing papat pusat data, dene simpul data Elasticsearch mung bisa ditemokake ing telung (kanggo sawetara alasan non-teknis).
Papat pusat data iki ngemot kira-kira 18 ewu sumber log sing beda - hardware, wadhah, mesin virtual.
Fitur penting: kluster diwiwiti ing kontaner ora ing mesin fisik, nanging ing . Wadhah dijamin 2 intine, padha karo 2.0Ghz v4, kanthi kamungkinan daur ulang inti sing isih ana yen lagi nganggur.
Ing tembung liya:
Topologi
Aku pisanan weruh wangun umum saka solusi minangka nderek:
- 3-4 VIPs konco A-rekaman saka domain Graylog, iki alamat sing log dikirim.
- saben VIP punika imbangan LVS.
- Sawise iku, log menyang baterei Graylog, sawetara data ana ing format GELF, sawetara ing format syslog.
- Banjur kabeh iki ditulis ing batch gedhe menyang baterei koordinator Elasticsearch.
- Lan padha ngirim panjalukan nulis lan maca menyang simpul data sing relevan.
Istilah kasebut
Mbok menawa ora saben wong ngerti terminologi kasebut kanthi rinci, mula aku pengin ngrembug babagan iki.
Elasticsearch duwe sawetara jinis simpul - master, koordinator, simpul data. Ana rong jinis liyane kanggo transformasi log beda lan komunikasi antarane klompok beda, nanging kita digunakake mung sing kadhaptar.
Master
Iki ping kabeh kelenjar sing ana ing kluster, njaga peta kluster sing paling anyar lan disebarake ing antarane simpul, ngolah logika acara, lan nindakake macem-macem housekeeping sudhut kluster.
Koordinator
Nindakake siji tugas: nampa panjalukan maca utawa nulis saka klien lan nuntun lalu lintas iki. Ing kasus ana panjalukan nulis, paling kamungkinan, iku bakal takon master kang shard saka indeks cocog kudu sijine iku, lan bakal pangalihan panjalukan luwih.
Node data
Nyimpen data, nindakake pitakon telusuran sing teka saka njaba lan nindakake operasi ing pecahan sing ana ing kono.
greylog
Iki kaya gabungan Kibana karo Logstash ing tumpukan ELK. Graylog nggabungake UI lan pipa pangolahan log. Ing hood, Graylog mbukak Kafka lan Zookeeper, sing nyedhiyakake konektivitas menyang Graylog minangka kluster. Graylog bisa cache log (Kafka) yen Elasticsearch ora kasedhiya lan mbaleni panjalukan maca lan nulis gagal, klompok lan tandha log miturut aturan tartamtu. Kaya Logstash, Graylog nduweni fungsi kanggo ngowahi baris sadurunge nulis menyang Elasticsearch.
Kajaba iku, Graylog nduweni panemuan layanan sing dibangun sing ngidini, adhedhasar siji simpul Elasticsearch sing kasedhiya, entuk kabeh peta kluster lan nyaring kanthi tag tartamtu, sing ndadekake panjaluk langsung menyang wadhah tartamtu.
Secara visual katon kaya iki:
Iki minangka gambar saka conto tartamtu. Ing kene kita mbangun histogram adhedhasar pitakon telusuran lan nampilake baris sing cocog.
Indeks
Mbalik menyang arsitektur sistem, aku pengin luwih rinci babagan carane mbangun model indeks supaya kabeh bisa digunakake kanthi bener.
Ing diagram ing ndhuwur, iki minangka tingkat paling ngisor: simpul data Elasticsearch.
Indeks minangka entitas virtual gedhe sing digawe saka pecahan Elasticsearch. Ing dhewe, saben pecahan ora luwih saka indeks Lucene. Lan saben indeks Lucene, ing siji, kasusun saka siji utawa luwih segmen.
Nalika ngrancang, kita nemtokake manawa kanggo nyukupi kabutuhan kacepetan maca ing jumlah data sing akeh, kita kudu "nyebar" data iki kanthi merata ing simpul data.
Iki nyebabake kasunyatan manawa jumlah pecahan saben indeks (karo replika) kudu padha karo jumlah simpul data. Kaping pisanan, kanggo mesthekake faktor replikasi sing padha karo loro (yaiku, bisa ilang setengah saka kluster). Lan, sareh, kanggo proses maca lan nulis panjalukan ing paling setengah saka kluster.
Kita pisanan nemtokake wektu panyimpenan minangka 30 dina.
Distribusi pecahan bisa dituduhake kanthi grafis kaya ing ngisor iki:
Persegi panjang abu-abu peteng kabeh minangka indeks. Kothak abang ing sisih kiwa minangka beling utama, sing pisanan ing indeks. Lan kothak biru minangka replika pecahan. Padha dumunung ing pusat data beda.
Nalika kita nambah shard liyane, dadi menyang pusat data katelu. Lan, ing pungkasan, kita entuk struktur iki, sing bisa ilang DC tanpa kelangan konsistensi data:
Rotasi indeks, i.e. nggawe indeks anyar lan mbusak sing paling tuwa, kita nggawe padha karo 48 jam (miturut pola panggunaan indeks: 48 jam pungkasan paling kerep digoleki).
Interval rotasi indeks iki amarga alasan ing ngisor iki:
Nalika panjaluk telusuran teka ing simpul data tartamtu, banjur, saka sudut pandang kinerja, luwih nguntungake nalika siji beling ditakoni, yen ukurane bisa dibandhingake karo ukuran pinggul simpul. Iki ngidini sampeyan nyimpen bagean "panas" saka indeks ing tumpukan lan ngakses kanthi cepet. Nalika ana akeh "bagean panas", kacepetan panelusuran indeks mudhun.
Nalika simpul wiwit nglakokake pitakon telusuran ing siji beling, simpul kasebut menehi sawetara benang sing padha karo jumlah inti hyperthreading mesin fisik. Yen pitakon telusuran mengaruhi jumlah pecahan sing akeh, mula jumlah benang mundhak kanthi proporsional. Iki nduwe pengaruh negatif marang kacepetan telusuran lan nduwe pengaruh negatif marang indeksasi data anyar.
Kanggo nyedhiyakake latensi telusuran sing dibutuhake, kita mutusake nggunakake SSD. Kanggo ngolah panjalukan kanthi cepet, mesin sing dadi tuan rumah kontainer iki kudu paling sethithik 56 intine. Angka 56 dipilih minangka nilai sing cukup kondisional sing nemtokake jumlah benang sing bakal diasilake Elasticsearch sajrone operasi. Ing Elasitcsearch, akeh paramèter blumbang benang langsung gumantung ing jumlah intine sing kasedhiya, sing bakal langsung mengaruhi jumlah kelenjar sing dibutuhake ing kluster miturut prinsip "intine luwih sithik - luwih akeh kelenjar".
Akibaté, kita nemokake yen rata-rata shard bobote kira-kira 20 gigabyte, lan ana 1 shards saben indeks. Dadi, yen kita muter saben 360 jam, banjur ana 48. Saben indeks ngemot data kanggo 15 dina.
Sirkuit nulis lan maca data
Ayo ngerteni carane data direkam ing sistem iki.
Ayo dadi sawetara panjalukan teka saka Graylog menyang koordinator. Contone, kita pengin ngindeks 2-3 ewu larik.
Koordinator, sawise nampa panjalukan saka Graylog, takon marang master: "Ing panyuwunan indeksasi, kita khusus nemtokake indeks, nanging ing endi sing ditulis ora ditemtokake."
Master nanggapi: "Tulis informasi iki menyang shard nomer 71," banjur dikirim langsung menyang simpul data sing cocog, ing ngendi nomer 71 utama-shard dumunung.
Sawise log transaksi direplikasi menyang replika-shard, sing dumunung ing pusat data liyane.
Panjaluk telusuran teka saka Graylog menyang koordinator. Koordinator pangalihan kasebut miturut indeks, nalika Elasticsearch nyebarake panjaluk antarane beling utama lan beling replika nggunakake prinsip round-robin.
180 simpul nanggapi kanthi ora rata, lan nalika nanggapi, koordinator nglumpukake informasi sing wis "dibuwang" dening simpul data sing luwih cepet. Sawise iki, nalika kabeh informasi wis teka, utawa panjalukan wis tekan wektu entek, menehi kabeh langsung menyang klien.
Sistem kabeh iki rata-rata ngolah pitakon telusuran sajrone 48 jam pungkasan ing 300-400ms, ora kalebu pitakon kasebut kanthi wildcard utama.
Kembang karo Elasticsearch: persiyapan Jawa
Kanggo nggawe kabeh bisa kaya sing dikarepake, kita ngenteni wektu sing suwe kanggo debugging macem-macem barang ing kluster.
Bagean pisanan saka masalah sing ditemokake ana gandhengane karo cara Java wis dikonfigurasi kanthi standar ing Elasticsearch.
Masalah siji
Kita wis ndeleng akeh banget laporan sing ing tingkat Lucene, nalika proyek latar mburi mlaku, bagean Lucene merges gagal karo kesalahan. Ing wektu sing padha, iku cetha ing log sing iki kesalahan OutOfMemoryError. Kita weruh saka telemetri manawa pinggul gratis, lan ora jelas kenapa operasi iki gagal.
Ternyata indeks Lucene gabung ing njaba pinggul. Lan kontaner diwatesi kanthi ketat babagan sumber daya sing dikonsumsi. Mung tumpukan bisa pas karo sumber daya iki (nilai heap.size kira-kira padha karo RAM), lan sawetara operasi mati-numpuk tabrakan karo kesalahan alokasi memori yen sakperangan alesan padha ora pas menyang ~ 500MB sing tetep sadurunge watesan.
Ndandani cukup ora pati penting: jumlah RAM sing kasedhiya kanggo wadhah tambah, sawise iku kita lali yen kita duwe masalah kaya ngono.
Masalah loro
4-5 dina sawise diluncurake kluster, kita ngerteni manawa simpul data wiwit tiba saka kluster kanthi periodik lan mlebu sawise 10-20 detik.
Nalika kita miwiti ngerteni, ternyata memori mati-numpuk iki ing Elasticsearch ora dikontrol kanthi cara apa wae. Nalika kita menehi memori liyane kanggo wadhah, kita bisa kanggo isi pools buffer langsung karo macem-macem informasi, lan iki ngankat sawise GC eksplisit dibukak saka Elasticsearch.
Ing sawetara kasus, operasi iki njupuk wektu sing cukup suwe, lan ing wektu iki kluster bisa nandhani simpul iki minangka wis metu. Masalah iki uga diterangake .
Solusi kasebut kaya ing ngisor iki: kita mbatesi kemampuan Jawa kanggo nggunakake akeh memori ing njaba tumpukan kanggo operasi kasebut. We diwatesi kanggo 16 gigabyte (-XX: MaxDirectMemorySize = 16g), mesthekake yen GC eksplisit diarani luwih kerep lan diproses luwih cepet, saéngga ora destabilizing kluster maneh.
Masalah telu
Yen sampeyan mikir yen masalah karo "simpul ninggalake kluster ing wayahe paling ora dikarepke" wis rampung, sampeyan salah.
Nalika kita ngatur karya karo indeks, kita milih mmapfs kanggo ing shards seger karo segmentasi gedhe. Iki cukup blunder, amarga nalika nggunakake mmapfs file dipetakan menyang RAM, banjur kita bisa karo file dipetakan. Amarga iki, ternyata nalika GC nyoba kanggo mungkasi thread ing aplikasi, kita pindhah menyang safepoint kanggo wektu sing suwe banget, lan ing dalan menyang, aplikasi mandheg nanggapi panjalukan master babagan apa iku urip. . Mulane, master percaya yen simpul kasebut ora ana maneh ing kluster. Sawise iki, sawise 5-10 detik, kolektor sampah bisa digunakake, simpul kasebut urip, mlebu kluster maneh lan miwiti miwiti shards. Iku kabeh felt banget kaya "produksi kita pantes" lan ora cocok kanggo apa serius.
Kanggo nyisihaken saka prilaku iki, kita pisanan pindhah menyang niofs standar, lan banjur, nalika kita migrasi saka versi kalima Elastis kanggo enem, kita nyoba hybridfs, ngendi masalah iki ora maleh. Sampeyan bisa maca liyane babagan jinis panyimpenan .
Masalah papat
Banjur ana masalah liyane sing menarik banget sing diobati kanthi wektu rekaman. Kita nyekel nganti 2-3 wulan amarga pola kasebut pancen ora bisa dingerteni.
Kadhangkala koordinator kita menyang GC Lengkap, biasane sawise nedha awan, lan ora nate bali saka kana. Ing wektu sing padha, nalika logging tundha GC, katon kaya mangkene: kabeh mlaku kanthi apik, uga, banjur dumadakan kabeh dadi ala banget.
Kaping pisanan, kita ngira yen ana pangguna ala sing ngluncurake panjaluk sing nyebabake koordinator metu saka mode kerja. Kita mlebu panjalukan kanggo wektu sing suwe, nyoba ngerteni apa sing kedadeyan.
Akibaté, ternyata nalika pangguna ngluncurake panjaluk gedhe, lan tekan koordinator Elasticsearch tartamtu, sawetara kelenjar nanggapi luwih suwe tinimbang liyane.
Lan nalika koordinator ngenteni respon saka kabeh kelenjar, dheweke nglumpukake asil sing dikirim saka kelenjar sing wis nanggapi. Kanggo GC, iki tegese pola panggunaan tumpukan ganti cepet banget. Lan GC sing digunakake ora bisa ngrampungake tugas iki.
Mung fix kita ketemu kanggo ngganti prilaku kluster ing kahanan iki migrasi kanggo JDK13 lan nggunakake Shenandoah uwuh kolektor. Iki ngrampungake masalah, koordinator kita mandheg.
Iki ngendi masalah karo Jawa rampung lan masalah bandwidth wiwit.
"Woh wohan beri" karo Elasticsearch: throughput
Masalah karo throughput tegese kluster kita bisa digunakake kanthi stabil, nanging ing puncak jumlah dokumen sing diindeks lan sajrone maneuver, kinerja ora cukup.
Gejala pisanan sing ditemoni: sajrone sawetara "bledosan" ing produksi, nalika akeh log sing tiba-tiba digawe, kesalahan indeksasi es_rejected_execution wiwit kerep kerlip ing Graylog.
Iki amarga kasunyatan sing thread_pool.write.queue ing siji simpul data, nganti wayahe Elasticsearch bisa kanggo proses request indeksasi lan upload informasi kanggo beling ing disk, bisa cache mung 200 panjalukan minangka standar. Lan ing Banget sethitik ngandika bab parameter iki. Mung jumlah maksimum utas lan ukuran standar sing dituduhake.
Mesthi, kita banjur corak Nilai iki lan ketemu metu ing ngisor iki: khusus, ing persiyapan kita, nganti 300 panjalukan cached cukup apik, lan nilai sing luwih dhuwur iku fraught karo kasunyatan sing kita mabur maneh menyang Full GC.
Kajaba iku, amarga iki kumpulan pesen sing teka ing siji panyuwunan, iku perlu kanggo ngapiki Graylog supaya nulis ora asring lan ing kelompok cilik, nanging ing kelompok ageng utawa sapisan saben 3 detik yen kumpulan isih ora lengkap. Ing kasus iki, ternyata informasi sing kita tulis ing Elasticsearch kasedhiya ora ing rong detik, nanging ing limang (sing cocog karo kita cukup), nanging jumlah retrays sing kudu digawe kanggo push liwat gedhe. tumpukan informasi suda.
Iki penting banget ing wektu nalika ana sing nabrak ing endi wae lan laporan kanthi nesu, supaya ora entuk Elastis sing wis rampung spammed, lan sawise sawetara wektu - kelenjar Graylog sing ora bisa digunakake amarga buffer tersumbat.
Kajaba iku, nalika kita ngalami bledosan sing padha ing produksi, kita nampa keluhan saka programer lan penguji: nalika dheweke pancen mbutuhake log kasebut, dheweke diwenehi alon-alon.
Dheweke wiwit ngerteni. Ing tangan siji, cetha yen pitakon telusuran lan pitakon indeksasi diproses, ing dasare, ing mesin fisik sing padha, lan siji utawa liyane bakal ana drawdowns tartamtu.
Nanging iki sebagian bisa dicegah amarga kasunyatane ing versi kaping enem saka Elasticsearch, ana algoritma sing ngidini sampeyan nyebarake pitakon antarane simpul data sing relevan ora miturut prinsip round-robin acak (wadhah sing ngindeks lan nyekel utami- beling bisa dadi sibuk banget, bakal ora ana cara kanggo nanggapi cepet), nanging kanggo nerusake request iki kanggo wadhah kurang dimuat karo tiron-shard, kang bakal nanggapi luwih cepet. Ing tembung liyane, kita teka ing use_adaptive_replica_selection: bener.
Gambar maca wiwit katon kaya iki:
Transisi menyang algoritma iki ndadekake bisa nambah wektu pitakon kanthi signifikan ing wektu nalika kita duwe aliran log sing akeh kanggo nulis.
Pungkasan, masalah utama yaiku mbusak pusat data sing ora krasa lara.
Apa sing dikarepake saka kluster kasebut sawise ilang sambungan karo siji DC:
- Yen kita duwe master saiki ing pusat data sing gagal, banjur bakal dipilih maneh lan dipindhah minangka peran menyang simpul liyane ing DC liyane.
- Master bakal cepet mbusak kabeh simpul sing ora bisa diakses saka kluster.
- Adhedhasar sing isih ana, dheweke bakal ngerti: ing pusat data sing ilang, kita duwe pecahan utami lan kaya ngono, dheweke bakal cepet ningkatake pecahan replika pelengkap ing pusat data sing isih ana, lan kita bakal terus ngindeks data kasebut.
- Minangka asil iki, tulisan kluster lan throughput maca bakal mboko sithik mudhun, nanging ing umum kabeh bakal bisa, sanajan alon, nanging stabil.
Ternyata, kita pengin kaya iki:
Lan kita entuk ing ngisor iki:
Kepiye kedadeyane?
Nalika pusat data ambruk, master kita dadi bottleneck.
Kenapa?
Kasunyatane yaiku master duwe TaskBatcher, sing tanggung jawab kanggo nyebarake tugas lan acara tartamtu ing kluster. Sembarang simpul metu, promosi shard saka replika menyang utami, tugas apa wae kanggo nggawe shard nang endi wae - kabeh iki dadi pisanan menyang TaskBatcher, ing ngendi diproses kanthi urutan lan ing siji utas.
Ing wektu mundur saka siji pusat data, ternyata kabeh simpul data ing pusat data sing isih urip nganggep tugase kanggo ngandhani master "kita wis ilang pecahan kasebut lan simpul data kasebut."
Ing wektu sing padha, simpul data sing isih urip ngirim kabeh informasi kasebut menyang master saiki lan nyoba ngenteni konfirmasi yen dheweke nampa. Dheweke ora ngenteni iki, amarga master nampa tugas luwih cepet tinimbang sing bisa dijawab. Node wis rampung mbaleni panjalukan, lan master ing wektu iki ora nyoba mangsuli, nanging wis rampung digunakke ing tugas ngurutake panjalukan dening prioritas.
Ing wangun terminal, ternyata simpul data spammed master menyang titik sing dadi GC lengkap. Sawisé iku, peran master kita pindhah menyang sawetara simpul sabanjure, pancen padha kedadeyan, lan minangka asil kluster kasebut ambruk.
We njupuk pangukuran, lan sadurunge versi 6.4.0, ngendi iki wis didandani, iku cukup kanggo kita bebarengan output mung 10 simpul data saka 360 supaya rampung mati kluster.
Iku katon kaya iki:
Sawise versi 6.4.0, ing ngendi bug elek iki didandani, simpul data mandheg mateni master. Nanging iki ora nggawe dheweke "luwih pinter". Yaiku: nalika kita ngasilake 2, 3 utawa 10 (nomer liyane saka siji) simpul data, master nampa sawetara pesen pisanan sing ngandhani yen simpul A wis ninggalake, lan nyoba ngandhani simpul B, simpul C babagan iki, simpul D.
Lan ing wayahe, iki mung bisa ditangani kanthi nyetel wektu entek kanggo nyoba marang wong bab soko, witjaksono kanggo bab 20-30 detik, lan kanthi mangkono ngontrol kacepetan pusat data obah metu saka kluster.
Ing asas, iki cocog karo syarat sing pisanan diwenehi kanggo produk final minangka bagéan saka project, nanging saka sudut pandang "ilmu murni" iki bug. Kang, dening cara, wis kasil didandani dening pangembang ing versi 7.2.
Menapa malih, nalika simpul data tartamtu metu, ternyata nyebarake informasi babagan metune luwih penting tinimbang ngandhani kabeh kluster yen ana pecahan utama kasebut (kanggo ningkatake replika-shard ing data liyane. pusat ing utami, lan ing informasi bisa ditulis ing wong).
Mulane, nalika kabeh wis mati, simpul data sing dirilis ora langsung ditandhani minangka basi. Patut, kita kepeksa ngenteni nganti kabeh ping wis wektu metu kanggo simpul data dirilis, lan mung sawise kluster kita wiwit marang kita nang endi wae, ana, lan ing kono kita kudu terus ngrekam informasi. Sampeyan bisa maca liyane babagan iki .
Akibaté, operasi mbatalake pusat data saiki mbutuhake udakara 5 menit sajrone jam sibuk. Kanggo colossus sing gedhe lan kikuk, iki minangka asil sing apik banget.
Akibaté, kita njupuk keputusan ing ngisor iki:
- Kita duwe 360 simpul data kanthi 700 gigabyte disk.
- 60 koordinator kanggo nuntun lalu lintas liwat simpul data sing padha.
- 40 master sing wis ditinggalake minangka warisan wiwit versi sadurunge 6.4.0 - supaya bisa urip mundur saka pusat data, kita wis siyap mental ilang sawetara mesin supaya bisa dijamin duwe kuorum master sanajan ing skenario paling awon
- Sembarang usaha kanggo gabungke peran ing siji wadhah ketemu karo kasunyatan sing cepet utawa mengko simpul bakal break ing mbukak.
- Kabeh kluster nggunakake heap.size 31 gigabyte: kabeh upaya kanggo nyuda ukuran nyebabake salah siji mateni sawetara kelenjar ing pitakonan telusuran abot karo wildcard anjog utawa njupuk pemutus sirkuit ing Elasticsearch dhewe.
- Kajaba iku, kanggo mesthekake kinerja search, kita nyoba kanggo njaga jumlah obyek ing kluster minangka cilik sabisa kanggo proses minangka sawetara acara sabisa ing bottleneck sing kita entuk ing master.
Pungkasane babagan pemantauan
Kanggo mesthekake yen kabeh iki bisa ditindakake, kita ngawasi ing ngisor iki:
- Saben simpul data nglaporake menyang awan yen ana, lan ana pecahan kasebut. Nalika kita mateni soko nang endi wae, kluster laporan sawise 2-3 detik sing ing tengah A kita mateni simpul 2, 3, lan 4 - iki tegese ing pusat data liyane kita ing kahanan ora bisa mateni kelenjar sing mung ana siji beling. ngiwa.
- Ngerti sifat prilaku master, kita katon kanthi ati-ati babagan jumlah tugas sing ditundha. Amarga malah siji tugas macet, yen ora wektu metu ing wektu, miturut teori ing sawetara kahanan darurat bisa dadi alesan ngapa, contone, promosi shard tiron ing utami ora bisa, kang kok indeksasi bakal mandheg digunakake.
- Kita uga ndeleng kanthi rapet babagan penundaan pengumpul sampah, amarga kita wis ngalami kesulitan gedhe sajrone optimasi.
- Nolak dening thread kanggo ngerti ing advance ngendi bottleneck.
- Ya, metrik standar kayata heap, RAM lan I/O.
Nalika ngawasi bangunan, sampeyan kudu nggatekake fitur Thread Pool ing Elasticsearch. njlèntrèhaké opsi konfigurasi lan nilai standar kanggo telusuran lan indeksasi, nanging ora bisu babagan thread_pool.management. Utas iki ngolah, utamane, pitakon kaya _cat/shards lan liyane sing padha, sing trep digunakake nalika nulis pemantauan. Kluster luwih gedhe, luwih akeh panjaluk kasebut dileksanakake saben unit wektu, lan thread_pool.management kasebut ora mung ora ditampilake ing dokumentasi resmi, nanging uga diwatesi kanthi standar kanggo 5 benang, sing cepet banget dibuwang, sawise. sing ngawasi mandheg kanthi bener.
Apa sing arep dakkandhakake ing kesimpulan: kita nindakake! Kita bisa menehi programer lan pangembang alat sing, ing meh kabeh kahanan, bisa kanthi cepet lan andal nyedhiyakake informasi babagan apa sing kedadeyan ing produksi.
Ya, ternyata cukup rumit, nanging, nanging, kita bisa nyukupi kekarepan kita menyang produk sing wis ana, sing ora kudu ditambal lan ditulis maneh kanggo awake dhewe.
Source: www.habr.com