Registroj estas grava parto de la sistemo, permesante al vi kompreni, ke ĝi funkcias (aŭ ne funkcias) kiel atendite. En mikroserva arkitekturo, labori kun ŝtipoj fariĝas aparta disciplino por speciala Olimpiko. Aro da demandoj devas esti solvitaj tuj:
- kiel skribi protokolojn de aplikaĵo;
- kie skribi protokolojn;
- kiel liveri ŝtipojn por stokado kaj prilaborado;
- kiel prilabori kaj konservi protokolojn.
La uzo de nuntempe popularaj kontenerigteknologioj aldonas sablon sur la rastilo al la kampo de opcioj por solvi la problemon.
Ĝuste pri tio temas la transskribo de la raporto de Yuri Bushmelev "Mapo de rastiloj en la kampo de kolektado kaj liverado de ŝtipoj".
Kiu zorgas, bonvolu sub la kato.
Mia nomo estas Jurij Bushmelev. Mi laboras ĉe Lazada. Hodiaŭ mi parolos pri kiel ni faris niajn ŝtipojn, kiel ni kolektis ilin, kaj kion ni skribas tie.
De kie ni estas? Kiuj ni estas? Lazada estas la numero 1 reta podetalisto en ses landoj en Sudorienta Azio. Ĉiuj ĉi tiuj landoj estas distribuitaj inter niaj datumcentroj. Nuntempe estas 4 datumcentroj entute. Kial ĉi tio gravas? Ĉar iuj decidoj estis pro tio, ke estas tre malforta ligo inter la centroj. Ni havas mikroservan arkitekturon. Mi surpriziĝis trovi, ke ni jam havas 80 mikroservojn. Kiam mi komencis la taskon per protokoloj, estis nur 20. Krome estas sufiĉe granda peco de PHP-heredaĵo, kun kiu mi ankaŭ devas vivi kaj elteni. Ĉio ĉi nuntempe generas pli ol 6 milionojn da mesaĝoj por minuto por la sistemo entute. Poste mi montros kiel ni provas vivi kun ĉi tio, kaj kial ĉi tio estas tiel.
Vi devas iel vivi kun ĉi tiuj 6 milionoj da mesaĝoj. Kion ni faru kun ili? 6 milionoj da mesaĝoj, kiujn vi bezonas:
- sendi de la programo
- akcepti por livero
- liveru por analizo kaj konservado.
- analizi
- konservu ĝin iel.
Kiam aperis tri milionoj da mesaĝoj, mi aspektis proksimume same. Ĉar ni komencis per nur kelkaj moneroj. Estas klare, ke aplikaj protokoloj estas skribitaj tie. Ekzemple, mi ne povis konektiĝi al la datumbazo, mi povis konektiĝi al la datumbazo sed mi povis legi nenion. Sed krom ĉi tio, ĉiu el niaj mikroservoj ankaŭ skribas alirprotokolo. Ĉiu peto, kiu alvenas al la mikroservo, estas registrita en la protokolo. Kial ni faras ĉi tion? Programistoj volas povi spuri. Ĉiu alirprotokolo enhavas spuridan kampon, uzante kiun speciala interfaco tiam malvolvas la tutan ĉenon kaj bele montras la spuron. La spuro montras kiel la peto iris, kaj ĉi tio helpas niajn programistojn rapide trakti ajnan neidentigitan rubon.
Kiel vivi kun ĉi tio? Nun mi mallonge priskribos la kampon de elektoj - kiel ĉi tiu problemo estas ĝenerale solvita. Kiel solvi la problemon kolekti, transdoni kaj konservi ŝtipojn.
Kiel skribi de aplikaĵo? Estas klare, ke ekzistas malsamaj manieroj. Precipe estas plej bona praktiko, kiel diras al ni niaj modaj kamaradoj. Estas du specoj de malnova lernejo, kiel diris al ni niaj avoj. Estas aliaj manieroj.
La situacio kun kolektado de ŝtipoj estas proksimume la sama. Ne estas multaj ebloj por solvi ĉi tiun apartan parton. Jam estas pli da ili, sed ankoraŭ ne tiom.
Sed kun transdono kaj posta analizo, la nombro da variadoj komencas eksplodi. Mi ne priskribos ĉiun opcion nun. Mi pensas, ke la ĉefaj elektoj estas bone konataj de ĉiuj, kiuj interesiĝas pri la temo.
Mi montros al vi kiel ni faris ĝin ĉe Lazada, kaj kiel ĉio efektive komenciĝis.
Antaŭ unu jaro mi venis al Lazada kaj estis sendita al projekto pri ŝtipoj. Estis io tia. La aplikaĵa protokolo estis skribita al stdout kaj stderr. Ĉio estis farita laŭmode. Sed tiam la programistoj forĵetis ĝin el la normaj fluoj, kaj tiam iel infrastrukturaj specialistoj eltrovos ĝin. Inter infrastrukturaj specialistoj kaj programistoj, estas ankaŭ eldonantoj, kiuj diris: "uh... bone, ni simple envolvu ilin en dosieron kun ŝelo, kaj jen." Kaj ĉar ĉio ĉi estis en ujo, ili envolvis ĝin ĝuste en la ujo mem, mapis la katalogon enen kaj metis ĝin tien. Mi pensas, ke estas sufiĉe evidente por ĉiuj, kio rezultis el ĝi.
Ni rigardu iom plu nun. Kiel ni liveris ĉi tiujn ŝtipojn? Iu elektis td-agento, kiu fakte estas flua, sed ne tute flua. Mi ankoraŭ ne komprenas la rilaton inter ĉi tiuj du projektoj, sed ili ŝajnas esti pri la sama afero. Kaj ĉi tiu fluentd, skribita en Ruby, legis protokolojn, analizis ilin en JSON uzante ian regulecon. Poste mi sendis ilin al Kafka. Cetere, en Kafka ni havis 4 apartajn temojn por ĉiu API. Kial 4? Ĉar ekzistas viva, estas surscenigo, kaj ĉar estas stdout kaj stderr. Programistoj kreas ilin, kaj infrastrukturprogramistoj devas krei ilin en Kafka. Krome, Kafka estis kontrolita de alia departemento. Tial, necesis krei bileton por ke ili kreu 4 temojn por ĉiu apio. Ĉiuj forgesis pri ĝi. Ĝenerale, estis rubo kaj tumulto.
Kion ni faris poste kun ĉi tio? Ni sendis ĝin al Kafka. Tiam duono de la ŝtipoj de Kafka flugis al Logstash. La alia duono de la tagaloj estis dividita. Kelkaj flugis al unu Graylog, kelkaj al alia Graylog. Kiel rezulto, ĉio ĉi eniris unu Elasticsearch-areton. Tio estas, ĉi tiu tuta malordo finiĝis tie. Ne faru tion!
Jen kiel ĝi aspektas, se vi rigardas ĝin de supre. Ne faru tion! Ĉi tie la problemaj areoj tuj estas markitaj per nombroj. Efektive estas pli da ili, sed 6 estas vere problemaj, pri kiuj oni devas ion fari. Mi rakontos al vi pri ili aparte nun.
Ĉi tie (1,2,3) ni skribas dosierojn kaj, sekve, estas tri rastiloj ĉi tie samtempe.
La unua (1) estas, ke ni devas skribi ilin ie. Ne ĉiam estus dezirinde doni al la API la kapablon skribi rekte al dosiero. Estas dezirinde, ke la API estu izolita en ujo, aŭ eĉ pli bone, ke ĝi estu nurlegebla. Mi estas sistemadministranto, do mi havas iomete alternativan vidon pri ĉi tiuj aferoj.
La dua punkto (2,3) estas, ke ni havas multajn petojn venantajn al la API. La API skribas multajn datumojn al dosiero. La dosieroj kreskas. Ni devas turni ilin. Ĉar alie vi ne povos provizi iajn diskojn tie. Rotacii ilin estas malbona ĉar ili estas faritaj per alidirektado tra la ŝelo al la dosierujo. Ni neniel povas revizii ĝin. Vi ne povas diri al la aplikaĵo remalfermi la tenilojn. Ĉar la programistoj rigardos vin kvazaŭ vi estas malsaĝulo: "Kiuj priskribiloj? Ni ĝenerale skribas al stdout." Infrastrukturaj programistoj faris copytruncate al logrotate, kiu simple faras kopion de la dosiero kaj transskribas la originalon. Sekve, inter tiuj kopiaj procezoj la diskospaco kutime elĉerpiĝas.
(4) Ni havis malsamajn formatojn en malsamaj APIoj. Ili estis iomete malsamaj, sed la regexp devis esti skribita malsame. Ĉar ĉio ĉi estis kontrolita fare de Puppet, ekzistis granda aro da klasoj kun siaj propraj blatoj. Plie, plejofte td-agent povis manĝi memoron, esti stulta, ĝi povis simple ŝajnigi, ke ĝi funkcias kaj fari nenion. De ekstere estis neeble kompreni, ke li nenion faras. Plej bone, li falos kaj iu poste prenos lin. Pli precize alvenos alarmo, kaj iu iros kaj levos ĝin per siaj manoj.
(6) Kaj la plej rubo kaj malŝparo estis elasta serĉo. Ĉar ĝi estis malnova versio. Ĉar ni ne havis dediĉitajn majstrojn tiutempe. Ni havis heterogenajn tagalojn, kies kampoj povus interkovri. Malsamaj protokoloj de malsamaj aplikoj povus esti skribitaj kun la samaj kamponomoj, sed povus esti malsamaj datumoj ene. Tio estas, unu ŝtipo venas kun Entjero en la kampo, ekzemple, nivelo. Alia ŝtipo venas kun String en la nivelkampo. En foresto de statika mapado, ĉi tio estas tiel mirinda afero. Se, post turnado de la indekso en elasta serĉo, mesaĝo kun ŝnuro alvenas unue, tiam ni vivas normale. Sed se la unua alvenis de Entjero, tiam ĉiuj postaj mesaĝoj kiuj alvenis de String estas simple forĵetitaj. Ĉar la kampotipo ne kongruas.
Ni komencis demandi ĉi tiujn demandojn. Ni decidis ne serĉi kulpulojn.
Sed io necesas fari! La evidenta afero estas, ke ni devas starigi normojn. Ni jam havis kelkajn normojn. Ni komencis kelkajn iom poste. Feliĉe, ununura protokolo-formato por ĉiuj API-oj jam estis aprobita tiutempe. Ĝi estas skribita rekte en la normojn por interagado inter servoj. Sekve, tiuj, kiuj volas ricevi protokolojn, devas skribi ilin en ĉi tiu formato. Se iu ne skribas protokolojn en ĉi tiu formato, tiam ni nenion garantias.
Poste, mi ŝatus krei unuigitan normon por la metodoj de registrado, liverado kaj kolektado de protokoloj. Fakte, kie skribi ilin, kaj kiel liveri ilin. La ideala situacio estas kiam projektoj uzas la saman bibliotekon. Estas aparta protokolo-biblioteko por Go, kaj aparta biblioteko por PHP. Ĉiuj ni havas devus uzi ilin. Nuntempe, mi dirus, ke ni sukcesas 80 procentojn pri tio. Sed kelkaj homoj daŭre manĝas kaktojn.
Kaj tie (sur la glito) la "SLA por livero de ŝtipoj" apenaŭ komencas aperi. Ĝi ankoraŭ ne ekzistas, sed ni laboras pri ĝi. Ĉar estas tre oportune, kiam la infrastrukturo diras, ke se oni skribas en tia kaj tia formato al tia kaj tia loko kaj ne pli ol N mesaĝojn sekundo, tiam ni plej verŝajne liveros ĝin al tia kaj tia loko. Ĉi tio malpezigas multajn kapdolorojn. Se ekzistas SLA, tiam ĉi tio estas absolute mirinda!
Kiel ni komencis solvi la problemon? La ĉefa problemo estis kun td-agent. Ne estis klare kien niaj ŝtipoj iris. Ĉu ili estas liveritaj? Ĉu ili iras? Kie ili estas ĉiukaze? Tial, la unua punkto estis decidita anstataŭigi td-agent. Mi mallonge skizis la eblojn por kio anstataŭigi ĝin ĉi tie.
Fluentad. Unue, mi renkontis lin ĉe antaŭa laboro, kaj li ankaŭ periode falis tie. Due, ĉi tio estas la sama afero, nur profile.
Filebeat. Kiel ĝi estis oportuna por ni? Ĉar ĝi estas en Go, kaj ni havas multan kompetentecon en Go. Sekve, se io okazus, ni povus iel aldoni al ĝi por ni mem. Tial ni ne prenis ĝin. Por ke eĉ ne estu tento komenci reverki ĝin por vi mem.
La evidenta solvo por la sistemadministranto estas ĉiaj syslogs en ĉi tiu kvanto (syslog-ng/rsyslog/nxlog).
Aŭ skribu ion propran, sed ni forĵetis ĉi tion, same kiel filebeat. Se vi skribas ion, estas pli bone skribi ion utilan por komerco. Por liveri ŝtipojn, estas pli bone preni ion pretan.
Tial, la elekto fakte venis al la elekto inter syslog-ng kaj rsyslog. Mi klinis al rsyslog simple ĉar ni jam havis klasojn por rsyslog en Puppet, kaj mi ne trovis evidentan diferencon inter ili. Kio estas syslog, kio estas syslog. Jes, iuj havas pli malbonan dokumentadon, iuj havas pli bonan. Ĉi tiu povas fari ĝin tiel, kaj la alia povas fari ĝin alimaniere.
Kaj iom pri rsyslog. Antaŭ ĉio, ĝi estas bonega ĉar ĝi havas multajn modulojn. Ĝi havas homlegeblan RainerScript (moderna agorda lingvo). Estas mirinda gratifiko, ke ni povus imiti la konduton de td-agent uzante normajn ilojn, kaj nenio ŝanĝiĝis por aplikoj. Tio estas, ni ŝanĝas td-agent al rsyslog, kaj lasas ĉion alian por nun. Kaj ni tuj ricevas laboran liveron. Poste, mmnormalize estas mirinda afero en rsyslog. Ĝi permesas vin analizi protokolojn, sed ne kun Grok kaj regexp. Ĝi faras abstraktan sintaksarbon. Ĝi analizas protokolojn en la sama maniero kiel kompililo analizas fontojn. Ĉi tio permesas vin labori tre rapide, konsumi malmulte da CPU kaj, ĝenerale, ĝi estas vere bonega afero. Estas amaso da aliaj gratifikoj. Mi ne traktos ilin.
rsyslog havas multajn aliajn malavantaĝojn. Ili estas proksimume la samaj kiel gratifikoj. La ĉefaj problemoj estas, ke vi devas scii kiel kuiri ĝin, kaj vi devas elekti la version.
Ni decidis, ke ni skribus protokolojn al uniksa ingo. Kaj ne en /dev/log, ĉar tie ni havas ĥaoson da sistemaj protokoloj, journald estas en ĉi tiu dukto. Do ni skribu al kutima ingo. Ni aldonos ĝin al aparta regularo. Ni ne malhelpu ion ajn. Ĉio estos travidebla kaj komprenebla. Ĝuste tion ni faris. La dosierujo kun ĉi tiuj ingoj estas normigita kaj plusendita al ĉiuj ujoj. Ujoj povas vidi la ingon, kiun ili bezonas, malfermiĝi kaj skribi al ĝi.
Kial ne dosiero? Ĉar ĉiuj legis ĝin , kiu provis plusendi dosieron al docker, kaj estis malkovrite ke post rekomencado de rsyslog, la dosierpriskribilo ŝanĝiĝis, kaj docker perdis ĉi tiun dosieron. Ĝi tenas ion alian malfermita, sed ne la ingo kie ili skribas. Ni decidis, ke ni traktos ĉi tiun problemon, kaj samtempe ni traktos la blokan problemon.
Rsyslog faras la agojn indikitajn sur la glito kaj sendas protokolojn al aŭ relajso aŭ Kafka. Kafka sekvas la malnovan vojon. Relay - Mi provis uzi puran rsyslog por liveri protokolojn. Sen Message Queue, uzante normajn rsyslog-iloj. Esence, ĝi funkcias.
Sed estas nuancoj pri kiel puŝi ilin en ĉi tiun parton (Logstash/Graylog/ES). Ĉi tiu parto (rsyslog-rsyslog) estas uzata inter datencentroj. Jen kunpremita tcp-ligo, kiu ebligas al ni ŝpari larĝon de bando kaj, sekve, iel pliigi la verŝajnecon, ke ni ricevos iujn protokolojn de alia datumcentro kiam la kanalo estas ŝtopita. Ĉar ni havas Indonezion, kie ĉio estas malbona. Ĉi tie kuŝas la konstanta problemo.
Ni pensis pri kiel ni povas efektive kontroli kiom verŝajne la protokoloj, kiujn ni registris de la aplikaĵo, atingos la finon? Ni decidis krei metrikojn. rsyslog havas sian propran statistikan kolektomodulon, kiu enhavas ian nombrilojn. Ekzemple, ĝi povas montri al vi la grandecon de la vico, aŭ kiom da mesaĝoj alvenis en tia kaj tia ago. Vi jam povas preni ion de ili. Krome, ĝi havas kutimajn nombrilojn, kiuj povas esti agorditaj, kaj ĝi montros al vi, ekzemple, la nombron da mesaĝoj, kiujn iuj API registris. Poste, mi skribis rsyslog_exporter en Python, kaj ni sendis ĉion al Prometeo kaj konstruis grafikaĵojn. Ni vere volis Graylog-metrikojn, sed ni ankoraŭ ne havis tempon agordi ilin.
Kio estis la problemoj? Problemoj ekestis kiam ni malkovris (SUBITE!) ke niaj Vivaj API-oj skribis 50k mesaĝojn sekundo. Ĉi tio estas nur Live API sen surscenigo. Kaj Graylog montras al ni nur 12 mil mesaĝojn sekundo. Kaj ekestis racia demando: kie estas la restaĵoj? El kio ni konkludis, ke Graylog simple ne povas elteni. Ni rigardis, kaj, efektive, Graylog kaj Elasticsearch ne povis trakti ĉi tiun fluon.
Poste, aliajn malkovrojn ni faris survoje.
Skriboj al la ingo estas blokitaj. Kiel ĝi okazis? Kiam mi uzis rsyslog por livero, iam la kanalo inter la datumcentroj rompiĝis. Liveraĵo ĉesis en unu loko, livero ĉesis en alia loko. Ĉio ĉi atingis la maŝinon kun API-oj, kiuj skribas al la rsyslog socket. Estis vico tie. Tiam pleniĝis la vico por skribi al la unix-soko, kiu defaŭlte estas 128 pakoj. Kaj la sekva write() en la aplikaĵo estas blokita. Kiam ni rigardis la bibliotekon, kiun ni uzas en Go-aplikoj, tie estis skribite, ke skribo al la ingo okazas en ne-bloka reĝimo. Ni estis certaj, ke nenio estas blokita. Ĉar ni legas kiu skribis pri ĝi. Sed estas momento. Estis ankaŭ senfina buklo ĉirkaŭ ĉi tiu voko, en kiu estis konstanta provo puŝi mesaĝon en la ingon. Ni ne rimarkis lin. Mi devis reverki la bibliotekon. Ekde tiam ĝi plurfoje ŝanĝiĝis, sed nun ni forigis blokadon en ĉiuj subsistemoj. Sekve, vi povas ĉesigi rsyslog, kaj nenio kraŝos.
Necesas kontroli la grandecon de la vicoj, kio helpas eviti paŝi sur ĉi tiun rastilon. Unue, ni povas monitori kiam ni komencas perdi mesaĝojn. Due, ni povas kontroli, ke ni havas problemojn kun livero.
Kaj alia malagrabla momento - plifortigo de 10 fojojn en mikroserva arkitekturo estas tre facila. Ni ne havas multajn envenantajn petojn, sed pro la grafikaĵo laŭ kiu ĉi tiuj mesaĝoj vojaĝas plu, pro la alirprotokoloj, ni efektive pliigas la protokolan ŝarĝon je ĉirkaŭ dekoble. Bedaŭrinde, mi ne havis tempon por kalkuli la ĝustajn nombrojn, sed mikroservoj estas kiaj ili estas. Ĉi tio devas esti memorita. Montriĝas, ke nuntempe la subsistemo de ŝtipkolekto estas la plej ŝarĝita en Lazada.
Kiel solvi elastan serĉan problemon? Se vi bezonas rapide akiri protokolojn en unu loko, por ne kuri al ĉiuj maŝinoj kaj kolekti ilin tie, uzu dosier-stokadon. Ĉi tio estas garantiita funkcii. Ĝi povas esti farita de iu ajn servilo. Vi nur bezonas alglui diskojn tie kaj instali syslog. Post ĉi tio, vi estas garantiita havi ĉiujn ŝtipojn en unu loko. Tiam vi povas malrapide agordi elasticsearch, graylog, kaj ion alian. Sed vi jam havos ĉiujn protokolojn, kaj, krome, vi povas konservi ilin tiom kiom sufiĉas disko-tabeloj.
En la momento de mia raporto, la skemo komencis aspekti tiel. Ni preskaŭ ĉesis skribi al la dosiero. Nun, plej verŝajne, ni malŝaltos la reston. Sur lokaj maŝinoj kurantaj la API, ni ĉesos skribi al dosieroj. Unue, estas dosier-stokado, kiu funkcias tre bone. Due, ĉi tiuj maŝinoj konstante mankas spaco; ĝi devas esti konstante monitorita.
Ĉi tiu parto kun Logstash kaj Graylog, ĝi vere ekas. Tial ni devas forigi ĝin. Vi devas elekti unu aferon.
Ni decidis forĵeti Logstash kaj Kibana. Ĉar ni havas sekurecan fakon. Kia rilato? La konekto estas, ke Kibana sen X-Pack kaj sen Ŝildo ne permesas al vi diferencigi alirrajtojn al protokoloj. Tial ni prenis Graylog. Ĝi havas ĉion. Mi ne ŝatas ĝin, sed ĝi funkcias. Ni aĉetis novan aparataron, instalis freŝan Graylog tie kaj transdonis ĉiujn protokolojn kun striktaj formatoj al aparta Graylog. Ni solvis la problemon kun malsamaj specoj de identaj kampoj organize.
Kio ĝuste estas inkluzivita en la nova Graylog. Ni ĵus skribis ĉion en docker. Ni prenis amason da serviloj, lanĉis tri Kafka-instancojn, 7 Graylog-servilojn version 2.3 (ĉar ni volis Elasticsearch version 5). Ĉio ĉi estis reprenita dum atakoj de la HDD. Ni vidis indeksan indicon de ĝis 100 mil mesaĝoj sekundo. Ni vidis la ciferon, ke 140 terabajtoj da datumoj semajne.
Kaj denove la rastilon! Ni havas du vendojn venantaj. Ni transiris 6 milionojn da mesaĝoj. Graylog ne havas tempon por maĉi. Iel ni devas denove pluvivi.
Jen kiel ni pluvivis. Ni aldonis kelkajn pliajn servilojn kaj SSDojn. Nuntempe ni vivas tiel. Nun ni jam maĉas 160k mesaĝojn je sekundo. Ni ankoraŭ ne trafis la limon, do estas neklare kiom ni efektive povas eltiri el ĉi tio.
Ĉi tiuj estas niaj planoj por la estonteco. El ĉi tiuj, la plej grava verŝajne estas alta havebleco. Ni ankoraŭ ne havas ĝin. Pluraj aŭtoj estas agorditaj en la sama maniero, sed ĝis nun ĉio iras tra unu aŭto. Necesas tempo por agordi malsukceson inter ili.
Kolektu metrikojn de Graylog.
Faru tariflimon por ke ni havu unu frenezan API, kiu ne mortigas nian bendolarĝon kaj ĉion alian.
Kaj finfine, subskribu ian SLA kun la programistoj por ke ni povu servi ĉi tion. Se vi skribas pli, tiam mi bedaŭras.
Kaj verku dokumentadon.
Mallonge, la rezultoj de ĉio, kion ni spertis. Unue, normoj. Due, syslog estas kuko. Trie, rsyslog funkcias ĝuste kiel ĝi estas skribita sur la glito. Kaj ni transiru al la demandoj.
Viaj demandoj.
la demando: Kial vi decidis ne preni... (filebeat?)
Respondu: Ni devas skribi al dosiero. Mi vere ne volis. Kiam via API skribas milojn da mesaĝoj sekundo, eĉ se vi turnas ĝin unufoje hore, ĉi tio ankoraŭ ne estas eblo. Vi povas skribi per pipo. Al kio la programistoj demandis min: "Kio okazos se la procezo, al kiu ni skribas, kraŝos?" Mi simple ne trovis kion respondi al ili, kaj diris: "Nu, bone, ni ne faru tion."
la demando: Kial vi ne simple skribas protokolojn al HDFS?
Respondu: Ĉi tio estas la sekva etapo. Ni pensis pri tio komence, sed ĉar nuntempe ne ekzistas rimedoj por fari tion, ĝi pendas en nia longdaŭra solvo.
la demando: Kolumna formato estus pli taŭga.
Respondu: Mi komprenas. Ni estas por ĝi per ambaŭ manoj.
la demando: Vi skribas al rsyslog. Tie vi povas uzi kaj TCP kaj UDP. Sed se UDP, kiel vi garantias liveron?
Respondu: Estas du punktoj. Unue, mi diras al ĉiuj tuj, ke ni ne garantias liveron de ŝtipoj. Ĉar kiam programistoj venas kaj diras: "Ni komencu skribi financajn datumojn tie, kaj vi metos ĝin ien por ni, se io okazos", ni respondas al ili: "Bonege! Ni komencu bloki skribante al la ingo, kaj faru tion en transakcioj, por ke vi garantiu ĝin meti ĝin sur la ingon por ni kaj certigi, ke ni ricevas ĝin de la alia flanko." Kaj ĉi-momente ĉiuj tuj ne plu bezonas ĝin. Se ĝi ne estas necesa, kiajn demandojn ni faru? Se vi ne volas garantii skribadon al ingo, kial do ni devas garantii liveron? Ni faras nian plej bonan penon. Ni vere provas liveri kiel eble plej multe kaj laŭ la plej bona maniero, sed ni ne donas 100% garantion. Tial, ne necesas skribi financajn datumojn tie. Estas datumbazoj kun transakcioj por ĉi tio.
la demando: Kiam la API generas iun mesaĝon en la protokolo kaj transdonas kontrolon al mikroservoj, ĉu vi renkontis la problemon, ke mesaĝoj de malsamaj mikroservoj alvenas en malĝusta ordo? Ĉi tio kaŭzas konfuzon.
Respondu: Estas normale, ke ili venas en malsamaj ordoj. Vi devas esti preta por ĉi tio. Ĉar ajna reto livero ne garantias mendon, aŭ vi devas elspezi specialajn rimedojn por ĉi tio. Se ni prenas dosierojn, tiam ĉiu API konservas protokolojn al sia propra dosiero. Aŭ pli ĝuste, tie rsyslog ordigas ilin en dosierujojn. Ĉiu API havas siajn proprajn protokolojn, kie vi povas iri kaj rigardi, kaj tiam vi povas kompari ilin uzante la tempomarkon en ĉi tiu protokolo. Se ili iras rigardi en Graylog, tiam ili estas ordigitaj tie laŭ tempostampo. Ĉio estos bone tie.
la demando: Tempostampo povas varii je milisekundoj.
Respondu: Tempostampo estas generita de la API mem. Ĉi tio estas, fakte, la tuta punkto. Ni havas NTP. La API generas tempomarkon en la mesaĝo mem. rsyslog ne aldonas ĝin.
la demando: La interago inter datumcentroj ne estas tre klara. Ene de la datumcentro, estas klare kiel la ŝtipoj estis kolektitaj kaj prilaboritaj. Kiel okazas la interago inter datumcentroj? Aŭ ĉu ĉiu datumcentro vivas sian propran vivon?
Respondu: Preskaŭ. En nia lando, ĉiu lando situas en unu datumcentro. Nuntempe, ni ne havas disvastiĝon tiel ke unu lando situas en malsamaj datumcentroj. Tial, ne necesas kombini ilin. Ĉiu centro havas Log Relay interne. Ĉi tio estas Rsyslog-servilo. Fakte du administraj maŝinoj. Ili havas la saman sintenon. Sed nuntempe, trafiko nur trairas unu el ili. Ĝi agregas ĉiujn ŝtipojn. Ŝi havas diskovicon por la okazo. Ĝi elŝutas la protokolojn kaj sendas ilin al la centra datumcentro (Singapuro), kie ili tiam estas senditaj al Graylog. Kaj ĉiu datumcentro havas sian propran dosierstokadon. Se nia konekto estas perdita, ni havas ĉiujn protokolojn tie. Ili restos tie. Ili estos konservitaj tie.
la demando: En kazo de nenormalaj situacioj, ĉu vi ricevas protokolojn de tie?
Respondu: Vi povas iri tien (al la dosierstokado) kaj rigardi.
la demando: Kiel vi kontrolas ke vi ne perdas protokolojn?
Respondu: Ni fakte perdas ilin, kaj ni kontrolas ĝin. Monitorado estis lanĉita antaŭ monato. La biblioteko kiun la Go-APIoj uzas havas metrikojn. Ŝi povas kalkuli kiom da fojoj ŝi ne povis skribi al ingo. Nuntempe ekzistas lerta heŭristiko tie. Estas bufro tie. Ĝi provas skribi mesaĝon de ĝi al la ingo. Se la bufro superfluas, ĝi komencas faligi ilin. Kaj li kalkulas kiom da ili li faligis. Se la mezuriloj komencos superflui tie, ni scios pri tio. Ili nun ankaŭ venas al Prometeo, kaj vi povas vidi la grafikaĵojn en Grafana. Vi povas agordi atentigojn. Sed ankoraŭ ne estas klare al kiu sendi ilin.
la demando: En elasticsearch vi konservas protokolojn kun redundo. Kiom da kopioj vi havas?
Respondu: Unu linio.
la demando: Ĉu ĉi tio estas nur unu linio?
Respondu: Ĉi tiu estas la majstro kaj la kopio. La datumoj estas konservitaj en du kopioj.
la demando: Ĉu vi ĝustigis la rsyslog-bufrgrandon iel?
Respondu: Ni skribas datagramojn al kutima uniksa ingo. Ĉi tio tuj trudas al ni limon de 128 kilobajtoj. Ni ne povas skribi pli al ĝi. Ni skribis ĉi tion en la normo. Tiuj, kiuj volas eniri en stokadon, skribas 128 kilobajtojn. Bibliotekoj, krome, estas fortranĉitaj, kaj flago estas metita, ke la mesaĝo estas fortranĉita. Nia normo por la mesaĝo mem havas specialan kampon, kiu montras ĉu ĝi estis fortranĉita dum registrado aŭ ne. Do ni havas la ŝancon spuri ĉi tiun momenton ankaŭ.
Demando: Ĉu vi skribas rompitan JSON?
Respondu: Rompita JSON estos forĵetita aŭ dum relajso ĉar la pako estas tro granda. Aŭ Graylog estos forĵetita ĉar ĝi ne povas analizi JSON. Sed estas nuancoj, kiuj devas esti riparitaj, kaj ili estas plejparte ligitaj al rsyslog. Mi jam plenigis tie plurajn temojn, pri kiuj ankoraŭ necesas prilabori.
Demando: Kial Kafka? Ĉu vi provis RabbitMQ? Ĉu Graylog malsukcesas sub tiaj ŝarĝoj?
Respondu: Ĝi ne funkcias por ni kun Graylog. Kaj Graylog formiĝas por ni. Li estas vere problema. Li estas stranga afero. Kaj, fakte, ĝi ne estas bezonata. Mi preferus skribi de rsyslog rekte al elasticsearch kaj poste rigardi Kibana. Sed ni devas solvi la aferon kun la sekurecaj gardistoj. Ĉi tio estas ebla elekto por nia evoluo, kiam ni forĵetas Graylog kaj uzas Kibana. Ne utilas uzi Logstash. Ĉar mi povas fari la samon kun rsyslog. Kaj ĝi havas modulon por skribi al elasticsearch. Ni provas vivi iel kun Graylog. Ni eĉ iom agordis ĝin. Sed estas ankoraŭ loko por plibonigo.
Pri Kafka. Tiel okazis historie. Kiam mi alvenis, ĝi jam estis tie, kaj protokoloj jam estis skribitaj al ĝi. Ni simple levis nian areton kaj movis ŝtipojn en ĝin. Ni estas lia administrado, ni scias kiel li sentas. Koncerne RabbitMQ... ĝi ne funkcias por ni kun RabbitMQ. Kaj RabbitMQ formiĝas por ni. Ni havas ĝin en produktado, kaj estis problemoj kun ĝi. Nun, antaŭ la vendo, ili ĉarmus lin, kaj li eklaborus normale. Sed antaŭ tio mi ne estis preta liberigi ĝin en produktadon. Estas unu plia punkto. Graylog povas legi version AMQP 0.9, kaj rsyslog povas skribi version AMQP 1.0. Kaj ne estas unu sola solvo en la mezo, kiu povas fari ambaŭ. Ĝi estas aŭ unu aŭ la alia. Tial, nuntempe nur Kafka. Sed ĝi ankaŭ havas siajn proprajn nuancojn. Ĉar omkafka de la versio de rsyslog, kiun ni uzas, povas perdi la tutan mesaĝan bufron, kiun ĝi elrabis el rsyslog. Nuntempe ni eltenas ĝin.
Demando: Ĉu vi uzas Kafka ĉar vi jam havis ĝin? Ne plu uzata por iu ajn celo?
Respondu: Kafka, kiu estis, estas uzata de la teamo de Data Science. Temas pri tute aparta projekto, pri kiu mi bedaŭrinde nenion povas diri. Mi ne scias. Ĝi estis prizorgita fare de la Data Science-teamo. Kiam la protokoloj estis kreitaj, ni decidis uzi ĝin por ne instali nian propran. Nun ni ĝisdatigis Graylog, kaj ni perdis kongruon ĉar ĝi havas malnovan version de Kafka. Ni devis komenci nian propran. Samtempe, ni forigis ĉi tiujn kvar temojn por ĉiu API. Ni faris unu larĝan temon por ĉiuj vivas, unu larĝan temon por ĉiuj surscenigo kaj simple metis ĉion tien. Graylog skrapas ĉion ĉi paralele.
Demando: Kial ni bezonas ĉi tiun ŝamanismon kun ingoj? Ĉu vi provis uzi la syslog protokolan pelilon por ujoj?
Respondu: En la tempo, kiam ni faris ĉi tiun demandon, nia rilato kun la doker estis streĉa. Ĝi estis docker 1.0 aŭ 0.9. Docker mem estis stranga. Due, se vi ankaŭ puŝas protokolojn en ĝin... Mi havas nekontrolitan suspekton, ke ĝi pasas ĉiujn protokolojn tra si mem, tra la docker-demono. Se unu API freneziĝas, tiam la ceteraj API-oj estas blokitaj en la fakto, ke ili ne povas sendi stdout kaj stderr. Mi ne scias kien ĉi tio kondukos. Mi havas suspekton je la nivelo de sento, ke ne necesas uzi la Docker-syslog-ŝoforon en ĉi tiu loko. Nia funkcia testa fako havas sian propran Graylog-grupon kun protokoloj. Ili uzas Docker-registrajn ŝoforojn kaj ĉio ŝajnas esti bona tie. Sed ili tuj skribas GELF al Graylog. En la tempo, kiam ni komencis ĉion ĉi, ni nur bezonis, ke ĝi funkciu. Eble poste, kiam iu venos kaj diros, ke ĝi bone funkcias dum cent jaroj, ni provos.
Demando: Vi faras liveron inter datumcentroj uzante rsyslog. Kial ne Kafka?
Respondu: Ni faras ambaŭ fakte. Pro du kialoj. Se la kanalo estas tute morta, tiam ĉiuj niaj ŝtipoj, eĉ en kunpremita formo, ne rampos tra ĝi. Kaj Kafka permesas vin simple perdi ilin en la procezo. Jen kiel ni forigas, ke ĉi tiuj ŝtipoj blokiĝas. Ni nur uzas Kafkan rekte en ĉi tiu kazo. Se ni havas bonan kanalon kaj volas liberigi ĝin, tiam ni uzas ilian rsyslog. Sed fakte, vi povas agordi ĝin por ke ĝi mem faligu tion, kio ne konvenis. Nuntempe ni nur uzas rsyslog-liveron rekte ie, kaj Kafka ie.
fonto: www.habr.com