Žurnāli ir svarīga sistēmas daļa, kas ļauj saprast, ka tā darbojas (vai nedarbojas), kā paredzēts. Mikropakalpojumu arhitektūras apstākļos darbs ar baļķiem kļūst par atsevišķu speciālās olimpiādes disciplīnu. Ir daudz problēmu, kas jārisina:
- kā rakstīt žurnālus no lietojumprogrammas;
- kur rakstīt žurnālus;
- kā nogādāt baļķus uzglabāšanai un apstrādei;
- kā apstrādāt un uzglabāt žurnālus.
Šobrīd populāro konteinerizācijas tehnoloģiju izmantošana problēmu risināšanas iespēju jomā liek grābeklim virsū smiltis.
Tieši par to ir Jurija Bušmeļeva ziņojuma "Grābekļa karte baļķu savākšanas un piegādes jomā" atšifrējums.
Kam tas interesē, lūdzu zem kaķa.
Mani sauc Jurijs Bušmeļevs. Es strādāju Lazada. Šodien es runāšu par to, kā mēs veidojām savus baļķus, kā mēs tos savācām un ko mēs tur rakstām.
No kurienes mēs esam? Kas mēs esam? Lazada ir vadošais tiešsaistes mazumtirgotājs sešās Dienvidaustrumāzijas valstīs. Visas šīs valstis ir sadalītas pa datu centriem. Tagad kopā ir 1 datu centri. Kāpēc tas ir svarīgi? Jo daži lēmumi bija tāpēc, ka starp centriem ir ļoti vāja saikne. Mums ir mikropakalpojumu arhitektūra. Es biju pārsteigts, atklājot, ka mums jau ir 4 mikropakalpojumi. Kad sāku uzdevumu ar žurnāliem, to bija tikai 80. Turklāt ir diezgan liels PHP mantojuma gabals, ar kuru arī man ir jāsadzīvo un jāsamierinās. Tas viss mums šobrīd rada vairāk nekā 20 miljonus ziņojumu minūtē visai sistēmai. Tālāk es parādīšu, kā mēs cenšamies ar to sadzīvot un kāpēc tas tā ir.
Ar šiem 6 miljoniem ziņojumu kaut kā ir jāsadzīvo. Ko mums ar viņiem darīt? Nepieciešami 6 miljoni ziņojumu:
- sūtīt no lietotnes
- pieņemt piegādei
- piegādāt analīzei un uzglabāšanai.
- analizēt
- kaut kā uzglabāt.
Kad bija trīs miljoni ziņojumu, man bija apmēram tāds pats izskats. Jo sākām ar dažiem santīmiem. Skaidrs, ka tur ir rakstīti pieteikumu žurnāli. Piemēram, nevarēja izveidot savienojumu ar datu bāzi, varēja izveidot savienojumu ar datu bāzi, bet nevarēja kaut ko nolasīt. Bet papildus tam katrs mūsu mikropakalpojums raksta arī piekļuves žurnālu. Katrs pieprasījums, kas pienāk mikropakalpojumā, iekrīt žurnālā. Kāpēc mēs to darām? Izstrādātāji vēlas, lai tie varētu izsekot. Katrā piekļuves žurnālā ir izsekošanas lauks, saskaņā ar kuru īpašs interfeiss pēc tam atrit visu ķēdi un skaisti parāda izsekošanu. Izsekošana parāda, kā tika izpildīts pieprasījums, un tas palīdz mūsu izstrādātājiem ātrāk tikt galā ar nezināmiem atkritumiem.
Kā ar to sadzīvot? Tagad es īsi aprakstīšu opciju lauku - kā šī problēma kopumā tiek atrisināta. Kā atrisināt baļķu savākšanas, pārvietošanas un uzglabāšanas problēmu.
Kā rakstīt no pieteikuma? Ir skaidrs, ka ir dažādi veidi. Jo īpaši ir labākā prakse, kā mums stāsta modes biedri. Ir divu veidu vecā skola, kā teica vectēvi. Ir arī citi veidi.
Ar baļķu vākšanu situācija ir aptuveni tāda pati. Lai atrisinātu šo konkrēto daļu, nav tik daudz iespēju. Viņu ir vairāk, bet vēl nav tik daudz.
Taču ar piegādi un turpmāko analīzi variāciju skaits sāk eksplodēt. Tagad neaprakstīšu katru variantu. Es domāju, ka galvenās iespējas ir labi zināmas visiem, kam šī tēma interesēja.
Es jums parādīšu, kā mums tas izdevās Lazadā un kā tas viss sākās.
Pirms gada atbraucu uz Lazadu un mani nosūtīja uz baļķu projektu. Tur bija šādi. Lietojumprogrammas žurnāls tika rakstīts uz stdout un stderr. Viss tika darīts modernā veidā. Bet tad izstrādātāji to izmeta no standarta straumēm, un tad infrastruktūras speciālisti to kaut kā izdomās. Starp infrastruktūras speciālistiem un izstrādātājiem ir arī izdevēji, kuri teica: "u... nu, vienkārši iesaiņosim tos failā ar čaulu, un viss." Un tā kā tas viss ir konteinerā, viņi to iesaiņoja tieši pašā konteinerā, kartēja iekšā esošo direktoriju un ievietoja to. Es domāju, ka visiem ir diezgan skaidrs, kas notika.
Paskatīsimies mazliet tālāk. Kā mēs piegādājām šos baļķus. Kāds izvēlējās td-agent, kas faktiski ir fluentd, bet ne gluži brīvi. Es joprojām nesaprotu šo divu projektu attiecības, bet šķiet, ka tie ir par vienu un to pašu. Un šis fluentd, kas rakstīts Ruby valodā, lasīja žurnālfailus, parsēja tos JSON, izmantojot kaut kādas regulāras izteiksmes. Tad viņi tika nosūtīti uz Kafku. Turklāt Kafkā mums bija 4 atsevišķas tēmas katrai API. Kāpēc 4? Jo ir tiešraide, ir iestudējums un tāpēc, ka ir stdout un stderr. Izstrādātāji tos ražo, un infrastruktūras darbiniekiem tie jāizveido Kafkā. Turklāt Kafku kontrolēja cita nodaļa. Tāpēc vajadzēja izveidot biļeti, lai viņi tur izveidoja 4 tēmas katrai api. Visi par to aizmirsa. Kopumā tā bija miskaste un atkritumi.
Ko mēs ar to darījām tālāk? Mēs to nosūtījām kafkai. Tālāk no Kafkas puse baļķu aizlidoja uz Logstašu. Otra puse no baļķiem tika dalīta. Daži lidoja uz vienu Greylog, daži uz citu Graylog. Rezultātā tas viss ieplūda vienā Elasticsearch klasterī. Tas ir, viss šis haoss galu galā iekrita tur. Jums tas nav jādara!
Tā tas izskatās, skatoties no augšas. Jums tas nav jādara! Šeit problemātiskās vietas uzreiz tiek atzīmētas ar cipariem. Patiesībā viņu ir vairāk, bet 6 ir patiešām problemātiskas, ar kurām kaut kas jādara. Par tiem tagad pastāstīšu atsevišķi.
Šeit (1,2,3) mēs rakstām failus un attiecīgi šeit ir trīs grābekļi uzreiz.
Pirmais (1) ir tas, ka mums tie kaut kur jāuzraksta. Ne vienmēr ir vēlams nodrošināt API iespēju rakstīt tieši failā. Ir vēlams, lai API būtu izolēts konteinerā, un vēl labāk, lai tas būtu tikai lasāms. Esmu sistēmas administrators, tāpēc man ir nedaudz alternatīvs skatījums uz šīm lietām.
Otrais punkts (2,3.) ir tāds, ka API saņem daudz pieprasījumu. API failā ieraksta daudz datu. Faili pieaug. Mums tie ir jāpagriež. Jo citādi tur nevarēs saglabāt nevienu disku. To pagriešana ir slikta, jo tie tiek novirzīti caur čaulu uz direktoriju. Mēs to nekādi nevaram pagriezt. Jūs nevarat likt lietojumprogrammai atkārtoti atvērt rokturus. Jo izstrādātāji uz tevi skatīsies kā uz muļķi: “Kādi deskriptori? Mēs parasti rakstām uz stdout. Ietvariem tika veikta kopēšana par logrotate, kas tikai izveido faila kopiju un atdala oriģinālu. Attiecīgi starp šiem kopēšanas procesiem diska vieta parasti izbeidzas.
(4) Mums bija dažādi formāti dažādās API. Tie bija nedaudz atšķirīgi, bet regexp bija jāraksta savādāk. Tā kā to visu vadīja Lelle, bija liels bars klašu ar saviem tarakāniem. Turklāt td aģents lielāko daļu laika varēja ēst atmiņu, būt stulbs, viņš varēja vienkārši izlikties, ka strādā, un neko nedarīt. Ārēji nevarēja saprast, ka viņš neko nedara. Labākajā gadījumā viņš nokritīs, un vēlāk kāds viņu pacels. Precīzāk, ielidos trauksme, un kāds ies un pacels to ar rokām.
(6) Un visvairāk atkritumu un atkritumu - tas bija elasticsearch. Jo tā bija veca versija. Jo mums tajā laikā nebija veltītu meistaru. Mums bija neviendabīgi baļķi, kuru lauki varēja pārklāties. Ar vienādiem lauku nosaukumiem var rakstīt dažādus dažādu lietojumprogrammu žurnālus, bet tajā pašā laikā iekšpusē var būt dažādi dati. Tas ir, viens žurnāls nāk ar veselu skaitli laukā, piemēram, līmenī. Citam žurnālam ir pievienota virkne līmeņa laukā. Ja nav statiskās kartēšanas, izrādās tik brīnišķīga lieta. Ja pēc indeksa pagriešanas elasticsearch pirmais ieradās ziņojums ar virkni, tad mēs dzīvojam normāli. Un, ja pirmais tika saņemts ar Integer, tad visi nākamie ziņojumi, kas tika saņemti ar virkni, tiek vienkārši izmesti. Tā kā lauka veids neatbilst.
Mēs sākām uzdot šos jautājumus. Nolēmām vainīgos nemeklēt.
Bet kaut kas ir jādara! Acīmredzami ir tas, ka mums ir jāizveido standarti. Mums jau bija daži standarti. Dažus atvedām nedaudz vēlāk. Par laimi, tajā laikā jau tika apstiprināts viens žurnāla formāts visām API. Tas ir ierakstīts tieši pakalpojumu mijiedarbības standartos. Attiecīgi tiem, kas vēlas saņemt žurnālus, tie jāraksta šādā formātā. Ja kāds neraksta žurnālus šādā formātā, tad mēs neko negarantējam.
Turklāt es vēlētos vienotu standartu baļķu reģistrēšanas, piegādes un savākšanas metodēm. Patiesībā, kur tos rakstīt un kā tos piegādāt. Ideāla situācija ir tad, ja projekti izmanto vienu un to pašu bibliotēku. Ir atsevišķa reģistrēšanas bibliotēka Go, ir atsevišķa bibliotēka PHP. Ikvienam, kas mums ir, visiem tie ir jāizmanto. Šobrīd es teiktu, ka mums tas izdodas par 80 procentiem. Bet daži turpina ēst kaktusus.
Un tur (slaidā) “SLA baļķu piegādei” tik tikko sāk parādīties. Tā vēl nav, bet mēs pie tā strādājam. Jo tas ir ļoti ērti, ja infra saka, ka, ja tu rakstīsi tādā un tādā formātā uz tādu un tādu vietu un ne vairāk kā N ziņas sekundē, tad mēs to visticamāk tur nogādāsim. Tas noņem daudzas galvassāpes. Ja ir SLA, tad tas ir vienkārši lieliski!
Kā mēs sākām risināt problēmu? Galvenais grābeklis bija ar td-agent. Nebija skaidrs, kur nonāk mūsu baļķi. Vai tie tiek piegādāti? Vai viņi iet? Kur viņi vispār ir? Tāpēc tika nolemts aizstāt td-agent ar pirmo vienumu. Šeit es īsumā izklāstīju iespējas, ar ko to aizstāt.
Fluentd. Pirmkārt, es saskāros ar viņu iepriekšējā darbā, un viņš arī periodiski tur krita. Otrkārt, tas ir tas pats, tikai profilā.
filebeat. Kā tas mums bija labs? Fakts, ka viņš ir Go, un mums ir liela pieredze Go. Attiecīgi, ja kas, mēs to varētu kaut kā pievienot sev. Tāpēc mēs to neņēmām. Lai pat nebūtu kārdinājuma sākt to pārrakstīt sev.
Acīmredzams risinājums sysadminam ir visu veidu syslogs šādā daudzumā (syslog-ng/rsyslog/nxlog).
Vai arī uzrakstiet kaut ko savu, bet mēs to atmetām, tāpat kā filebeat. Ja kaut ko raksti, tad labāk uzrakstīt ko noderīgu biznesam. Lai piegādātu baļķus, labāk ņemt kaut ko gatavu.
Tāpēc izvēle faktiski bija izvēle starp syslog-ng un rsyslog. Es sliecos uz rsyslog vienkārši tāpēc, ka mums jau bija rsyslog nodarbības programmā Puppet, un es neatradu starp tām acīmredzamu atšķirību. Kas ir syslog, kas ir syslog. Jā, daži dokumenti ir sliktāki, daži labāki. Viņš to zina, un viņš to dara savādāk.
Un nedaudz par rsyslog. Pirmkārt, tas ir forši, jo tajā ir daudz moduļu. Tam ir cilvēkiem lasāma RainerScript (mūsdienu konfigurācijas valoda). Lielisks bonuss ir tas, ka mēs varētu līdzināties td-agent darbībai ar tā standarta rīkiem, un lietojumprogrammām nekas nav mainījies. Tas nozīmē, ka mēs mainām td-agent uz rsyslog un vēl nepieskaramies visam pārējam. Un nekavējoties saņemam darba piegādi. Nākamais, mmnormalize ir foršais rsyslog. Tas ļauj parsēt žurnālus, bet ne ar Grok un regexp. Tas veido abstraktu sintakses koku. Tas parsē žurnālus tādā pašā veidā, kā kompilators parsē avota kodu. Tas ļauj strādāt ļoti ātri, ēst maz CPU, un kopumā tā ir ļoti forša lieta. Ir virkne citu bonusu. Es pie tiem nekavēšos.
rsyslog ir daudz vairāk trūkumu. Tie ir aptuveni tādi paši kā prēmijas. Galvenās problēmas ir tādas, ka jums ir jāspēj to pagatavot, un jums ir jāizvēlas versija.
Nolēmām, ka žurnālus rakstīsim unix ligzdā. Un ne mapē /dev/log, jo tur mums ir sistēmas žurnālu haoss, šajā konveijerā ir žurnāls. Tātad rakstīsim uz pielāgotu ligzdu. Mēs to pievienosim atsevišķam noteikumu kopumam. Nejaucam neko. Viss būs caurspīdīgs un saprotams. Tā mēs patiesībā darījām. Direktorija ar šīm ligzdām ir standartizēta un pārsūtīta uz visiem konteineriem. Konteineri var redzēt vajadzīgo ligzdu, atvērt un rakstīt uz to.
Kāpēc ne failu? Jo visi ir lasījuši , kas mēģināja pārsūtīt failu uz docker, un konstatēja, ka pēc rsyslog restartēšanas mainās faila deskriptors un docker zaudē šo failu. Viņš turpina atvērt kaut ko citu, bet ne to pašu kontaktligzdu, kurā viņi raksta. Mēs nolēmām, ka apiesim šo problēmu un tajā pašā laikā apiesim bloķēšanas problēmu.
Rsyslog veic slaidā norādītās darbības un nosūta žurnālus uz releju vai Kafka. Kafka iet pa veco ceļu. Rayleigh - es mēģināju izmantot tīru rsyslog, lai piegādātu žurnālus. Bez ziņojumu rindas, izmantojot standarta rsyslog rīkus. Būtībā tas darbojas.
Taču ir nianses, kā tās vēlāk ievietot šajā daļā (Logstash/Graylog/ES). Šī daļa (rsyslog-rsyslog) tiek izmantota starp datu centriem. Šeit ir saspiesta tcp saite, kas ļauj ietaupīt joslas platumu un attiecīgi kaut kā palielināt varbūtību, ka mēs saņemsim dažus žurnālus no cita datu centra, kad kanāls būs pilns. Jo mums ir Indonēzija, kur viss ir slikti. Lūk, kur slēpjas pastāvīgā problēma.
Mēs domājām par to, kā mēs faktiski uzraugām, ar kādu varbūtību no lietojumprogrammas ierakstītie žurnāli sasniedz šo mērķi? Mēs nolēmām sākt metriku. Rsyslog ir savs statistikas vākšanas modulis, kurā ir sava veida skaitītāji. Piemēram, tas var parādīt rindas lielumu vai to, cik ziņojumu ir saņemts šādā un tādā darbībā. No viņiem jau var kaut ko paņemt. Turklāt tam ir pielāgoti skaitītāji, kurus varat konfigurēt, un tas parādīs, piemēram, dažu API reģistrēto ziņojumu skaitu. Tālāk es Pythonā uzrakstīju rsyslog_exporter, un mēs to visu nosūtījām Prometheus un izveidojām grafikus. Mēs ļoti vēlējāmies Graylog metriku, taču līdz šim mums nav bijis laika to iestatīt.
Kādas ir problēmas? Problēma radās ar faktu, ka mēs uzzinājām (pēkšņi!), ka mūsu Live API raksta 50 12 ziņojumu sekundē. Tas ir tikai tiešraides API bez inscenēšanas. Un Graylog mums parāda tikai XNUMX tūkstošus ziņojumu sekundē. Un radās pamatots jautājums, kur paliek paliekas? No kā mēs secinājām, ka Greylog vienkārši netiek galā. Mēs paskatījāmies, un patiešām, Greylog ar Elasticsearch nepārvalda šo plūsmu.
Tālāk, citi atklājumi, ko esam veikuši ceļā.
Rakstīšana kontaktligzdā ir bloķēta. Kā tas notika? Kad piegādei izmantoju rsyslog, kādā brīdī mēs pārrāvām kanālu starp datu centriem. Piegāde pacēlās vienā vietā, piegāde pacēlās citā vietā. Tas viss ir nonācis mašīnā ar API, kas raksta uz rsyslog ligzdu. Tur bija rinda. Tad aizpildījās rinda rakstīšanai uz unix ligzdu, kas pēc noklusējuma ir 128 paketes. Un nākamais rakstiet () lietojumprogrammu blokos. Kad apskatījām bibliotēku, kuru lietojam Go lietojumprogrammās, tur bija rakstīts, ka rakstīšana uz ligzdu notiek nebloķēšanas režīmā. Mēs bijām pārliecināti, ka nekas nav bloķēts. Jo mēs esam lasījuši kurš par to rakstīja. Bet ir mirklis. Ap šo zvanu bija arī bezgalīga cilpa, kurā nepārtraukti tika mēģināts iespiest ligzdā ziņojumu. Mēs viņu nepamanījām. Man bija jāpārraksta bibliotēka. Kopš tā laika tas ir vairākkārt mainījies, bet tagad esam atbrīvojušies no slēdzenēm visās apakšsistēmās. Tāpēc jūs varat apturēt rsyslog un nekas nekritīs.
Ir jāuzrauga rindu lielums, kas palīdz neuzkāpt uz šī grābekļa. Pirmkārt, mēs varam pārraudzīt, kad sākam zaudēt ziņojumus. Otrkārt, mēs varam uzraudzīt, ka mums pamatā ir problēmas ar piegādi.
Un vēl viens nepatīkams moments - pastiprināšana par 10 reizēm mikropakalpojumu arhitektūrā ir ļoti vienkārša. Mums nav tik daudz ienākošo pieprasījumu, taču diagrammas dēļ, kurā šie ziņojumi tiek rādīti tālāk, piekļuves žurnālu dēļ mēs faktiski palielinām žurnālu slodzi apmēram desmit reizes. Diemžēl man nebija laika aprēķināt precīzus skaitļus, bet mikropakalpojumi ir tādi, kādi tie ir. Tas ir jāpatur prātā. Izrādās, šobrīd Lazadā visvairāk noslogota baļķu savākšanas apakšsistēma.
Kā atrisināt elastīgās meklēšanas problēmu? Ja jums ir nepieciešams ātri iegūt žurnālus vienuviet, lai nedarbotos visās iekārtās un neapkopotu tos tur, izmantojiet failu krātuvi. Tas garantēti darbosies. Tas tiek darīts no jebkura servera. Jums vienkārši jāpielīmē diski un jāievieto syslog. Pēc tam jūs garantējat, ka visi baļķi būs vienuviet. Tad būs iespējams lēnām konfigurēt elasticsearch, graylog vai ko citu. Bet jums jau būs visi žurnāli, un turklāt jūs varat tos uzglabāt, ja vien ir pietiekami daudz disku masīvu.
Mana ziņojuma laikā shēma sāka izskatīties šādi. Mēs praktiski pārtraucām rakstīt failā. Tagad, visticamāk, mēs izslēgsim paliekas. Vietējās iekārtās, kurās darbojas API, mēs pārtrauksim rakstīt failos. Pirmkārt, ir failu krātuve, kas darbojas ļoti labi. Otrkārt, šajās mašīnās pastāvīgi pietrūkst vietas, jums tas pastāvīgi jāuzrauga.
Šī daļa ar Logstash un Graylog patiešām paceļas. Tāpēc jums ir jāatbrīvojas no tā. Jums ir jāizvēlas viens.
Mēs nolēmām nomest Logstash un Kibana. Jo mums ir drošības nodaļa. Kāds ir savienojums? Saistība ir tāda, ka Kibana bez X-Pack un bez vairoga neļauj jums atšķirt piekļuves tiesības žurnāliem. Tāpēc viņi paņēma Greylog. Tam ir viss. Man tas nepatīk, bet tas darbojas. Mēs iegādājāmies jaunu aparatūru, instalējām tur jaunu Graylog un pārvietojām visus žurnālus ar stingriem formātiem uz atsevišķu Graylog. Esam organizatoriski atrisinājuši problēmu ar dažāda veida vienādām jomām.
Kas īsti ir iekļauts jaunajā Graylog. Mēs vienkārši visu ierakstījām dokā. Mēs paņēmām virkni serveru, izlaidām trīs Kafka gadījumus, 7 Graylog serveru versiju 2.3 (jo es gribēju Elasticsearch versiju 5). Tas viss tika izvirzīts reidos no HDD. Mēs redzējām indeksēšanas ātrumu līdz 100 tūkstošiem ziņojumu sekundē. Mēs redzējām skaitli, ka 140 terabaiti datu nedēļā.
Un atkal grābeklis! Mums ir divas izpārdošanas. Mēs esam pārcēluši vairāk nekā 6 miljonus ziņu. Mums, Greylogam, nav laika košļāt. Kaut kā atkal ir jāizdzīvo.
Tā mēs izdzīvojām. Pievienoti vēl daži serveri un SSD. Šobrīd dzīvojam šādi. Tagad mēs jau košļājam 160 XNUMX ziņojumu sekundē. Mēs vēl neesam sasnieguši robežu, tāpēc nav skaidrs, cik daudz mēs reāli varam no tā iegūt.
Tādi ir mūsu nākotnes plāni. No tiem patiešām vissvarīgākā, iespējams, ir augsta pieejamība. Mums tā vēl nav. Vairākas mašīnas ir uzstādītas vienādi, bet pagaidām viss iet caur vienu mašīnu. Ir nepieciešams pavadīt laiku, lai starp tām iestatītu kļūmjpārlēci.
Apkopojiet metriku no Graylog.
Iestatiet ātruma ierobežojumu, lai mums būtu viena traka API, kas neiznīcina joslas platumu un visu pārējo.
Un visbeidzot parakstiet kaut kādu SLA ar izstrādātājiem, lai mēs varētu tik daudz apkalpot. Ja raksti vairāk, tad atvainojos.
Un rakstīt dokumentāciju.
Īsumā par visu, ko esam piedzīvojuši, rezultāti. Pirmkārt, standarti. Otrkārt, syslog ir kūka. Treškārt, rsyslog darbojas tieši tā, kā rakstīts uz slaida. Un ķersimies pie jautājumiem.
jautājumi.
jautājums: Kāpēc viņi nolēma neņemt ... (filebeat?)
atbilde: jāraksta failā. Es tiešām negribēju. Ja jūsu API raksta tūkstošiem ziņojumu sekundē, pat ja jūs to pagriežat reizi stundā, tas joprojām nav risinājums. Jūs varat rakstīt caurulē. Uz ko izstrādātāji man jautāja: “Kas notiks, ja process, kurā mēs rakstām, nokristos”? Es vienkārši neatradu, ko viņiem atbildēt, un teicu: "Nu, labi, nedarīsim tā."
jautājums: Kāpēc jūs vienkārši nerakstāt žurnālus HDFS?
atbildeA: Šis ir nākamais solis. Mēs par to domājām pašā sākumā, bet, tā kā šobrīd nav resursu, lai ar to nodarbotos, tas paliek mūsu ilgtermiņa risinājumā.
jautājums: piemērotāks būtu kolonnas formāts.
atbilde: Es saprotu. Mēs esam "par" ar abām rokām.
jautājums: Jūs rakstāt uz rsyslog. Tur ir pieejami gan TCP, gan UDP. Bet ja UDP, tad kā jūs garantējat piegādi?
atbildeA: Ir divi punkti. Pirmkārt, es uzreiz visiem saku, ka mēs negarantējam baļķu piegādi. Jo, kad atnāk izstrādātāji un saka: “Sāksim tur rakstīt finanšu datus, un jūs tos kaut kur noliksit mums, ja kaut kas notiks”, mēs viņiem atbildam: “Lieliski! Sāksim bloķēt rakstīšanu ligzdā, un darīsim to darījumos, lai jūs garantēti to ieliktu ligzdā mūsu vietā un pārliecinātos, ka mēs to saņēmām no otras puses. Un šajā brīdī visi uzreiz kļūst nevajadzīgi. Un ja nē, tad kādi jautājumi mums ir? Ja nevēlaties garantēt rakstīšanu kontaktligzdā, tad kāpēc mēs garantējam piegādi? Mēs darām visu iespējamo. Mēs patiešām cenšamies piegādāt pēc iespējas vairāk un pēc iespējas labāk, taču nedodam 100% garantiju. Tāpēc tur nav jāraksta finanšu dati. Šim nolūkam ir darījumu datu bāzes.
jautājums: Kad API ģenerē kādu ziņojumu žurnālam un nodod kontroli uz mikropakalpojumiem, vai esat saskāries ar problēmu, ka ziņojumi no dažādiem mikropakalpojumiem tiek saņemti nepareizā secībā? Sakarā ar to rodas apjukums.
atbildeA: Tas ir normāli, ka tie nāk citā secībā. Tam ir jābūt gatavam. Tā kā jebkura tīkla piegāde negarantē jums pasūtījumu, vai arī jums ir jātērē īpaši resursi. Ja mēs ņemam failu krātuves, tad katra API saglabā žurnālus savā failā. Drīzāk rsyslog sadala tos tur esošajos direktorijos. Katrai API ir savi žurnāli, kuros varat doties un apskatīties, un pēc tam varat tos salīdzināt, izmantojot šī žurnāla laikspiedolu. Ja viņi iet meklēt Graylog, tad tur tie tiks sakārtoti pēc laika zīmoga. Tur viss būs labi.
jautājums: laikspiedols var atšķirties pa milisekundēm.
atbilde: laikspiedolu ģenerē pati API. Patiesībā šī ir visa būtība. Mums ir NTP. API ģenerē laikspiedolu jau pašā ziņojumā. To nepievieno rsyslog.
jautājums: Mijiedarbība starp datu centriem nav ļoti skaidra. Datu centra ietvaros ir skaidrs, kā tika vākti un apstrādāti žurnāli. Kā notiek mijiedarbība starp datu centriem? Vai arī katrs datu centrs dzīvo savu dzīvi?
atbilde: Gandrīz. Katra valsts atrodas vienā datu centrā. Mums pašlaik nav izkliedes, lai viena valsts būtu izvietota dažādos datu centros. Tāpēc nav nepieciešams tos apvienot. Katra centra iekšpusē ir baļķu relejs. Šis ir Rsyslog serveris. Patiesībā divas vadības mašīnas. Tie ir iestatīti tādā pašā veidā. Taču pagaidām satiksme iet tikai caur vienu no tām. Viņa reģistrē visu apkopojumus. Tam katram gadījumam ir diska rinda. Viņa nospiež žurnālus un nosūta uz centrālo datu centru (Singapūra), kur tālāk tie jau tiek saindēti Greylogā. Un katram datu centram ir sava failu krātuve. Gadījumā, ja mēs zaudējam savienojumu, mums ir visi žurnāli. Viņi tur paliks. Tur tie tiks glabāti.
jautājums: Vai neparastās situācijās no turienes saņemat baļķus?
atbilde: varat doties tur (uz failu krātuvi) un apskatīties.
jautājums: Kā uzraugāt, lai žurnāli nepazaudētu?
atbilde: Mēs tos faktiski zaudējam, un mēs to uzraugām. Monitorings sākās pirms mēneša. Bibliotēkai, ko izmanto Go API, ir metrika. Viņa var saskaitīt, cik reizes viņai neizdevās rakstīt uz ligzdu. Šobrīd tur ir viltīga heiristika. Tur ir buferis. Tas mēģina uzrakstīt ziņojumu no tā uz ligzdu. Ja buferis pārplūst, tas sāk tos nomest. Un viņš saskaita, cik viņš tos nometa. Ja skaitītāji tur sāks plūst pāri, mēs par to uzzināsim. Viņi tagad nāk arī uz Prometheus, un jūs varat redzēt grafikus Grafana. Varat iestatīt brīdinājumus. Taču pagaidām nav skaidrs, kam tās sūtīt.
jautājums: programmā elasticsearch jūs glabājat žurnālus ar dublēšanos. Cik repliku jums ir?
atbilde: Viena kopija.
jautājums: Vai tā ir tikai viena rinda?
atbilde: Šis ir galvenais un kopija. Dati tiek glabāti divos eksemplāros.
jautājums: Vai jūs kaut kā mainījāt rsyslog bufera lielumu?
atbilde: Mēs rakstām datagrammas uz pielāgotu unix ligzdu. Tas mums nekavējoties uzliek 128 kilobaitu ierobežojumu. Mēs nevaram tajā rakstīt vairāk. Mēs to esam ierakstījuši standartā. Kas vēlas iekļūt krātuvē, viņi raksta 128 kilobaitus. Bibliotēkas turklāt nogriež un uzliek karogu, ka ziņa ir nogriezta. Pašā ziņojuma standartā mums ir īpašs lauks, kas parāda, vai ierakstīšanas laikā tas tika nogriezts vai nē. Tātad mums ir iespēja izsekot šim brīdim.
Jautājums: Vai jūs rakstāt bojātu JSON?
atbilde: Bojāts JSON tiks izmests pārraides laikā, jo pakete ir pārāk liela. Vai arī Graylog tiks atmests, jo tas nevarēs parsēt JSON. Bet šeit ir nianses, kas ir jālabo, un tās galvenokārt ir saistītas ar rsyslog. Tur jau esmu aizpildījis dažus numurus, pie kuriem vēl jāpiestrādā.
Jautājums: Kāpēc Kafka? Vai esat izmēģinājis RabbitMQ? Pie tādām slodzēm pelēklogs nesanāk?
atbilde: Ar Graylog tas neizdodas. Un Greylog iegūst formu. Viņam tas tiešām ir problemātiski. Viņš ir sava veida lieta. Un patiesībā tas nav vajadzīgs. Es labāk rakstīšu no rsyslog tieši uz elasticsearch un tad skatos Kibana. Bet mums ir jārisina jautājums ar apsargiem. Tas ir iespējamais mūsu attīstības variants, kad mēs izmetam Graylog un lietojam Kibana. Logstash nebūs jēgas. Jo es varu darīt to pašu ar rsyslog. Un tam ir modulis, lai rakstītu elasticsearch. Ar Greylog mēs cenšamies kaut kā sadzīvot. Mēs to pat nedaudz pielabojām. Taču vēl ir kur uzlaboties.
Par Kafku. Tā tas notika vēsturiski. Kad es ierados, tas jau bija tur, un tai jau tika rakstīti žurnāli. Mēs tikko paaugstinājām savu kopu un pārvietojām tajā baļķus. Mēs viņu pārvaldām, zinām, kā viņš jūtas. Kas attiecas uz RabbitMQ... mums ir problēmas ar RabbitMQ. Un RabbitMQ mums attīstās. Mums tas ir ražošanā, un ar to bija problēmas. Tagad, pirms pārdošanas, viņš tika šamanizēts, un viņš sāks normāli strādāt. Bet pirms tam es nebiju gatavs to laist ražošanā. Ir vēl viens punkts. Graylog var lasīt AMQP 0.9 versiju un rsyslog var rakstīt AMQP 1.0 versiju. Un nav neviena risinājuma, kas varētu veikt abus pa vidu. Ir vai nu viens, vai otrs. Tātad pagaidām tikai Kafka. Bet ir arī nianses. Tā kā mūsu izmantotās rsyslog versijas omkafka var pazaudēt visu ziņojumu buferi, ko tas izņēma no rsyslog. Kamēr mēs to pacietīsim.
Jautājums: Vai jūs lietojat Kafku, jo jums tā bija? Vai neizmantojat kādam citam mērķim?
atbilde: Kafka, ko izmantoja datu zinātnes komanda. Tas ir pilnīgi atsevišķs projekts, par kuru diemžēl neko nevaru pateikt. ES nezinu. Viņu vadīja Data Science komanda. Kad sākās baļķi, nolēma to izmantot, lai neliktu savu. Tagad esam atjauninājuši Graylog, un esam zaudējuši savietojamību, jo ir veca Kafka versija. Mums bija jātaisa savējie. Tajā pašā laikā mēs atbrīvojāmies no šīm četrām tēmām katrai API. Mēs izveidojām vienu platu augšdaļu visiem tiešraidēm, vienu platu platu augšdaļu visiem iestudējumiem, un mēs tur visu vienkārši nofilmējam. Graylog grābj to visu paralēli.
Jautājums: Kāpēc mums vajag šo šamanismu ar rozetēm? Vai esat mēģinājis konteineriem izmantot syslog žurnāla draiveri.
atbilde: Laikā, kad uzdevām šo jautājumu, mums bija saspringtas attiecības ar dokeri. Tas bija docker 1.0 vai 0.9. Pats Dokers bija dīvains. Otrkārt, ja tu tajā iegrūdīs arī baļķus... Man ir nepārbaudītas aizdomas, ka tas visus baļķus izlaiž caur sevi, caur dokera dēmonu. Ja mums ir viens API, kas kļūst traks, tad pārējās API saskarsies ar faktu, ka tās nevar nosūtīt stdout un stderr. Es nezinu, kur tas novedīs. Man ir aizdomas sajūtas līmenī, ka šajā vietā nav nepieciešams izmantot docker syslog draiveri. Mūsu funkcionālās testēšanas nodaļai ir savs Graylog klasteris ar baļķiem. Viņi izmanto docker log draiverus, un šķiet, ka tur viss ir kārtībā. Bet viņi uzreiz raksta GELF uz Greylog. Brīdī, kad mēs to visu sākām, mums vajadzēja, lai tas vienkārši darbojas. Varbūt vēlāk, kad kāds atnāks un teiks, ka jau simts gadus strādā normāli, mēģināsim.
Jautājums: Jūs piegādājat starp datu centriem, izmantojot rsyslog. Kāpēc ne uz Kafku?
atbilde: Mēs to darām, un tā tas patiesībā ir. Divu iemeslu dēļ. Ja kanāls ir pilnīgi miris, tad visi mūsu baļķi, pat saspiestā veidā, netiks cauri tam. Un kafka ļauj viņiem vienkārši zaudēt šajā procesā. Tādā veidā mēs atbrīvojamies no šo baļķu pielipšanas. Mēs šajā gadījumā tieši izmantojam Kafku. Ja mums ir labs kanāls un vēlamies to atbrīvot, tad izmantojam viņu rsyslog. Bet patiesībā jūs varat to iestatīt tā, lai tas atmestu to, kas nav ticis cauri. Pašlaik mēs tikai izmantojam rsyslog piegādi tieši kaut kur, kaut kur Kafka.
Avots: www.habr.com