Têketin beşek girîng a pergalê ne, ku dihêle hûn fêm bikin ku ew wekî ku tê hêvî kirin dixebite (an naxebite). Di mîmariya mîkroxizmetê de, xebata bi têketin ji bo Olîmpiyadek taybetî dibe dîsîplînek cihê. Gelek pirs divê bi yekcarî bêne çareser kirin:
- meriv çawa ji serîlêdanê têketin binivîse;
- li ku derê têketin binivîse;
- meriv çawa têketinên ji bo hilanîn û hilanînê radest dike;
- çawa têketin û hilanînê.
Bikaranîna teknolojiyên konteynirkirinê yên niha yên populer qûmê li ser rakê li qada vebijarkan ji bo çareserkirina pirsgirêkê zêde dike.
Tişta ku li ser nivîsa rapora Yuri Bushmelev ya bi navê "Nexşeya rakêşan di warê berhevkirin û radestkirina daran" de ye ev e.
Kî xem dike, kerem bike binê pisîkê.
Navê min Yuri Bushmelev e. Ez li Lazada dixebitim. Îro ez ê bipeyivim ka me têketinên xwe çawa çêkirin, me ew çawa berhev kirin û em li wir çi dinivîsin.
Em ji ku derê ne? Em kî ne? Lazada di şeş welatên li Asyaya Başûr-rojhilatê de firotgeha serhêl a No. 1 e. Hemî van welatan di nav navendên daneyên me de têne belav kirin. Niha bi tevahî 4 navendên daneyê hene, çima ev girîng e? Ji ber ku hin biryar ji ber wê yekê bûn ku pêwendiyek pir lawaz di navbera navendan de heye. Mîmarek mîkroxizmeta me heye. Ez şaş bûm ku min dît ku me berê 80 mîkroxizmet hene. Dema ku min dest bi peywira bi têketinan kir, tenê 20 ji wan hebûn. Bi ser de jî mîrasek pir mezin a PHP-ê heye, ku ez jî pê re bijîm û bi ser kevim. Ev hemî niha ji bo pergalê bi tevahî ji 6 mîlyon peyaman di hûrdemê de bêtir diafirîne. Dûv re ez ê nîşan bidim ka em çawa hewl didin ku bi vê re bijîn, û çima wusa ye.
Divê hûn bi awayekî bi van 6 mîlyon peyaman bijîn. Divê em bi wan re çi bikin? 6 mîlyon peyamên ku hûn hewce ne:
- ji sepanê bişînin
- ji bo teslîmkirina qebûl
- ji bo analîz û hilanînê radest bikin.
- lêkolîn
- bi awayekî hilanîn.
Dema ku sê mîlyon peyam xuya bûn, min li heman yekê nêrî. Ji ber ku me tenê bi çend qurişan dest pê kir. Diyar e ku têketinên serîlêdanê li wir hatine nivîsandin. Mesela, min nekarî bi databasê ve girêbidim, min karîbû bi databasê ve girêbide lê min nikarî tiştek bixwînim. Lê ji bilî vê, her mîkroxizmeta me jî têketinek gihîştinê dinivîse. Her daxwazek ku digihîje mîkroservisê di têketinê de tê tomar kirin. Çima em vê yekê dikin? Pêşdebir dixwazin ku karibin bişopînin. Her têketinek gihîştinê zeviyek traceid-ê vedihewîne, ku tê de têkiliyek taybetî bikar tîne û dûv re tevahiya zincîrê vedike û bi xweşikî şopê nîşan dide. Şop nîşan dide ka daxwaz çawa çû, û ev ji pêşdebirên me re dibe alîkar ku zû bi her zibilek nenas re mijûl bibin.
Meriv çawa bi vê yekê re bijî? Naha ez ê bi kurtasî qada vebijarkan diyar bikim - ev pirsgirêk bi gelemperî çawa tê çareser kirin. Meriv çawa pirsgirêka berhevkirin, veguheztin û hilanîna têketin çareser dike.
Meriv çawa ji serîlêdanê binivîse? Diyar e ku rêyên cuda hene. Bi taybetî, wekî ku hevalên me yên moda ji me re dibêjin, pratîka çêtirîn heye. Du celeb dibistanên kevn hene, wek ku kalikên me ji me re gotine. Rêyên din jî hene.
Rewşa berhevkirina têlan jî bi heman rengî ye. Ji bo çareserkirina vê beşa taybetî gelek vebijark tune. Jixwe gelek ji wan hene, lê hêj ne ewqas zêde ne.
Lê bi radestkirin û analîza paşîn re, hejmara variations dest bi teqandinê dike. Ez ê niha her vebijarkê venabêjim. Ez difikirim ku vebijarkên sereke ji her kesê ku bi mijarê re eleqedar e baş têne zanîn.
Ez ê nîşanî we bidim ka me ew çawa li Lazada kir, û bi rastî ew çawa dest pê kir.
Salek berê ez hatim Lazada û min şandin projeyek li ser têketin. Tiştekî wiha bû. Têketina serîlêdanê ji stdout û stderr re hate nivîsandin. Her tişt bi şêwazek modê hate kirin. Lê dûv re pêşdebiran ew ji herikîna standard avêtin, û dûv re bi rengek pisporên binesaziyê dê wê fêhm bikin. Di navbera pisporên binesaziyê û pêşdebiran de, serbestber jî hene ku digotin: "Ew ... baş e, em tenê wan di pelek bi şêlê de bipêçin, û ew e." Û ji ber ku ev hemû di konteynirê de bû, wan ew rast di konteynirê de pêça, nexşeya katalogê li hundur danî û danîn. Ez difikirim ku ji her kesî re pir eşkere ye ku çi jê hat.
Werin em ji bo niha hinekî din binerin. Me çawa van qeydan radest kir? Kesek td-agent hilbijart, ku bi rastî şêrîn e, lê ne tam ne xweş e. Ez hîn jî têkiliya di navbera van her du projeyan de fam nakim, lê dixuye ku ew li ser heman tiştî ne. Û ev herikbar, ku bi Ruby hatî nivîsandin, pelên têketinê dixwend, wan di JSON de bi karanîna cûreyek rêkûpêk veqetand. Paşê min ew şandin cem Kafka. Wekî din, di Kafka de ji bo her API-ê 4 mijarên me yên cuda hebûn. Çima 4? Ji ber ku zindî heye, sehkirin heye, û ji ber ku stdout û stderr heye. Pêşdebir wan diafirînin, û pêşdebirên binesaziyê divê wan di Kafka de biafirînin. Wekî din, Kafka ji hêla dezgehek din ve hate kontrol kirin. Ji ber vê yekê, pêdivî bû ku bilêtek çêbibe ku ew ji bo her apiyekê 4 mijaran çêbikin. Her kesî ew ji bîr kir. Bi gelemperî, çopê û tevlihevî hebû.
Me bi vê yekê çi kir? Me ji Kafka re şand. Paşê nîvê têlên ji Kafka firiyabûn Logstash. Nîvê dî yên têketin hatin dabeşkirin. Hin firiyan Graylogek, hin ji bo Graylogek din. Wekî encamek, ev hemî ketin yek komê Elasticsearch. Yanî ev hemû tevlihevî bi dawî bû. Vê yekê nekin!
Ger hûn ji jor ve lê binihêrin ev e ku ew dixuye. Vê yekê nekin! Li vir deverên pirsgirêk yekser bi hejmaran têne nîşankirin. Bi rastî bêtir ji wan hene, lê 6 bi rastî jî pirsgirêk in ku divê li ser wan tiştek were kirin. Ez ê niha li ser wan ji hev cuda vebêjim.
Li vir (1,2,3) em pelan dinivîsin û, li gorî vê yekê, li vir yekcar sê rakêş hene.
Ya yekem (1) ev e ku divê em wan li cîhek binivîsin. Dê her gav neyê xwestin ku meriv API-ê bide ku rasterast li pelek binivîse. Tê xwestin ku API di konteynerek de were veqetandin, an jî çêtir e, ku ew tenê-xwendin be. Ez rêveberek pergalê me, ji ber vê yekê min nêrînek hinekî alternatîf a van tiştan heye.
Xala duyemîn (2,3) ev e ku me gelek daxwazên ku têne API-yê hene. API gelek daneyan li pelek dinivîse. Dosya zêde dibin. Divê em wan bizivirînin. Ji ber ku wekî din hûn ê nikaribin li wir li ser ti dîskê berhev bikin. Zivirandina wan xirab e ji ber ku ew bi beralîkirina şêlê berbi pelrêçê têne çêkirin. Bi tu awayî em nikarin wê ji nû ve biguherînin. Hûn nikarin ji serîlêdanê re bêjin ku destan ji nû ve veke. Ji ber ku pêşdebir dê mîna ku hûn bêaqil in li we binerin: "Kîjan raveker? Em bi gelemperî ji stdout re dinivîsin." Pêşdebirên binesaziyê ji bo logrotate copytruncate çêkirine, ku bi tenê kopiyek pelê çêdike û orîjînalê vediguheze. Li gorî vê yekê, di navbera van pêvajoyên kopîkirinê de cîhê dîskê bi gelemperî diqede.
(4) Me di API-yên cihêreng de formên cûda hebûn. Ew hinekî cuda bûn, lê diviyabû regexp cuda bihata nivîsandin. Ji ber ku ev hemî ji hêla Puppet ve hate kontrol kirin, komek mezin ji çînên bi dîkên xwe re hebûn. Zêdeyî, pirê caran td-agent dikaribû bîranînê bixwe, bêaqil be, ew tenê dikaribû bifikire ku ew dixebitî û tiştek nekir. Ji derve ne mimkûn bû ku fêm bikira ku ew tiştek nake. Ya herî baş, ew ê bikeve û kesek wê paşê wî hilde. Zêdetir, dê hişyariyek were, û kesek dê biçe û wê bi destên xwe rabike.
(6) Û ya herî zibil û çopê lêgerîna elastîk bû. Ji ber ku ew versiyonek kevn bû. Ji ber ku wê demê mamosteyên me yên fedakar tunebûn. Têketinên me yên heterojen hebûn ku zeviyên wan dikarin li hev bikevin. Têketinên cihêreng ên ji serîlêdanên cûda dikarin bi heman navên zeviyê werin nivîsandin, lê dibe ku di hundurê de daneyên cûda hebin. Ango, yek têketin bi Integer di zeviyê de tê, mînakî, astê. Têketinek din bi String re di qada astê de tê. Di nebûna nexşeya statîk de, ev tiştek ecêb e. Ger, piştî zivirîna indexê di elasticsearch de, pêşî peyamek bi rêzek were, wê hingê em normal dijîn. Lê heke yekem ji Integer hat, wê hingê hemî peyamên paşîn ên ku ji String hatine bi tenê têne avêtin. Ji ber ku cureyê zeviyê li hev nayê.
Me dest bi van pirsan kir. Me biryar da ku em li kesên sûcdar negerin.
Lê divê tiştek bê kirin! Tiştê diyar ew e ku divê em pîvanan ava bikin. Jixwe hin pîvanên me hebûn. Me hinekî paşê dest pê kir. Xweşbextane, di wê demê de ji bo hemî API-an formatek têketinek yekane hatibû pejirandin. Ew rasterast di standardên danûstendina di navbera karûbaran de hatî nivîsandin. Li gorî vê yekê, kesên ku dixwazin têketinê werbigirin divê bi vî rengî binivîsin. Ger kesek têketinên bi vî rengî nenivîse, wê hingê em tiştek garantî nakin.
Dûv re, ez dixwazim standardek yekgirtî ji bo awayên tomarkirin, radestkirin û berhevkirina têketin biafirînim. Bi rastî, li ku derê wan binivîsin, û çawa wan radest bikin. Rewşa îdeal ev e ku gava proje heman pirtûkxaneyê bikar tînin. Ji bo Go pirtûkxaneyek têketinê ya cihê heye, ji bo PHP jî pirtûkxaneyek cihê heye. Divê her kesê me wan bikar bîne. Di vê demê de ez dibêjim ku em ji sedî 80 di vê yekê de serkeftî ne. Lê hin kes xwarina kaktusan didomînin.
Û li wir (li ser slaytê) "SLA ji bo radestkirina têketin" bi zor dest pê dike. Hîn tune ye, lê em li ser dixebitin. Ji ber ku dema ku binesaziyê dibêje heke hûn bi vî rengî ji filan cîhek re binivîsin û ji her çirkeyê bêtir ji N peyaman binivîsin pir rehet e, wê hingê bi îhtîmalek mezin em ê wê bigihînin cîhek filan. Ev yek ji serêşê gelek kêm dike. Ger SLA hebe, wê hingê ev bê guman ecêb e!
Me çawa dest bi çareserkirina pirsgirêkê kir? Pirsgirêka sereke bi td-agent bû. Ne diyar bû qeydên me bi ku ve çûn. Ew têne radest kirin? Ma ew diçin? Ew li ku derê ne? Ji ber vê yekê, xala yekem hate biryar da ku td-agent biguhezîne. Min bi kurtî vebijarkên ji bo çi li vir biguhezîne destnîşan kir.
Fluentd. Pêşî, ez di karekî berê de pê re rû bi rû hatim û ew jî dem bi dem ketibû wir. Ya duyemîn, ev heman tişt e, tenê di profîlê de.
Filebeat. Çawa ji me re xweş bû? Ji ber ku ew di Go de ye, û di Go de gelek pisporiya me heye. Li gorî vê yekê, ger tiştek biqewime, em dikarin bi rengekî ji xwe re lê zêde bikin. Ji ber vê yekê me ew negirt. Ji ber ku tewra çu ceribandinek tune ku hûn ji bo xwe dest bi ji nû ve nivîsandinê bikin.
Çareseriya eşkere ya ji bo rêvebirê pergalê her cûre syslogs di vê hejmarê de ye (syslog-ng/rsyslog/nxlog).
An jî tiştek ji xwe re binivîsin, lê me ev yek, û hem jî pelebeat ji holê rakir. Heke hûn tiştek binivîsin, çêtir e ku hûn ji bo karsaziyê tiştek kêrhatî binivîsin. Ji bo radestkirina têketin, çêtir e ku meriv tiştek amade bavêje.
Ji ber vê yekê, bijare bi rastî li hilbijartina di navbera syslog-ng û rsyslog de hat. Min berê xwe da rsyslog tenê ji ber ku me berê dersên rsyslog li Puppet hebûn, û min cûdahiyek eşkere di navbera wan de nedît. syslog çi ye, syslog çi ye. Erê, hinekan belgeyên xerabtir hene, hinekan çêtir in. Ev yek dikare bi vî rengî bike, û yê din dikare cûda bike.
Û hinekî li ser rsyslog. Berî her tiştî, ew xweş e ji ber ku gelek modulên wê hene. Ew RainerScript (zimanek veavakirina nûjen) ku ji hêla mirovan ve tê xwendin heye. Ew bonûsek ecêb e ku em dikarin tevkariya td-agent bi karanîna amûrên standard bişopînin, û ji bo serîlêdanan tiştek neguherî. Ango, em td-agent diguhezînin rsyslog, û her tiştê din ji bo nuha bihêlin. Û em tavilê radestkirina xebatê distînin. Dûv re, mmnormalize di rsyslog de tiştek ecêb e. Ew dihêle hûn têketinên parsek bikin, lê ne bi Grok û regexp. Ew dara hevoksaziyê ya razber çêdike. Ew têketinan bi heman awayê ku berhevkar jêderan par dike par dike. Ev dihêle hûn pir zû bixebitin, CPU-ya piçûk bixwin, û, bi gelemperî, ew tiştek pir xweş e. Gelek bonusên din hene. Ez ê li ser wan nesekinim.
rsyslog gelek kêmasiyên din hene. Ew li ser heman bonus in. Pirsgirêkên sereke ev e ku hûn hewce ne ku hûn zanibin ka meriv wê çawa çêdike, û hûn hewce ne ku guhertoyê hilbijêrin.
Me biryar da ku em ê têketin li ser soketek unix binivîsin. Û ne di /dev/log de, ji ber ku li wir têketinên pergalê me tevliheviyek heye, rojname di vê boriyê de ye. Ji ber vê yekê werin em li soketek xwerû binivîsin. Em ê wê bi qaîdeyek cûda ve girêbidin. Em mudaxeleyî tiştekî nekin. Her tişt dê zelal û têgihîştî be. Tiştê ku me kir tam ev e. Pelrêça bi van soketan re standardkirî ye û ji hemî konteyneran re tê şandin. Konteyner dikarin soketa ku ew hewce ne bibînin, vekin û jê re binivîsin.
Çima ne pelek? Ji ber ku her kesî ew dixwîne , ku hewl da ku pelek ji docker re bişîne, û hate kifş kirin ku piştî ji nû ve destpêkirina rsyslog, ravekera pelê guherî, û docker ev pel winda kir. Ew tiştek din vekirî dihêle, lê ne soketa ku ew lê dinivîsin. Me biryar da ku em ê li ser vê pirsgirêkê bixebitin, û di heman demê de, em ê li dora pirsgirêka astengkirinê bixebitin.
Rsyslog kiryarên ku li ser slaytê hatine destnîşan kirin pêk tîne û têketin ji relay an jî Kafka re dişîne. Kafka riya berê dişopîne. Relay - Min hewl da ku rsysloga paqij bikar bînim da ku têketin radest bikim. Bêyî Dora Peyamê, bi karanîna amûrên standard rsyslog. Di bingeh de, ew dixebite.
Lê nuans hene ku meriv wan çawa di vê beşê de bikişîne (Logstash / Graylog / ES). Ev beş (rsyslog-rsyslog) di navbera navendên daneyê de tê bikaranîn. Li vir zencîreyek tcp-ê ya pêçandî heye, ku dihêle ku em bandbêdeyê hilînin û, li gorî vê yekê, bi rengekî îhtîmala ku em ê hin têketin ji navendek daneya din wergirin dema ku kanal tê girtin zêde bikin. Ji ber ku me Endonezya heye, ku her tişt xirab e. Pirsgirêka domdar li vir e.
Me fikirîn ka em çawa dikarin bi rastî çavdêrî bikin ka çiqasî gengaz e ku têketinên ku me ji serîlêdanê tomar kirine bigihîjin dawiyê? Me biryar da ku metrîkan çêbikin. rsyslog modulek berhevkirina statîstîkên xwe heye, ku tê de cûreyek jimarvan vedihewîne. Mînakî, ew dikare mezinahiya dorê nîşanî we bide, an jî çend peyam di çalakiyek wusa û wusa de hatine. Hûn dikarin jixwe tiştek ji wan bistînin. Zêdeyî, wê hejmarên xwerû hene ku dikarin werin mîheng kirin, û ew ê ji we re, mînakî, hejmara peyamên ku hin API tomar kirine nîşan bide. Dûv re, min rsyslog_exporter li Python nivîsand, û me ew hemî ji Prometheus re şand û grafîkan çêkir. Me bi rastî metrîkên Graylog dixwest, lê me hîn wext nedît ku em wan saz bikin.
Pirsgirêk çi bûn? Pirsgirêkan derketin dema ku me kifş kir (NÎŞKÊ!) Ku API-yên me yên Zindî serê saniyeyê 50 hezar peyam dinivîsin. Ev tenê API-ya Zindî bêyî qonax e. Û Graylog di çirkeyê de tenê 12 hezar peyaman nîşanî me dide. Û pirsek maqûl derket holê: mayîn li ku ne? Ji vê yekê me encam da ku Graylog bi hêsanî nikare bisekine. Me nêrî, û, bi rastî, Graylog û Elasticsearch nekarîn vê herikînê bi rê ve bibin.
Piştre, vedîtinên din ên ku me di rê de çêkirin.
Nivîsên li ser soketê têne asteng kirin. Çawa çêbû? Dema ku min rsyslog ji bo radestkirinê bikar anî, di demek de kanala di navbera navendên daneyê de têk çû. Teslîm li cihekî rawestiya, li cihekî din rawestiya. Hemî ev bi API-yên ku li soketa rsyslog dinivîsin gihîştiye makîneyê. Li wir dorek hebû. Dûv re rêza nivîsandina li ser soketa unix, ku ji hêla xwerû 128 pakêt e, tijî bû. Û di serîlêdanê de nivîsandina din () tê asteng kirin. Dema ku me li pirtûkxaneya ku em di sepanên Go de bikar tînin nihêrî, li wir hate nivîsandin ku nivîsandina li soketê di moda ne-astengkirinê de pêk tê. Em piştrast bûn ku tiştek nehatiye asteng kirin. Ji ber ku em dixwînin ku li ser wê nivîsand. Lê demek heye. Di heman demê de li dora vê bangê dorpêkek bêdawî jî hebû, ku tê de hewildanek domdar hebû ku peyamek bişkîne. Me guh neda wî. Diviyabû min pirtûkxaneyê ji nû ve binivîsanda. Ji hingê ve ew çend caran guherî, lê naha me di hemî bine-pergalan de ji astengkirinê xilas kir. Ji ber vê yekê, hûn dikarin rsyslog rawestînin, û tiştek dê têk nebe.
Pêdivî ye ku meriv mezinahiya rêzan bişopîne, ku ev dibe alîkar ku meriv li ser vê raketinê nemîne. Pêşîn, em dikarin gava ku em dest bi windakirina peyaman dikin çavdêrî bikin. Ya duyemîn, em dikarin bişopînin ku pirsgirêkên me bi radestkirinê re hene.
Û demek din a nebaş - zêdekirina 10 carî di mîmariya mîkro-servisê de pir hêsan e. Gelek daxwazên me yên hatinî tune ne, lê ji ber grafika ku van peyaman pê ve diçin, ji ber têketinên gihîştinê, em bi rastî barkirina têketinê bi qasî deh carî zêde dikin. Mixabin, wextê min tune ku ez hejmarên rastîn hesab bikim, lê mîkroxizmet ew in. Divê ev yek li ber çavan bê girtin. Derket holê ku di vê gavê de binepergala berhevkirina têketinê li Lazada ya herî barkirî ye.
Meriv çawa pirsgirêka elasticsearch çareser dike? Heke hûn hewce ne ku zû têketin li yek cîhek bigirin, da ku hûn li dora hemî makîneyan nerevin û wan li wir kom bikin, hilanîna pelan bikar bînin. Ev garantî ye ku bixebite. Ew dikare ji her serverê were kirin. Hûn tenê hewce ne ku dîskan li wir bihêlin û syslog saz bikin. Piştî vê yekê, hûn garantî dikin ku hemî têketin li yek cîhek heye. Dûv re hûn dikarin hêdî hêdî elasticsearch, graylog, û tiştek din mîheng bikin. Lê hûn ê jixwe hemî têketin hebin, û, ji bilî vê, hûn dikarin wan bi qasî ku têr rêzikên dîskê hene hilînin.
Di dema rapora min de, pîlan bi vî rengî dest pê kir. Me di pratîkê de nivîsandina dosyayê rawestand. Naha, bi îhtîmalek mezin, em ê yên mayî vemirînin. Li ser makîneyên herêmî yên ku API-yê dixebitin, em ê nivîsandina pelan rawestînin. Pêşîn, hilanîna pelê heye, ku pir baş dixebite. Ya duyemîn jî, ev makîneyên hanê bi berdewamî ji cîhê xwe diqedin; pêdivî ye ku ew bi berdewamî were şopandin.
Ev beşa bi Logstash û Graylog re, ew bi rastî derdikeve. Ji ber vê yekê, divê em ji wê xilas bibin. Divê hûn yek tiştek hilbijêrin.
Me biryar da ku Logstash û Kibana bavêjin. Ji ber ku dezgeheke me ya ewlehiyê heye. Çi girêdan? Têkilî ev e ku Kibana bêyî X-Pack û bê Shield rê nade ku hûn mafên gihîştina têketinê ji hev cuda bikin. Ji ber vê yekê me Graylog girt. Hemî wê heye. Ez jê hez nakim, lê ew dixebite. Me hardware nû kirî, Grayloga nû li wir saz kir û hemî têketin bi formatên hişk veguheztin Graylogek cihê. Me pirsgirêk bi cûrbecûr qadên wekhev bi rêxistinî çareser kir.
Çi bi rastî di Graylog-a nû de tê de heye. Me tenê her tişt di docker de nivîsand. Me komek server girt, sê nimûneyên Kafka, 7 serverên Graylog guhertoya 2.3 (ji ber ku me guhertoya 5-ê Elasticsearch dixwest) derxist. Ev hemû di dema serdegirtinên ji HDD de hatin girtin. Me di saniyeyê de rêjeyek îndekskirinê ya 100 hezar peyaman dît. Me ev hejmar dît ku her hefte 140 terabytes dane.
Û dîsa rabe! Du firotanên me hene. Me ji 6 mîlyon peyaman derbas kir. Graylog wextê xwarkirinê tune. Bi rengekî divê em dîsa bijîn.
Em bi vî awayî xilas bûn. Me çend server û SSD-yên din lê zêde kirin. Niha em bi vî awayî dijîn. Naha em jixwe di çirkeyê de 160 hezar peyaman dişoxilînin. Me hê sînor negirtiye, ji ber vê yekê ne diyar e ka em bi rastî çiqas dikarin ji vê yekê derkevin.
Ev planên me yên pêşerojê ne. Ji van, ya herî girîng belkî hebûna bilind e. Hîn li cem me nemaye. Gelek otomobîl bi heman rengî têne mîheng kirin, lê heya nuha her tişt di yek otomobîlê de derbas dibe. Ji bo sazkirina failover di navbera wan de dem digire.
Metrîkên ji Graylog berhev bikin.
Sînorek rêjeyê çêbikin da ku me yek API-ya dîn hebe ku bandfirehiya me û her tiştê din nekuje.
Û di dawiyê de, cûreyek SLA bi pêşdebiran re îmze bikin da ku em bikarin ev qas xizmet bikin. Ger tu bêtir binivîsî, wê demê ez bibore.
Û belgeyan binivîse.
Bi kurtasî, encamên her tiştê ku me dît. Ya yekem, standard. Ya duyemîn, syslog kek e. Ya sêyemîn, rsyslog tam wekî ku li ser slaytê hatî nivîsandin dixebite. Û em herin ser pirsan.
Pirsên.
di pirsa: Çima te biryar da ku nestînî... (pelebeat?)
Bersiv: Divê em li dosyayekê binivîsin. Bi rastî min nexwest. Gava ku API-ya we di çirkeyê de bi hezaran mesajan dinivîse, tewra ku hûn wê saetê carekê bizivirînin, ev dîsa jî ne vebijarkek e. Hûn dikarin di boriyê de binivîsin. Ji bo ku pêşdebiran ji min pirsî: "Eger pêvajoya ku em dinivîsin têk bibe dê çi bibe?" Min tenê nedît ku ez çi bersivê bidim wan, û got: "Belê, baş e, em wiya nekin."
di pirsa: Çima hûn tenê têketinên HDFS-ê nanivîsin?
Bersiv: Ev qonaxa din e. Em di destpêkê de li ser wê fikirîn, lê ji ber ku heya niha çavkaniyên ku vê bikin tune ne, ew di çareseriya meya demdirêj de dimîne.
di pirsa: Forma stûnê dê guncawtir be.
Bersiv: Ez dizanim. Em bi herdu destan ji bo wê ne.
di pirsa: Tu ji rsyslogê re dinivîsî. Li wir hûn dikarin hem TCP û hem jî UDP bikar bînin. Lê heke UDP, wê hingê hûn çawa radestkirinê garantî dikin?
Bersiv: Du xal hene. Pêşîn, ez tavilê ji her kesî re dibêjim ku em radestkirina têketin garantî nakin. Ji ber ku gava pêşdebir têne û dibêjin: "Werin em li wir dest bi nivîsandina daneyên darayî bikin, û heke tiştek çêbibe hûn ê wê ji me re deynin cîhek," em bersiva wan didin, "Gelo! Werin em dest bi astengkirina nivîsandina soketê bikin, û vê yekê di danûstendinan de bikin, da ku hûn garantî bin ku hûn wê ji me re deynin ser soketê û piştrast bikin ku em wê ji aliyekî din werdigirin." Û di vê gavê de, her kes tavilê êdî hewce nake. Ger ne hewce be, wê demê divê em çi pirsan bipirsin? Ger hûn nexwazin garantiya nivîsandina soketê bidin, wê hingê çima em hewce ne ku radestkirinê garantî bikin? Em hewldanên xwe yên herî baş dikin. Em bi rastî hewl didin ku bi qasî ku gengaz û bi awayê çêtirîn gengaz radest bikin, lê em garantiyek 100% nadin. Ji ber vê yekê, ne hewce ye ku daneyên darayî li wir binivîsin. Ji bo vê databasên danûstandinan hene.
di pirsa: Gava ku API di têketinê de hin peyamek çêdike û kontrolê vediguhezîne servîsên mîkro, gelo hûn rastî pirsgirêkê hatine ku peyamên ji mîkroxizmetên cihêreng bi rêzek xelet digihîjin? Ev dibe sedema tevliheviyê.
Bersiv: Normal e ku bi rêzên cuda tên. Divê hûn ji bo vê yekê amade bibin. Ji ber ku her radestkirina torê fermanê garantî nake, an jî divê hûn çavkaniyên taybetî li ser vê yekê xerc bikin. Ger em depoyên pelan bigirin, wê hingê her API têketin li pelê xwe tomar dike. An jî, li wir rsyslog wan di pelrêçan de rêz dike. Her API têketinên xwe hene, ku hûn dikarin herin û lê binihêrin, û dûv re hûn dikarin wan bi karanîna demjimêra di vê têketinê de bidin ber hev. Ger ew biçin Graylog-ê binihêrin, wê hingê ew li wir li gorî demjimêrê têne rêz kirin. Li wir dê her tişt baş bibe.
di pirsa: Demjimêr dibe ku bi milî çirkeyan diguhere.
Bersiv: Demjimêr ji hêla API-ê bixwe ve hatî çêkirin. Ev e, di rastiyê de, hemû xala. NTP me heye. API di peyamê de bi xwe re demjimêrek çêdike. rsyslog wê lê zêde nake.
di pirsa: Têkiliya di navbera navendên daneyan de ne pir zelal e. Di nav navenda daneyê de, diyar e ka têketin çawa hatine berhev kirin û pêvajo kirin. Têkiliya di navbera navendên daneyê de çawa pêk tê? An her navendek daneyê jiyana xwe dijî?
Bersiv: Hema hema. Li welatê me, her welatek di navendek daneyê de ye. Heya nuha, me belavbûnek tune ku yek welat di navendên daneyên cihêreng de cih bigire. Ji ber vê yekê, ne hewce ye ku wan bi hev re bikin. Her navendek têketinek di hundurê de heye. Ev serverek Rsyslog e. Bi rastî du makîneyên rêveberiyê. Heman helwestê wan heye. Lê heya niha, seyrûsefer tenê di yek ji wan re derbas dibe. Ew hemî têketin berhev dike. Di her rewşê de wê rêzek dîskê heye. Ew têketinan dadixe û wan dişîne navenda daneya navendî (Singapore), ku paşê ew ji Graylog re têne şandin. Û her navendek daneyê hilanîna pelê xwe heye. Ger pêwendiya me winda bibe, em hemî têketin li wir hene. Ew ê li wir bimînin. Ew ê li wir werin hilanîn.
di pirsa: Di rewşên nenormal de, hûn têketin ji wir werdigirin?
Bersiv: Hûn dikarin herin wir (ji bo hilanîna pelan) û lê binêrin.
di pirsa: Tu çawa çavdêrî dikî ku tu têketin winda nakî?
Bersiv: Bi rastî em wan winda dikin, û em çavdêriya wê dikin. Çavdêrî beriya mehekê hatibû destpêkirin. Pirtûkxaneya ku Go API bikar tîne metrîk heye. Ew dikare bijmêre çend caran wê nikarîbû li soketekê binivîsîne. Niha li wir heurîstîkek jîr heye. Li wir tamponek heye. Ew hewl dide ku ji wê re peyamek li ser soketê binivîse. Ger tampon zêde bibe, ew dest bi avêtina wan dike. Û ew dihejmêre ku çend ji wan avêtine. Ger metre li wir dest pê bikin, em ê pê zanibin. Ew naha jî têne prometheus, û hûn dikarin grafikên li Grafana bibînin. Hûn dikarin hişyariyan saz bikin. Lê hêj ne diyar e ku ji kê re bişînin.
di pirsa: Di elasticsearch de hûn têketinên bi zêdebarî hilînin. Çend kopiyên te hene?
Bersiv: Yek rêz.
di pirsa: Ma ev tenê yek rêz e?
Bersiv: Ev serdest û replica ye. Daneyên di du kopiyan de têne tomar kirin.
di pirsa: We bi rengekî mezinahiya tamponê ya rsyslog eyar kir?
Bersiv: Em datagraman li soketek unix ya xwerû dinivîsin. Ev yek yekser sînorê 128 kilobyte li ser me ferz dike. Em nikarin bêtir jê re binivîsin. Me ev yek di standardê de nivîsand. Kesên ku dixwazin têkevin depoyê 128 kilobyte dinivîsin. Ji bilî vê, pirtûkxane têne qut kirin, û ala ku peyam qut bûye tê danîn. Standarda me ya ji bo peyamê bixwe qadek taybetî heye ku destnîşan dike ka ew di dema tomarkirinê de qut bûye an na. Ji ber vê yekê derfeta me heye ku em vê kêliyê jî bişopînin.
Pirs: Ma tu JSON şikestî dinivîsî?
Bersiv: JSON şikestî dê di dema reledanê de jî were avêtin ji ber ku pakêt pir mezin e. An jî Graylog dê were avêtin ji ber ku ew nikare JSON parsek bike. Lê nuans hene ku divê werin sererast kirin, û ew bi piranî bi rsyslog ve girêdayî ne. Min berê jî li wir çend mijar tijî kirine, ku hîn jî divê li ser wan xebat bê kirin.
Pirs: Çima Kafka? Ma we RabbitMQ ceriband? Ma Graylog di bin barên weha de têk diçe?
Bersiv: Bi Graylogê re li ba me nayê. Û Graylog ji bo me teşe digire. Ew bi rastî pirsgirêk e. Ew tiştek taybet e. Û, bi rastî, ew ne hewce ye. Ez tercîh dikim ku ji rsyslog rasterast ji elasticsearch re binivîsim û dûv re li Kibana binihêrim. Lê divê em pirsgirêkê bi pasewanan re çareser bikin. Dema ku em Graylogê bavêjin û Kibana bikar bînin ev vebijarkek mimkun e ji bo pêşkeftina me. Ti wateya bikaranîna Logstash tune. Ji ber ku ez dikarim heman tiştî bi rsyslog re bikim. Û ji bo nivîsandina elasticsearch modulek wê heye. Em hewl didin ku bi rengek Graylog bijîn. Me ew jî piçekî aheng kir. Lê hê jî cîhê pêşveçûnê heye.
Li ser Kafka. Ji aliyê dîrokî ve bi vî rengî bû. Dema ku ez hatim, ew jixwe li wir bû, û têketin jixwe jê re dihatin nivîsandin. Me bi tenê koma xwe bilind kir û têketin nav wê bar kir. Em rêveberiya wî ne, em dizanin ku ew çawa hîs dike. Ji bo RabbitMQ... ew ji bo me bi RabbitMQ re naxebite. Û RabbitMQ ji bo me şikil digire. Me ew di hilberînê de heye, û bi wê re pirsgirêk hebûn. Niha, berî firotanê, ew ê wî xweş bikin, û ew ê normal dest bi xebatê bike. Lê beriya wê ez ne amade bûm ku wê derxim nav berhemê. Xalek din jî heye. Graylog dikare guhertoya AMQP 0.9 bixwîne, û rsyslog dikare guhertoya AMQP 1.0 binivîse. Û di navberê de çareseriyek yekane tune ku bikaribe herduyan jî bike. Ew yek an ya din e. Ji ber vê yekê, niha tenê Kafka. Lê ew jî hûrgelên xwe hene. Ji ber ku omkafka guhertoya rsyslog ya ku em bikar tînin dikare tevahiya tampona peyamê ya ku ji rsyslog derxistiye winda bike. Ji bo niha em li ber xwe didin.
Pirs: Tu Kafka bikar tînî ji ber ku te berê hebû? Êdî ji bo tu armancê nayê bikaranîn?
Bersiv: Kafka, ku bû, ji hêla tîmê Zanistiya Danezan ve tê bikar anîn. Ev projeyek bi tevahî cûda ye, ku, mixabin, ez nikarim tiştek bibêjim. Ez nizanim. Ew ji hêla tîmê Zanistiya Daneyê ve hate rêve kirin. Dema ku têketin hatin afirandin, me biryar da ku em wê bikar bînin da ku xweya xwe saz nekin. Naha me Graylog nûve kir, û me lihevhatî winda kir ji ber ku guhertoyek kevn a Kafka heye. Diviyabû me dest bi xwe bikira. Di heman demê de, me ji bo her API-ê ji van çar mijaran xilas kir. Me mijarek berfireh ji bo hemî zindî, mijarek berfireh ji bo hemî şanoyê çêkir û tenê her tişt li wir danî. Graylog van hemûyan bi paralelî derdixe.
Pirs: Çima pêwîstiya me bi vê şamanîzma bi soketan heye? We hewl da ku ajokera têketinê ya syslog-ê ji bo konteyneran bikar bînin?
Bersiv: Wextê ku me ev pirs kir, pêwendiya me bi doçkê re aloz bû. Ew docker 1.0 an 0.9 bû. Docker bixwe xerîb bû. Ya duyemîn, heke hûn têketin jî têxin nav wê... Gumanek min a nerastkirî heye ku ew hemî têketin di nav xwe de, di nav şeyda dokerê re derbas dibe. Ger yek API dîn bibe, wê hingê API-yên mayî di vê rastiyê de asê mane ku ew nikanin stdout û stderr bişînin. Ez nizanim ev ê ber bi ku ve biçe. Di asta hestê de gumanek min heye ku li vê derê ne hewce ye ku ajokera sysloga Docker bikar bîne. Beşa meya ceribandina fonksiyonel komika xweya Graylog bi têketin heye. Ew ajokarên têketina Docker bikar tînin û her tişt li wir baş xuya dike. Lê ew yekser GELF ji Graylog re dinivîsin. Di dema ku me dest bi van hemûyan kir, me tenê hewce kir ku ew bixebitin. Belkî paşê gava kesek were û bibêje sed sal in baş dixebite, em ê hewl bidin.
Pirs: Hûn di navbera navendên daneyê de bi karanîna rsyslog radestkirinê dikin. Çima ne Kafka?
Bersiv: Em herduyan bi rastî dikin. Ji ber du sedeman. Ger kanal bi tevahî mirî be, wê hingê hemî têketinên me, tewra di forma pêçandî de, dê di nav wê de negerin. Û Kafka destûrê dide te ku hûn di vê pêvajoyê de bi hêsanî wan winda bikin. Bi vî awayî em ji van têketinên asê xilas dibin. Em tenê di vê rewşê de rasterast Kafka bikar tînin. Ger kanalek me ya baş hebe û dixwazin wê azad bikin, wê hingê em rsysloga wan bikar tînin. Lê di rastiyê de, hûn dikarin wê mîheng bikin da ku ew bixwe tiştê ku tê de derbas nebûye davêje. Heya nuha, em tenê radestkirina rsyslog rasterast li cîhek, û Kafka li cîhek bikar tînin.
Source: www.habr.com