Seueur jalma bajoang sareng Elasticsearch. Tapi naon anu lumangsung nalika anjeun hoyong nganggo éta pikeun nyimpen log "dina volume anu ageung"? Sareng éta ogé henteu aya rasa nyeri ngalaman kagagalan salah sahiji sababaraha pusat data? Jenis arsitéktur naon anu anjeun kedah laksanakeun, sareng pitfalls naon anu anjeun bakal titajong?
Kami di Odnoklassniki mutuskeun nganggo elasticsearch pikeun ngabéréskeun masalah manajemén log, sareng ayeuna urang bagikeun pangalaman sareng Habr: boh ngeunaan arsitéktur sareng pitfalls.
Abdi Pyotr Zaitsev, abdi damel salaku administrator sistem di Odnoklassniki. Sateuacan éta, kuring ogé admin, damel sareng Manticore Search, Sphinx search, Elasticsearch. Panginten, upami panéangan anu sanés muncul, kuring sigana bakal tiasa dianggo ogé. Kuring ogé ilubiung dina sababaraha proyék open source sacara sukarela.
Nalika kuring sumping ka Odnoklassniki, kuring gagabah nyarios dina wawancara yén kuring tiasa damel sareng Elasticsearch. Sanggeus kuring meunang nongkrong jeung réngsé sababaraha pancén basajan, kuring dibéré tugas badag reforming sistem manajemen log anu aya dina waktu éta.
sarat
Sarat sistem dirumuskeun saperti kieu:
- Graylog kedah dianggo salaku frontend. Kusabab perusahaan parantos gaduh pangalaman nganggo produk ieu, programer sareng panguji terang éta, éta wawuh sareng merenah pikeun aranjeunna.
- Volume data: rata-rata 50-80 sarébu pesen per detik, tapi lamun aya nu ngarecah, lalu lintas teu diwatesan ku nanaon, bisa jadi 2-3 juta garis per detik.
- Saatos ngabahas sareng para nasabah sarat pikeun laju ngolah pamundut panéangan, kami sadar yén pola khas pikeun ngagunakeun sistem sapertos kieu: jalma-jalma milarian log aplikasina dina dua dinten ka pengker sareng henteu hoyong ngantosan langkung ti hiji kadua pikeun hasil query ngarumuskeun.
- Para pangurus negeskeun yén sistem éta gampang diskalakeun upami diperyogikeun, tanpa meryogikeun aranjeunna pikeun ngalenyepan langkung jero kumaha éta jalanna.
- Janten hiji-hijina tugas pangropéa anu diperyogikeun ku sistem ieu périodik nyaéta ngarobih sababaraha hardware.
- Salaku tambahan, Odnoklassniki ngagaduhan tradisi téknis anu saé: jasa naon waé anu kami luncurkeun kedah salamet tina gagalna pusat data (ngadadak, teu direncanakeun sareng leres-leres iraha waé).
Sarat panungtungan dina palaksanaan proyék ieu ngarugikeun urang paling, nu kuring bakal ngobrol ngeunaan leuwih jéntré.
Rebo
Kami damel di opat pusat data, sedengkeun titik data Elasticsearch ngan ukur tiasa aya dina tilu (kusabab sababaraha alesan non-teknis).
Opat pusat data ieu ngandung kira-kira 18 rébu sumber log anu béda - hardware, wadahna, mesin virtual.
fitur penting: klaster dimimitian dina peti teu dina mesin fisik, tapi dina . Wadahna dijamin 2 cores, sarupa jeung 2.0Ghz v4, kalawan kamungkinan ngadaur mulangkeunana cores sésana lamun aranjeunna dianggurkeun.
Istilah sanésna:
Topologi
Kuring mimitina ningali bentuk umum solusi sapertos kieu:
- 3-4 VIP aya di tukangeun A-catetan tina domain Graylog, ieu mangrupikeun alamat dimana log dikirim.
- unggal VIP mangrupa balancer LVS.
- Saatos éta, log asup ka batré Graylog, sababaraha data dina format GELF, sababaraha dina format syslog.
- Lajeng sadayana ieu ditulis dina bets badag ka batré koordinator Elasticsearch.
- Jeung maranéhna, kahareupna ngirim nulis jeung maca requests ka titik data relevan.
Terminologi
Panginten henteu sadayana ngartos terminologi sacara rinci, janten kuring badé ngémutan sakedik.
Elasticsearch gaduh sababaraha jinis titik - master, koordinator, titik data. Aya dua tipe séjén pikeun transformasi log béda jeung komunikasi antara klaster béda, tapi kami dipaké ngan maranéhanana didaptarkeun.
ngawasaan
Éta ping sadaya titik anu aya dina kluster, ngajaga peta kluster anu up-to-date sareng nyebarkeunana antara titik-titik, prosés logika acara, sareng ngalaksanakeun rupa-rupa housekeeping lega kluster.
koordinator
Ngalakukeun hiji tugas tunggal: narima maca atawa nulis requests ti klien tur ruteu lalulintas ieu. Bisi aya pamundut nulis, paling dipikaresep, éta bakal nanya master nu beling tina indéks relevan sakuduna nempatkeun eta, sarta bakal alihan pamundut salajengna.
Node data
Nyimpen data, ngalaksanakeun pamundut milarian anu sumping ti luar sareng ngalaksanakeun operasi dina beling anu aya di dinya.
graylog
Ieu mangrupikeun gabungan Kibana sareng Logstash dina tumpukan ELK. Graylog ngagabungkeun duanana UI sareng pipa pangolahan log. Di handapeun tiung, Graylog ngajalankeun Kafka sareng Zookeeper, anu nyayogikeun konektipitas ka Graylog salaku klaster. Graylog tiasa cache log (Kafka) upami Elasticsearch henteu sayogi sareng ngulang pamundut maca sareng nyerat anu gagal, grup sareng tanda log dumasar kana aturan anu ditangtukeun. Sapertos Logstash, Graylog ngagaduhan fungsionalitas pikeun ngarobih baris sateuacan nyeratna ka Elasticsearch.
Sajaba ti éta, Graylog boga kapanggihna jasa diwangun-di anu ngamungkinkeun, dumasar kana hiji titik Elasticsearch sadia, pikeun ménta sakabéh peta klaster sarta nyaring eta ku tag husus, nu ngamungkinkeun pikeun requests langsung kana wadahna husus.
Sacara visual sigana sapertos kieu:
Ieu screenshot ti conto husus. Di dieu urang ngawangun hiji histogram dumasar kana pamundut pilarian tur mintonkeun baris relevan.
Indéks
Balik deui ka arsitéktur sistem, kuring hoyong langkung rinci ngeunaan kumaha urang ngawangun modél indéks supados sadayana tiasa dianggo leres.
Dina diagram di luhur, ieu tingkat panghandapna: titik data Elasticsearch.
Indéks mangrupikeun éntitas maya ageung anu diwangun ku beling Elasticsearch. Dina sorangan, unggal beling teu leuwih ti hiji indéks Lucene. Sarta unggal indéks Lucene, kahareupna diwangun ku hiji atawa leuwih bagéan.
Nalika ngarancang, kami nyangka yén pikeun nyumponan sarat pikeun laju maca dina jumlah data anu ageung, urang kedah "nyebarkeun" data ieu sacara merata dina titik data.
Ieu nyababkeun kanyataan yén jumlah beling per indéks (kalayan réplika) kedah sami sareng jumlah titik data. Firstly, guna mastikeun faktor réplikasi sarua dua (nyaéta, urang bisa leungit satengah tina klaster). Jeung, Bréh, dina urutan ngolah maca jeung nulis requests on sahenteuna satengah tina klaster.
Urang mimiti nangtukeun waktu neundeun salaku 30 poé.
Sebaran beling tiasa digambarkeun sacara grafis sapertos kieu:
Sakabéh sagi opat abu poék mangrupa indéks. Kuadrat beureum kénca di jerona mangrupikeun beling primér, anu munggaran dina indéks. Jeung pasagi biru mangrupa beling replika. Éta lokasina di puseur data béda.
Lamun urang tambahkeun beling sejen, eta mana ka puseur data katilu. Sareng, tungtungna, urang nampi struktur ieu, anu ngamungkinkeun kaleungitan DC tanpa kaleungitan konsistensi data:
Rotasi indéks, i.e. nyieun indéks anyar jeung mupus hiji pangkolotna, urang dijieun sarua jeung 48 jam (nurutkeun pola pamakéan indéks: panungtungan 48 jam paling sering searched).
Interval rotasi indéks ieu disababkeun ku alesan ieu:
Nalika pamundut pilarian sumping ka titik data husus, lajeng, ti sudut pandang kinerja, éta leuwih nguntungkeun lamun hiji beling ieu queried, upami ukuranana comparable kana ukuran hip titik urang. Ieu ngamungkinkeun anjeun pikeun nyimpen bagian "panas" tina indéks dina tumpukan sareng gancang ngaksés éta. Lamun aya loba "bagian panas", laju pilarian indéks degrades.
Nalika hiji titik mimiti ngajalankeun pamundut pilarian dina hiji beling, éta allocates sababaraha threads sarua jeung jumlah cores hyperthreading tina mesin fisik. Upami pamundut pamilarian mangaruhan sajumlah ageung beling, maka jumlah benang naék sacara proporsional. Ieu boga dampak negatif kana speed pilarian sarta négatip mangaruhan indexing data anyar.
Pikeun nyadiakeun latency pilarian diperlukeun, urang mutuskeun pikeun ngagunakeun SSD. Pikeun gancang ngolah pamundut, mesin anu nyayogikeun wadah ieu kedah sahenteuna 56 inti. Angka 56 dipilih salaku nilai anu cukup sarat anu nangtukeun jumlah benang anu bakal ngahasilkeun Elasticsearch salami operasi. Dina Elasitcsearch, loba parameter thread pool langsung gumantung kana jumlah cores sadia, anu dina gilirannana langsung mangaruhan jumlah diperlukeun titik dina klaster nurutkeun prinsip "leuwih cores - leuwih titik".
Hasilna, urang manggihan yén rata-rata beling beuratna kira 20 gigabytes, sarta aya 1 shards per indéks. Sasuai, upami urang muterkeunana sakali unggal 360 jam, maka urang gaduh 48 di antarana. Unggal indéks ngandung data pikeun 15 dinten.
Nulis data jeung sirkuit bacaan
Hayu urang terang kumaha data kacatet dina sistem ieu.
Hayu urang nyebutkeun sababaraha pamundut datang ti Graylog ka koordinator nu. Contona, urang rék indéks 2-3 sarébu jajar.
Koordinator, nampi pamenta ti Graylog, naroskeun ka master: "Dina pamundut indéks, kami sacara khusus netepkeun indéks, tapi anu mana beling nyeratna henteu dieusian."
Master ngabales: "Tulis inpormasi ieu kana nomer beling 71," saatos éta dikirim langsung ka titik data anu relevan, dimana nomer beling primér 71 aya.
Sanggeus éta log urus ieu replicated ka replica-shard, anu lokasina di puseur data sejen.
Paménta milarian sumping ti Graylog ka koordinator. Koordinator alihan eta nurutkeun indéks, bari Elasticsearch distributes requests antara primér-shard jeung replica-shard ngagunakeun prinsip round-robin.
180 titik ngabales henteu rata, sareng nalika aranjeunna ngaréspon, koordinator ngumpulkeun inpormasi anu parantos "diciduh" ku titik data anu langkung gancang. Saatos ieu, nalika sadaya inpormasi parantos sumping, atanapi pamundut parantos dugi ka waktosna, éta masihan sadayana langsung ka klien.
Sakabéh sistem ieu rata-rata ngolah query pilarian salila 48 jam panungtungan dina 300-400ms, teu kaasup queries kalawan wildcard ngarah.
Kembang sareng Elasticsearch: Setélan Java
Jang ngalampahkeun eta kabeh jalan cara urang asalna hayang, urang spent waktu anu pohara lila debugging rupa-rupa hal dina klaster.
Bagian kahiji tina masalah anu kapanggih aya hubunganana sareng cara Java tos dikonpigurasi sacara standar dina Elasticsearch.
Masalah hiji
Kami parantos ningali sajumlah ageung laporan yén dina tingkat Lucene, nalika padamelan tukang jalan, bagean Lucene ngagabung gagal sareng kasalahan. Dina waktos anu sami, éta écés dina log yén ieu mangrupikeun kasalahan OutOfMemoryError. Kami ningali tina telemétri yén hip éta gratis, sareng éta henteu écés naha operasi ieu gagal.
Tétéla yén indéks Lucene merges lumangsung di luar hip. Sareng wadahna cukup ketat dina watesan sumber daya anu dikonsumsi. Ngan heap bisa nyocogkeun kana sumberdaya ieu (nilai heap.size kira-kira sarua jeung RAM), sarta sababaraha operasi off-numpuk nabrak kalawan kasalahan alokasi memori lamun pikeun sababaraha alesan maranéhna teu cocog kana ~ 500MB nu tetep saméméh wates.
Perbaikan éta rada sepele: jumlah RAM anu sayogi pikeun wadahna ningkat, saatos éta urang hilap yén urang ogé ngagaduhan masalah sapertos kitu.
Masalah kadua
4-5 dinten saatos peluncuran kluster, urang perhatikeun yén titik data mimiti turun tina kluster périodik sareng lebetkeun saatos 10-20 detik.
Nalika urang mimiti terang, tétéla yén mémori pareum-numpuk ieu dina Elasticsearch henteu dikontrol ku cara naon waé. Nalika kami masihan langkung memori ka wadahna, kami bisa ngeusian pools panyangga langsung kalayan sagala rupa informasi, sarta eta diberesihan ngan sanggeus GC eksplisit diawalan tina Elasticsearch.
Dina sababaraha kasus, operasi ieu nyandak rada lila, sarta salila ieu klaster junun nandaan titik ieu geus kaluar. masalah ieu ogé digambarkeun .
Solusina nyaéta kieu: kami ngawatesan kamampuan Java pikeun ngagunakeun mémori anu ageung di luar tumpukan pikeun operasi ieu. Kami dugi ka 16 gigabyte (-XX: MaxDirectMemorySize = 16g), mastikeun yén GC eksplisit disebut langkung sering sareng diolah langkung gancang, ku kituna henteu deui ngaganggu kluster.
Masalah tilu
Lamun Anjeun mikir yén masalah sareng "titik ninggalkeun klaster dina momen paling teu kaduga" geus réngsé, anjeun salah.
Nalika kami ngonpigurasi karya kalawan indexes, urang milih mmapfs mun on shards seger kalawan segmentation hébat. Ieu rada blunder a, sabab lamun maké mmapfs file dipetakeun kana RAM, lajeng urang dianggo kalayan file dipetakeun. Kusabab ieu, tétéla yén nalika GC nyobian ngeureunkeun utas dina aplikasi, urang angkat ka safepoint pikeun waktos anu lami pisan, sareng dina jalanna, aplikasina lirén ngaréspon kana pamundut master ngeunaan naha éta hirup. . Sasuai, master percaya yén titik henteu aya dina kluster. Saatos ieu, saatos 5-10 detik, tukang sampah damel, titikna hirup, asup deui kluster sareng ngamimitian ngamimitian beling. Eta sadayana dirasakeun pisan kawas "produksi kami deserved" na éta teu cocog pikeun nanaon serius.
Pikeun ngaleungitkeun kabiasaan ieu, urang mimiti ngalih ka niofs standar, teras, nalika urang hijrah tina versi kalima Elastis ka kagenep, urang nyobian hybridfs, dimana masalah ieu henteu diproduksi deui. Anjeun tiasa maca langkung seueur ngeunaan jinis panyimpen .
Masalah opat
Lajeng aya masalah sejen pisan metot nu urang dirawat pikeun waktos catetan. Kami nyekel éta pikeun 2-3 bulan sabab polana leres-leres teu kaharti.
Kadang-kadang koordinator urang indit ka Full GC, biasana sometime sanggeus dahar beurang, sarta pernah balik ti dinya. Dina waktos anu sami, nalika logging tunda GC, katingalina sapertos kieu: sadayana jalanna, muhun, teras ujug-ujug sadayana parah pisan.
Awalna urang ngira yén urang boga pamaké jahat anu launching sababaraha jenis pamundut nu knocked koordinator kaluar tina mode gawé. Urang log requests lila pisan, nyoba angka kaluar naon anu lumangsung.
Hasilna, tétéla yén dina momen nalika pamaké ngaluncurkeun pamundut badag, sarta nya meunang ka koordinator Elasticsearch husus, sababaraha titik ngabales leuwih panjang batan batur.
Sareng nalika koordinator ngantosan tanggapan ti sadaya titik, anjeunna ngumpulkeun hasil anu dikirim tina titik anu parantos ngaréspon. Pikeun GC, ieu hartosna pola pamakean tumpukan urang gancang pisan robih. Sareng GC anu kami anggo henteu tiasa ngatasi tugas ieu.
Hijina fix kami kapanggih pikeun ngarobah paripolah klaster dina kaayaan ieu migrasi ka JDK13 sarta pamakéan collector sampah Shenandoah. Ieu direngsekeun masalah, koordinator urang dieureunkeun ragrag.
Ieu dimana masalah sareng Java réngsé sareng masalah rubakpita dimimitian.
"Berries" sareng Elasticsearch: throughput
Masalah sareng throughput hartosna kluster urang tiasa dianggo sacara stabil, tapi dina puncak jumlah dokumén anu diindeks sareng nalika manuver, kinerja henteu cekap.
Gejala kahiji anu dipendakan: salami sababaraha "ngabeledug" dina produksi, nalika sajumlah ageung log anu ujug-ujug dibangkitkeun, kasalahan indexing es_rejected_execution mimiti sering kedip-kedip dina Graylog.
Ieu alatan kanyataan yén thread_pool.write.queue on hiji titik data, nepi ka momen Elasticsearch téh bisa ngolah pamundut indexing sarta unggah informasi ka beling on disk, sanggup cache ngan 200 requests sacara standar. Jeung di Saeutik pisan anu nyarios ngeunaan parameter ieu. Ngan jumlah maksimum benang sareng ukuran standar anu dituduhkeun.
Tangtu, urang indit ka pulas nilai ieu sarta kapanggih kaluar di handap: husus, dina setelan urang, nepi ka 300 requests anu sindangan cukup alus, sarta nilai luhur fraught kalawan kanyataan yén urang deui ngapung ka Full GC.
Salaku tambahan, saprak ieu bets pesen anu sumping dina hiji pamundut, nya éta diperlukeun pikeun tweak Graylog meh nulis teu sering jeung bets leutik, tapi bets badag atawa sakali unggal 3 detik lamun bets masih teu lengkep. Dina hal ieu, tétéla yén inpormasi anu kami tulis dina Elasticsearch sayogi henteu dina dua detik, tapi dina lima (anu cocog sareng kami saé), tapi jumlah retrays anu kedah dilakukeun pikeun nyorong anu ageung. tumpukan informasi ngurangan.
Ieu hususna penting dina maranéhanana moments lamun hal geus nabrak wae jeung furiously ngalaporkeun ngeunaan eta, ku kituna teu meunang lengkep spammed Elastis, sarta sanggeus sababaraha waktu - titik Graylog nu inoperable alatan panyangga clogged.
Salaku tambahan, nalika urang ngabeledug anu sami dina produksi, kami nampi keluhan ti programer sareng panguji: dina waktos éta leres-leres peryogi log ieu, aranjeunna dipasihkeun lalaunan pisan.
Aranjeunna mimiti terang éta. Di hiji sisi, éta jelas yén duanana queries pilarian sarta queries indexing anu diolah, dasarna, dina mesin fisik sarua, sarta salah sahiji atawa cara séjén bakal aya drawdowns tangtu.
Tapi ieu tiasa dihindari sawaréh kusabab kanyataan yén dina vérsi kagenep Elasticsearch, algoritma muncul anu ngamungkinkeun anjeun nyebarkeun patarosan antara titik-titik data anu relevan henteu dumasar kana prinsip round-robin acak (wadah anu ngindeks sareng nyepeng primér. -shard bisa jadi pisan sibuk, moal aya deui jalan pikeun ngabales gancang), tapi mun diteruskeun pamundut ieu wadahna kirang dimuat ku replica-shard, nu bakal ngabales leuwih gancang. Dina basa sejen, urang anjog di use_adaptive_replica_selection: leres.
Gambar bacaan mimiti kasampak kawas kieu:
Transisi kana algoritma ieu ngamungkinkeun pikeun sacara signifikan ningkatkeun waktos query dina waktos-waktos urang ngagaduhan aliran log anu ageung pikeun nyerat.
Tungtungna, masalah utama nyaéta panyabutan henteu aya rasa nyeri tina pusat data.
Anu kami pikahoyong tina kluster saatos kaleungitan sambungan sareng hiji DC:
- Upami urang gaduh master ayeuna di pusat data anu gagal, maka éta bakal dipilih deui sareng dipindahkeun salaku peran ka titik anu sanés dina DC anu sanés.
- Master bakal gancang ngahapus sadaya titik anu teu tiasa diaksés tina kluster.
- Dumasar kana sésa-sésa, anjeunna bakal ngartos: di pusat data anu leungit kami ngagaduhan beling primér sapertos kitu, anjeunna bakal gancang ngamajukeun beling réplika pelengkap dina sésa-sésa pusat data, sareng kami bakal terus ngindeks data.
- Salaku hasil tina ieu, tulisan kluster urang jeung throughput bacaan laun bakal nguraikeun, tapi sacara umum sagalana bakal jalan, sanajan lalaunan, tapi stably.
Salaku tétéla, urang hayang hiji hal kawas kieu:
Sareng kami ngagaduhan ieu:
Kumaha ieu kajadian?
Nalika pusat data murag, master kami janten bottleneck.
Naha?
Kanyataanna nyaéta master gaduh TaskBatcher, anu tanggung jawab pikeun nyebarkeun tugas sareng acara anu tangtu dina kluster. Sakur kaluar titik, naon waé promosi beling ti réplika ka primér, naon waé tugas pikeun nyiptakeun beling dimana waé - sadayana ieu mimitina ka TaskBatcher, dimana éta diolah sacara berurutan sareng dina hiji benang.
Dina waktos ditarikna hiji pusat data, tétéla yén sadaya titik data dina pusat data anu salamet dianggap tugasna pikeun nginpokeun ka master "urang kaleungitan beling sapertos kitu sareng titik data sapertos kitu."
Dina waktos anu sami, titik data anu salamet dikirimkeun sadayana inpormasi ieu ka master ayeuna sareng nyobian ngantosan konfirmasi yén anjeunna nampi éta. Aranjeunna teu ngadagoan ieu, sabab master narima tugas gancang ti anjeunna bisa ngajawab. The titik timed kaluar requests repeating, sarta master dina waktu ieu teu coba mun ngajawab aranjeunna, tapi sagemblengna kaserep dina tugas asihan requests ku prioritas.
Dina formulir terminal, tétéla yén titik data spammed master nepi ka titik nu eta lebet kana GC pinuh. Sanggeus éta, peran master urang dipindahkeun ka sababaraha titik salajengna, hal anu sarua kajadian ka dinya, sarta salaku hasilna klaster sagemblengna ambruk.
Kami nyandak pangukuran, sareng sateuacan versi 6.4.0, dimana ieu dibenerkeun, éta cekap pikeun urang sakaligus kaluaran ngan ukur 10 titik data tina 360 pikeun nutup klaster sacara lengkep.
Éta katingali sapertos kieu:
Saatos versi 6.4.0, dimana bug dahsyat ieu dibereskeun, titik data dieureunkeun killing master. Tapi éta henteu ngajantenkeun anjeunna "langkung pinter." Nyaéta: nalika urang kaluaran 2, 3 atanapi 10 (sagala angka lian ti hiji) titik data, master narima sababaraha pesen munggaran nu nyebutkeun yén titik A geus ditinggalkeun, sarta nyoba ngabejaan titik B, titik C ngeunaan ieu, titik D.
Sarta di momen, ieu ngan bisa diurus ku netepkeun waktu kaluar pikeun usaha ngabejaan batur ngeunaan hiji hal, sarua jeung ngeunaan 20-30 detik, sahingga ngadalikeun laju puseur data pindah kaluar kluster.
Sacara prinsip, ieu cocog kana sarat anu mimitina dibere ka produk ahir salaku bagian tina proyék, tapi tina sudut pandang "ilmu murni" ieu bug a. Anu, ku jalan kitu, suksés dibenerkeun ku pamekar dina versi 7.2.
Sumawona, nalika titik data anu tangtu kaluar, tétéla nyebarkeun inpormasi ngeunaan jalan kaluarna langkung penting tibatan nyarios ka sadayana klaster yén aya beling primér sapertos kitu (pikeun ngamajukeun réplika-shard dina data anu sanés. puseur dina primér, sarta dina informasi bisa ditulis dina aranjeunna).
Ku alatan éta, nalika sagalana geus maot handap, titik data dileupaskeun teu langsung ditandaan salaku bulukan. Sasuai, urang kapaksa ngadagoan nepi ka sadaya pings geus timed kaluar ka titik data dileupaskeun, sarta ngan sanggeus éta klaster urang ngawitan ngabejaan urang yen aya, aya, jeung aya urang kudu neruskeun ngarekam informasi. Anjeun tiasa maca langkung seueur ngeunaan ieu .
Hasilna, operasi mundur pusat data ayeuna nyandak urang sakitar 5 menit salami jam sibuk. Pikeun kolosus anu ageung sareng kagok, ieu mangrupikeun hasil anu saé.
Hasilna, urang sumping ka kaputusan di handap ieu:
- Kami gaduh 360 titik data sareng 700 gigabyte disk.
- 60 koordinator pikeun routing lalulintas ngaliwatan ieu titik data sarua.
- 40 master anu kami tinggalkeun salaku jinis warisan ti saprak vérsi sateuacan 6.4.0 - supados salamet ditarikna pusat data, kami siap mental kaleungitan sababaraha mesin supados dijamin gaduh kuorum master bahkan dina skenario hal awon
- Sagala usaha pikeun ngagabungkeun peran dina hiji wadah anu patepung jeung kanyataan yén sooner atanapi engké titik bakal megatkeun dina beban.
- Sakabeh klaster ngagunakeun heap.size 31 gigabytes: sagala usaha pikeun ngurangan ukuranana ngakibatkeun boh maéhan sababaraha titik dina queries pilarian beurat jeung wildcard ngarah atawa meunang circuit breaker di Elasticsearch sorangan.
- Sajaba ti éta, pikeun mastikeun kinerja pilarian, urang diusahakeun tetep jumlah objék dina klaster sakumaha leutik sabisa, dina urutan pikeun ngolah sababaraha acara sabisa dina bottleneck nu urang meunang dina master.
Tungtungna ngeunaan monitoring
Pikeun mastikeun yén sadaya ieu jalan sakumaha anu dimaksud, kami ngawaskeun ieu:
- Unggal titik data ngalaporkeun ka awan urang yén éta aya, sareng aya beling sapertos kitu. Nalika urang mareuman hiji hal di mana waé, klaster ngalaporkeun saatos 2-3 detik yén di pusat A urang mareuman titik 2, 3, sareng 4 - ieu hartosna di pusat data sanés urang dina kaayaan naon waé tiasa mareuman titik-titik anu ngan aya hiji beling. ditinggalkeun.
- Nyaho sifat paripolah master, urang taliti pisan kana jumlah tugas anu ditangguhkeun. Kusabab sanajan hiji tugas nyangkut, upami teu waktos kaluar dina waktu, téoritis dina sababaraha kaayaan darurat bisa jadi alesan naha, contona, promosi beling replica dina primér teu jalan, naha nu mangrupa indexing bakal eureun gawé.
- Urang ogé kasampak raket pisan dina reureuh collector sampah, sabab urang geus ngalaman kasusah hébat dina mangsa optimasi.
- Nolak ku thread ngartos sateuacanna dimana bottleneck nu.
- Nya, métrik standar sapertos tumpukan, RAM sareng I / O.
Nalika ngawangun monitoring, anjeun kedah tumut kana fitur Thread Pool dina Elasticsearch. ngajelaskeun pilihan konfigurasi sareng nilai standar pikeun milarian sareng ngindeks, tapi lengkep jempé ngeunaan thread_pool.management. Proses utas ieu, khususna, patarosan sapertos _cat/shards sareng anu sanésna, anu cocog pikeun dianggo nalika nyerat monitoring. The badag klaster, beuki requests sapertos anu dieksekusi per Unit waktu, sarta thread_pool.management disebut tadi teu ngan teu dibere dina dokuméntasi resmi, tapi ogé dugi sacara standar 5 threads, nu pisan gancang disposed tina, sanggeus. nu ngawaskeun eureun gawéna leres.
Naon anu kuring hoyong nyarios dina kacindekan: urang ngalakukeun éta! Kami tiasa masihan programer sareng pamekar alat anu, dina ampir kaayaan naon waé, tiasa gancang sareng dipercaya masihan inpormasi ngeunaan naon anu lumangsung dina produksi.
Sumuhun, tétéla rada pajeulit, tapi, Tapi, urang junun nyocogkeun kahayang urang kana produk aya, nu urang teu kudu patch na nulis balik pikeun diri urang sorangan.
sumber: www.habr.com