ProHoster > Blogs > Administrācija > Jurijs BuÅ”meļevs "Grābekļa karte baļķu savākÅ”anas un piegādes jomā" - ziņojuma atÅ”ifrējums

Jurijs BuÅ”meļevs "Grābekļa karte baļķu savākÅ”anas un piegādes jomā" - ziņojuma atÅ”ifrējums

Ž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.

Jurijs BuÅ”meļevs "Grābekļa karte baļķu savākÅ”anas un piegādes jomā" - ziņojuma atÅ”ifrējums

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.

Jurijs BuÅ”meļevs "Grābekļa karte baļķu savākÅ”anas un piegādes jomā" - ziņojuma atÅ”ifrējums

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.

Jurijs BuÅ”meļevs "Grābekļa karte baļķu savākÅ”anas un piegādes jomā" - ziņojuma atÅ”ifrējums

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.

Jurijs BuÅ”meļevs "Grābekļa karte baļķu savākÅ”anas un piegādes jomā" - ziņojuma atÅ”ifrējums

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.

Jurijs BuÅ”meļevs "Grābekļa karte baļķu savākÅ”anas un piegādes jomā" - ziņojuma atÅ”ifrējums

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.

Jurijs BuÅ”meļevs "Grābekļa karte baļķu savākÅ”anas un piegādes jomā" - ziņojuma atÅ”ifrējums

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.

Jurijs BuÅ”meļevs "Grābekļa karte baļķu savākÅ”anas un piegādes jomā" - ziņojuma atÅ”ifrējums

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.

Jurijs BuÅ”meļevs "Grābekļa karte baļķu savākÅ”anas un piegādes jomā" - ziņojuma atÅ”ifrējums

Es jums parādīŔu, kā mums tas izdevās Lazadā un kā tas viss sākās.

Jurijs BuÅ”meļevs "Grābekļa karte baļķu savākÅ”anas un piegādes jomā" - ziņojuma atÅ”ifrējums

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.

Jurijs BuÅ”meļevs "Grābekļa karte baļķu savākÅ”anas un piegādes jomā" - ziņojuma atÅ”ifrējums

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.

Jurijs BuÅ”meļevs "Grābekļa karte baļķu savākÅ”anas un piegādes jomā" - ziņojuma atÅ”ifrējums

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!

Jurijs BuÅ”meļevs "Grābekļa karte baļķu savākÅ”anas un piegādes jomā" - ziņojuma atÅ”ifrējums

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.

Jurijs BuÅ”meļevs "Grābekļa karte baļķu savākÅ”anas un piegādes jomā" - ziņojuma atÅ”ifrējums

Å 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.

Jurijs BuÅ”meļevs "Grābekļa karte baļķu savākÅ”anas un piegādes jomā" - ziņojuma atÅ”ifrējums

(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.

Jurijs BuÅ”meļevs "Grābekļa karte baļķu savākÅ”anas un piegādes jomā" - ziņojuma atÅ”ifrējums

Mēs sākām uzdot Å”os jautājumus. Nolēmām vainÄ«gos nemeklēt.

Jurijs BuÅ”meļevs "Grābekļa karte baļķu savākÅ”anas un piegādes jomā" - ziņojuma atÅ”ifrējums

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!

Jurijs BuÅ”meļevs "Grābekļa karte baļķu savākÅ”anas un piegādes jomā" - ziņojuma atÅ”ifrējums

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.

Jurijs BuÅ”meļevs "Grābekļa karte baļķu savākÅ”anas un piegādes jomā" - ziņojuma atÅ”ifrējums

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.

Jurijs BuÅ”meļevs "Grābekļa karte baļķu savākÅ”anas un piegādes jomā" - ziņojuma atÅ”ifrējums

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.

Jurijs BuÅ”meļevs "Grābekļa karte baļķu savākÅ”anas un piegādes jomā" - ziņojuma atÅ”ifrējums

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 raksts par BaduÅ”ečku, 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.

Jurijs BuÅ”meļevs "Grābekļa karte baļķu savākÅ”anas un piegādes jomā" - ziņojuma atÅ”ifrējums

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.

Jurijs BuÅ”meļevs "Grābekļa karte baļķu savākÅ”anas un piegādes jomā" - ziņojuma atÅ”ifrējums

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.

Jurijs BuÅ”meļevs "Grābekļa karte baļķu savākÅ”anas un piegādes jomā" - ziņojuma atÅ”ifrējums

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.

Jurijs BuÅ”meļevs "Grābekļa karte baļķu savākÅ”anas un piegādes jomā" - ziņojuma atÅ”ifrējums

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 raksts par BaduÅ”ečkukurÅ” 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.

Jurijs BuÅ”meļevs "Grābekļa karte baļķu savākÅ”anas un piegādes jomā" - ziņojuma atÅ”ifrējums

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.

Jurijs BuÅ”meļevs "Grābekļa karte baļķu savākÅ”anas un piegādes jomā" - ziņojuma atÅ”ifrējums

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.

Jurijs BuÅ”meļevs "Grābekļa karte baļķu savākÅ”anas un piegādes jomā" - ziņojuma atÅ”ifrējums

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.

Jurijs BuÅ”meļevs "Grābekļa karte baļķu savākÅ”anas un piegādes jomā" - ziņojuma atÅ”ifrējums

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ēļā.

Jurijs BuÅ”meļevs "Grābekļa karte baļķu savākÅ”anas un piegādes jomā" - ziņojuma atÅ”ifrējums

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.

Jurijs BuÅ”meļevs "Grābekļa karte baļķu savākÅ”anas un piegādes jomā" - ziņojuma atÅ”ifrējums

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.

Jurijs BuÅ”meļevs "Grābekļa karte baļķu savākÅ”anas un piegādes jomā" - ziņojuma atÅ”ifrējums

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.

Jurijs BuÅ”meļevs "Grābekļa karte baļķu savākÅ”anas un piegādes jomā" - ziņojuma atÅ”ifrējums

ÄŖ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

Pievieno komentāru