Logfiler er en vigtig del af systemet, så du kan forstå, at det fungerer (eller ikke virker) som forventet. Under betingelserne for mikroservicearkitektur bliver arbejdet med logfiler en separat disciplin i Special Olympiad. Der er mange problemer, der skal løses:
- hvordan man skriver log fra applikationen;
- hvor man skriver logs;
- hvordan man leverer logs til opbevaring og behandling;
- hvordan man behandler og opbevarer logfiler.
Brugen af aktuelt populære containeriseringsteknologier tilføjer sand på toppen af riven inden for problemløsningsmuligheder.
Lige om dette er udskriften af rapporten af Yuri Bushmelev "Kort over en rive inden for indsamling og levering af træstammer"
Hvem bekymrer sig, venligst under katten.
Mit navn er Yuri Bushmelev. Jeg arbejder for Lazada. I dag vil jeg tale om, hvordan vi lavede vores logfiler, hvordan vi samlede dem, og hvad vi skriver der.
Hvor er vi fra? Hvem er vi? Lazada er den #1 online forhandler i seks lande i Sydøstasien. Alle disse lande er fordelt på datacentre. Der er nu 4 datacentre i alt. Hvorfor er det vigtigt? For nogle beslutninger skyldtes, at der er et meget svagt led mellem centrene. Vi har en mikroservicearkitektur. Jeg var overrasket over at opdage, at vi allerede har 80 mikrotjenester. Da jeg startede opgaven med logs, var der kun 20 af dem.Derudover er der et ret stort stykke PHP-arv, som jeg også må leve med og finde mig i. Alt dette genererer for os i øjeblikket mere end 6 millioner beskeder i minuttet for systemet som helhed. Yderligere vil jeg vise, hvordan vi forsøger at leve med dette, og hvorfor det er sådan.
Du må leve med disse 6 millioner beskeder på en eller anden måde. Hvad skal vi gøre med dem? 6 millioner beskeder nødvendige:
- send fra app
- acceptere til levering
- levere til analyse og opbevaring.
- analysere
- gemme på en eller anden måde.
Da der var tre millioner beskeder, havde jeg omtrent det samme udseende. For vi startede med nogle øre. Det er tydeligt, at ansøgningslogs er skrevet der. For eksempel kunne ikke oprette forbindelse til databasen, kunne oprette forbindelse til databasen, men kunne ikke læse noget. Men udover dette skriver hver af vores mikrotjenester også en adgangslog. Hver anmodning, der ankommer til mikrotjenesten, falder ind i loggen. Hvorfor gør vi dette? Udviklere ønsker at kunne spore. Hver adgangslog indeholder sporingsfeltet, ifølge hvilket en speciel grænseflade derefter afvikler hele kæden og smukt viser sporet. Sporet viser, hvordan anmodningen gik, og dette hjælper vores udviklere med at håndtere ukendt affald hurtigere.
Hvordan skal man leve med det? Nu vil jeg kort beskrive feltet af muligheder - hvordan dette problem generelt løses. Hvordan man løser problemet med at indsamle, overføre og opbevare logfiler.
Hvordan skriver man fra ansøgningen? Det er klart, at der er forskellige måder. Især er der best practice, som fashionable kammerater fortæller os. Der er to typer old school, som bedstefædre sagde. Der er andre måder.
Med indsamling af logs er situationen nogenlunde den samme. Der er ikke så mange muligheder for at løse netop denne del. Der er flere af dem, men ikke så mange endnu.
Men med levering og efterfølgende analyse begynder antallet af variationer at eksplodere. Jeg vil ikke beskrive hver mulighed nu. Jeg tror, at de vigtigste muligheder er velkendte for alle, der var interesserede i emnet.
Jeg vil vise dig, hvordan vi gjorde det på Lazada, og hvordan det hele startede.
For et år siden kom jeg til Lazada og blev sendt til logprojektet. Det var sådan her. Loggen fra applikationen blev skrevet til stdout og stderr. Alt blev gjort på en moderigtig måde. Men så smed udviklerne det ud af standardstrømmene, og så vil infrastrukturspecialister finde ud af det på en eller anden måde. Mellem infrastrukturspecialister og udviklere er der også udgivere, der sagde: "øh ... ja, lad os bare pakke dem ind i en fil med en shell, og det er det." Og da alt dette er i en container, pakkede de det ind i selve containeren, kortlagde mappen indeni og lagde det der. Jeg tror, det er ret indlysende for alle, hvad der skete.
Lad os se lidt længere. Hvordan vi leverede disse logfiler. Nogen valgte td-agent, som faktisk er flydende, men ikke helt flydende. Jeg forstår stadig ikke sammenhængen mellem disse to projekter, men de ser ud til at handle om det samme. Og denne flydende, skrevet i Ruby, læste logfiler, parsede dem ind i JSON ved hjælp af nogle regulære udtryk. Så blev de sendt til Kafka. Desuden havde vi i Kafka 4 separate emner for hver API. Hvorfor 4? Fordi der er live, der er iscenesættelse, og fordi der er stdout og stderr. Udviklere producerer dem, og infrastrukturarbejdere skal skabe dem i Kafka. Desuden blev Kafka kontrolleret af en anden afdeling. Derfor var det nødvendigt at oprette en billet, så de oprettede 4 emner der for hvert api. Alle glemte det. Generelt var det skrald og affald.
Hvad gjorde vi så med det? Vi sendte det til kafka. Længere fra Kafka fløj halvdelen af stammerne til Logstash. Den anden halvdel af kævlerne blev delt. Nogle fløj til en Graylog, nogle til en anden Graylog. Som et resultat fløj alt dette ind i én Elasticsearch-klynge. Det vil sige, at alt det rod faldt til sidst der. Det behøver du ikke gøre!
Sådan ser det ud, set fra oven. Det behøver du ikke gøre! Her er problemområderne umiddelbart markeret med tal. Der er faktisk flere af dem, men 6 er virkelig problematiske, som der skal gøres noget med. Jeg vil fortælle om dem separat nu.
Her (1,2,3) skriver vi filer, og derfor er der tre rakes her på én gang.
Den første (1) er, at vi skal skrive dem et sted. Det er ikke altid ønskeligt at give en API mulighed for at skrive direkte til en fil. Det er ønskeligt, at API'en er isoleret i en container, og endnu bedre, at den er skrivebeskyttet. Jeg er systemadministrator, så jeg har et lidt alternativt syn på disse ting.
Det andet punkt (2,3) er, at vi har mange anmodninger, der kommer til API'et. API'et skriver en masse data til en fil. Filerne vokser. Vi er nødt til at rotere dem. For ellers vil du ikke kunne gemme nogen diske der. Det er dårligt at rotere dem, fordi de omdirigeres via skallen til en mappe. Der er ingen måde, vi kan rotere det. Du kan ikke bede applikationen om at genåbne håndtagene. Fordi udviklerne vil se på dig som et fjols: "Hvilke beskrivelser? Vi skriver generelt til stdout. Frameworks lavet copytruncate til logrotate, som blot laver en kopi af filen og trunk originalen. Følgelig løber der normalt diskplads mellem disse kopieringsprocesser.
(4) Vi havde forskellige formater i forskellige API'er. De var lidt forskellige, men regexp skulle skrives anderledes. Da det hele blev styret af Puppet, var der en stor flok klasser med deres egne kakerlakker. Plus, td-agent kunne det meste af tiden spise hukommelse, være dum, han kunne bare lade som om han arbejdede og lave ingenting. Udadtil var det umuligt at forstå, at han ikke lavede noget. I bedste fald vil han falde, og nogen vil samle ham op senere. Mere præcist vil en alarm flyve ind, og nogen vil gå og hæve den med deres hænder.
(6) Og mest affald og affald - det var elastisk søgning. Fordi det var en gammel version. For vi havde ikke dedikerede mestre på det tidspunkt. Vi havde heterogene træstammer, hvis marker kunne overlappe hinanden. Forskellige logfiler for forskellige applikationer kunne skrives med de samme feltnavne, men der kan samtidig være forskellige data inde. Det vil sige, at én log kommer med et heltal i et felt, for eksempel niveau. En anden log kommer med en streng i niveaufeltet. I mangel af statisk kortlægning viser sådan en vidunderlig ting sig. Hvis der efter indeksrotation først ankom en besked med en streng i elasticsearch, så lever vi normalt. Og hvis den første ankom med Integer, så bliver alle efterfølgende meddelelser, der ankom med String, simpelthen kasseret. Fordi felttypen ikke stemmer overens.
Vi begyndte at stille disse spørgsmål. Vi besluttede ikke at lede efter de skyldige.
Men der skal gøres noget! Det åbenlyse er, at vi skal etablere standarder. Vi havde allerede nogle standarder. Nogle kom vi med lidt senere. Heldigvis var et enkelt logformat for alle API'er allerede godkendt på det tidspunkt. Det skrives direkte ind i serviceinteraktionsstandarderne. Derfor bør de, der ønsker at modtage logs, skrive dem i dette format. Hvis nogen ikke skriver logs i dette format, så garanterer vi ikke noget.
Yderligere vil jeg gerne have en enkelt standard for metoderne til registrering, levering og indsamling af logfiler. Faktisk, hvor man skriver dem, og hvordan man leverer dem. Den ideelle situation er, når projekter bruger det samme bibliotek. Der er et separat logbibliotek til Go, der er et separat bibliotek til PHP. Alle vi har, alle burde bruge dem. I øjeblikket vil jeg sige, at vi lykkes med 80 procent. Men nogle fortsætter med at spise kaktusser.
Og dér (på sliden) begynder "SLA for log levering" knap at dukke op. Det er der ikke endnu, men vi arbejder på det. For det er meget praktisk, når infra siger, at hvis du skriver i sådan og sådan et format til sådan og sådan et sted og ikke mere end N beskeder i sekundet, så leverer vi det højst sandsynligt der. Det fjerner en masse hovedpine. Hvis der er en SLA, så er det bare fantastisk!
Hvordan begyndte vi at løse problemet? Den vigtigste rake var med td-agent. Det var uklart, hvor vores logs bliver af. Er de leveret? Går de? Hvor er de alligevel? Derfor blev det besluttet at erstatte td-agent med den første vare. Muligheder for, hvad den skal erstattes med, skitserede jeg kort her.
Flydende. For det første stødte jeg på ham på et tidligere job, og han faldt også med jævne mellemrum der. For det andet er dette det samme, kun i profil.
filbeat. Hvordan var det godt for os? Det faktum, at han er i Go, og vi har en stor ekspertise i Go. Derfor kunne vi på en eller anden måde tilføje det til os selv. Derfor tog vi det ikke. Så der ikke engang ville være nogen fristelse til at begynde at omskrive det til dig selv.
Den åbenlyse løsning for sysadmin er alle mulige slags syslogs i denne mængde (syslog-ng/rsyslog/nxlog).
Eller skriv noget af dit eget, men vi kasserede det, såvel som filebeat. Hvis du skriver noget, så er det bedre at skrive noget nyttigt for erhvervslivet. For at levere logs er det bedre at tage noget færdiglavet.
Derfor kom valget faktisk ned på et valg mellem syslog-ng og rsyslog. Jeg hældede til rsyslog, simpelthen fordi vi allerede havde klasser til rsyslog i Puppet, og jeg fandt ikke en tydelig forskel mellem dem. Hvad er syslog, hvad er syslog. Ja, noget dokumentation er værre, noget bedre. Han ved det, og han gør det anderledes.
Og lidt om rsyslog. For det første er det fedt, fordi det har mange moduler. Den har et menneskelæsbart RainerScript (moderne konfigurationssprog). En fantastisk bonus er, at vi kunne efterligne adfærden hos td-agent med dets standardværktøjer, og intet har ændret sig for applikationer. Det vil sige, at vi ændrer td-agent til rsyslog, og rører ikke alt andet endnu. Og straks får vi en fungerende levering. Dernæst er mmnormalize det fede ved rsyslog. Det giver dig mulighed for at parse logfiler, men ikke med Grok og regexp. Det laver et abstrakt syntakstræ. Den analyserer logfiler på nogenlunde samme måde, som en compiler analyserer kildekoden. Dette giver dig mulighed for at arbejde meget hurtigt, spise lidt CPU, og generelt er det bare en meget cool ting. Der er en masse andre bonusser. Jeg vil ikke dvæle ved dem.
rsyslog har mange flere ulemper. De er omtrent det samme som bonusser. De største problemer er, at du skal kunne tilberede den, og du skal vælge en version.
Vi besluttede, at vi ville skrive logs i en unix-socket. Og ikke i /dev/log, for der har vi et rod af systemlogfiler, der er journalført i denne pipeline. Så lad os skrive til en brugerdefineret stikkontakt. Vi vedhæfter det til et separat regelsæt. Lad os ikke blande os i noget. Alt vil være gennemsigtigt og forståeligt. Så det gjorde vi faktisk. Biblioteket med disse sockets er standardiseret og videresendes til alle containere. Containere kan se den stikkontakt, de skal bruge, åbne og skrive til den.
Hvorfor ikke en fil? Fordi alle har læst , som forsøgte at videresende filen til docker, og fandt ud af, at efter genstart af rsyslog ændres filbeskrivelsen, og docker mister denne fil. Han holder noget andet åbent, men ikke den samme fatning, hvor de skriver. Vi besluttede, at vi ville omgå dette problem, og samtidig omgå blokeringsproblemet.
Rsyslog udfører handlingerne angivet på sliden og sender logfiler til enten relæ eller Kafka. Kafka følger den gamle måde. Rayleigh - Jeg forsøgte at bruge ren rsyslog til at levere logfiler. Uden Message Queue, ved hjælp af standard rsyslog-værktøjer. I bund og grund virker det.
Men der er nuancer med, hvordan man stopper dem senere i denne del (Logstash/Graylog/ES). Denne del (rsyslog-rsyslog) bruges mellem datacentre. Her er et komprimeret tcp-link, som giver dig mulighed for at spare båndbredde og følgelig på en eller anden måde øge sandsynligheden for, at vi modtager nogle logfiler fra et andet datacenter, når kanalen er fuld. For vi har Indonesien, hvor alt er dårligt. Det er der, det konstante problem ligger.
Vi tænkte på, hvordan vi rent faktisk overvåger, med hvilken sandsynlighed når de logfiler, som vi registrerede fra applikationen? Vi besluttede at starte metrics. Rsyslog har sit eget statistikindsamlingsmodul, som har en form for tællere. Det kan for eksempel vise dig størrelsen på køen, eller hvor mange beskeder der er kommet i sådan en handling. Du kan allerede tage noget fra dem. Derudover har den brugerdefinerede tællere, som du kan konfigurere, og den vil for eksempel vise dig antallet af beskeder, som nogle API har registreret. Dernæst skrev jeg rsyslog_exporter i Python, og vi sendte det hele til Prometheus og byggede grafer. Vi ville virkelig gerne have Graylog-metrics, men indtil videre har vi ikke haft tid til at sætte dem op.
Hvad er problemerne? Problemet opstod med, at vi fandt ud af (PLUDSELIGT!), at vores Live API'er skriver 50k beskeder i sekundet. Dette er kun Live API uden iscenesættelse. Og Graylog viser os kun 12 tusinde beskeder i sekundet. Og et rimeligt spørgsmål opstod, hvor er resterne? Hvorfra vi konkluderede, at Graylog simpelthen ikke kan klare det. Vi kiggede, og faktisk mestrede Graylog med Elasticsearch ikke dette flow.
Dernæst andre opdagelser, vi har gjort undervejs.
Skrivning til socket er blokeret. Hvordan skete det? Da jeg brugte rsyslog til levering, brød vi på et tidspunkt kanalen mellem datacentrene. Levering steg et sted, levering steg et andet sted. Alt dette er kommet ned til en maskine med API'er, der skriver til rsyslog-socket. Der var kø. Så blev køen for at skrive til unix-socket fyldt op, som som standard er 128 pakker. Og den næste write() i applikationsblokkene. Da vi kiggede på biblioteket, som vi bruger i Go-applikationer, stod det der, at skrivning til soklen sker i ikke-blokerende tilstand. Vi var sikre på, at intet var blokeret. Fordi vi har læst hvem skrev om det. Men der er et øjeblik. Der var også en uendelig løkke omkring dette opkald, hvor der var et konstant forsøg på at skubbe en besked ind i stikkontakten. Vi lagde ikke mærke til ham. Jeg var nødt til at omskrive biblioteket. Siden har det ændret sig flere gange, men nu er vi sluppet for låse i alle delsystemer. Derfor kan du stoppe rsyslog og intet falder.
Det er nødvendigt at overvåge størrelsen af køerne, hvilket hjælper med ikke at træde på denne rake. For det første kan vi overvåge, hvornår vi begynder at miste beskeder. For det andet kan vi overvåge, at vi grundlæggende har problemer med leveringen.
Og et andet ubehageligt øjeblik - forstærkning med 10 gange i en mikroservicearkitektur er meget let. Vi har ikke så mange indkommende forespørgsler, men på grund af grafen, som disse beskeder kører videre langs, på grund af adgangsloggene, øger vi faktisk belastningen på logfilerne med omkring ti gange. Desværre havde jeg ikke tid til at beregne de nøjagtige tal, men mikrotjenester er, hvad de er. Dette skal huskes. Det viser sig, at logindsamlingsundersystemet i øjeblikket er det mest belastede i Lazada.
Hvordan løser man et elastisk søgningsproblem? Hvis du hurtigt har brug for at få logs ét sted, for ikke at køre på tværs af alle maskiner og samle dem der, så brug fillagring. Dette vil med garanti virke. Det gøres fra enhver server. Du skal bare sætte diske der og sætte syslog. Herefter er du garanteret at have alle logs på ét sted. Så vil det være muligt langsomt at konfigurere elasticsearch, graylog eller noget andet. Men du vil allerede have alle logfilerne, og du kan desuden gemme dem, så vidt der er nok diskarrays.
På tidspunktet for min rapport begyndte ordningen at se sådan ud. Vi holdt næsten op med at skrive til filen. Nu vil vi højst sandsynligt slukke for resterne. På lokale maskiner, der kører API'et, stopper vi med at skrive til filer. For det første er der fillagring, som fungerer meget godt. For det andet løber disse maskiner konstant tør for plads, du skal konstant overvåge det.
Denne del med Logstash og Graylog, det svæver virkelig. Derfor skal du af med det. Du skal vælge en.
Vi besluttede at droppe Logstash og Kibana. Fordi vi har en sikkerhedsafdeling. Hvad er sammenhængen? Forbindelsen er, at Kibana uden X-Pack og uden Shield ikke giver dig mulighed for at differentiere adgangsrettigheder til loggene. Derfor tog de Graylog. Den har det hele. Jeg kan ikke lide det, men det virker. Vi købte ny hardware, installerede en frisk Graylog der og flyttede alle logfiler med strenge formater til en separat Graylog. Vi har løst problemet med forskellige typer af de samme felter organisatorisk.
Hvad der præcist er inkluderet i den nye Graylog. Vi har lige skrevet alt i dockeren. Vi tog en masse servere, udrullede tre Kafka-instanser, 7 Graylog-servere version 2.3 (fordi jeg ville have Elasticsearch version 5). Alt dette blev rejst på raids fra HDD'en. Vi så en indekseringshastighed på op til 100 tusinde beskeder i sekundet. Vi så tallet, at 140 terabyte data om ugen.
Og igen en rive! Vi har to udsalg på vej. Vi har bevæget os ud over 6 millioner indlæg. Vi Graylog har ikke tid til at tygge. På en eller anden måde skal du overleve igen.
Sådan overlevede vi. Tilføjet et par flere servere og SSD'er. I øjeblikket lever vi sådan her. Nu tygger vi allerede 160 beskeder i sekundet. Vi har ikke nået grænsen endnu, så det er uklart, hvor meget vi realistisk kan få ud af det.
Det er vores planer for fremtiden. Af disse er det vigtigste nok høj tilgængelighed. Vi har det ikke endnu. Flere biler er sat op på samme måde, men indtil videre går alt gennem én bil. Det er nødvendigt at bruge tid på at oprette en failover mellem dem.
Indsaml metrics fra Graylog.
Lav en hastighedsgrænse, så vi har en skør API, der ikke dræber os båndbredde og alt muligt andet.
Og endelig, underskriv en slags SLA med udviklere, så vi kan tjene så meget. Hvis du skriver mere, så undskyld.
Og skrive dokumentation.
Kort sagt resultaterne af alt, hvad vi har oplevet. For det første standarderne. For det andet er syslog kage. For det tredje fungerer rsyslog nøjagtigt, som det er skrevet på sliden. Og lad os komme til spørgsmålene.
R'RѕRїSЂRѕSЃS <.
Spørgsmål: Hvorfor besluttede de ikke at tage ... (filebeat?)
Svar: Skal skrive til en fil. Det ville jeg virkelig ikke. Når din API skriver tusindvis af beskeder i sekundet, selvom du roterer en gang i timen, er dette stadig ikke en mulighed. Du kan skrive til pipe. Hvortil udviklerne spurgte mig: "Hvad vil der ske, hvis processen, som vi skriver i, falder ned"? Jeg fandt bare ikke, hvad jeg skulle svare dem, og sagde: "Nå, ok, lad os ikke gøre det."
Spørgsmål: Hvorfor skriver du ikke bare logs til HDFS?
SvarA: Dette er næste fase. Vi tænkte på det i begyndelsen, men da der ikke er ressourcer til at håndtere det i øjeblikket, hænger det i vores langsigtede løsning.
Spørgsmål: Et kolonneformat ville være mere passende.
Svar: Jeg forstår. Vi er "til" med begge hænder.
Spørgsmål: Du skriver til rsyslog. Både TCP og UDP er tilgængelige der. Men hvis UDP, hvordan garanterer du så levering?
SvarA: Der er to punkter. Først fortæller jeg straks alle, at vi ikke garanterer levering af logs. For når udviklerne kommer og siger: "Lad os begynde at skrive økonomiske data der, og du vil lægge dem et sted for os, hvis der skulle ske noget," svarer vi dem: "Fantastisk! Lad os begynde at blokere for at skrive til stikkontakten, og gøre det i transaktioner, så du med garanti kan lægge det i stikkontakten for os og sikre dig, at vi har modtaget det fra den anden side. Og i dette øjeblik bliver alle straks unødvendige. Og hvis ikke, hvilke spørgsmål har vi så? Hvis du ikke vil garantere en skrivning til stikkontakten, hvorfor skulle vi så garantere levering? Vi gør den bedste indsats. Vi forsøger virkelig at levere så meget som muligt og bedst muligt, men vi giver ikke 100% garanti. Derfor behøver du ikke skrive økonomiske data der. Der er transaktionsdatabaser til dette.
Spørgsmål: Når API'en genererer en besked til loggen og overfører kontrol til mikrotjenester, er du så stødt på det problem, at beskeder fra forskellige mikrotjenester ankommer i den forkerte rækkefølge? På grund af dette opstår forvirring.
SvarA: Det er normalt, at de kommer i en anden rækkefølge. Du skal være klar til dette. Fordi enhver netværkslevering ikke garanterer orden til dig, eller du skal bruge særlige ressourcer på dette. Hvis vi tager fillager, gemmer hver API logfiler til sin egen fil. Snarere opdeler rsyslog dem i mapper der. Hver API har sine egne logs der, hvor du kan gå og kigge, og så kan du sammenligne dem ved at bruge tidsstemplet i denne log. Hvis de går for at kigge i Graylog, så bliver de der sorteret efter tidsstempel. Alt vil være fint der.
Spørgsmål: Tidsstemplet kan variere med millisekunder.
Svar: Tidsstemplet genereres af selve API'et. Dette er faktisk hele pointen. Vi har NTP. API'en genererer et tidsstempel allerede i selve meddelelsen. Det er ikke tilføjet af rsyslog.
Spørgsmål: Interaktion mellem datacentre er ikke særlig tydelig. Inden for rammerne af datacentret er det tydeligt, hvordan loggene er blevet indsamlet og behandlet. Hvordan er samspillet mellem datacentre? Eller lever hvert datacenter sit eget liv?
Svar: Næsten. Vi har hvert land placeret i ét datacenter. Vi har i øjeblikket ikke spredning, så et land er placeret i forskellige datacentre. Derfor er der ingen grund til at kombinere dem. Inde i hvert center er der et logrelæ. Dette er en Rsyslog-server. Faktisk to styringsmaskiner. De er sat op på samme måde. Men indtil videre går trafikken bare gennem en af dem. Hun logger alt sammen. Den har en diskkø for en sikkerheds skyld. Hun trykker på logfilerne og sender dem til det centrale datacenter (Singapore), hvor yderligere de allerede er forgiftet i Graylog. Og hvert datacenter har sit eget fillager. Hvis vi mistede forbindelsen, har vi alle logfilerne der. De bliver der. De vil blive opbevaret der.
Spørgsmål: Får du logs derfra under unormale situationer?
Svar: Du kan gå dertil (til fillageret) og se.
Spørgsmål: Hvordan overvåger du, at du ikke mister logs?
Svar: Vi mister dem faktisk, og vi overvåger det. Overvågningen startede for en måned siden. Det bibliotek, som Go API'erne bruger, har metrics. Hun kan tælle, hvor mange gange hun undlod at skrive til socket. Der er i øjeblikket en vanskelig heuristik. Der er en buffer der. Den forsøger at skrive en besked fra den til socket. Hvis bufferen løber over, begynder den at tabe dem. Og han tæller, hvor mange han droppede dem. Hvis tællerne begynder at flyde over der, ved vi om det. De kommer nu også til prometheus, og du kan se graferne i Grafana. Du kan konfigurere advarsler. Men det er endnu ikke klart, hvem de skal sendes til.
Spørgsmål: I elasticsearch gemmer du logfiler med redundans. Hvor mange replikaer har du?
Svar: Én replika.
Spørgsmål: Er det kun en linje?
Svar: Dette er master og replika. Dataene gemmes i to eksemplarer.
Spørgsmål: Har du justeret størrelsen på rsyslog-bufferen på en eller anden måde?
Svar: Vi skriver datagrammer til en brugerdefineret unix-sokkel. Dette pålægger os straks en begrænsning på 128 kilobyte. Vi kan ikke skrive mere ind i det. Det har vi skrevet ind i standarden. Hvem ønsker at komme ind på lager, de skriver 128 kilobyte. Biblioteker skærer desuden af, og sætter et flag om, at beskeden er afskåret. Vi har et særligt felt i standarden for selve beskeden, som viser, om den blev afskåret under optagelsen eller ej. Så vi har mulighed for at spore dette øjeblik.
Spørgsmål: Skriver du ødelagt JSON?
Svar: Ødelagt JSON vil blive kasseret enten under relæ, fordi pakken er for stor. Eller Graylog vil blive slettet, fordi den ikke vil være i stand til at parse JSON. Men der er nuancer her, der skal rettes, og de er for det meste bundet til rsyslog. Jeg har allerede udfyldt et par spørgsmål der, som stadig mangler at blive arbejdet på.
Spørgsmål: Hvorfor Kafka? Har du prøvet RabbitMQ? Kan Graylog ikke lægges sammen under sådanne belastninger?
Svar: Det går ikke med Graylog. Og Graylog tager form. Det er virkelig problematisk for ham. Han er en slags ting. Og faktisk er det ikke nødvendigt. Jeg vil hellere skrive fra rsyslog direkte til elasticsearch og så se Kibana. Men vi skal løse problemet med sikkerhedsvagterne. Dette er en mulig variant af vores udvikling, når vi smider Graylog ud og bruger Kibana. Logstash vil ikke give mening. Fordi jeg kan gøre det samme med rsyslog. Og den har et modul til at skrive til elasticsearch. Med Graylog prøver vi på en eller anden måde at leve. Vi har endda justeret lidt. Men der er stadig plads til forbedringer.
Om Kafka. Sådan skete det historisk. Da jeg ankom, var den der allerede, og der blev allerede skrevet logs til den. Vi har lige rejst vores klynge og flyttet log ind i den. Vi styrer ham, vi ved, hvordan han har det. Med hensyn til RabbitMQ... har vi problemer med RabbitMQ. Og RabbitMQ udvikler for os. Vi har den i produktion, og der var problemer med den. Nu, før salget, ville han blive shamaniseret, og han ville begynde at arbejde normalt. Men før det var jeg ikke klar til at frigive den i produktion. Der er en pointe mere. Graylog kan læse AMQP 0.9 version og rsyslog kan skrive AMQP 1.0 version. Og der er ikke en eneste løsning, der kan gøre begge dele på midten. Der er enten det ene eller det andet. Så indtil videre kun Kafka. Men der er også nuancer. Fordi omkafka af versionen af rsyslog, som vi bruger, kan miste hele meddelelsesbufferen, som den hentede op fra rsyslog. Så længe vi holder os til det.
Spørgsmål: Bruger du Kafka, fordi du havde det? Ikke brugt til andre formål?
Svar: Kafka, som blev brugt af Data Science-teamet. Dette er et helt separat projekt, som jeg desværre ikke kan sige noget om. Jeg ved ikke. Hun blev drevet af Data Science-teamet. Da logfilerne startede, besluttede de at bruge det, for ikke at sætte deres eget. Nu har vi opdateret Graylog, og vi har mistet kompatibiliteten, fordi der er en gammel version af Kafka. Vi skulle lave vores egne. Samtidig slap vi af med disse fire emner for hver API. Vi lavede en bred top til alle live, en bred bred top til alle iscenesættelser, og vi skyder bare alt der. Graylog river alt dette ud parallelt.
Spørgsmål: Hvorfor har vi brug for denne shamanisme med stikkontakter? Har du prøvet at bruge syslog-logdriveren til containere.
Svar: På det tidspunkt, hvor vi stillede dette spørgsmål, havde vi et anspændt forhold til havnearbejderen. Det var docker 1.0 eller 0.9. Docker selv var mærkelig. For det andet, hvis du også skubber logfiler ind i den ... Jeg har en ubekræftet mistanke om, at den sender alle logfilerne gennem sig selv, gennem docker-dæmonen. Hvis vi har en API, der går amok, så vil resten af API'erne løbe ind i, at de ikke kan sende stdout og stderr. Jeg ved ikke, hvor det vil føre hen. Jeg har en mistanke om, at det ikke er nødvendigt at bruge docker syslog-driveren på dette sted. Vores funktionstestafdeling har sin egen Graylog-klynge med logs. De bruger docker log-drivere, og alt ser ud til at være fint der. Men de skriver straks GELF til Graylog. I det øjeblik, hvor vi startede alt dette, havde vi brug for, at det bare fungerede. Måske senere, når nogen kommer og siger, at det har fungeret normalt i hundrede år, vil vi prøve.
Spørgsmål: Du leverer mellem datacentre ved hjælp af rsyslog. Hvorfor ikke på Kafka?
Svar: Det gør vi, og sådan er det i virkeligheden. Af to grunde. Hvis kanalen er helt død, vil alle vores logfiler, selv i en komprimeret form, ikke klatre gennem den. Og kafka giver dem mulighed for simpelthen at tabe i processen. På denne måde slipper vi for klæbningen af disse kævler. Vi bruger bare Kafka i dette tilfælde direkte. Hvis vi har en god kanal og vil frigøre den, så bruger vi deres rsyslog. Men faktisk kan du sætte den op, så den taber det, den ikke nåede igennem. I øjeblikket bruger vi bare rsyslog levering direkte et sted, et sted Kafka.
Kilde: www.habr.com