Yuri Bushmelev "Karta över kratta på fältet för att samla in och leverera stockar" - utskrift av rapporten

Loggar är en viktig del av systemet, så att du kan förstå att det fungerar (eller inte fungerar) som förväntat. I en mikrotjänstarkitektur blir arbetet med loggar en separat disciplin för en speciell Olympiad. En massa frågor måste lösas på en gång:

• hur man skriver loggar från en applikation;
• var man skriver loggar;
• hur man levererar stockar för lagring och bearbetning;
• hur man bearbetar och lagrar loggar.

Användningen av för närvarande populära containeriseringsteknologier lägger till sand ovanpå raken till fältet av alternativ för att lösa problemet.

Det är precis vad utskriften av Yuri Bushmelevs rapport "Karta över krattor inom området för insamling och leverans av stockar" handlar om.

För alla intresserade, se katt.

Jag heter Yuri Bushmelev. Jag jobbar på Lazada. Idag ska jag prata om hur vi gjorde våra loggar, hur vi samlade in dem och vad vi skriver där.

Var kommer vi ifrån? Vilka är vi? Lazada är den första online-återförsäljaren i sex länder i Sydostasien. Alla dessa länder är fördelade på våra datacenter. Det finns för närvarande 1 datacenter totalt. Varför är detta viktigt? För vissa beslut berodde på att det är en väldigt svag länk mellan centra. Vi har en mikroservicearkitektur. Jag blev förvånad när jag upptäckte att vi redan har 4 mikrotjänster. När jag började med uppgiften med loggar fanns det bara 80. Plus att det finns ett ganska stort PHP-arv som jag också måste leva med och stå ut med. Allt detta genererar för närvarande mer än 20 miljoner meddelanden per minut för systemet som helhet. Härnäst kommer jag att visa hur vi försöker leva med detta, och varför det är så.

Du måste på något sätt leva med dessa 6 miljoner meddelanden. Vad ska vi göra med dem? 6 miljoner meddelanden du behöver:

• skicka från appen
• acceptera för leverans
• leverera för analys och lagring.
• analysera
• lagra det på något sätt.

När tre miljoner meddelanden dök upp såg jag ungefär likadan ut. För vi började med bara några ören. Det är tydligt att ansökningsloggar skrivs där. Jag kunde till exempel inte ansluta till databasen, jag kunde ansluta till databasen men jag kunde inte läsa någonting. Men förutom detta skriver var och en av våra mikrotjänster också en åtkomstlogg. Varje begäran som kommer till mikrotjänsten registreras i loggen. Varför gör vi det här? Utvecklare vill kunna spåra. Varje åtkomstlogg innehåller ett spårningsfält, med vilket ett speciellt gränssnitt sedan avvecklar hela kedjan och visar spåret vackert. Spåret visar hur förfrågan gick, och detta hjälper våra utvecklare att snabbt hantera allt oidentifierat skräp.

Hur ska man leva med detta? Nu ska jag kort beskriva alternativområdet - hur detta problem i allmänhet löses. Hur man löser problemet med att samla in, överföra och lagra loggar.

Hur skriver man från en ansökan? Det är klart att det finns olika sätt. I synnerhet finns det bästa praxis, som våra fashionabla kamrater säger till oss. Det finns två typer av old school, som våra farfar sa till oss. Det finns andra sätt.

Situationen med att samla stockar är ungefär densamma. Det finns inte många alternativ för att lösa just den här delen. Det finns redan fler av dem, men inte så många ännu.

Men med leverans och efterföljande analys börjar antalet variationer explodera. Jag kommer inte att beskriva varje alternativ nu. Jag tror att de viktigaste alternativen är välkända för alla som är intresserade av ämnet.

Jag ska visa dig hur vi gjorde det på Lazada, och hur det hela började.

För ett år sedan kom jag till Lazada och blev skickad till ett projekt om stockar. Det var något sånt här. Ansökningsloggen skrevs till stdout och stderr. Allt gjordes på ett moderiktigt sätt. Men sedan slängde utvecklarna ut det från standardflödena, och då kommer på något sätt infrastrukturspecialister att ta reda på det. Mellan infrastrukturspecialister och utvecklare finns det också utgivare som sa: "eh... okej, låt oss bara slå in dem i en fil med ett skal, och det är det." Och eftersom allt detta låg i en container, lindade de in det direkt i själva containern, kartlade katalogen inuti och lade den där. Jag tror att det är ganska uppenbart för alla vad som kom ur det.

Låt oss titta lite längre än så länge. Hur levererade vi dessa stockar? Någon valde td-agent, som egentligen är flytande, men inte riktigt flytande. Jag förstår fortfarande inte förhållandet mellan dessa två projekt, men de verkar handla om samma sak. Och denna flytande, skriven i Ruby, läste loggfiler, analyserade dem till JSON med någon form av regelbundenhet. Sedan skickade jag dem till Kafka. Dessutom hade vi i Kafka fyra separata ämnen för varje API. Varför 4? För att det finns live, det finns iscensättning och för att det finns stdout och stderr. Utvecklare skapar dem, och infrastrukturutvecklare måste skapa dem i Kafka. Dessutom kontrollerades Kafka av en annan avdelning. Därför var det nödvändigt att skapa en biljett så att de skulle skapa 4 ämnen för varje api. Alla glömde det. I allmänhet var det skräp och tjafs.

Vad gjorde vi sedan med detta? Vi skickade den till Kafka. Sedan flög hälften av stockarna från Kafka till Logstash. Den andra hälften av stockarna delades. Några flög till en Graylog, några till en annan Graylog. Som ett resultat gick allt detta in i ett Elasticsearch-kluster. Det vill säga, all denna röra hamnade där. Gör inte det!

Så här ser det ut om man ser det uppifrån. Gör inte det! Här markeras problemområdena omedelbart med siffror. Det finns faktiskt fler av dem, men 6 är verkligen problematiska som måste göras något åt. Jag ska berätta om dem separat nu.

Här (1,2,3) skriver vi filer och följaktligen finns det tre rakes här samtidigt.

Den första (1) är att vi måste skriva dem någonstans. Det skulle inte alltid vara önskvärt att ge API:et möjlighet att skriva direkt till en fil. Det är önskvärt att API:t är isolerat i en behållare, eller ännu bättre, att det är skrivskyddat. Jag är systemadministratör, så jag har en lite alternativ syn på dessa saker.

Den andra punkten (2,3) är att vi har många förfrågningar som kommer till API:t. API:et skriver mycket data till en fil. Filerna växer. Vi måste rotera dem. För annars kommer du inte att kunna fylla på några diskar där. Att rotera dem är dåligt eftersom de görs genom att omdirigera genom skalet till katalogen. Det finns inget sätt vi kan revidera det. Du kan inte säga åt programmet att öppna handtagen igen. Eftersom utvecklarna kommer att se på dig som om du är en idiot: "Vilka beskrivningar? Vi skriver vanligtvis till stdout.” Infrastrukturutvecklare gjorde copytruncate till logrotate, vilket helt enkelt gör en kopia av filen och transkriberar originalet. Följaktligen tar vanligtvis diskutrymmet slut mellan dessa kopieringsprocesser.

(4) Vi hade olika format i olika API:er. De var lite olika, men regexp måste skrivas annorlunda. Eftersom allt detta styrdes av Puppet fanns det ett stort gäng klasser med sina egna kackerlackor. Plus, för det mesta kunde td-agent äta minne, vara dum, den kunde bara låtsas att den fungerade och inte göra någonting. Från utsidan var det omöjligt att förstå att han inte gjorde någonting. I bästa fall kommer han att ramla och någon tar upp honom senare. Närmare bestämt kommer en varning, och någon kommer att gå och höja den med sina händer.

(6) Och mest skräp och avfall var elasticsearch. För det var en gammal version. För vi hade inte dedikerade mästare på den tiden. Vi hade heterogena stockar vars fält kunde överlappa varandra. Olika loggar från olika applikationer kan skrivas med samma fältnamn, men det kan finnas olika data inuti. Dvs en logg kommer med heltal i fältet, till exempel nivå. En annan logg kommer med String i nivåfältet. I avsaknad av statisk kartläggning är detta en så underbar sak. Om, efter att ha roterat indexet i elasticsearch, kommer meddelandet med strängen först, då lever vi normalt. Men om det första kom från Integer, så kasseras helt enkelt alla efterföljande meddelanden som kom från String. Eftersom fälttypen inte matchar.

Vi började ställa dessa frågor. Vi bestämde oss för att inte leta efter dem att skylla på.

Men något måste göras! Det uppenbara är att vi måste fastställa standarder. Vi hade redan några standarder. Vi började lite senare. Lyckligtvis hade ett enda loggformat för alla API:er redan godkänts vid den tiden. Den skrivs direkt in i standarderna för interaktion mellan tjänster. Följaktligen måste de som vill ta emot loggar skriva dem i detta format. Om någon inte skriver loggar i detta format så garanterar vi ingenting.

Därefter skulle jag vilja skapa en enhetlig standard för metoderna för inspelning, leverans och insamling av loggar. Egentligen, var man ska skriva dem och hur man levererar dem. Den idealiska situationen är när projekt använder samma bibliotek. Det finns ett separat loggningsbibliotek för Go och ett separat bibliotek för PHP. Alla vi har borde använda dem. I nuläget skulle jag säga att vi är 80 procent framgångsrika i detta. Men vissa människor fortsätter att äta kaktusar.

Och där (på bilden) börjar knappt "SLA för leverans av stockar" dyka upp. Det finns inte än, men vi jobbar på det. För det är väldigt bekvämt när infrastrukturen säger att om man skriver i ett och annat format till ett och ett ställe och inte mer än N meddelanden per sekund så kommer vi med största sannolikhet att leverera det till ett och annat ställe. Detta lindrar mycket huvudvärk. Om det finns en SLA så är detta helt underbart!

Hur började vi lösa problemet? Det största problemet var med td-agent. Det var inte klart vart våra stockar tog vägen. Levereras de? Går de? Var är de förresten? Därför beslutades den första punkten att ersätta td-agent. Jag har kort beskrivit alternativen för vad den ska ersättas med här.

Flytande. För det första stötte jag på honom på ett tidigare jobb, och han ramlade också då och då. För det andra är detta samma sak, bara i profil.

Filebeat. Hur var det bekvämt för oss? För det är i Go, och vi har mycket expertis inom Go. Följaktligen, om något hände, kan vi på något sätt lägga till det för oss själva. Det var därför vi inte tog det. Så att det inte ens är någon frestelse att börja skriva om det själv.

Den självklara lösningen för systemadministratören är alla typer av syslogs i denna mängd (syslog-ng/rsyslog/nxlog).

Eller skriv något eget, men vi kasserade detta, såväl som filebeat. Om du skriver något är det bättre att skriva något användbart för affärer. För att leverera stockar är det bättre att ta något färdigt.

Därför kom valet faktiskt ner på valet mellan syslog-ng och rsyslog. Jag lutade mig mot rsyslog helt enkelt för att vi redan hade klasser för rsyslog i Puppet, och jag hittade ingen uppenbar skillnad mellan dem. Vad är syslog, vad är syslog. Ja, vissa har sämre dokumentation, andra har bättre. Den här kan göra det på det här sättet, och den andra kan göra det annorlunda.

Och lite om rsyslog. Först och främst är det coolt eftersom det har många moduler. Det har mänskligt läsbart RainerScript (ett modernt konfigurationsspråk). Det är en fantastisk bonus att vi kunde efterlikna beteendet hos td-agent med standardverktyg, och ingenting förändrades för applikationer. Det vill säga, vi byter td-agent till rsyslog och låter allt annat vara ifred tills vidare. Och vi får omedelbart fungerande leverans. Därefter är mmnormalize en fantastisk sak i rsyslog. Det låter dig analysera loggar, men inte med Grok och regexp. Det gör ett abstrakt syntaxträd. Den analyserar loggar på ungefär samma sätt som en kompilator analyserar källor. Detta gör att du kan arbeta mycket snabbt, förbruka lite CPU, och i allmänhet är det en riktigt cool sak. Det finns en massa andra bonusar. Jag tänker inte uppehålla mig vid dem.

rsyslog har många andra nackdelar. De är ungefär samma som bonusar. De största problemen är att du måste veta hur man lagar den, och du måste välja version.

Vi bestämde att vi skulle skriva loggar till ett unix-uttag. Och inte i /dev/log, för där har vi en röra av systemloggar, journald är i denna pipeline. Så låt oss skriva till ett anpassat uttag. Vi kommer att bifoga det till en separat regeluppsättning. Låt oss inte blanda oss i någonting. Allt kommer att vara transparent och begripligt. Det var precis vad vi gjorde. Katalogen med dessa uttag är standardiserad och vidarebefordras till alla containrar. Behållare kan se uttaget de behöver, öppna och skriva till det.

Varför inte en fil? För alla läser det artikel om Badushechka, som försökte vidarebefordra en fil till docker, och det upptäcktes att efter omstart av rsyslog ändrades filbeskrivningen och docker förlorade den här filen. Det håller något annat öppet, men inte uttaget där de skriver. Vi bestämde oss för att vi skulle lösa det här problemet, och samtidigt skulle vi komma runt blockeringsproblemet.

Rsyslog utför de åtgärder som anges på bilden och skickar loggar till antingen relä eller Kafka. Kafka följer det gamla sättet. Relä - Jag försökte använda ren rsyslog för att leverera loggar. Utan Message Queue, med standardverktyg för rsyslog. I grund och botten fungerar det.

Men det finns nyanser med hur man trycker in dem i den här delen (Logstash/Graylog/ES). Den här delen (rsyslog-rsyslog) används mellan datacenter. Här är en komprimerad tcp-länk, som gör att vi kan spara bandbredd och följaktligen på något sätt öka sannolikheten för att vi kommer att få några loggar från ett annat datacenter när kanalen är igensatt. För vi har Indonesien, där allt är dåligt. Det är här det ständiga problemet ligger.

Vi funderade på hur vi faktiskt kan övervaka hur troligt det är att loggarna vi spelade in från applikationen når slutet? Vi bestämde oss för att skapa mätvärden. rsyslog har en egen statistikinsamlingsmodul, som innehåller någon form av räknare. Den kan till exempel visa dig storleken på kön, eller hur många meddelanden som har kommit i en sådan och en sådan åtgärd. Du kan redan ta något från dem. Dessutom har den anpassade räknare som kan konfigureras, och den visar dig till exempel antalet meddelanden som vissa API registrerade. Därefter skrev jag rsyslog_exporter i Python, och vi skickade allt till Prometheus och byggde grafer. Vi ville verkligen ha Graylog-statistik, men vi har inte hunnit ställa in dem än.

Vilka var problemen? Problem uppstod när vi upptäckte (PLÖTSLIGT!) att våra Live API:er skrev 50 12 meddelanden per sekund. Detta är bara ett Live API utan iscensättning. Och Graylog visar oss bara XNUMX tusen meddelanden per sekund. Och en rimlig fråga uppstod: var finns kvarlevorna? Av vilken vi drog slutsatsen att Graylog helt enkelt inte kan klara sig. Vi tittade, och faktiskt, Graylog och Elasticsearch kunde inte hantera detta flöde.

Därefter andra upptäckter vi gjorde på vägen.

Skriver till uttaget är blockerade. Hur hände det? När jag använde rsyslog för leverans gick kanalen mellan datacentren sönder vid något tillfälle. Leverans stoppades på ett ställe, leverans stoppades på ett annat ställe. Allt detta har nått maskinen med API:er som skriver till rsyslog-socketen. Där var det kö. Sedan fylldes kön för att skriva till unix-socket, som som standard är 128 paket. Och nästa write() i applikationen är blockerad. När vi tittade på biblioteket som vi använder i Go-applikationer skrevs det där att skrivning till socket sker i icke-blockerande läge. Vi var säkra på att ingenting var blockerat. För vi läser artikel om Badushechkasom skrev om det. Men det finns ett ögonblick. Det fanns också en oändlig loop runt detta samtal, där det var ett ständigt försök att trycka in ett meddelande i uttaget. Vi märkte honom inte. Jag var tvungen att skriva om biblioteket. Sedan dess har det ändrats flera gånger, men nu har vi blivit av med blockering i alla delsystem. Därför kan du stoppa rsyslog, och ingenting kommer att krascha.

Det är nödvändigt att övervaka storleken på köerna, vilket hjälper till att undvika att trampa på denna rake. Först kan vi övervaka när vi börjar tappa meddelanden. För det andra kan vi övervaka att vi har problem med leveransen.

Och ett annat obehagligt ögonblick - förstärkning med 10 gånger i en mikrotjänstarkitektur är mycket lätt. Vi har inte många inkommande förfrågningar, men på grund av grafen längs vilken dessa meddelanden färdas längre, på grund av åtkomstloggarna, ökar vi faktiskt loggbelastningen med cirka tio gånger. Tyvärr hade jag inte tid att beräkna de exakta siffrorna, men mikrotjänster är vad de är. Detta måste hållas i åtanke. Det visar sig att för tillfället är delsystemet för insamling av stockar det mest laddade i Lazada.

Hur löser man ett elastiskt sökproblem? Om du snabbt behöver få tag i loggar på ett ställe, för att inte springa runt till alla maskiner och samla dem där, använd fillagring. Detta kommer garanterat att fungera. Det kan göras från vilken server som helst. Du behöver bara fästa diskar där och installera syslog. Efter detta har du garanterat alla stockar på ett ställe. Sedan kan du långsamt konfigurera elasticsearch, graylog och något annat. Men du kommer redan att ha alla loggar, och dessutom kan du lagra dem så långt det finns tillräckligt med diskarrayer.

Vid tidpunkten för min rapport började upplägget se ut så här. Vi slutade praktiskt taget skriva till filen. Nu kommer vi troligen att stänga av resten. På lokala maskiner som kör API:et kommer vi att sluta skriva till filer. För det första finns det fillagring, vilket fungerar mycket bra. För det andra, dessa maskiner får ständigt ont om utrymme, det måste övervakas ständigt.

Den här delen med Logstash och Graylog, det tar verkligen fart. Därför måste vi bli av med det. Du måste välja en sak.

Vi bestämde oss för att kasta ut Logstash och Kibana. För vi har en säkerhetsavdelning. Vilken koppling? Kopplingen är att Kibana utan X-Pack och utan Shield inte tillåter dig att skilja åtkomsträttigheter till loggar. Det var därför vi tog Graylog. Den har allt. Jag gillar det inte, men det fungerar. Vi köpte ny hårdvara, installerade färsk Graylog där och överförde alla loggar med strikta format till en separat Graylog. Vi löste problemet med olika typer av identiska fält organisatoriskt.

Vad exakt ingår i den nya Graylog. Vi skrev precis allt i docker. Vi tog ett gäng servrar, rullade ut tre Kafka-instanser, 7 Graylog-servrar version 2.3 (eftersom vi ville ha Elasticsearch version 5). Allt detta plockades upp under razzior från hårddisken. Vi såg en indexeringshastighet på upp till 100 tusen meddelanden per sekund. Vi såg siffran att 140 terabyte data per vecka.

Och återigen krattan! Vi har två försäljningar på gång. Vi gick över 6 miljoner meddelanden. Graylog har inte tid att tugga. På något sätt måste vi överleva igen.

Så här överlevde vi. Vi har lagt till några fler servrar och SSD:er. Just nu lever vi på det här sättet. Nu tuggar vi redan 160 XNUMX meddelanden per sekund. Vi har inte nått gränsen än, så det är oklart hur mycket vi faktiskt kan få ut av det här.

Det här är våra planer för framtiden. Av dessa är nog den viktigaste hög tillgänglighet. Vi har det inte än. Flera bilar är konfigurerade på samma sätt, men än så länge går allt genom en bil. Det tar tid att ställa in failover mellan dem.

Samla mätvärden från Graylog.

Gör en hastighetsgräns så att vi har ett galet API som inte dödar vår bandbredd och allt annat.

Och slutligen, teckna någon form av SLA med utvecklarna så att vi kan tjäna så mycket. Om du skriver mer så är jag ledsen.

Och skriva dokumentation.

Kortfattat, resultatet av allt vi upplevt. Först, standarder. För det andra är syslog tårta. För det tredje fungerar rsyslog precis som det är skrivet på bilden. Och låt oss gå vidare till frågorna.

frågor.

Fråga: Varför valde du att inte ta... (filebeat?)

Svar: Vi måste skriva till en fil. Jag ville verkligen inte. När ditt API skriver tusentals meddelanden per sekund, även om du roterar det en gång i timmen, är detta fortfarande inte ett alternativ. Du kan skriva i pipe. Till vilket utvecklarna frågade mig: "Vad kommer att hända om processen vi skriver till kraschar?" Jag hittade bara inte vad jag skulle svara dem och sa: "Okej, låt oss inte göra det."

Fråga: Varför skriver du inte bara loggar till HDFS?

Svar: Detta är nästa steg. Vi funderade på det i början, men eftersom det i nuläget inte finns några resurser för att göra detta så hänger det i vår långsiktiga lösning.

Fråga: Kolumnformat skulle vara mer lämpligt.

Svar: Jag förstår. Vi är för det med båda händerna.

Fråga: Du skriver till rsyslog. Där kan du använda både TCP och UDP. Men om UDP, hur garanterar du leverans?

Svar: Det finns två punkter. Först säger jag till alla direkt att vi inte garanterar leverans av stockar. För när utvecklare kommer och säger: "Låt oss börja skriva ekonomisk data där, och du kommer att lägga den någonstans åt oss ifall något händer," svarar vi dem, "Bra! Låt oss börja blockera att skriva till uttaget och göra detta i transaktioner, så att du garanterat kan lägga det på uttaget åt oss och se till att vi tar emot det från andra sidan." Och i det här ögonblicket behöver alla det omedelbart inte längre. Om det inte är nödvändigt, vilka frågor ska vi då ställa? Om du inte vill garantera att du skriver till ett uttag, varför måste vi då garantera leverans? Vi gör vårt bästa. Vi försöker verkligen leverera så mycket som möjligt och på bästa möjliga sätt, men vi ger ingen 100% garanti. Därför finns det inget behov av att skriva ekonomisk data där. Det finns databaser med transaktioner för detta.

Fråga: När API:et genererar något meddelande i loggen och överför kontrollen till mikrotjänster, har du stött på problemet att meddelanden från olika mikrotjänster kommer i fel ordning? Detta orsakar förvirring.

Svar: Det är normalt att de kommer i olika ordningsföljder. Du måste vara beredd på detta. Eftersom någon nätverksleverans inte garanterar ordning, eller så måste du spendera speciella resurser på detta. Om vi ​​tar fillagringar sparar varje API loggar till sin egen fil. Eller rättare sagt, där sorterar rsyslog dem i kataloger. Varje API har sina egna loggar, där du kan gå och titta, och sedan kan du jämföra dem med hjälp av tidsstämpeln i den här loggen. Om de går och letar i Graylog, så sorteras de där efter tidsstämpel. Allt kommer att bli bra där.

Fråga: Tidsstämpeln kan variera med millisekunder.

Svar: Tidsstämpel genereras av själva API:et. Detta är faktiskt hela poängen. Vi har NTP. API:et genererar en tidsstämpel i själva meddelandet. rsyslog lägger inte till det.

Fråga: Interaktionen mellan datacenter är inte särskilt tydlig. Inom datacentret är det tydligt hur loggarna samlades in och bearbetades. Hur sker interaktionen mellan datacenter? Eller lever varje datacenter sitt eget liv?

Svar: Nästan. I vårt land finns varje land i ett datacenter. För tillfället har vi ingen spridning så att ett land ligger i olika datacenter. Därför finns det inget behov av att kombinera dem. Varje center har ett logrelä inuti. Detta är en Rsyslog-server. Egentligen två hanteringsmaskiner. De har samma inställning. Men för tillfället går trafiken bara genom en av dem. Den samlar alla loggar. Hon har en diskkö för säkerhets skull. Den laddar ner loggarna och skickar dem till det centrala datacentret (Singapore), där de sedan skickas till Graylog. Och varje datacenter har sin egen fillagring. Om vår anslutning försvinner har vi alla loggar där. De kommer att vara kvar där. De kommer att förvaras där.

Fråga: Vid onormala situationer, får du loggar därifrån?

Svar: Du kan gå dit (till fillagringen) och titta.

Fråga: Hur övervakar du att du inte tappar loggar?

Svar: Vi tappar faktiskt dem, och vi övervakar det. Övervakning lanserades för en månad sedan. Biblioteket som Go API:er använder har mätvärden. Hon kan räkna hur många gånger hon inte kunde skriva till ett uttag. Det finns för närvarande en smart heuristik där. Det finns en buffert där. Den försöker skriva ett meddelande från den till uttaget. Om bufferten svämmar över börjar den tappa dem. Och han räknar hur många av dem han tappade. Om mätarna börjar svämma över där så får vi veta det. De kommer nu också till prometheus, och du kan se graferna i Grafana. Du kan ställa in varningar. Men det är ännu inte klart till vem man ska skicka dem.

Fråga: I elasticsearch lagrar du stockar med redundans. Hur många kopior har du?

Svar: En linje.

Fråga: Är detta bara en rad?

Svar: Det här är mästaren och repliken. Uppgifterna lagras i två exemplar.

Fråga: Justerade du rsyslog-buffertstorleken på något sätt?

Svar: Vi skriver datagram till en anpassad unix-socket. Detta sätter omedelbart en gräns på 128 kilobyte för oss. Vi kan inte skriva mer till den. Vi har skrivit in detta i standarden. De som vill komma in i lager skriver 128 kilobyte. Bibliotek skärs dessutom av, och en flagga placeras om att meddelandet skärs bort. Vår standard för själva meddelandet har ett specialfält som visar om det klipptes av under inspelningen eller inte. Så vi har möjlighet att spåra detta ögonblick också.

Fråga: Skriver du trasig JSON?

Svar: Trasig JSON kommer att kasseras antingen under relä eftersom paketet är för stort. Eller så kommer Graylog att kasseras eftersom den inte kan analysera JSON. Men det finns nyanser som måste fixas, och de är mestadels knutna till rsyslog. Jag har redan fyllt i flera frågor där, som fortfarande måste bearbetas.

Fråga: Varför Kafka? Har du testat RabbitMQ? Misslyckas Graylog under sådana belastningar?

Svar: Det fungerar inte för oss med Graylog. Och Graylog tar form för oss. Han är verkligen problematisk. Han är en märklig sak. Och det behövs faktiskt inte. Jag skulle föredra att skriva från rsyslog direkt till elasticsearch och sedan titta på Kibana. Men vi måste lösa problemet med säkerhetsvakterna. Detta är ett möjligt alternativ för vår utveckling, när vi kastar ut Graylog och använder Kibana. Det är ingen idé att använda Logstash. För jag kan göra samma sak med rsyslog. Och den har en modul för att skriva till elasticsearch. Vi försöker på något sätt leva med Graylog. Vi justerade till och med lite. Men det finns fortfarande utrymme för förbättringar.

Om Kafka. Så här gick det till historiskt. När jag kom fram var den redan där och loggar skrevs redan till den. Vi höjde helt enkelt vårt kluster och flyttade in stockar i det. Vi är hans ledning, vi vet hur han känner. När det gäller RabbitMQ... det fungerar inte för oss med RabbitMQ. Och RabbitMQ tar form för oss. Vi har den i produktion, och det var problem med den. Nu, innan försäljningen, skulle de charma honom, och han skulle börja arbeta normalt. Men innan dess var jag inte redo att släppa den i produktion. Det finns ytterligare en poäng. Graylog kan läsa version AMQP 0.9 och rsyslog kan skriva version AMQP 1.0. Och det finns inte en enda lösning i mitten som kan göra både och. Det är antingen det ena eller det andra. Därför för tillfället bara Kafka. Men det har också sina egna nyanser. Eftersom omkafka av versionen av rsyslog som vi använder kan förlora hela meddelandebufferten som den rakade ut från rsyslog. För nu står vi ut med det.

Fråga: Använder du Kafka för att du redan hade det? Används inte längre för något syfte?

Svar: Kafka, som var, används av Data Science-teamet. Detta är ett helt separat projekt, som jag tyvärr inte kan säga något om. Jag vet inte. Det drevs av Data Science-teamet. När loggarna skapades bestämde vi oss för att använda dem för att inte installera våra egna. Nu har vi uppdaterat Graylog, och vi har tappat kompatibiliteten eftersom den har en gammal version av Kafka. Vi var tvungna att starta eget. Samtidigt blev vi av med dessa fyra ämnen för varje API. Vi skapade ett brett ämne för alla live, ett brett ämne för alla iscensättningar och satte bara allt där. Graylog skrapar ut allt detta parallellt.

Fråga: Varför behöver vi denna shamanism med uttag? Har du testat att använda syslog-loggdrivrutinen för behållare?

Svar: När vi ställde den här frågan var vårt förhållande till hamnarbetaren spänd. Det var docker 1.0 eller 0.9. Docker själv var konstigt. För det andra, om du också trycker in loggar i den... Jag har en obekräftad misstanke om att den skickar alla loggar genom sig själv, genom docker-demonen. Om ett API blir galet, så har resten av API:erna fastnat i det faktum att de inte kan skicka stdout och stderr. Jag vet inte vart detta kommer att leda. Jag har en misstanke på nivån att jag känner att det inte finns något behov av att använda Docker syslog-drivrutinen på det här stället. Vår funktionstestavdelning har ett eget Graylog-kluster med loggar. De använder Docker log-drivrutiner och allt verkar vara bra där. Men de skriver genast GELF till Graylog. När vi började med allt detta behövde vi bara att det skulle fungera. Kanske senare, när någon kommer och säger att det har fungerat bra i hundra år, så ska vi försöka.

Fråga: Du gör leverans mellan datacenter med rsyslog. Varför inte Kafka?

Svar: Vi gör båda faktiskt. Av två anledningar. Om kanalen är helt död, kommer inte alla våra loggar, även i komprimerad form, att krypa igenom den. Och Kafka låter dig helt enkelt tappa dem i processen. Det är så vi blir av med att dessa stockar fastnar. Vi använder bara Kafka direkt i det här fallet. Om vi ​​har en bra kanal och vill frigöra den så använder vi deras rsyslog. Men i själva verket kan du konfigurera den så att den själv tappar det som inte passade igenom. För närvarande använder vi bara rsyslog-leverans direkt någonstans, och Kafka någonstans.

Källa: will.com