Logs is 'n belangrike deel van die stelsel, wat jou toelaat om te verstaan dat dit werk (of nie werk nie) soos verwag word. Onder die voorwaardes van mikrodiensargitektuur word werk met logs 'n aparte dissipline van die Spesiale Olimpiade. Daar is baie kwessies wat aangespreek moet word:
- hoe om logs vanaf die toepassing te skryf;
- waar om logs te skryf;
- hoe om logs vir berging en verwerking af te lewer;
- hoe om logs te verwerk en te stoor.
Die gebruik van tans gewilde containeriseringstegnologieë voeg sand bo-op die hark op die gebied van probleemoplossingsopsies.
Net hieroor is die transkripsie van die verslag deur Yuri Bushmelev "Kaart van 'n hark in die veld van die versameling en aflewering van houtblokke"
Wie gee om, asseblief onder die kat.
My naam is Yuri Bushmelev. Ek werk vir Lazada. Vandag sal ek praat oor hoe ons ons logs gemaak het, hoe ons dit versamel het en wat ons daar skryf.
Waar kom ons vandaan? Wie is ons? Lazada is die #1 aanlyn handelaar in ses lande in Suidoos-Asië. Al hierdie lande is onder datasentrums versprei. Daar is nou altesaam 4 datasentrums. Hoekom is dit belangrik? Omdat sommige besluite te wyte was aan die feit dat daar 'n baie swak skakel tussen die senters is. Ons het 'n mikrodiensargitektuur. Ek was verbaas om te vind dat ons reeds 80 mikrodienste het. Toe ek die taak met logs begin het, was daar net 20 van hulle. Boonop is daar 'n taamlike groot stuk PHP-nalatenskap, waarmee ek ook moet saamleef en verdra. Dit alles genereer vir ons op die oomblik meer as 6 miljoen boodskappe per minuut vir die stelsel as geheel. Verder sal ek wys hoe ons hiermee probeer saamleef, en hoekom dit so is.
Jy moet op een of ander manier met hierdie 6 miljoen boodskappe saamleef. Wat moet ons met hulle doen? 6 miljoen boodskappe benodig:
- stuur vanaf app
- aanvaar vir aflewering
- lewer vir ontleding en berging.
- ontleed
- stoor op een of ander manier.
Toe daar drie miljoen boodskappe was, het ek omtrent dieselfde voorkoms gehad. Want ons het met 'n paar pennies begin. Dit is duidelik dat aansoeklogboeke daar geskryf is. Kon byvoorbeeld nie aan die databasis koppel nie, kon aan die databasis koppel, maar kon nie iets lees nie. Maar behalwe dit, skryf elkeen van ons mikrodienste ook 'n toegangslogboek. Elke versoek wat by die mikrodiens aankom, val in die logboek. Hoekom doen ons dit? Ontwikkelaars wil in staat wees om op te spoor. Elke toegangslogboek bevat die traceid-veld, waarvolgens 'n spesiale koppelvlak dan die hele ketting afwikkel en die spoor pragtig vertoon. Die spoor wys hoe die versoek verloop het, en dit help ons ontwikkelaars om enige onbekende vullis vinniger te hanteer.
Hoe om daarmee saam te leef? Nou sal ek kortliks die veld van opsies beskryf - hoe hierdie probleem oor die algemeen opgelos word. Hoe om die probleem van die versameling, oordrag en berging van logs op te los.
Hoe om uit die aansoek te skryf? Dit is duidelik dat daar verskillende maniere is. Daar is veral beste praktyk, soos modieuse kamerade ons vertel. Daar is twee tipes ou skool, soos oupas gesê het. Daar is ander maniere.
Met die versameling van logs is die situasie ongeveer dieselfde. Daar is nie soveel opsies om hierdie spesifieke deel op te los nie. Daar is meer van hulle, maar nog nie so baie nie.
Maar met aflewering en daaropvolgende ontleding begin die aantal variasies ontplof. Ek sal nie nou elke opsie beskryf nie. Ek dink die hoofopsies is goed bekend aan almal wat in die onderwerp belang gestel het.
Ek sal jou wys hoe ons dit by Lazada gedoen het en hoe dit alles begin het.
'n Jaar gelede het ek na Lazada gekom en is na die logprojek gestuur. Dit was so daar. Die logboek van die toepassing is geskryf na stdout en stderr. Alles is op 'n modieuse manier gedoen. Maar toe gooi die ontwikkelaars dit uit die standaardstrome, en dan sal infrastruktuurspesialiste dit op een of ander manier uitvind. Tussen infrastruktuurspesialiste en ontwikkelaars is daar ook vrystellers wat gesê het: "uh ... wel, kom ons draai hulle net in 'n lêer met 'n dop, en dit is dit." En aangesien dit alles in 'n houer is, het hulle dit reg in die houer self toegedraai, die gids binne gekarteer en dit daar gesit. Ek dink dit is vir almal redelik duidelik wat gebeur het.
Kom ons kyk bietjie verder. Hoe ons hierdie logs afgelewer het. Iemand het td-agent gekies, wat eintlik vlot is, maar nie heeltemal vlot nie. Ek verstaan steeds nie die verhouding van hierdie twee projekte nie, maar dit lyk of dit omtrent dieselfde ding is. En hierdie vlot, geskryf in Ruby, het loglêers gelees, dit in JSON ontleed deur 'n paar gereelde uitdrukkings te gebruik. Toe is hulle na Kafka gestuur. Boonop het ons in Kafka 4 afsonderlike onderwerpe vir elke API gehad. Hoekom 4? Omdat daar lewendig is, is daar opvoering, en omdat daar stdout en stderr is. Ontwikkelaars produseer dit, en infrastruktuurwerkers moet dit in Kafka skep. Bowendien is Kafka deur 'n ander departement beheer. Daarom was dit nodig om 'n kaartjie te skep sodat hulle 4 onderwerpe daar vir elke api geskep het. Almal het daarvan vergeet. Oor die algemeen was dit rommel en afval.
Wat het ons volgende daarmee gedoen? Ons het dit vir kafka gestuur. Verder van Kafka af het die helfte van die stompe na Logstash gevlieg. Die ander helfte van die stompe is gedeel. Sommige het na een Graylog gevlieg, sommige na 'n ander Graylog. Gevolglik het dit alles in een Elasticsearch-kluster gevlieg. Dit wil sê, al hierdie gemors het op die ou end daar geval. Jy hoef dit nie te doen nie!
Dit is hoe dit lyk as dit van bo af gesien word. Jy hoef dit nie te doen nie! Hier word die probleemareas dadelik met nommers gemerk. Daar is eintlik meer van hulle, maar 6 is regtig problematiese, waarmee iets gedoen moet word. Ek sal nou afsonderlik van hulle vertel.
Hier (1,2,3) skryf ons lêers en gevolglik is daar drie harke op een slag hier.
Die eerste (1) is dat ons hulle iewers moet skryf. Dit is nie altyd wenslik om 'n API die vermoë te gee om direk na 'n lêer te skryf nie. Dit is wenslik dat die API in 'n houer geïsoleer word, en nog beter, dat dit leesalleen is. Ek is 'n stelseladministrateur, so ek het 'n effens alternatiewe siening van hierdie dinge.
Die tweede punt (2,3) is dat ons baie versoeke het wat na die API kom. Die API skryf baie data na 'n lêer. Die lêers groei. Ons moet hulle roteer. Want anders sal jy geen skyfies daar kan stoor nie. Dit is sleg om hulle te draai omdat hulle via die dop na 'n gids herlei word. Daar is geen manier waarop ons dit kan draai nie. Jy kan nie vir die toepassing sê om die handvatsels weer oop te maak nie. Want die ontwikkelaars sal na jou kyk soos 'n dwaas: “Watter beskrywers? Ons skryf gewoonlik aan stdout. Die raamwerke wat copytruncate gemaak is in logrotate, wat net 'n kopie van die lêer maak en die oorspronklike trunks. Gevolglik raak skyfspasie gewoonlik tussen hierdie kopieerprosesse op.
(4) Ons het verskillende formate in verskillende API's gehad. Hulle was effens anders, maar regexp moes anders geskryf word. Aangesien dit alles deur Puppet bestuur is, was daar 'n groot klomp klasse met hul eie kakkerlakke. Boonop kon td-agent die meeste van die tyd geheue eet, dom wees, hy kon net voorgee dat hy werk en niks doen nie. Uiterlik was dit onmoontlik om te verstaan dat hy niks doen nie. Op sy beste sal hy val, en iemand sal hom later optel. Meer presies, 'n waarskuwing sal invlieg, en iemand sal dit met hul hande gaan lig.
(6) En die meeste gemors en afval - dit was elastiese soektog. Want dit was 'n ou weergawe. Omdat ons nie destyds toegewyde meesters gehad het nie. Ons het heterogene stompe gehad waarvan die velde kon oorvleuel. Verskillende logs van verskillende toepassings kan met dieselfde veldname geskryf word, maar terselfdertyd kan daar verskillende data binne wees. Dit wil sê, een log kom met 'n heelgetal in 'n veld, byvoorbeeld vlak. Nog 'n log kom met 'n string in die vlak veld. In die afwesigheid van statiese kartering, blyk so 'n wonderlike ding. As, na indeksrotasie, 'n boodskap met 'n tou eerste in elastiese soektog aangekom het, dan leef ons normaal. En as die eerste een met Integer aangekom het, word alle daaropvolgende boodskappe wat met String aangekom het eenvoudig weggegooi. Omdat die veldtipe nie ooreenstem nie.
Ons het hierdie vrae begin vra. Ons het besluit om nie die skuldiges te soek nie.
Maar iets moet gedoen word! Die ooglopende ding is dat ons standaarde moet daarstel. Ons het reeds 'n paar standaarde gehad. Sommige het ons bietjie later gebring. Gelukkig is 'n enkele logformaat vir alle API's toe reeds goedgekeur. Dit word direk in die diensinteraksiestandaarde ingeskryf. Gevolglik moet diegene wat logs wil ontvang dit in hierdie formaat skryf. As iemand nie logs in hierdie formaat skryf nie, waarborg ons niks nie.
Verder wil ek 'n enkele standaard hê vir die metodes om logs op te teken, af te lewer en te versamel. Eintlik, waar om dit te skryf en hoe om dit af te lewer. Die ideale situasie is wanneer projekte dieselfde biblioteek gebruik. Daar is 'n aparte logbiblioteek vir Go, daar is 'n aparte biblioteek vir PHP. Almal wat ons het, almal moet dit gebruik. Op die oomblik sou ek sê ons slaag met 80 persent. Maar sommige hou aan om kaktusse te eet.
En daar (op die skyfie) begin die "SLA vir logaflewering" skaars verskyn. Dit is nog nie daar nie, maar ons werk daaraan. Want dit is baie gerieflik as infra sê dat as jy in so en so 'n formaat na so en so 'n plek skryf en nie meer as N boodskappe per sekonde nie, dan sal ons dit heel waarskynlik daar aflewer. Dit neem baie hoofpyne weg. As daar 'n SLA is, dan is dit net wonderlik!
Hoe het ons die probleem begin oplos? Die hoofhark was by td-agent. Dit was onduidelik waarheen ons houtblokke gaan. Word hulle afgelewer? Gaan hulle? Waar is hulle in elk geval? Daarom is besluit om td-agent met die eerste item te vervang. Opsies vir wat om dit mee te vervang, het ek kortliks hier uiteengesit.
Vlotd. Eerstens het ek hom by 'n vorige werk raakgeloop, en hy het ook periodiek daar geval. Tweedens is dit dieselfde, net in profiel.
filebeat. Hoe was dit goed vir ons? Die feit dat hy in Go is, en ons het 'n groot kundigheid in Go. Gevolglik, indien enigiets, kan ons dit op een of ander manier by onsself voeg. Dis hoekom ons dit nie geneem het nie. Sodat daar nie eers enige versoeking sou wees om dit vir jouself te begin herskryf nie.
Die ooglopende oplossing vir die sysadmin is allerhande syslogs in hierdie hoeveelheid (syslog-ng/rsyslog/nxlog).
Of skryf iets van jou eie, maar ons het dit weggegooi, sowel as filebeat. As jy iets skryf, dan is dit beter om iets nuttigs vir besigheid te skryf. Om stompe te lewer, is dit beter om iets klaargemaak te neem.
Daarom het die keuse eintlik neergekom op 'n keuse tussen syslog-ng en rsyslog. Ek het na rsyslog geleun bloot omdat ons reeds klasse vir rsyslog in Puppet gehad het, en ek het nie 'n duidelike verskil tussen hulle gevind nie. Wat is syslog, wat is syslog. Ja, sommige dokumentasie is slegter, ander beter. Hy weet hierdie manier, en hy doen dit anders.
En 'n bietjie oor rsyslog. Eerstens is dit gaaf, want dit het baie modules. Dit het 'n mens-leesbare RainerScript (moderne konfigurasietaal). 'n Fantastiese bonus is dat ons die gedrag van td-agent met sy standaardgereedskap kan naboots, en niks het verander vir toepassings nie. Dit wil sê, ons verander td-agent na rsyslog, en raak nog nie aan alles anders nie. En dadelik kry ons 'n werkende aflewering. Vervolgens is mmnormalize die cool ding van rsyslog. Dit laat jou toe om logs te ontleed, maar nie met Grok en regexp nie. Dit maak 'n abstrakte sintaksisboom. Dit ontleed logs op baie dieselfde manier as wat 'n samesteller bronkode ontleed. Dit laat jou toe om baie vinnig te werk, min SVE te eet, en in die algemeen is dit net 'n baie oulike ding. Daar is 'n klomp ander bonusse. Ek sal nie by hulle stilstaan nie.
rsyslog het baie meer nadele. Hulle is omtrent dieselfde as bonusse. Die grootste probleme is dat jy dit moet kan kook, en jy moet 'n weergawe kies.
Ons het besluit dat ons logs in 'n Unix-sok sal skryf. En nie in /dev/log nie, want daar het ons 'n gemors van stelsellogboeke, daar is in hierdie pyplyn gejoernaal. So kom ons skryf na 'n pasgemaakte sok. Ons sal dit aan 'n aparte reëlstel heg. Laat ons met niks inmeng nie. Alles sal deursigtig en verstaanbaar wees. So het ons eintlik gedoen. Die gids met hierdie voetstukke word gestandaardiseer en na alle houers gestuur. Houers kan die sok sien wat hulle benodig, oopmaak en daaraan skryf.
Hoekom nie 'n lêer nie? Want almal het gelees , wat probeer het om die lêer na docker aan te stuur, en gevind het dat nadat rsyslog herbegin is, die lêerbeskrywing verander, en docker verloor hierdie lêer. Hy hou nog iets oop, maar nie dieselfde sok waar hulle skryf nie. Ons het besluit dat ons hierdie probleem sal omseil, en terselfdertyd die blokkeringsprobleem sal omseil.
Rsyslog doen die aksies wat op die skyfie aangedui word en stuur logs na óf aflos óf Kafka. Kafka volg die ou manier. Rayleigh - Ek het probeer om suiwer rsyslog te gebruik om logs te lewer. Sonder Message Queue, gebruik standaard rsyslog-nutsgoed. Basies werk dit.
Maar daar is nuanses met hoe om hulle later in hierdie deel (Logstash/Graylog/ES) in te vul. Hierdie deel (rsyslog-rsyslog) word tussen datasentrums gebruik. Hier is 'n saamgeperste tcp-skakel, waarmee u bandwydte kan bespaar en dienooreenkomstig die waarskynlikheid verhoog dat ons 'n paar logs van 'n ander datasentrum sal ontvang wanneer die kanaal vol is. Want ons het Indonesië, waar alles sleg is. Dis waar die voortdurende probleem lê.
Ons het gedink oor hoe ons eintlik monitor, met watter waarskynlikheid bereik die logs wat ons vanaf die toepassing aangeteken het, daardie doel? Ons het besluit om metrieke te begin. Rsyslog het sy eie statistiek-insamelingsmodule, wat 'n soort tellers het. Dit kan jou byvoorbeeld die grootte van die tou wys, of hoeveel boodskappe vir so en so 'n aksie ingekom het. Jy kan reeds iets van hulle neem. Boonop het dit pasgemaakte tellers wat u kan instel, en dit sal u byvoorbeeld die aantal boodskappe wys wat een of ander API opgeneem het. Vervolgens het ek rsyslog_exporter in Python geskryf, en ons het dit alles na Prometheus gestuur en saamgevat. Ons wou regtig Graylog-statistieke hê, maar tot dusver het ons nie tyd gehad om dit op te stel nie.
Wat is die probleme? Die probleem het ontstaan met die feit dat ons uitgevind het (SKIELIK!) dat ons Live API's 50k boodskappe per sekonde skryf. Dit is slegs Live API sonder opvoering. En Graylog wys ons net 12 duisend boodskappe per sekonde. En 'n redelike vraag het ontstaan, waar is die oorblyfsels? Waaruit ons tot die gevolgtrekking gekom het dat Graylog eenvoudig nie kan klaarkom nie. Ons het gekyk, en inderdaad, Graylog met Elasticsearch het nie hierdie vloei bemeester nie.
Volgende, ander ontdekkings wat ons langs die pad gemaak het.
Skryfwerk na sok is geblokkeer. Hoe het dit gebeur? Toe ek rsyslog vir aflewering gebruik het, het ons op 'n stadium die kanaal tussen die datasentrums gebreek. Aflewering het op een plek opgestaan, aflewering op 'n ander plek. Dit alles het neergekom op 'n masjien met API's wat na die rsyslog-sok skryf. Daar was 'n tou. Toe word die tou vir skryf na die unix-sok vol, wat by verstek 128 pakkies is. En die volgende skryf() in die toepassingsblokke. Toe ons na die biblioteek gekyk het wat ons in Go-toepassings gebruik, is daar geskryf dat skryf na die sok in nie-blokkerende modus plaasvind. Ons was seker dat niks geblokkeer is nie. Want ons het gelees wie daaroor geskryf het. Maar daar is 'n oomblik. Daar was ook 'n oneindige lus om hierdie oproep, waarin daar voortdurend 'n poging was om 'n boodskap in die sok te druk. Ons het hom nie raakgesien nie. Ek moes die biblioteek herskryf. Sedertdien het dit verskeie kere verander, maar nou het ons ontslae geraak van slotte in alle substelsels. Daarom kan jy rsyslog stop en niks sal val nie.
Dit is nodig om die grootte van die toue te monitor, wat help om nie op hierdie hark te trap nie. Eerstens kan ons monitor wanneer ons boodskappe begin verloor. Tweedens kan ons monitor dat ons basies probleme met aflewering het.
En nog 'n onaangename oomblik - versterking met 10 keer in 'n mikrodiensargitektuur is baie maklik. Ons het nie soveel inkomende versoeke nie, maar as gevolg van die grafiek waarlangs hierdie boodskappe verder loop, as gevolg van die toegang logs, verhoog ons eintlik die las op die logs met ongeveer tien keer. Ongelukkig het ek nie tyd gehad om die presiese getalle te bereken nie, maar mikrodienste is wat hulle is. Dit moet in gedagte gehou word. Dit blyk dat die loginsamelingsubstelsel tans die meeste in Lazada gelaai is.
Hoe om elastiese soek-probleem op te los? As jy logs vinnig op een plek moet kry, om nie oor alle masjiene te hardloop en dit daar te versamel nie, gebruik lêerberging. Dit is gewaarborg om te werk. Dit word vanaf enige bediener gedoen. Jy moet net skywe daar plak en syslog sit. Daarna is jy gewaarborg om al die logs op een plek te hê. Dan sal dit moontlik wees om elasticsearch, greylog of iets anders stadig op te stel. Maar jy sal reeds al die logs hê, en jy kan dit boonop stoor, so ver as wat daar genoeg skyfskikkings is.
Ten tyde van my verslag het die skema so begin lyk. Ons het feitlik opgehou om aan die lêer te skryf. Nou, heel waarskynlik, sal ons die oorblyfsels afskakel. Op plaaslike masjiene wat die API gebruik, sal ons ophou om na lêers te skryf. Eerstens is daar lêerberging, wat baie goed werk. Tweedens, hierdie masjiene het gedurig min spasie, jy moet dit voortdurend monitor.
Hierdie deel met Logstash en Graylog, dit styg regtig. Daarom moet jy daarvan ontslae raak. Jy moet een kies.
Ons het besluit om Logstash en Kibana te laat val. Want ons het 'n sekuriteitsafdeling. Wat is die verband? Die verband is dat Kibana sonder X-Pack en sonder Shield jou nie toelaat om toegangsregte tot die logs te onderskei nie. Daarom het hulle Graylog geneem. Dit het alles. Ek hou nie daarvan nie, maar dit werk. Ons het nuwe hardeware gekoop, 'n vars Graylog daar geïnstalleer en alle logs met streng formate na 'n aparte Graylog geskuif. Ons het die probleem met verskillende tipes van dieselfde velde organisatories opgelos.
Wat presies is ingesluit in die nuwe Graylog. Ons het net alles in die docker geskryf. Ons het 'n klomp bedieners geneem, drie Kafka-instansies uitgerol, 7 Graylog-bedieners weergawe 2.3 (omdat ek Elasticsearch weergawe 5 wou hê). Dit alles is geopper op klopjagte vanaf die HDD. Ons het 'n indekseringskoers van tot 100 duisend boodskappe per sekonde gesien. Ons het die syfer gesien dat 140 teragrepe data per week.
En weer 'n hark! Ons het twee verkope wat voorlê. Ons het verby 6 miljoen plasings beweeg. Ons Graylog het nie tyd om te kou nie. Op een of ander manier moet jy weer oorleef.
Dit is hoe ons oorleef het. Het nog 'n paar bedieners en SSD's bygevoeg. Op die oomblik leef ons so. Nou kou ons reeds 160k boodskappe per sekonde. Ons het nog nie die limiet bereik nie, so dit is onduidelik hoeveel ons realisties daaruit kan kry.
Dit is ons planne vir die toekoms. Hiervan is die belangrikste waarskynlik hoë beskikbaarheid. Ons het dit nog nie. Verskeie motors is op dieselfde manier opgestel, maar tot dusver gaan alles deur een motor. Dit is nodig om tyd te spandeer om 'n failover tussen hulle op te stel.
Versamel statistieke van Graylog.
Maak 'n tarieflimiet sodat ons een mal API het wat ons nie bandwydte en al die ander doodmaak nie.
En ten slotte, teken 'n soort SLA met ontwikkelaars sodat ons soveel kan dien. As jy meer skryf, jammer.
En skryf dokumentasie.
Kortliks, die resultate van alles wat ons ervaar het. Eerstens, die standaarde. Tweedens, syslog is koek. Derdens werk rsyslog presies soos dit op die skyfie geskryf is. En kom ons kom by die vrae.
vrae.
Vraag: Hoekom het hulle besluit om nie ... (filebeat?)
Beantwoord: Moet na 'n lêer skryf. Ek wou regtig nie. Wanneer jou API duisende boodskappe per sekonde skryf, selfs al draai jy een keer per uur, is dit steeds nie 'n opsie nie. Jy kan na pyp skryf. Waarop die ontwikkelaars my gevra het: "Wat sal gebeur as die proses waarin ons skryf, val"? Ek het net nie gevind wat om hulle te antwoord nie, en het gesê: "Wel, ok, laat ons dit nie doen nie."
Vraag: Hoekom skryf jy nie net logs na HDFS nie?
BeantwoordA: Dit is die volgende fase. Ons het heel aan die begin daaroor gedink, maar aangesien daar geen hulpbronne is om dit op die oomblik te hanteer nie, hang dit in ons langtermynoplossing.
Vraag: 'n Kolomformaat sal meer gepas wees.
Beantwoord: Ek verstaan. Ons is "vir" met albei hande.
Vraag: Jy skryf aan rsyslog. Beide TCP en UDP is daar beskikbaar. Maar as UDP, hoe waarborg u aflewering dan?
BeantwoordA: Daar is twee punte. Eerstens sê ek dadelik vir almal dat ons nie die aflewering van stompe waarborg nie. Want wanneer die ontwikkelaars kom en sê: “Kom ons begin finansiële data daar skryf, en jy sal dit iewers vir ons plaas vir ingeval iets gebeur,” antwoord ons hulle, “Fantastisch! Kom ons begin blokkeer op skryf na die sok, en doen dit in transaksies, sodat jy gewaarborg is om dit vir ons in die sok te sit en seker te maak dat ons dit van die ander kant af ontvang het. En op hierdie oomblik word almal dadelik onnodig. En indien nie, watter vrae het ons dan? As jy nie 'n skrywe aan die sok wil waarborg nie, hoekom sal ons dan aflewering waarborg? Ons doen die beste poging. Ons probeer regtig om soveel as moontlik en so goed moontlik te lewer, maar ons gee nie 'n 100% waarborg nie. Daarom hoef jy nie finansiële data daar te skryf nie. Daar is transaksionele databasisse hiervoor.
Vraag: Wanneer die API een of ander boodskap na die log genereer en beheer na mikrodienste oordra, het jy die probleem ondervind dat boodskappe van verskillende mikrodienste in die verkeerde volgorde aankom? As gevolg hiervan ontstaan verwarring.
BeantwoordA: Dit is normaal dat hulle in 'n ander volgorde kom. Jy moet gereed wees hiervoor. Omdat enige netwerkaflewering nie bestelling aan u waarborg nie, of u spesiale hulpbronne hieraan moet spandeer. As ons lêerbergings neem, stoor elke API logs in sy eie lêer. Inteendeel, rsyslog ontbind hulle in gidse daar. Elke API het sy eie logs daar, waar jy kan gaan kyk, en dan kan jy dit vergelyk deur die tydstempel in hierdie log te gebruik. As hulle in Graylog gaan kyk, dan sal hulle daar volgens tydstempel gesorteer word. Alles sal reg wees daar.
Vraag: Tydstempel kan met millisekondes verskil.
Beantwoord: Die tydstempel word deur die API self gegenereer. Dit is eintlik die hele punt. Ons het NTP. Die API genereer 'n tydstempel reeds in die boodskap self. Dit word nie deur rsyslog bygevoeg nie.
Vraag: Interaksie tussen datasentrums is nie baie duidelik nie. Binne die raamwerk van die datasentrum is dit duidelik hoe die logs versamel en verwerk is. Hoe is die interaksie tussen datasentrums? Of leef elke datasentrum sy eie lewe?
Beantwoord: Amper. Ons het elke land in een datasentrum geleë. Ons het tans nie verspreiding nie, sodat een land in verskillende datasentrums geplaas word. Daarom is dit nie nodig om hulle te kombineer nie. Binne elke sentrum is daar 'n Log Relay. Dit is 'n Rsyslog-bediener. Trouens, twee bestuursmasjiene. Hulle is op dieselfde manier opgestel. Maar vir nou gaan die verkeer net deur een van hulle. Sy teken alles saam. Dit het 'n skyf tou net vir ingeval. Sy druk die logs en stuur dit na die sentrale datasentrum (Singapore), waar hulle verder reeds in Graylog vergiftig is. En elke datasentrum het sy eie lêerberging. As ons verbinding verloor het, het ons al die logs daar. Hulle sal daar bly. Hulle sal daar gestoor word.
Vraag: Kry jy logs van daar af tydens abnormale situasies?
Beantwoord: Jy kan daarheen gaan (na die lêerberging) en kyk.
Vraag: Hoe monitor jy dat jy nie logs verloor nie?
Beantwoord: Ons verloor hulle eintlik, en ons monitor dit. Monitering het 'n maand gelede begin. Die biblioteek wat die Go API's gebruik, het statistieke. Sy kan tel hoeveel keer sy versuim het om na sok te skryf. Daar is op die oomblik 'n moeilike heuristiek. Daar is 'n buffer daar. Dit probeer om 'n boodskap daaruit na die sok te skryf. As die buffer oorloop, begin dit hulle laat val. En hy tel hoeveel hy hulle laat val het. As die tellers daar begin oorloop, sal ons daarvan weet. Hulle kom nou ook na prometheus, en jy kan die grafieke in Grafana sien. Jy kan waarskuwings opstel. Maar dit is nog nie duidelik na wie om hulle te stuur nie.
Vraag: In elasticsearch stoor jy logs met oortolligheid. Hoeveel replikas het jy?
Beantwoord: Een replika.
Vraag: Is dit net een reël?
Beantwoord: Dit is die meester en replika. Die data word in duplikaat gestoor.
Vraag: Het jy op een of ander manier die grootte van die rsyslog-buffer aangepas?
Beantwoord: Ons skryf datagramme na 'n pasgemaakte unix-sok. Dit plaas ons dadelik 'n beperking van 128 kilogrepe. Ons kan nie meer daarin skryf nie. Ons het dit in die standaard geskryf. Wie wil in die stoor kom, hulle skryf 128 kilogrepe. Biblioteke sny boonop af, en sit 'n vlag dat die boodskap afgesny is. Ons het 'n spesiale veld in die standaard van die boodskap self, wat wys of dit tydens opname afgesny is of nie. Ons het dus die geleentheid om hierdie oomblik na te spoor.
Vraag: Skryf jy gebroke JSON?
Beantwoord: Gebreekte JSON sal óf tydens aflos weggegooi word omdat die pakkie te groot is. Of Graylog sal laat vaar word, want dit sal nie JSON kan ontleed nie. Maar daar is nuanses hier wat reggemaak moet word, en hulle is meestal gekoppel aan rsyslog. Ek het reeds 'n paar uitgawe daar ingevul, waaraan nog gewerk moet word.
Vraag: Hoekom Kafka? Het jy RabbitMQ probeer? Graylog nie optel onder sulke vragte nie?
Beantwoord: Dit werk nie uit met Graylog nie. En Graylog neem vorm aan. Dit is regtig problematies vir hom. Hy is soort van 'n ding. En in werklikheid is dit nie nodig nie. Ek skryf eerder van rsyslog direk na elasticsearch en kyk dan Kibana. Maar ons moet die kwessie met die veiligheidswagte oplos. Dit is 'n moontlike variant van ons ontwikkeling wanneer ons Graylog uitgooi en Kibana gebruik. Logstash sal nie sin maak nie. Want ek kan dieselfde doen met rsyslog. En dit het 'n module om na elasticsearch te skryf. Met Graylog probeer ons op een of ander manier leef. Ons het dit selfs 'n bietjie aangepas. Maar daar is nog ruimte vir verbetering.
Oor Kafka. Dis hoe dit histories gebeur het. Toe ek daar aankom, was dit reeds daar, en logboeke is reeds daarop geskryf. Ons het net ons cluster opgelig en stompe daarin geskuif. Ons bestuur hom, ons weet hoe hy voel. Wat RabbitMQ betref ... ons sukkel met RabbitMQ. En RabbitMQ ontwikkel vir ons. Ons het dit in produksie, en daar was probleme daarmee. Nou, voor die verkoop, sou hy gesmaniseer word, en hy sou normaal begin werk. Maar voor dit was ek nie gereed om dit in produksie vry te stel nie. Daar is nog een punt. Graylog kan AMQP 0.9-weergawe lees en rsyslog kan AMQP 1.0-weergawe skryf. En daar is nie 'n enkele oplossing wat albei in die middel kan doen nie. Daar is óf die een óf die ander. So vir eers net Kafka. Maar daar is ook nuanses. Omdat omkafka van die weergawe van rsyslog wat ons gebruik die hele boodskapbuffer wat dit van rsyslog opgetel het, kan verloor. Solank ons dit verdra.
Vraag: Gebruik jy Kafka omdat jy dit gehad het? Nie vir enige ander doel gebruik nie?
Beantwoord: Kafka, wat deur die Data Science-span gebruik is. Dit is 'n heeltemal aparte projek, waaroor ek ongelukkig niks kan sê nie. Ek weet nie. Sy is deur die Data Science-span bestuur. Toe die stompe begin het, het hulle besluit om dit te gebruik, om nie hul eie te sit nie. Nou het ons Graylog opgedateer, en ons het versoenbaarheid verloor, want daar is 'n ou weergawe van Kafka. Ons moes ons eie maak. Terselfdertyd het ons van hierdie vier onderwerpe vir elke API ontslae geraak. Ons het een wye top vir almal lewendig gemaak, een wye wye top vir alle opvoerings en ons skiet net alles daar. Graylog hark dit alles parallel uit.
Vraag: Hoekom het ons hierdie sjamanisme met voetstukke nodig? Het jy al probeer om die syslog log-bestuurder vir houers te gebruik.
Beantwoord: In die tyd toe ons hierdie vraag gevra het, het ons gespanne verhoudings met die dokwerker gehad. Dit was docker 1.0 of 0.9. Docker self was vreemd. Tweedens, as jy ook logs daarin stoot ... Ek het 'n ongeverifieerde vermoede dat dit al die logs deur homself stuur, deur die docker daemon. As ons een API het wat mal word, dan sal die res van die API's in die feit loop dat hulle nie stdout en stderr kan stuur nie. Ek weet nie waarheen dit sal lei nie. Ek het 'n vermoede op die vlak van gevoel dat dit nie nodig is om die docker syslog-bestuurder op hierdie plek te gebruik nie. Ons funksionele toetsafdeling het sy eie Graylog-kluster met logs. Hulle gebruik docker log-bestuurders en dit lyk of alles goed is daar. Maar hulle skryf dadelik GELF aan Graylog. Op die oomblik toe ons dit alles begin het, het ons dit nodig gehad om net te werk. Miskien later, wanneer iemand kom en sê dat dit al 'n honderd jaar normaal werk, sal ons probeer.
Vraag: Jy lewer tussen datasentrums af deur rsyslog te gebruik. Hoekom nie op Kafka nie?
Beantwoord: Ons doen dit, en dit is hoe dit regtig is. Om twee redes. As die kanaal heeltemal dood is, sal al ons stompe, selfs in 'n saamgeperste vorm, nie daardeur klim nie. En kafka laat hulle toe om eenvoudig in die proses te verloor. Op hierdie manier raak ons ontslae van die vassit van hierdie stompe. Ons gebruik Kafka in hierdie geval net direk. As ons 'n goeie kanaal het en dit wil bevry, gebruik ons hul rsyslog. Maar in werklikheid kan jy dit so opstel dat dit laat val wat dit nie deurgekom het nie. Op die oomblik gebruik ons net rsyslog aflewering direk iewers, iewers Kafka.
Bron: will.com