Logger er en viktig del av systemet, slik at du kan forstå at det fungerer (eller ikke fungerer) som forventet. I en mikrotjenestearkitektur blir arbeid med logger en egen disiplin for en spesiell Olympiade. En haug med spørsmål må løses på en gang:
- hvordan skrive logger fra en applikasjon;
- hvor du skal skrive logger;
- hvordan levere logger for lagring og behandling;
- hvordan behandle og lagre logger.
Bruken av for tiden populære containeriseringsteknologier legger sand på toppen av raken til feltet av alternativer for å løse problemet.
Dette er nøyaktig hva utskriften av Yuri Bushmelevs rapport "Kart over raker i feltet for innsamling og levering av tømmerstokker" handler om.
Hvem bryr seg, vær så snill under katten.
Mitt navn er Yuri Bushmelev. Jeg jobber på Lazada. I dag skal jeg snakke om hvordan vi laget loggene våre, hvordan vi samlet dem og hva vi skriver der.
Hvor er vi fra? Hvem er vi? Lazada er nr. 1 nettforhandler i seks land i Sørøst-Asia. Alle disse landene er fordelt på våre datasentre. Det er for tiden totalt 4 datasentre. Hvorfor er dette viktig? For noen vedtak skyldtes at det er en veldig svak kobling mellom sentrene. Vi har en mikrotjenestearkitektur. Jeg ble overrasket over å finne at vi allerede har 80 mikrotjenester. Da jeg startet oppgaven med logger var det bare 20. Pluss at det er en ganske stor del av PHP-arven, som jeg også må leve med og tåle. Alt dette genererer for tiden mer enn 6 millioner meldinger per minutt for systemet som helhet. Deretter vil jeg vise hvordan vi prøver å leve med dette, og hvorfor det er slik.
Du må på en eller annen måte leve med disse 6 millioner meldingene. Hva skal vi gjøre med dem? 6 millioner meldinger du trenger:
- send fra app
- akseptere for levering
- levere til analyse og lagring.
- analysere
- lagre det på en eller annen måte.
Da tre millioner meldinger dukket opp, så jeg omtrent det samme ut. For vi startet med bare noen få kroner. Det er tydelig at det skrives søknadslogger der. For eksempel kunne jeg ikke koble til databasen, jeg kunne koble til databasen, men jeg kunne ikke lese noe. Men i tillegg til dette, skriver hver av våre mikrotjenester også en tilgangslogg. Hver forespørsel som kommer til mikrotjenesten blir registrert i loggen. Hvorfor gjør vi dette? Utviklere ønsker å kunne spore. Hver tilgangslogg inneholder et traceid-felt, som bruker et spesielt grensesnitt deretter avvikler hele kjeden og viser sporet vakkert. Sporet viser hvordan forespørselen gikk, og dette hjelper utviklerne våre raskt å håndtere uidentifisert søppel.
Hvordan leve med dette? Nå vil jeg kort beskrive feltet for alternativer - hvordan dette problemet generelt løses. Hvordan løse problemet med innsamling, overføring og lagring av logger.
Hvordan skrive fra en søknad? Det er tydelig at det er forskjellige måter. Spesielt er det beste praksis, som våre fasjonable kamerater forteller oss. Det er to typer old school, som våre bestefedre fortalte oss. Det finnes andre måter.
Situasjonen med innsamling av tømmerstokker er omtrent den samme. Det er ikke mange alternativer for å løse akkurat denne delen. Det er allerede flere av dem, men ikke så mange ennå.
Men med levering og påfølgende analyse begynner antallet variasjoner å eksplodere. Jeg vil ikke beskrive hvert alternativ nå. Jeg tror hovedalternativene er godt kjent for alle som er interessert i temaet.
Jeg skal vise deg hvordan vi gjorde det på Lazada, og hvordan det hele faktisk startet.
For et år siden kom jeg til Lazada og ble sendt til et prosjekt om tømmerstokker. Det var noe sånt som dette. Søknadsloggen ble skrevet til stdout og stderr. Alt ble gjort på en fasjonabel måte. Men så kastet utviklerne det ut av standardstrømmene, og da vil infrastrukturspesialister finne ut av det. Mellom infrastrukturspesialister og utviklere er det også utgivere som sa: "åh... vel, la oss bare pakke dem inn i en fil med et skall, og det er det." Og siden alt dette var i en container, pakket de det rett inn i selve containeren, kartla katalogen inni og la den der. Jeg tror det er ganske åpenbart for alle hva som kom ut av det.
La oss se litt lenger for nå. Hvordan leverte vi disse loggene? Noen valgte td-agent, som egentlig er flytende, men ikke helt flytende. Jeg forstår fortsatt ikke forholdet mellom disse to prosjektene, men de ser ut til å handle om det samme. Og denne flytende, skrevet i Ruby, leste loggfiler, analyserte dem inn i JSON ved å bruke en slags regularitet. Så sendte jeg dem til Kafka. Dessuten hadde vi i Kafka 4 separate emner for hvert API. Hvorfor 4? Fordi det er live, det er iscenesettelse, og fordi det er stdout og stderr. Utviklere lager dem, og infrastrukturutviklere må lage dem i Kafka. Dessuten ble Kafka kontrollert av en annen avdeling. Derfor var det nødvendig å lage en billett slik at de skulle lage 4 emner for hvert api. Alle glemte det. Generelt var det søppel og oppstyr.
Hva gjorde vi videre med dette? Vi sendte den til Kafka. Så fløy halvparten av tømmerstokkene fra Kafka til Logstash. Den andre halvparten av stokkene ble delt. Noen fløy til en Graylog, noen til en annen Graylog. Som et resultat gikk alt dette inn i én Elasticsearch-klynge. Det vil si at alt dette rotet havnet der. Ikke gjør det!
Slik ser det ut hvis du ser det ovenfra. Ikke gjør det! Her merkes problemområdene umiddelbart med tall. Det er faktisk flere av dem, men 6 er virkelig problematiske som må gjøres noe med. Jeg skal fortelle deg om dem separat nå.
Her (1,2,3) skriver vi filer og følgelig er det tre rakes her samtidig.
Den første (1) er at vi må skrive dem et sted. Det vil ikke alltid være ønskelig å gi API-en muligheten til å skrive direkte til en fil. Det er ønskelig at API-en er isolert i en beholder, eller enda bedre, at den er skrivebeskyttet. Jeg er systemadministrator, så jeg har et litt alternativt syn på disse tingene.
Det andre punktet (2,3) er at vi har mange forespørsler som kommer til API. APIen skriver mye data til en fil. Filene vokser. Vi må rotere dem. For ellers vil du ikke kunne lagre på noen disker der. Å rotere dem er dårlig fordi de er laget ved å omdirigere gjennom skallet til katalogen. Det er ingen måte vi kan revidere det. Du kan ikke fortelle applikasjonen å åpne håndtakene på nytt. Fordi utviklerne vil se på deg som om du er en tosk: «Hvilke beskrivelser? Vi skriver vanligvis til stdout.» Infrastrukturutviklere laget copytruncate til logrotate, som ganske enkelt lager en kopi av filen og transkriberer originalen. Følgelig går diskplassen vanligvis tom mellom disse kopieringsprosessene.
(4) Vi hadde forskjellige formater i forskjellige APIer. De var litt forskjellige, men regexp måtte skrives annerledes. Siden alt dette ble kontrollert av Puppet, var det en stor gjeng med klasser med sine egne kakerlakker. Pluss, mesteparten av tiden kunne td-agent spise minne, være dum, den kunne bare late som om den fungerte og ikke gjøre noe. Fra utsiden var det umulig å forstå at han ikke gjorde noe. I beste fall vil han falle og noen henter ham senere. Mer presist kommer et varsel, og noen vil gå og løfte det med hendene.
(6) Og mest søppel og avfall var elasticsearch. Fordi det var en gammel versjon. Fordi vi ikke hadde dedikerte mestere på den tiden. Vi hadde heterogene tømmerstokker hvis felt kunne overlappe. Ulike logger fra forskjellige applikasjoner kan skrives med de samme feltnavnene, men det kan være forskjellige data inne. Det vil si at én logg kommer med heltall i feltet, for eksempel nivå. En annen logg kommer med String i nivåfeltet. I fravær av statisk kartlegging er dette en fantastisk ting. Hvis, etter å ha rotert indeksen i elasticsearch, kommer en melding med en streng først, så lever vi normalt. Men hvis den første kom fra Integer, blir alle påfølgende meldinger som kom fra String ganske enkelt forkastet. Fordi felttypen ikke stemmer overens.
Vi begynte å stille disse spørsmålene. Vi bestemte oss for å ikke lete etter dem å klandre.
Men noe må gjøres! Det åpenbare er at vi må etablere standarder. Vi hadde allerede noen standarder. Vi startet noen litt senere. Heldigvis var et enkelt loggformat for alle APIer allerede godkjent på det tidspunktet. Det skrives direkte inn i standardene for samhandling mellom tjenester. Følgelig må de som ønsker å motta logger skrive dem i dette formatet. Hvis noen ikke skriver logger i dette formatet, garanterer vi ingenting.
Deretter vil jeg lage en enhetlig standard for metodene for registrering, levering og innsamling av logger. Faktisk, hvor du skal skrive dem, og hvordan du skal levere dem. Den ideelle situasjonen er når prosjekter bruker samme bibliotek. Det er et eget loggbibliotek for Go, og et eget bibliotek for PHP. Alle vi har burde bruke dem. For øyeblikket vil jeg si at vi lykkes 80 prosent i dette. Men noen fortsetter å spise kaktus.
Og der (på lysbildet) begynner så vidt "SLA for levering av logger" å dukke opp. Det eksisterer ikke ennå, men vi jobber med det. For det er veldig praktisk når infrastrukturen sier at hvis du skriver i sånn og sånn format til sånn og sånn plass og ikke mer enn N meldinger i sekundet så leverer vi det mest sannsynlig til sånn og sånn plass. Dette lindrer mye hodepine. Hvis det er en SLA, så er dette helt fantastisk!
Hvordan begynte vi å løse problemet? Hovedproblemet var med td-agent. Det var ikke klart hvor loggene våre ble av. Blir de levert? Skal de gå? Hvor er de forresten? Derfor ble det første punktet besluttet å erstatte td-agent. Jeg har kort skissert alternativene for hva den skal erstattes med her.
Flytende. For det første møtte jeg ham på en tidligere jobb, og han falt også med jevne mellomrom der. For det andre er dette det samme, bare i profilen.
Filebeat. Hvordan var det praktisk for oss? Fordi det er i Go, og vi har mye ekspertise på Go. Følgelig, hvis noe skjedde, kunne vi på en eller annen måte legge til det for oss selv. Derfor tok vi det ikke. Slik at det ikke en gang er noen fristelse til å begynne å skrive det om for deg selv.
Den åpenbare løsningen for systemadministratoren er alle slags syslogs i denne mengden (syslog-ng/rsyslog/nxlog).
Eller skriv noe eget, men vi forkastet dette, så vel som filebeat. Hvis du skriver noe, er det bedre å skrive noe nyttig for virksomheten. For å levere stokker er det bedre å ta noe ferdig.
Derfor kom valget faktisk ned på valget mellom syslog-ng og rsyslog. Jeg lente meg mot rsyslog ganske enkelt fordi vi allerede hadde klasser for rsyslog i Puppet, og jeg fant ikke en åpenbar forskjell mellom dem. Hva er syslog, hva er syslog. Ja, noen har dårligere dokumentasjon, noen har bedre. Denne kan gjøre det på denne måten, og den andre kan gjøre det annerledes.
Og litt om rsyslog. Først av alt er det kult fordi det har mange moduler. Den har menneskelesbare RainerScript (et moderne konfigurasjonsspråk). Det er en fantastisk bonus at vi kunne etterligne oppførselen til td-agent ved å bruke standardverktøy, og ingenting endret seg for applikasjoner. Det vil si at vi bytter td-agent til rsyslog, og lar alt annet være i fred for nå. Og vi får umiddelbart fungerende levering. Deretter er mmnormalize en fantastisk ting i rsyslog. Den lar deg analysere logger, men ikke med Grok og regexp. Det lager et abstrakt syntakstre. Den analyserer logger på omtrent samme måte som en kompilator analyserer kilder. Dette lar deg jobbe veldig raskt, forbruke lite CPU, og generelt sett er det en veldig kul ting. Det er en haug med andre bonuser. Jeg vil ikke dvele ved dem.
rsyslog har mange andre ulemper. De er omtrent det samme som bonuser. Hovedproblemene er at du trenger å vite hvordan du skal lage den, og du må velge versjon.
Vi bestemte oss for at vi skulle skrive logger til en unix-kontakt. Og ikke i /dev/log, for der har vi et rot av systemlogger, journald er i denne pipelinen. Så la oss skrive til en tilpasset stikkontakt. Vi legger det ved et eget regelsett. La oss ikke blande oss inn i noe. Alt vil være gjennomsiktig og forståelig. Det var akkurat det vi gjorde. Katalogen med disse stikkontaktene er standardisert og videresendt til alle containere. Containere kan se stikkontakten de trenger, åpne og skrive til den.
Hvorfor ikke en fil? Fordi alle leser den , som prøvde å videresende en fil til docker, og det ble oppdaget at etter omstart av rsyslog, endret filbeskrivelsen seg, og docker mistet denne filen. Det holder noe annet åpent, men ikke stikkontakten der de skriver. Vi bestemte oss for at vi skulle omgå dette problemet, og samtidig ville vi omgå blokkeringsproblemet.
Rsyslog utfører handlingene som er angitt på lysbildet og sender logger til enten relé eller Kafka. Kafka følger den gamle måten. Relé - Jeg prøvde å bruke ren rsyslog for å levere logger. Uten Message Queue, ved å bruke standard rsyslog-verktøy. I utgangspunktet fungerer det.
Men det er nyanser med hvordan du skyver dem inn i denne delen (Logstash/Graylog/ES). Denne delen (rsyslog-rsyslog) brukes mellom datasentre. Her er en komprimert tcp-kobling, som lar oss spare båndbredde og følgelig på en eller annen måte øke sannsynligheten for at vi vil motta noen logger fra et annet datasenter når kanalen er tilstoppet. Fordi vi har Indonesia, hvor alt er dårlig. Det er her det konstante problemet ligger.
Vi tenkte på hvordan vi faktisk kan overvåke hvor sannsynlig det er at loggene vi registrerte fra applikasjonen når slutten? Vi bestemte oss for å lage beregninger. rsyslog har sin egen statistikkinnsamlingsmodul, som inneholder en slags tellere. Den kan for eksempel vise deg størrelsen på køen, eller hvor mange meldinger som har kommet i en slik og en slik handling. Du kan allerede ta noe fra dem. I tillegg har den tilpassede tellere som kan konfigureres, og den vil for eksempel vise deg antall meldinger som noen API har registrert. Deretter skrev jeg rsyslog_exporter i Python, og vi sendte alt til Prometheus og bygde grafer. Vi ønsket virkelig Graylog-målinger, men vi har ikke hatt tid til å sette dem opp ennå.
Hva var problemene? Problemer oppsto da vi oppdaget (PLUTSELIG!) at våre Live API-er skrev 50 12 meldinger per sekund. Dette er bare en Live API uten iscenesettelse. Og Graylog viser oss bare XNUMX tusen meldinger per sekund. Og et rimelig spørsmål dukket opp: hvor er restene? Som vi konkluderte med at Graylog rett og slett ikke kan takle. Vi så, og Graylog og Elasticsearch kunne faktisk ikke håndtere denne flyten.
Deretter andre funn vi gjorde underveis.
Skriver til stikkontakten er blokkert. Hvordan skjedde det? Da jeg brukte rsyslog for levering, brøt på et tidspunkt kanalen mellom datasentrene sammen. Levering stoppet ett sted, levering stoppet et annet sted. Alt dette har nådd maskinen med APIer som skriver til rsyslog-kontakten. Det var kø der. Så fyltes køen for å skrive til unix-kontakten, som som standard er 128 pakker. Og neste write() i applikasjonen er blokkert. Da vi så på biblioteket som vi bruker i Go-applikasjoner, ble det skrevet der at skriving til socket skjer i ikke-blokkerende modus. Vi var sikre på at ingenting var blokkert. Fordi vi leser som skrev om det. Men det er et øyeblikk. Det var også en uendelig sløyfe rundt denne samtalen, der det var et konstant forsøk på å dytte en melding inn i stikkontakten. Vi la ikke merke til ham. Jeg måtte skrive om biblioteket. Siden har det endret seg flere ganger, men nå har vi blitt kvitt blokkering i alle delsystemer. Derfor kan du stoppe rsyslog, og ingenting vil krasje.
Det er nødvendig å overvåke størrelsen på køene, noe som bidrar til å unngå å tråkke på denne raken. For det første kan vi overvåke når vi begynner å miste meldinger. For det andre kan vi overvåke at vi har problemer med levering.
Og et annet ubehagelig øyeblikk - forsterkning med 10 ganger i en mikrotjenestearkitektur er veldig enkelt. Vi har ikke mange innkommende forespørsler, men på grunn av grafen som disse meldingene går videre langs, på grunn av tilgangsloggene, øker vi faktisk loggbelastningen med omtrent ti ganger. Dessverre hadde jeg ikke tid til å beregne de nøyaktige tallene, men mikrotjenester er hva de er. Dette må man huske på. Det viser seg at for øyeblikket er undersystemet for innsamling av tømmer det mest belastede i Lazada.
Hvordan løse et elastisk søk-problem? Hvis du raskt trenger å få logger på ett sted, for ikke å løpe rundt til alle maskinene og samle dem der, bruk fillagring. Dette vil garantert fungere. Det kan gjøres fra hvilken som helst server. Du trenger bare å feste disker der og installere syslog. Etter dette har du garantert alle loggene på ett sted. Deretter kan du sakte konfigurere elasticsearch, graylog og noe annet. Men du vil allerede ha alle loggene, og dessuten kan du lagre dem så langt det er nok diskarrayer.
På tidspunktet for min rapport begynte ordningen å se slik ut. Vi sluttet praktisk talt å skrive til filen. Nå vil vi mest sannsynlig slå av resten. På lokale maskiner som kjører API, vil vi slutte å skrive til filer. For det første er det fillagring, som fungerer veldig bra. For det andre går disse maskinene stadig tom for plass; de må overvåkes konstant.
Denne delen med Logstash og Graylog, det tar virkelig av. Derfor må vi bli kvitt det. Du må velge én ting.
Vi bestemte oss for å kaste ut Logstash og Kibana. Fordi vi har en sikkerhetsavdeling. Hvilken forbindelse? Sammenhengen er at Kibana uten X-Pack og uten Shield ikke lar deg differensiere tilgangsrettigheter til logger. Det er derfor vi tok Graylog. Den har alt. Jeg liker det ikke, men det fungerer. Vi kjøpte ny maskinvare, installerte fersk Graylog der og overførte alle logger med strenge formater til en egen Graylog. Vi løste problemet med ulike typer identiske felt organisatorisk.
Hva er nøyaktig inkludert i den nye Graylog. Vi skrev bare alt inn i docker. Vi tok en haug med servere, rullet ut tre Kafka-instanser, 7 Graylog-servere versjon 2.3 (fordi vi ønsket Elasticsearch versjon 5). Alt dette ble plukket opp under raid fra HDD. Vi så en indekseringshastighet på opptil 100 tusen meldinger per sekund. Vi så tallet som 140 terabyte med data per uke.
Og igjen raken! Vi har to salg på vei. Vi beveget oss over 6 millioner meldinger. Graylog har ikke tid til å tygge. På en eller annen måte må vi overleve igjen.
Slik overlevde vi. Vi la til noen flere servere og SSD-er. For øyeblikket lever vi på denne måten. Nå tygger vi allerede 160 XNUMX meldinger per sekund. Vi har ikke nådd grensen ennå, så det er uklart hvor mye vi faktisk kan få ut av dette.
Dette er våre planer for fremtiden. Av disse er nok den viktigste høy tilgjengelighet. Vi har det ikke ennå. Flere biler er konfigurert på samme måte, men så langt går alt gjennom én bil. Det tar tid å sette opp failover mellom dem.
Samle beregninger fra Graylog.
Lag en hastighetsgrense slik at vi har en sprø API som ikke dreper båndbredden vår og alt annet.
Og til slutt, signer en slags SLA med utviklerne slik at vi kan tjene så mye. Hvis du skriver mer, så beklager jeg.
Og skrive dokumentasjon.
Kort fortalt, resultatene av alt vi opplevde. Først, standarder. For det andre er syslog kake. For det tredje fungerer rsyslog nøyaktig slik det er skrevet på lysbildet. Og la oss gå videre til spørsmålene.
spørsmål.
spørsmålet: Hvorfor bestemte du deg for å ikke ta... (filbeat?)
svar: Vi må skrive til en fil. Jeg ville virkelig ikke. Når API-en din skriver tusenvis av meldinger per sekund, selv om du roterer den en gang i timen, er dette fortsatt ikke et alternativ. Du kan skrive i pipe. Som utviklerne spurte meg til: "Hva vil skje hvis prosessen vi skriver til krasjer?" Jeg fant bare ikke hva jeg skulle svare dem, og sa: "Vel, ok, la oss ikke gjøre det."
spørsmålet: Hvorfor skriver du ikke bare logger til HDFS?
svar: Dette er neste trinn. Vi tenkte på det helt i starten, men siden det for øyeblikket ikke er ressurser til å gjøre dette, henger det i vår langsiktige løsning.
spørsmålet: Kolonneformat ville være mer egnet.
svar: Jeg forstår. Vi er for det med begge hender.
spørsmålet: Du skriver til rsyslog. Der kan du bruke både TCP og UDP. Men hvis UDP, hvordan garanterer du levering?
svar: Det er to punkter. Først forteller jeg alle med en gang at vi ikke garanterer levering av tømmerstokker. For når utviklere kommer og sier: "La oss begynne å skrive økonomiske data der, og du vil legge dem et sted for oss i tilfelle noe skjer," svarer vi dem: "Flott! La oss begynne å blokkere for å skrive til stikkontakten, og gjøre dette i transaksjoner, slik at du er garantert å sette den på stikkontakten for oss og sørge for at vi mottar den fra den andre siden.» Og i dette øyeblikket trenger ikke alle det umiddelbart lenger. Hvis det ikke er nødvendig, hvilke spørsmål bør vi stille? Hvis du ikke vil garantere skriving til en stikkontakt, hvorfor må vi da garantere levering? Vi gjør vårt beste. Vi prøver virkelig å levere så mye som mulig og på best mulig måte, men vi gir ingen 100% garanti. Derfor er det ikke nødvendig å skrive økonomiske data der. Det finnes databaser med transaksjoner for dette.
spørsmålet: Når API-en genererer en melding i loggen og overfører kontroll til mikrotjenester, har du støtt på problemet med at meldinger fra forskjellige mikrotjenester kommer i feil rekkefølge? Dette skaper forvirring.
svar: Det er normalt at de kommer i forskjellige rekkefølger. Du må være forberedt på dette. Fordi enhver nettverkslevering ikke garanterer orden, eller du må bruke spesielle ressurser på dette. Hvis vi tar fillagring, lagrer hver API logger til sin egen fil. Eller rettere sagt, der sorterer rsyslog dem i kataloger. Hver API har sine egne logger, hvor du kan gå og se, og så kan du sammenligne dem ved å bruke tidsstemplet i denne loggen. Hvis de ser i Graylog, blir de sortert der etter tidsstempel. Alt blir bra der.
spørsmålet: Tidsstemplet kan variere med millisekunder.
svar: Tidsstempel genereres av selve APIen. Dette er faktisk hele poenget. Vi har NTP. API-en genererer et tidsstempel i selve meldingen. rsyslog legger det ikke til.
spørsmålet: Samspillet mellom datasentre er ikke veldig tydelig. Innenfor datasenteret er det tydelig hvordan loggene ble samlet inn og behandlet. Hvordan foregår samspillet mellom datasentre? Eller lever hvert datasenter sitt eget liv?
svar: Nesten. I vårt land er hvert land plassert i ett datasenter. For øyeblikket har vi ikke en spredning slik at ett land ligger i forskjellige datasentre. Derfor er det ikke nødvendig å kombinere dem. Hvert senter har et loggrelé inni. Dette er en Rsyslog-server. Egentlig to styringsmaskiner. De har samme holdning. Men foreløpig går trafikken bare gjennom en av dem. Den samler alle loggene. Hun har en diskkø for sikkerhets skyld. Den laster ned loggene og sender dem til det sentrale datasenteret (Singapore), hvor de deretter sendes til Graylog. Og hvert datasenter har sin egen fillagring. I tilfelle tilkoblingen vår mistes, har vi alle loggene der. De vil forbli der. De vil bli lagret der.
spørsmålet: Ved unormale situasjoner, mottar du logger derfra?
svar: Du kan gå dit (til fillagringen) og se.
spørsmålet: Hvordan overvåker du at du ikke mister logger?
svar: Vi mister dem faktisk, og vi overvåker det. Overvåking ble lansert for en måned siden. Biblioteket som Go API-ene bruker har beregninger. Hun kan telle hvor mange ganger hun ikke klarte å skrive til en stikkontakt. Det er for tiden en smart heuristikk der. Det er en buffer der. Den prøver å skrive en melding fra den til stikkontakten. Hvis bufferen renner over, begynner den å slippe dem. Og han teller hvor mange av dem han droppet. Hvis målerne begynner å renne over der, får vi vite om det. De kommer nå også til prometheus, og du kan se grafene i Grafana. Du kan sette opp varsler. Men det er ennå ikke klart hvem de skal sendes til.
spørsmålet: I elasticsearch lagrer du logger med redundans. Hvor mange kopier har du?
svar: En linje.
spørsmålet: Er dette bare én linje?
svar: Dette er mesteren og kopien. Dataene lagres i to kopier.
spørsmålet: Justerte du rsyslog-bufferstørrelsen på en eller annen måte?
svar: Vi skriver datagrammer til en tilpasset unix-sokkel. Dette pålegger oss umiddelbart en grense på 128 kilobyte. Vi kan ikke skrive mer til den. Vi har skrevet dette inn i standarden. De som ønsker å komme inn på lager skriver 128 kilobyte. Biblioteker kuttes dessuten av, og det settes et flagg om at meldingen kuttes av. Vår standard for selve meldingen har et spesialfelt som viser om den ble kuttet under opptak eller ikke. Så vi har muligheten til å spore dette øyeblikket også.
Spørsmål: Skriver du ødelagt JSON?
svar: Ødelagt JSON vil bli forkastet enten under relé fordi pakken er for stor. Eller Graylog vil bli forkastet fordi den ikke kan analysere JSON. Men det er nyanser som må fikses, og de er stort sett knyttet til rsyslog. Jeg har allerede fylt ut flere saker der, som det fortsatt må jobbes med.
Spørsmål: Hvorfor Kafka? Har du prøvd RabbitMQ? Mislykkes Graylog under slike belastninger?
svar: Det fungerer ikke for oss med Graylog. Og Graylog tar form for oss. Han er virkelig problematisk. Han er en merkelig ting. Og det er faktisk ikke nødvendig. Jeg foretrekker å skrive fra rsyslog direkte til elasticsearch og så se på Kibana. Men vi må løse problemet med sikkerhetsvaktene. Dette er et mulig alternativ for vår utvikling, når vi kaster ut Graylog og bruker Kibana. Det er ingen vits i å bruke Logstash. Fordi jeg kan gjøre det samme med rsyslog. Og den har en modul for å skrive til elasticsearch. Vi prøver på en eller annen måte å leve med Graylog. Vi justerte det til og med litt. Men det er fortsatt rom for forbedring.
Om Kafka. Slik skjedde det historisk. Da jeg kom, var den allerede der, og logger ble allerede skrevet til den. Vi hevet ganske enkelt klyngen vår og flyttet tømmerstokker inn i den. Vi er ledelsen hans, vi vet hvordan han har det. Når det gjelder RabbitMQ... det fungerer ikke for oss med RabbitMQ. Og RabbitMQ tar form for oss. Vi har den i produksjon, og det var problemer med den. Nå, før salget, ville de sjarmere ham, og han ville begynne å jobbe normalt. Men før det var jeg ikke klar til å gi den ut i produksjon. Det er ett poeng til. Graylog kan lese versjon AMQP 0.9, og rsyslog kan skrive versjon AMQP 1.0. Og det er ikke en eneste løsning i midten som kan gjøre begge deler. Det er enten det ene eller det andre. Derfor for øyeblikket bare Kafka. Men den har også sine egne nyanser. Fordi omkafka av versjonen av rsyslog som vi bruker kan miste hele meldingsbufferen som den raket ut fra rsyslog. Foreløpig tåler vi det.
Spørsmål: Bruker du Kafka fordi du allerede hadde det? Ikke lenger brukt til noe formål?
svar: Kafka, som var, brukes av Data Science-teamet. Dette er et helt eget prosjekt, som jeg dessverre ikke kan si noe om. Jeg vet ikke. Det ble drevet av Data Science-teamet. Da loggene ble opprettet, bestemte vi oss for å bruke den for ikke å installere vår egen. Nå har vi oppdatert Graylog, og vi har mistet kompatibiliteten fordi den har en gammel versjon av Kafka. Vi måtte starte vårt eget. Samtidig ble vi kvitt disse fire emnene for hvert API. Vi laget ett bredt emne for alle live, ett bredt bredt emne for alle iscenesettelser og bare satte alt der. Graylog skraper alt dette ut parallelt.
Spørsmål: Hvorfor trenger vi denne sjamanismen med stikkontakter? Har du prøvd å bruke syslog-loggdriveren for containere?
svar: På det tidspunktet da vi stilte dette spørsmålet, var forholdet vårt til havnearbeideren anspent. Det var docker 1.0 eller 0.9. Docker selv var merkelig. For det andre, hvis du også skyver logger inn i den... Jeg har en ubekreftet mistanke om at den sender alle loggene gjennom seg selv, gjennom docker-demonen. Hvis en API blir gal, så sitter resten av APIene fast i det faktum at de ikke kan sende stdout og stderr. Jeg vet ikke hvor dette vil føre. Jeg har en mistanke om at det ikke er nødvendig å bruke Docker syslog-driveren på dette stedet. Vår funksjonstestavdeling har en egen Graylog-klynge med logger. De bruker Docker-loggdrivere og alt ser ut til å være bra der. Men de skriver umiddelbart GELF til Graylog. På den tiden da vi startet alt dette, trengte vi bare at det skulle fungere. Kanskje senere, når noen kommer og sier at det har fungert bra i hundre år, skal vi prøve.
Spørsmål: Du utfører levering mellom datasentre ved hjelp av rsyslog. Hvorfor ikke Kafka?
svar: Vi gjør begge deler faktisk. Av to grunner. Hvis kanalen er helt død, vil ikke alle loggene våre, selv i komprimert form, krype gjennom den. Og Kafka lar deg rett og slett miste dem i prosessen. Slik blir vi kvitt disse stokkene som setter seg fast. Vi bruker bare Kafka direkte i dette tilfellet. Hvis vi har en god kanal og ønsker å frigjøre den, så bruker vi deres rsyslog. Men faktisk kan du konfigurere den slik at den selv slipper det som ikke passet gjennom. For øyeblikket bruker vi bare rsyslog-levering direkte et sted, og Kafka et sted.
Kilde: www.habr.com