Logboeken zijn een belangrijk onderdeel van het systeem, zodat u kunt begrijpen dat het werkt (of niet werkt) zoals verwacht. Onder de voorwaarden van microservice-architectuur wordt het werken met logs een aparte discipline van de Special Olympiad. Er zijn veel problemen die moeten worden aangepakt:
- hoe logs te schrijven vanuit de applicatie;
- waar logs te schrijven;
- hoe logboeken aan te leveren voor opslag en verwerking;
- hoe logs te verwerken en op te slaan.
Het gebruik van momenteel populaire containerisatietechnologieën voegt zand toe aan de hark op het gebied van probleemoplossende opties.
Zowat dit is het transcript van het rapport van Yuri Bushmelev "Kaart van een hark op het gebied van verzamelen en bezorgen van boomstammen"
Wat maakt het uit, alsjeblieft onder de kat.
Mijn naam is Yuri Bushmelev. Ik werk voor Lazada. Vandaag zal ik het hebben over hoe we onze logboeken hebben gemaakt, hoe we ze hebben verzameld en wat we daar schrijven.
Waar komen we vandaan? Wie zijn we? Lazada is de nummer 1 online retailer in zes landen in Zuidoost-Azië. Al deze landen zijn verdeeld over datacenters. Er zijn nu in totaal 4 datacenters, waarom is dit belangrijk? Omdat sommige beslissingen te wijten waren aan het feit dat er een zeer zwakke schakel is tussen de centra. We hebben een microservice-architectuur. Ik was verrast toen ik ontdekte dat we al 80 microservices hebben. Toen ik de taak met logs begon, waren dat er slechts 20. Bovendien is er een vrij groot stuk PHP-erfenis, waar ik ook mee moet leven. Dit alles genereert voor ons op dit moment meer dan 6 miljoen berichten per minuut voor het systeem als geheel. Verder zal ik laten zien hoe we hiermee proberen te leven, en waarom dit zo is.
Je moet op de een of andere manier met deze 6 miljoen berichten leven. Wat moeten we met ze doen? 6 miljoen berichten nodig:
- stuur vanuit de app
- accepteren voor levering
- leveren voor analyse en opslag.
- analyseren
- op de een of andere manier opslaan.
Toen er drie miljoen berichten waren, had ik ongeveer dezelfde blik. Omdat we begonnen met wat centen. Het is duidelijk dat daar applicatielogboeken worden geschreven. Kan bijvoorbeeld geen verbinding maken met de database, kan wel verbinding maken met de database, maar kan iets niet lezen. Maar daarnaast schrijft elk van onze microservices ook een toegangslogboek. Elk verzoek dat bij de microservice binnenkomt, valt in het logboek. Waarom doen we dit? Ontwikkelaars willen kunnen traceren. Elk toegangslogboek bevat het traceid-veld, volgens welke een speciale interface vervolgens de hele keten afwikkelt en het trace mooi weergeeft. De trace laat zien hoe het verzoek is verlopen, en dit helpt onze ontwikkelaars om onbekende rotzooi sneller te verwerken.
Hoe ermee te leven? Nu zal ik kort het gebied van opties beschrijven - hoe dit probleem in het algemeen wordt opgelost. Hoe het probleem van het verzamelen, overdragen en opslaan van logboeken op te lossen.
Hoe te schrijven vanuit de applicatie? Het is duidelijk dat er verschillende manieren zijn. Er is met name best practice, zoals modieuze kameraden ons vertellen. Er zijn twee soorten oude school, zoals grootvaders zeiden. Er zijn andere manieren.
Met het verzamelen van logboeken is de situatie ongeveer hetzelfde. Er zijn niet zoveel opties om dit specifieke onderdeel op te lossen. Er zijn er meer, maar nog niet zo veel.
Maar met de levering en daaropvolgende analyse begint het aantal variaties te exploderen. Ik zal nu niet elke optie beschrijven. Ik denk dat de belangrijkste opties bekend zijn bij iedereen die geïnteresseerd was in het onderwerp.
Ik zal je laten zien hoe we het bij Lazada hebben gedaan en hoe het allemaal begon.
Een jaar geleden kwam ik naar Lazada en werd naar het logproject gestuurd. Zo was het daar. Het logboek van de applicatie is geschreven naar stdout en stderr. Alles werd op een modieuze manier gedaan. Maar toen gooiden de ontwikkelaars het uit de standaardstreams, en dan komen infrastructuurspecialisten er op de een of andere manier achter. Tussen infrastructuurspecialisten en ontwikkelaars zijn er ook releasers die zeiden: "uh ... nou, laten we ze gewoon in een bestand met een shell wikkelen, en dat is alles." En aangezien dit allemaal in een container zit, wikkelden ze het precies in de container zelf, brachten de directory erin in kaart en plaatsten het daar. Ik denk dat het voor iedereen vrij duidelijk is wat er is gebeurd.
Laten we eens wat verder kijken. Hoe we deze logboeken hebben afgeleverd. Iemand koos td-agent, wat eigenlijk vloeiend is, maar niet helemaal vloeiend. Ik begrijp de relatie tussen deze twee projecten nog steeds niet, maar ze lijken over hetzelfde te gaan. En deze vloeiende, geschreven in Ruby, las logbestanden, ontleedde ze in JSON met behulp van enkele reguliere expressies. Daarna werden ze naar Kafka gestuurd. Bovendien hadden we in Kafka 4 afzonderlijke onderwerpen voor elke API. Waarom 4? Omdat er live is, is er enscenering, en omdat er stdout en stderr zijn. Ontwikkelaars produceren ze en infrastructuurwerkers moeten ze in Kafka maken. Bovendien werd Kafka gecontroleerd door een andere afdeling. Daarom was het nodig om een ticket aan te maken zodat ze daar voor elke api 4 onderwerpen creëerden. Iedereen was het vergeten. Over het algemeen was het afval en afval.
Wat hebben we er vervolgens mee gedaan? We hebben het naar Kafka gestuurd. Verder van Kafka vloog de helft van de boomstammen naar Logstash. De andere helft van de logs werd gedeeld. Sommige vlogen naar een Graylog, sommige naar een andere Graylog. Hierdoor vloog dit alles in één Elasticsearch-cluster. Dat wil zeggen, al deze rotzooi viel uiteindelijk daar. Dat hoeft u niet te doen!
Zo ziet het eruit als je het van bovenaf bekijkt. Dat hoeft u niet te doen! Hier worden de probleemgebieden direct met cijfers gemarkeerd. Er zijn er eigenlijk meer, maar 6 zijn echt problematische, waar iets aan moet gebeuren. Ik zal er nu apart over vertellen.
Hier (1,2,3) schrijven we bestanden en dienovereenkomstig zijn er hier drie harken tegelijk.
De eerste (1) is dat we ze ergens moeten schrijven. Het is niet altijd wenselijk om een API de mogelijkheid te geven om rechtstreeks naar een bestand te schrijven. Het is wenselijk dat de API wordt geïsoleerd in een container, en nog beter, dat deze alleen-lezen is. Ik ben een systeembeheerder, dus ik heb een iets andere kijk op deze dingen.
Het tweede punt (2,3) is dat er veel verzoeken naar de API komen. De API schrijft veel data naar een bestand. De dossiers groeien. We moeten ze draaien. Omdat u anders daar geen schijven kunt opslaan. Ze roteren is slecht omdat ze via de shell naar een map worden omgeleid. We kunnen het op geen enkele manier draaien. U kunt de toepassing niet vertellen de ingangen opnieuw te openen. Omdat de ontwikkelaars je als een dwaas zullen aankijken: “Welke descriptoren? We schrijven over het algemeen naar stdout. De gemaakte copytruncaties van het framework worden omgezet in logrotate, wat gewoon een kopie van het bestand maakt en het origineel bundelt. Dienovereenkomstig raakt de schijfruimte tussen deze kopieerprocessen meestal op.
(4) We hadden verschillende formaten in verschillende API's. Ze waren iets anders, maar regexp moest anders worden geschreven. Omdat het allemaal door Puppet werd beheerd, was er een groot aantal klassen met hun eigen kakkerlakken. Bovendien kon td-agent meestal geheugen opeten, dom zijn, hij kon gewoon doen alsof hij aan het werk was en niets doen. Uiterlijk was het onmogelijk te begrijpen dat hij niets deed. In het beste geval zal hij vallen en zal iemand hem later oppakken. Om precies te zijn, er zal een waarschuwing binnenvliegen en iemand zal het met zijn handen gaan opheffen.
(6) En het meeste afval en afval - het was elastisch zoeken. Omdat het een oude versie was. Omdat we toen nog geen toegewijde meesters hadden. We hadden heterogene logboeken waarvan de velden elkaar konden overlappen. Er kunnen verschillende logboeken van verschillende applicaties worden geschreven met dezelfde veldnamen, maar tegelijkertijd kunnen er verschillende gegevens in staan. Dat wil zeggen, één logboek wordt geleverd met een geheel getal in een veld, bijvoorbeeld niveau. Een ander logboek wordt geleverd met een tekenreeks in het niveauveld. Bij afwezigheid van statische mapping blijkt zoiets geweldigs. Als na indexrotatie een bericht met een string als eerste binnenkwam in elasticsearch, dan leven we normaal. En als de eerste met Integer is aangekomen, worden alle volgende berichten die met String zijn aangekomen gewoon weggegooid. Omdat het veldtype niet overeenkomt.
Met deze vragen zijn we aan de slag gegaan. We besloten niet op zoek te gaan naar de schuldigen.
Maar er moet iets gebeuren! Het ligt voor de hand dat we normen moeten vaststellen. We hadden al enkele normen. Sommige hebben we wat later gebracht. Gelukkig was toen al één log-formaat voor alle API's goedgekeurd. Het is rechtstreeks in de service-interactiestandaarden geschreven. Dienovereenkomstig moeten degenen die logboeken willen ontvangen, deze in dit formaat schrijven. Als iemand geen logs in dit formaat schrijft, kunnen we niets garanderen.
Verder zou ik graag één standaard willen hebben voor de wijze van vastleggen, afleveren en verzamelen van logboeken. Eigenlijk, waar ze te schrijven en hoe ze te bezorgen. De ideale situatie is wanneer projecten dezelfde bibliotheek gebruiken. Er is een aparte logging-bibliotheek voor Go, er is een aparte bibliotheek voor PHP. Iedereen die we hebben, iedereen zou ze moeten gebruiken. Op dit moment zou ik zeggen dat we daarin voor 80 procent slagen. Maar sommigen blijven cactussen eten.
En daar (op de dia) begint de "SLA voor logboekbezorging" nog maar net te verschijnen. Het is er nog niet, maar we werken eraan. Want het is erg handig als infra zegt dat als je in dat en dat formaat naar die en die plek schrijft en niet meer dan N berichten per seconde, dan zullen we het hoogstwaarschijnlijk daar afleveren. Het scheelt een hoop kopzorgen. Als er een SLA is, dan is het gewoon geweldig!
Hoe zijn we begonnen met het oplossen van het probleem? De belangrijkste rake was met td-agent. Het was onduidelijk waar onze logboeken naartoe gaan. Worden ze bezorgd? Gaan ze? Waar zijn ze eigenlijk? Daarom werd besloten om td-agent te vervangen door het eerste item. Opties voor wat het moet vervangen, heb ik hier kort geschetst.
vloeiend Ten eerste kwam ik hem tegen bij een vorige baan, en daar viel hij ook af en toe uit. Ten tweede is dit hetzelfde, alleen in profiel.
filebeat. Hoe was het goed voor ons? Het feit dat hij in Go zit, en we hebben een grote expertise in Go. Dienovereenkomstig zouden we het op de een of andere manier aan onszelf kunnen toevoegen. Daarom hebben we het niet meegenomen. Zodat er niet eens de verleiding zou zijn om het voor jezelf te gaan herschrijven.
De voor de hand liggende oplossing voor de sysadmin is allerlei syslogs in deze hoeveelheid (syslog-ng/rsyslog/nxlog).
Of schrijf zelf iets, maar dat hebben we weggegooid, evenals filebeat. Als u iets schrijft, is het beter om iets nuttigs voor het bedrijfsleven te schrijven. Om logs te bezorgen, is het beter om iets kant-en-klaars te nemen.
Daarom kwam de keuze eigenlijk neer op een keuze tussen syslog-ng en rsyslog. Ik neigde naar rsyslog, simpelweg omdat we al lessen voor rsyslog hadden in Puppet, en ik vond geen duidelijk verschil tussen beide. Wat is syslog, wat is syslog. Ja, sommige documentatie is slechter, sommige beter. Hij kent deze manier, en hij doet het anders.
En een beetje over rsyslog. Ten eerste is het cool omdat het veel modules heeft. Het heeft een door mensen leesbaar RainerScript (moderne configuratietaal). Een geweldige bonus is dat we het gedrag van td-agent konden nabootsen met zijn standaardtools, en er is niets veranderd voor applicaties. Dat wil zeggen, we veranderen td-agent in rsyslog en raken nog niet aan al het andere. En meteen krijgen we een werkende levering. Vervolgens is mmnormalize het leuke van rsyslog. Hiermee kunt u logboeken ontleden, maar niet met Grok en regexp. Het maakt een abstracte syntaxisboom. Het parseert logboeken op ongeveer dezelfde manier als een compiler broncode parseert. Hierdoor kun je heel snel werken, weinig CPU eten, en over het algemeen is het gewoon heel cool. Er zijn nog een heleboel andere bonussen. Ik zal niet bij hen stilstaan.
rsyslog heeft veel meer nadelen. Ze zijn ongeveer hetzelfde als bonussen. De belangrijkste problemen zijn dat je het moet kunnen koken en dat je een versie moet selecteren.
We besloten dat we logs in een Unix-socket zouden schrijven. En niet in /dev/log, want daar hebben we een puinhoop van systeemlogboeken, er zit een journald in deze pijplijn. Laten we dus naar een aangepaste socket schrijven. We voegen het toe aan een aparte regelset. Laten we ons nergens mee bemoeien. Alles zal transparant en begrijpelijk zijn. Dat hebben we dus ook echt gedaan. De directory met deze sockets wordt gestandaardiseerd en doorgestuurd naar alle containers. Containers kunnen de socket zien die ze nodig hebben, openen en ernaar schrijven.
Waarom geen bestand? Want iedereen heeft gelezen , die probeerde het bestand door te sturen naar docker, en ontdekte dat na het herstarten van rsyslog de bestandsdescriptor verandert en dat docker dit bestand verliest. Hij houdt iets anders open, maar niet hetzelfde stopcontact waar ze schrijven. We besloten dat we dit probleem zouden omzeilen en tegelijkertijd het blokkeerprobleem zouden omzeilen.
Rsyslog voert de acties uit die op de dia worden aangegeven en stuurt logboeken naar relay of Kafka. Kafka volgt de oude weg. Rayleigh - Ik heb geprobeerd pure rsyslog te gebruiken om logboeken te bezorgen. Zonder Message Queue, met behulp van standaard rsyslog-tools. In principe werkt het.
Maar er zijn nuances met hoe ze later in dit deel moeten worden gepropt (Logstash/Graylog/ES). Dit deel (rsyslog-rsyslog) wordt gebruikt tussen datacenters. Hier is een gecomprimeerde tcp-link, waarmee u bandbreedte kunt besparen en dienovereenkomstig op de een of andere manier de kans vergroot dat we enkele logs van een ander datacenter ontvangen wanneer het kanaal vol is. Omdat we Indonesië hebben, waar alles slecht is. Dat is waar het constante probleem ligt.
We hebben nagedacht over hoe we eigenlijk monitoren, met welke waarschijnlijkheid bereiken de logs die we van de applicatie hebben opgenomen dat einde? We besloten om te beginnen met metrieken. Rsyslog heeft zijn eigen module voor het verzamelen van statistieken, die een soort tellers heeft. Het kan u bijvoorbeeld de grootte van de wachtrij laten zien, of hoeveel berichten er zijn binnengekomen voor die en die actie. Je kunt al iets van ze aannemen. Bovendien heeft het aangepaste tellers die u kunt configureren, en het toont u bijvoorbeeld het aantal berichten dat een API heeft geregistreerd. Vervolgens schreef ik rsyslog_exporter in Python, en we stuurden het allemaal naar Prometheus en plotten. We wilden echt Graylog-statistieken, maar tot nu toe hebben we geen tijd gehad om ze in te stellen.
Wat zijn de problemen? Het probleem ontstond doordat we er (PLOTSELING!) achter kwamen dat onze Live API's 50 berichten per seconde schrijven. Dit is alleen Live API zonder staging. En Graylog laat ons slechts 12 duizend berichten per seconde zien. En een redelijke vraag rees, waar zijn de overblijfselen? Waaruit we concludeerden dat Graylog het simpelweg niet aankan. We hebben gekeken, en inderdaad, Graylog met Elasticsearch beheerste deze stroom niet.
Vervolgens andere ontdekkingen die we onderweg hebben gedaan.
Schrijft naar socket is geblokkeerd. Hoe is het gebeurd? Toen ik rsyslog gebruikte voor bezorging, hebben we op een gegeven moment het kanaal tussen de datacenters verbroken. De bevalling is op de ene plaats ontstaan, de bevalling is op een andere plaats ontstaan. Dit alles is neergekomen op een machine met API's die naar de rsyslog-socket schrijven. Er stond een rij. Vervolgens liep de wachtrij voor het schrijven naar de unix-socket vol, wat standaard 128 pakketten is. En de volgende write() in de toepassingsblokken. Toen we naar de bibliotheek keken die we gebruiken in Go-applicaties, stond daar geschreven dat schrijven naar de socket plaatsvindt in niet-blokkerende modus. We waren er zeker van dat er niets geblokkeerd was. Omdat we hebben gelezen die erover schreef. Maar er is een moment. Er was ook een oneindige lus rond deze oproep, waarbij constant werd geprobeerd een bericht in de socket te duwen. We hebben hem niet opgemerkt. Ik moest de bibliotheek herschrijven. Sindsdien is het verschillende keren gewijzigd, maar nu hebben we sloten in alle subsystemen verwijderd. Daarom kunt u rsyslog stoppen en niets zal vallen.
Het is noodzakelijk om de grootte van de wachtrijen te bewaken, wat helpt om niet op deze hark te stappen. Ten eerste kunnen we controleren wanneer we berichten beginnen te verliezen. Ten tweede kunnen we monitoren dat we in principe problemen hebben met de bezorging.
En nog een onaangenaam moment - versterking met 10 keer in een microservice-architectuur is heel eenvoudig. We hebben niet zoveel inkomende verzoeken, maar door de grafiek waarlangs deze berichten verder lopen, door de toegangslogs, verhogen we de belasting van de logs eigenlijk met ongeveer tien keer. Helaas had ik geen tijd om de exacte cijfers te berekenen, maar microservices zijn wat ze zijn. Dit moet in gedachten worden gehouden. Het blijkt dat op dit moment het subsysteem voor het verzamelen van logboeken het meest wordt geladen in Lazada.
Hoe het Elasticsearch-probleem op te lossen? Gebruik bestandsopslag als u snel logboeken op één plek wilt ophalen, om niet alle machines te doorlopen en ze daar te verzamelen. Dit werkt gegarandeerd. Het wordt gedaan vanaf elke server. Je hoeft alleen maar schijven daar te plakken en syslog te plaatsen. Daarna heb je gegarandeerd alle logboeken op één plek. Dan is het mogelijk om langzaam elasticsearch, graylog of iets anders te configureren. Maar u hebt al alle logboeken en bovendien kunt u ze opslaan, voor zover schijfarrays voldoende zijn.
Ten tijde van mijn verslag begon het schema er zo uit te zien. We zijn praktisch gestopt met schrijven naar het bestand. Nu zullen we hoogstwaarschijnlijk de overblijfselen uitschakelen. Op lokale machines waarop de API draait, stoppen we met schrijven naar bestanden. Ten eerste is er bestandsopslag, wat erg goed werkt. Ten tweede hebben deze machines constant onvoldoende ruimte, u moet deze constant in de gaten houden.
Dit deel met Logstash en Graylog stijgt echt. Daarom moet u er vanaf komen. Je moet er een kiezen.
We hebben besloten Logstash en Kibana te laten vallen. Omdat we een beveiligingsafdeling hebben. Wat is de connectie? Het verband is dat je met Kibana zonder X-Pack en zonder Shield geen onderscheid kunt maken tussen toegangsrechten tot de logs. Daarom namen ze Graylog mee. Het heeft het allemaal. Ik vind het niet leuk, maar het werkt. We kochten nieuwe hardware, installeerden daar een verse Graylog en verplaatsten alle logs met strikte formaten naar een aparte Graylog. We hebben het probleem met verschillende typen van dezelfde velden organisatorisch opgelost.
Wat zit er precies in de nieuwe Graylog. We hebben zojuist alles in de docker geschreven. We hebben een aantal servers genomen, drie Kafka-instanties uitgerold, 7 Graylog-servers versie 2.3 (omdat ik Elasticsearch versie 5 wilde). Dit alles kwam voort uit invallen vanaf de harde schijf. We zagen een indexeringssnelheid van maximaal 100 berichten per seconde. We zagen het cijfer dat 140 terabytes aan data per week.
En weer een hark! Er komen twee verkopen aan. We zijn verder dan 6 miljoen berichten. Wij Graylog heeft geen tijd om te kauwen. Op de een of andere manier moet je weer zien te overleven.
Zo hebben we het overleefd. Nog een paar servers en SSD's toegevoegd. Op dit moment leven we zo. Nu kauwen we al 160 berichten per seconde. We hebben de limiet nog niet bereikt, dus het is onduidelijk hoeveel we er realistisch uit kunnen halen.
Dit zijn onze plannen voor de toekomst. Hiervan is waarschijnlijk de belangrijkste waarschijnlijk hoge beschikbaarheid. We hebben het nog niet. Meerdere auto's zijn op dezelfde manier ingesteld, maar tot nu toe gaat alles via één auto. Het is noodzakelijk om tijd te besteden aan het opzetten van een failover tussen hen.
Verzamel statistieken van Graylog.
Stel een snelheidslimiet in zodat we één gekke API hebben die ons geen bandbreedte en al het andere kost.
En tot slot, teken een soort SLA met ontwikkelaars zodat we zoveel van dienst kunnen zijn. Als je meer schrijft, sorry.
En schrijf documentatie.
In het kort de resultaten van alles wat we hebben meegemaakt. Eerst de normen. Ten tweede is syslog taart. Ten derde werkt rsyslog precies zoals het op de dia staat. En laten we naar de vragen gaan.
vragen.
Vraag: Waarom hebben ze besloten om ... (filebeat?)
Beantwoorden: Noodzaak om naar een bestand te schrijven. Ik wilde het echt niet. Wanneer je API duizenden berichten per seconde schrijft, zelfs als je één keer per uur rouleert, is dit nog steeds geen optie. Je kunt naar pipe schrijven. Waarop de ontwikkelaars me vroegen: "Wat gebeurt er als het proces waarin we schrijven instort"? Ik vond gewoon niet wat ik ze moest beantwoorden en zei: "Nou, oké, laten we dat niet doen."
Vraag: Waarom schrijf je niet gewoon logs naar HDFS?
BeantwoordenAntwoord: Dit is de volgende stap. We hebben er in het begin over nagedacht, maar aangezien er op dit moment geen middelen zijn om ermee om te gaan, blijft het hangen in onze langetermijnoplossing.
Vraag: Een kolomformaat zou geschikter zijn.
Beantwoorden: Ik begrijp. Wij zijn met beide handen "voor".
Vraag: Je schrijft naar rsyslog. Daar zijn zowel TCP als UDP beschikbaar. Maar als UDP, hoe garandeer je dan de levering?
BeantwoordenA: Er zijn twee punten. Ten eerste vertel ik iedereen meteen dat we de levering van logs niet garanderen. Want als de ontwikkelaars komen zeggen: "Laten we daar financiële gegevens gaan schrijven, en u zult het ergens voor ons bewaren voor het geval er iets gebeurt", antwoorden we hen: "Geweldig! Laten we beginnen met het blokkeren van schrijven naar de socket, en het in transacties doen, zodat u het gegarandeerd voor ons in de socket stopt en ervoor zorgt dat we het van de andere kant ontvangen. En op dit moment wordt iedereen meteen overbodig. En zo niet, welke vragen hebben we dan? Als u een schrijven naar de socket niet wilt garanderen, waarom zouden we dan de levering garanderen? We doen ons uiterste best. We proberen echt zoveel mogelijk en zo goed mogelijk te leveren, maar geven geen 100% garantie. U hoeft daar dus geen financiële gegevens in te schrijven. Hiervoor zijn er transactiedatabases.
Vraag: Wanneer de API een bericht naar het logboek genereert en de controle overdraagt aan microservices, bent u dan het probleem tegengekomen dat berichten van verschillende microservices in de verkeerde volgorde aankomen? Hierdoor ontstaat er verwarring.
BeantwoordenA: Het is normaal dat ze in een andere volgorde komen. Je moet hier klaar voor zijn. Omdat elke netwerklevering geen garantie voor u is, of u moet hier speciale middelen aan besteden. Als we bestandsopslag nemen, slaat elke API logboeken op in zijn eigen bestand. Integendeel, rsyslog ontleedt ze daar in mappen. Elke API heeft daar zijn eigen logs, waar je naartoe kunt gaan kijken, en dan kun je ze vergelijken aan de hand van de tijdstempel in deze log. Als ze in Graylog gaan kijken, dan worden ze daar gesorteerd op tijdstempel. Alles komt goed daar.
Vraag: Tijdstempel kan per milliseconde verschillen.
Beantwoorden: De tijdstempel wordt gegenereerd door de API zelf. Dit is in feite het hele punt. We hebben NTP. De API genereert al een tijdstempel in het bericht zelf. Het wordt niet toegevoegd door rsyslog.
Vraag: Interactie tussen datacenters is niet erg duidelijk. Binnen de kaders van het datacenter is duidelijk hoe de logs zijn verzameld en verwerkt. Hoe is de interactie tussen datacenters? Of leidt elk datacenter zijn eigen leven?
Beantwoorden: Bijna. We hebben elk land in één datacenter. We hebben momenteel geen spreiding zodat één land in verschillende datacenters wordt geplaatst. Daarom is het niet nodig om ze te combineren. Binnen elk centrum is er een Log Relay. Dit is een Rsyslog-server. In feite twee beheermachines. Ze zijn op dezelfde manier ingesteld. Maar voorlopig gaat het verkeer gewoon door een van hen. Ze logt alles aggregaten. Het heeft een schijfwachtrij voor het geval dat. Ze perst de logs en stuurt ze naar het centrale datacentrum (Singapore), waar ze verder al vergiftigd zijn in Graylog. En elk datacenter heeft zijn eigen bestandsopslag. Voor het geval we de verbinding hebben verloren, hebben we daar alle logboeken. Ze zullen daar blijven. Daar worden ze opgeslagen.
Vraag: Krijg je daar logboeken van tijdens abnormale situaties?
Beantwoorden: Je kunt daar naar toe gaan (naar de bestandsopslag) en kijken.
Vraag: Hoe zorg je ervoor dat je geen logs kwijtraakt?
Beantwoorden: We zijn ze eigenlijk aan het verliezen, en we houden het in de gaten. De monitoring is een maand geleden gestart. De bibliotheek die de Go-API's gebruiken, heeft metrische gegevens. Ze kan tellen hoe vaak ze niet naar socket heeft geschreven. Er is op dit moment een lastige heuristiek. Er is daar een buffer. Het probeert een bericht naar de socket te schrijven. Als de buffer overstroomt, begint het ze te laten vallen. En hij telt hoeveel hij ze liet vallen. Als de tellers daar overlopen, weten we het. Die komen nu ook naar prometheus, en je ziet de grafieken in Grafana. U kunt waarschuwingen instellen. Maar het is nog niet duidelijk naar wie ze moeten worden gestuurd.
Vraag: In Elasticsearch slaat u logboeken op met redundantie. Hoeveel replica's heb je?
Beantwoorden: Een replica.
Vraag: Is het maar één regel?
Beantwoorden: Dit is de master en replica. De gegevens worden in tweevoud opgeslagen.
Vraag: Heb je de grootte van de rsyslog-buffer op de een of andere manier aangepast?
Beantwoorden: We schrijven datagrammen naar een aangepaste Unix-socket. Dit legt ons meteen een beperking op van 128 kilobyte. Meer kunnen we er niet in schrijven. We hebben dit in de norm geschreven. Wie in de opslag wil komen, schrijft 128 kilobyte. Bibliotheken kappen bovendien af en zetten een vlaggetje dat de boodschap afkapt. We hebben een speciaal veld in de standaard van het bericht zelf, dat aangeeft of het tijdens de opname is afgebroken of niet. Dus we hebben de mogelijkheid om dit moment te volgen.
Vraag: Schrijf je gebroken JSON?
Beantwoorden: Broken JSON wordt tijdens de relay weggegooid omdat het pakket te groot is. Of Graylog wordt verwijderd, omdat het JSON niet kan parseren. Maar er zijn hier nuances die moeten worden opgelost, en deze zijn meestal gekoppeld aan rsyslog. Ik heb daar al een aantal zaken ingevuld waar nog aan gewerkt moet worden.
Vraag: Waarom Kafka? Heb je RabbitMQ geprobeerd? Graylog klopt niet onder dergelijke belastingen?
Beantwoorden: Het lukt niet met Graylog. En Graylog krijgt vorm. Het is echt problematisch voor hem. Hij is een ding. En eigenlijk is het niet nodig. Ik schrijf liever rechtstreeks vanuit rsyslog naar elasticsearch en kijk dan naar Kibana. Maar we moeten het probleem oplossen met de bewakers. Dit is een mogelijke variant van onze ontwikkeling wanneer we Graylog weggooien en Kibana gebruiken. Logstash heeft geen zin. Omdat ik hetzelfde kan doen met rsyslog. En het heeft een module om naar elasticsearch te schrijven. Met Graylog proberen we op de een of andere manier te leven. We hebben het zelfs een beetje aangepast. Maar er is nog ruimte voor verbetering.
Over Kafka. Zo is het historisch gegaan. Toen ik aankwam, was het er al en werden er al logboeken naar geschreven. We hebben zojuist ons cluster verhoogd en logs erin verplaatst. We managen hem, we weten hoe hij zich voelt. Wat betreft RabbitMQ... we hebben problemen met RabbitMQ. En RabbitMQ ontwikkelt voor ons. We hebben het in productie en er waren problemen mee. Nu, vóór de verkoop, zou hij worden gesjamaniseerd en zou hij normaal beginnen te werken. Maar daarvoor was ik nog niet klaar om het in productie te nemen. Er is nog een punt. Graylog kan AMQP 0.9-versie lezen en rsyslog kan AMQP 1.0-versie schrijven. En er is geen enkele oplossing die beide in het midden kan doen. Er is het een of het ander. Dus voorlopig alleen Kafka. Maar er zijn ook nuances. Omdat omkafka van de versie van rsyslog die we gebruiken, de volledige berichtenbuffer kan verliezen die het uit rsyslog heeft gehaald. Zolang we het er maar mee eens zijn.
Vraag: Gebruik je Kafka omdat je het had? Niet voor een ander doel gebruikt?
Beantwoorden: Kafka, dat werd gebruikt door het Data Science-team. Dit is een volledig apart project, waarover ik helaas niets kan zeggen. Ik weet het niet. Ze werd geleid door het Data Science-team. Toen de logs begonnen, besloten ze het te gebruiken, om niet hun eigen logs te plaatsen. Nu hebben we Graylog bijgewerkt en zijn we de compatibiliteit kwijtgeraakt, omdat er een oude versie van Kafka is. We moesten het zelf maken. Tegelijkertijd hebben we deze vier onderwerpen voor elke API verwijderd. We hebben één wijde top gemaakt voor alle live optredens, één wijde wijde top voor alle ensceneringen en we schieten alles gewoon daar. Graylog haalt dit er allemaal parallel uit.
Vraag: Waarom hebben we dit sjamanisme met stopcontacten nodig? Heb je geprobeerd de syslog-logdriver voor containers te gebruiken?
Beantwoorden: Op het moment dat we deze vraag stelden, hadden we een gespannen relatie met de havenarbeider. Het was docker 1.0 of 0.9. Docker zelf was raar. Ten tweede, als je er ook logs in schuift ... heb ik een niet-geverifieerd vermoeden dat het alle logs zelf doorgeeft, via de docker-daemon. Als we een API hebben die gek wordt, zullen de rest van de API's tegen het feit aanlopen dat ze stdout en stderr niet kunnen verzenden. Ik weet niet waar dit toe zal leiden. Ik heb een vermoeden op het niveau van het gevoel dat het niet nodig is om de docker syslog-driver op deze plek te gebruiken. Onze afdeling functioneel testen heeft een eigen Graylog-cluster met logs. Ze gebruiken docker-logstuurprogramma's en alles lijkt daar in orde te zijn. Maar ze schrijven meteen GELF naar Graylog. Op het moment dat we hiermee begonnen, hadden we het nodig om gewoon te werken. Misschien later, als iemand komt en zegt dat het al honderd jaar normaal werkt, zullen we het proberen.
Vraag: U levert tussen datacenters met behulp van rsyslog. Waarom niet op Kafka?
Beantwoorden: We doen dit, en zo is het echt. Om twee redenen. Als het kanaal helemaal dood is, zullen al onze boomstammen, zelfs in gecomprimeerde vorm, er niet doorheen klimmen. En kafka stelt hen in staat om gewoon te verliezen in het proces. Op deze manier komen we van het vastplakken van deze boomstammen af. We gebruiken Kafka in dit geval gewoon rechtstreeks. Als we een goed kanaal hebben en het willen vrijmaken, dan gebruiken we hun rsyslog. Maar in feite kun je het zo instellen dat het laat vallen wat het niet heeft doorstaan. Op dit moment gebruiken we rsyslog-bezorging gewoon ergens, ergens Kafka.
Bron: www.habr.com