Lokit ovat tärkeä osa järjestelmää, joten voit ymmärtää, että se toimii (tai ei toimi) odotetulla tavalla. Mikropalveluarkkitehtuurin olosuhteissa tukkien kanssa työskentelemisestä tulee Special Olympiadin erillinen tieteenala. On monia asioita, jotka on ratkaistava:
- kuinka kirjoittaa lokeja sovelluksesta;
- missä lokit kirjoitetaan;
- kuinka lokit toimitetaan varastointia ja käsittelyä varten;
- kuinka käsitellä ja tallentaa lokeja.
Tällä hetkellä suosittujen konttiteknologian käyttö lisää hiekkaa haravan päälle ongelmanratkaisuvaihtoehtojen alalla.
Juuri tästä on selostus Juri Bushmelevin raportista "Kartta haravoista tukkien keräämisen ja toimituksen alalla"
Ketä kiinnostaa, ota kissan alle.
Nimeni on Juri Bushmelev. Olen töissä Lazadalle. Tänään puhun siitä, kuinka teimme lokit, kuinka keräsimme ne ja mitä sinne kirjoitamme.
Mistä olemme kotoisin? Keitä me olemme? Lazada on suurin verkkokauppias kuudessa Kaakkois-Aasian maassa. Kaikki nämä maat on jaettu datakeskusten kesken. Palvelinkeskuksia on nyt yhteensä 1. Miksi tämä on tärkeää? Koska jotkut päätökset johtuivat siitä, että keskusten välillä on erittäin heikko yhteys. Meillä on mikropalveluarkkitehtuuri. Olin yllättynyt huomatessani, että meillä on jo 4 mikropalvelua. Kun aloitin tehtävän lokeilla, niitä oli vain 80. Lisäksi on melko suuri pala PHP-perintöä, jonka kanssa minun on myös elettävä ja siedettävä. Kaikki tämä tuottaa meille tällä hetkellä yli 20 miljoonaa viestiä minuutissa koko järjestelmälle. Lisäksi näytän, kuinka yritämme elää tämän kanssa ja miksi näin on.
Sinun täytyy jotenkin elää näiden 6 miljoonan viestin kanssa. Mitä meidän pitäisi tehdä niille? Tarvitaan 6 miljoonaa viestiä:
- lähetä sovelluksesta
- hyväksyä toimitettavaksi
- toimittaa analysointia ja varastointia varten.
- analysoida
- tallentaa jotenkin.
Kun oli kolme miljoonaa viestiä, minulla oli suunnilleen sama ilme. Koska aloitimme penneillä. On selvää, että sinne kirjoitetaan sovelluslokit. Esimerkiksi ei voinut muodostaa yhteyttä tietokantaan, pystyi muodostamaan yhteyttä tietokantaan, mutta ei voinut lukea jotain. Mutta tämän lisäksi jokainen mikropalvelumme kirjoittaa myös pääsylokin. Jokainen mikropalveluun saapuva pyyntö putoaa lokiin. Miksi teemme näin? Kehittäjät haluavat pystyä jäljittämään. Jokainen pääsyloki sisältää traceid-kentän, jonka mukaan erityinen käyttöliittymä purkaa koko ketjun ja näyttää jäljen kauniisti. Jäljitys näyttää, kuinka pyyntö meni, ja tämä auttaa kehittäjiämme käsittelemään tuntematonta roskaa nopeammin.
Kuinka elää sen kanssa? Nyt kuvailen lyhyesti vaihtoehtojen kenttää - kuinka tämä ongelma yleensä ratkaistaan. Kuinka ratkaista lokien keräämisen, siirtämisen ja varastoinnin ongelma.
Kuinka kirjoittaa sovelluksesta? On selvää, että tapoja on erilaisia. Erityisesti on olemassa parhaat käytännöt, kuten muodikkaat toverit kertovat meille. Vanhaa koulua on kahdenlaisia, kuten isoisät sanoivat. On muitakin tapoja.
Tukkien keräämisen kanssa tilanne on suunnilleen sama. Tämän osan ratkaisemiseksi ei ole niin monia vaihtoehtoja. Niitä on enemmän, mutta ei vielä niin paljon.
Mutta toimituksen ja myöhemmän analyysin myötä muunnelmien määrä alkaa kasvaa räjähdysmäisesti. En kuvaile nyt jokaista vaihtoehtoa. Luulen, että tärkeimmät vaihtoehdot ovat kaikkien aiheesta kiinnostuneiden tiedossa.
Näytän sinulle, kuinka teimme sen Lazadassa ja kuinka kaikki alkoi.
Vuosi sitten tulin Lazadaan ja minut lähetettiin hirsiprojektiin. Siellä oli näin. Sovelluksen loki kirjoitettiin stdout- ja stderr-tiedostoihin. Kaikki tehtiin muodikkaalla tavalla. Mutta sitten kehittäjät heittivät sen pois tavallisista virroista, ja sitten infrastruktuuriasiantuntijat selvittävät sen jotenkin. Infrastruktuuriasiantuntijoiden ja kehittäjien välillä on myös julkaisijoita, jotka sanoivat: "No, kääritään ne tiedostoon, jossa on kuori, ja siinä kaikki." Ja koska tämä kaikki on säiliössä, he käärivät sen suoraan säiliöön, kartoittivat sen sisällä olevan hakemiston ja laittoivat sen sinne. Luulen, että kaikille on aika selvää, mitä tapahtui.
Katsotaanpa hieman pidemmälle. Kuinka toimitimme nämä lokit. Joku valitsi td-agentin, joka on itse asiassa sujuvaa, mutta ei aivan sujuvaa. En vieläkään ymmärrä näiden kahden projektin suhdetta, mutta ne näyttävät olevan sama asia. Ja tämä fluentd, joka on kirjoitettu Rubylla, luki lokitiedostoja, jäsensi ne JSONiksi käyttämällä joitain säännöllisiä lausekkeita. Sitten heidät lähetettiin Kafkaan. Lisäksi Kafkassa meillä oli 4 erillistä aihetta jokaiselle API:lle. Miksi 4? Koska on liveä, on lavastusta ja koska on stdout ja stderr. Kehittäjät tuottavat ne, ja infrastruktuurityöntekijöiden on luotava ne Kafkassa. Lisäksi Kafkaa hallitsi toinen osasto. Siksi oli tarpeen luoda lippu niin, että he loivat sinne 4 aihetta jokaiselle apille. Kaikki unohtivat sen. Yleensä se oli roskaa ja jätettä.
Mitä teimme sen kanssa seuraavaksi? Lähetimme sen kafkalle. Kauempana Kafkasta puolet tukista lensi Logstashiin. Toinen puolet lokeista jaettiin. Jotkut lensivät yhdelle Graylogille, jotkut toiselle Graylogille. Tämän seurauksena kaikki tämä lensi yhteen Elasticsearch-klusteriin. Eli kaikki tämä sotku putosi lopulta sinne. Sinun ei tarvitse tehdä sitä!
Tältä se näyttää ylhäältä katsottuna. Sinun ei tarvitse tehdä sitä! Täällä ongelma-alueet on merkitty välittömästi numeroilla. Niitä on itse asiassa enemmänkin, mutta 6 on todella ongelmallisia, joille on tehtävä jotain. Kerron niistä nyt erikseen.
Täällä (1,2,3) kirjoitamme tiedostoja ja vastaavasti täällä on kolme rakea kerralla.
Ensimmäinen (1) on, että meidän on kirjoitettava ne jonnekin. Ei ole aina toivottavaa antaa API:lle kykyä kirjoittaa suoraan tiedostoon. On toivottavaa, että API on eristetty säilössä, ja vielä parempi, että se on vain luku -tilassa. Olen järjestelmänvalvoja, joten minulla on hieman vaihtoehtoinen näkemys näistä asioista.
Toinen kohta (2,3) on, että API:lle tulee paljon pyyntöjä. API kirjoittaa tiedostoon paljon dataa. Tiedostot kasvavat. Meidän on käännettävä niitä. Koska muuten et voi tallentaa levyjä sinne. Niiden kiertäminen on huonoa, koska ne ohjataan komentotulkin kautta hakemistoon. Emme voi mitenkään kiertää sitä. Et voi käskeä sovellusta avaamaan kahvoja uudelleen. Koska kehittäjät katsovat sinua kuin hölmöä: "Mitä kuvauksia? Yleensä kirjoitamme stdoutille. Viitekehykset, jotka on tehty copytruncate logrotateksi, tekee vain kopion tiedostosta ja tyhjentää alkuperäisen. Näin ollen näiden kopiointiprosessien välillä levytila yleensä loppuu.
(4) Meillä oli eri formaatteja eri sovellusliittymissä. Ne olivat hieman erilaisia, mutta regexp oli kirjoitettava eri tavalla. Koska kaikkea hallinnoi Puppet, siellä oli iso joukko luokkia omilla torakoillaan. Lisäksi td-agentti saattoi suurimman osan ajasta syödä muistia, olla tyhmä, hän saattoi vain teeskennellä tekevänsä töitä eikä tehdä mitään. Ulkoisesti oli mahdotonta ymmärtää, ettei hän tehnyt mitään. Parhaimmillaan hän kaatuu, ja joku hakee hänet myöhemmin. Tarkemmin sanottuna hälytys lentää sisään, ja joku menee ja nostaa sen käsillään.
(6) Ja eniten roskaa ja jätettä - se oli elasticsearch. Koska se oli vanha versio. Koska meillä ei tuolloin ollut omistautuneita mestareita. Meillä oli heterogeenisiä tukkeja, joiden kentät saattoivat mennä päällekkäin. Eri sovellusten eri lokeja voitaisiin kirjoittaa samoilla kenttien nimillä, mutta samalla sisällä voi olla erilaisia tietoja. Eli yhden lokin mukana tulee kokonaisluku kentässä, esimerkiksi tasolla. Toisessa lokissa on merkkijono tasokentässä. Staattisen kartoituksen puuttuessa niin upea asia osoittautuu. Jos indeksikierron jälkeen elasticsearchissa saapui ensin viesti, jossa on merkkijono, niin elämme normaalisti. Ja jos ensimmäinen saapui kokonaisluvulla, kaikki seuraavat viestit, jotka saapuivat merkkijonolla, yksinkertaisesti hylätään. Koska kentän tyyppi ei täsmää.
Aloimme kysyä näitä kysymyksiä. Päätimme olla etsimättä syyllisiä.
Mutta jotain on tehtävä! On selvää, että meidän on laadittava standardit. Meillä oli jo joitakin standardeja. Jotkut toimme vähän myöhemmin. Onneksi yksi lokimuoto kaikille API:lle hyväksyttiin jo tuolloin. Se on kirjoitettu suoraan palvelun vuorovaikutusstandardeihin. Näin ollen niiden, jotka haluavat vastaanottaa lokeja, tulee kirjoittaa ne tässä muodossa. Jos joku ei kirjoita lokeja tässä muodossa, emme takaa mitään.
Lisäksi haluaisin yhtenäisen standardin lokien kirjaamis-, toimitus- ja keräysmenetelmille. Itse asiassa, minne ne kirjoitetaan ja miten ne toimitetaan. Ihanteellinen tilanne on, kun projektit käyttävät samaa kirjastoa. Go:lle on erillinen lokikirjasto, PHP:lle on erillinen kirjasto. Kaikki, jotka meillä on, kaikkien pitäisi käyttää niitä. Tällä hetkellä sanoisin, että onnistumme 80 prosentilla. Mutta jotkut jatkavat kaktuksen syömistä.
Ja siellä (dialla) "SLA lokin toimittamiselle" alkaa tuskin ilmestyä. Se ei ole vielä siellä, mutta työskentelemme sen eteen. Koska se on erittäin kätevää, kun infra sanoo, että jos kirjoitat sellaisessa ja sellaisessa muodossa sellaiseen paikkaan ja enintään N viestiä sekunnissa, niin me todennäköisesti toimitamme sen sinne. Se poistaa paljon päänsärkyä. Jos SLA on olemassa, se on hienoa!
Miten aloimme ratkaisemaan ongelmaa? Päärake oli td-agentilla. Oli epäselvää, minne lokimme menevät. Toimitetaanko ne? Menevätkö he? Missä he muuten ovat? Siksi päätettiin korvata td-agent ensimmäisellä kohteella. Esittelin tässä lyhyesti vaihtoehtoja, millä se korvataan.
Fluentd. Ensinnäkin tapasin hänet aiemmassa työpaikassa, ja hän myös kaatui silloin tällöin. Toiseksi, tämä on sama, vain profiilissa.
filebeat. Miten se oli meille hyväksi? Se, että hän on Gossa, ja meillä on hyvä asiantuntemus Gosta. Näin ollen, jos mitään, voisimme jotenkin lisätä sen itseemme. Siksi emme ottaneet sitä. Jotta ei olisi kiusausta alkaa kirjoittaa sitä uudelleen itse.
Ilmeinen ratkaisu sysadminille on kaikenlaisia syslogeja tässä määrässä (syslog-ng/rsyslog/nxlog).
Tai kirjoita jotain omaa, mutta hylkäsimme sen, samoin kuin filebeatin. Jos kirjoitat jotain, on parempi kirjoittaa jotain hyödyllistä liiketoiminnalle. Tukkien toimittamiseksi on parempi ottaa jotain valmista.
Siksi valinta johtui itse asiassa valinnasta syslog-ng:n ja rsyslogin välillä. Nojauduin rsyslogiin yksinkertaisesti siksi, että meillä oli jo rsyslog-luokat Puppetissa, enkä löytänyt selvää eroa niiden välillä. Mikä on syslog, mikä on syslog. Kyllä, osa dokumentaatiosta on huonompaa, osa parempi. Hän tietää tämän tavan, ja hän tekee sen eri tavalla.
Ja vähän rsyslogista. Ensinnäkin se on siistiä, koska siinä on paljon moduuleja. Siinä on ihmisen luettavissa oleva RainerScript (moderni määrityskieli). Mahtava bonus on, että pystyimme jäljittelemään td-agentin käyttäytymistä sen vakiotyökaluilla, eikä mikään ole muuttunut sovelluksissa. Eli vaihdamme td-agentiksi rsyslogiksi, emmekä koske vielä kaikkeen muuhun. Ja heti saamme toimivan toimituksen. Seuraavaksi mmnormalize on hieno asia rsyslogissa. Sen avulla voit jäsentää lokeja, mutta ei Grokin ja regexpin avulla. Se tekee abstraktin syntaksipuun. Se jäsentää lokit samalla tavalla kuin kääntäjä jäsentää lähdekoodia. Tämän avulla voit työskennellä erittäin nopeasti, syödä vähän prosessoria, ja yleensä se on vain erittäin siistiä. Muitakin bonuksia on tarjolla. En aio käsitellä niitä.
rsyslogissa on paljon enemmän haittoja. Ne ovat suunnilleen samat kuin bonukset. Tärkeimmät ongelmat ovat, että sinun on kyettävä valmistamaan se ja sinun on valittava versio.
Päätimme kirjoittaa lokit unix-pistorasiaan. Eikä tiedostossa /dev/log, koska siellä on järjestelmälokit sotku, tässä liukuhihnassa on päiväkirja. Joten kirjoitetaan mukautettuun pistorasiaan. Liitämme sen erilliseen sääntökokoelmaan. Älkäämme puuttuko mihinkään. Kaikki tulee olemaan läpinäkyvää ja ymmärrettävää. Joten teimme itse asiassa. Hakemisto näillä pistokkeilla on standardoitu ja välitetty kaikkiin kontteihin. Säiliöt voivat nähdä tarvitsemansa pistorasian, avata ja kirjoittaa siihen.
Miksei tiedosto? Koska kaikki ovat lukeneet , joka yritti lähettää tiedoston edelleen Dockeriin ja havaitsi, että rsyslogin uudelleenkäynnistyksen jälkeen tiedostokuvaaja muuttuu ja docker menettää tämän tiedoston. Hän pitää auki jotain muuta, mutta ei samaa pistorasiaa, johon he kirjoittavat. Päätimme ohittaa tämän ongelman ja samalla ohittaa esto-ongelman.
Rsyslog tekee dialla ilmoitetut toiminnot ja lähettää lokit joko releelle tai Kafkaan. Kafka noudattaa vanhaa tapaa. Rayleigh - Yritin käyttää puhdasta rsyslogia lokien toimittamiseen. Ilman viestijonoa, käyttämällä tavallisia rsyslog-työkaluja. Periaatteessa se toimii.
Mutta on vivahteita, miten ne voidaan täyttää myöhemmin tähän osaan (Logstash/Graylog/ES). Tätä osaa (rsyslog-rsyslog) käytetään tietokeskusten välillä. Tässä on pakattu tcp-linkki, jonka avulla voit säästää kaistanleveyttä ja vastaavasti jotenkin lisätä todennäköisyyttä, että saamme joitain lokeja toisesta datakeskuksesta, kun kanava on täynnä. Koska meillä on Indonesia, jossa kaikki on huonosti. Siellä se jatkuva ongelma piilee.
Mietimme, kuinka me itse valvomme, millä todennäköisyydellä sovelluksesta tallentamamme lokit päätyvät siihen? Päätimme aloittaa mittaukset. Rsyslogissa on oma tilastonkeräysmoduuli, jossa on jonkinlaiset laskurit. Se voi esimerkiksi näyttää sinulle jonon koon tai kuinka monta viestiä saapui kyseisestä tai sellaisesta toiminnosta. Niistä voi jo ottaa jotain. Lisäksi siinä on mukautettuja laskureita, jotka voit määrittää, ja se näyttää esimerkiksi jonkin API:n tallentamien viestien määrän. Seuraavaksi kirjoitin Pythonissa rsyslog_exporter, lähetimme sen Prometheukselle ja piirsimme piirustuksen. Halusimme todella Graylog-mittareita, mutta toistaiseksi emme ole ehtineet asettaa niitä.
Mitkä ovat ongelmat? Ongelma syntyi siitä tosiasiasta, että saimme tietää (YHTÄKIIN!), että live-sovellusliittymämme kirjoittavat 50 12 viestiä sekunnissa. Tämä on vain Live API ilman lavastusta. Ja Graylog näyttää meille vain XNUMX tuhatta viestiä sekunnissa. Ja heräsi järkevä kysymys, missä ovat jäänteet? Mistä päättelimme, että Graylog ei yksinkertaisesti voi selviytyä. Katsoimme, ja todellakin, Graylog ja Elasticsearch ei hallitse tätä virtausta.
Seuraavaksi muita löytöjä, joita olemme tehneet matkan varrella.
Kirjoitukset pistorasiaan on estetty. Miten se tapahtui? Kun käytin toimitukseen rsyslogia, katkesimme jossain vaiheessa kanavan datakeskusten välillä. Toimitus nousi yhteen paikkaan, toimitus nousi toiseen paikkaan. Kaikki tämä on johtanut koneeseen, jossa on API:t, jotka kirjoittavat rsyslog-pistorasiaan. Siellä oli jono. Sitten jono unix-sockettiin kirjoittamista varten täyttyi, joka oletuksena on 128 pakettia. Ja seuraava kirjoitus() sovelluslohkoissa. Kun katsoimme Go-sovelluksissa käyttämäämme kirjastoa, siellä kirjoitettiin, että socketiin kirjoittaminen tapahtuu estotilassa. Olimme varmoja, ettei mikään ollut estetty. Koska olemme lukeneet kuka siitä kirjoitti. Mutta on hetki. Tämän puhelun ympärillä oli myös ääretön silmukka, jossa yritettiin jatkuvasti työntää viestiä pistorasiaan. Emme huomanneet häntä. Minun piti kirjoittaa kirjasto uudelleen. Sittemmin se on muuttunut useita kertoja, mutta nyt olemme päässeet eroon lukoista kaikissa alajärjestelmissä. Siksi voit pysäyttää rsyslogin ja mikään ei putoa.
On tarpeen seurata jonojen kokoa, mikä auttaa olemaan astumatta tämän haravan päälle. Ensinnäkin voimme seurata, milloin alamme kadota viestejä. Toiseksi voimme valvoa, että meillä on periaatteessa ongelmia toimituksen kanssa.
Ja toinen epämiellyttävä hetki - 10-kertainen vahvistus mikropalveluarkkitehtuurissa on erittäin helppoa. Meillä ei ole niin paljon saapuvia pyyntöjä, mutta kaavion vuoksi, jota pitkin nämä viestit kulkevat pidemmälle, pääsylokien vuoksi lisäämme lokien kuormitusta noin kymmenen kertaa. Valitettavasti en ehtinyt laskea tarkkoja lukuja, mutta mikropalvelut ovat mitä ne ovat. Tämä on pidettävä mielessä. Osoittautuu, että tällä hetkellä lokinkeruualijärjestelmä on Lazadan kuormitetuin.
Kuinka ratkaista elasticchearch-ongelma? Jos haluat saada lokit nopeasti yhdestä paikasta, jotta et joutuisi kaikkien koneiden yli ja kerää niitä sinne, käytä tiedostojen tallennustilaa. Tämä taatusti toimii. Se tehdään mistä tahansa palvelimesta. Sinun tarvitsee vain kiinnittää levyt sinne ja laittaa syslog. Sen jälkeen sinulla on taatusti kaikki lokit yhdessä paikassa. Sitten on mahdollista määrittää hitaasti elasticsearch, graylog tai jotain muuta. Mutta sinulla on jo kaikki lokit, ja lisäksi voit tallentaa ne, mikäli levyryhmiä on tarpeeksi.
Raporttini aikaan suunnitelma alkoi näyttää tältä. Käytännössä lopetimme tiedostoon kirjoittamisen. Nyt todennäköisesti sammutamme jäännökset. Paikallisissa koneissa, joissa on API, lopetamme tiedostoihin kirjoittamisen. Ensinnäkin on tiedostojen tallennus, joka toimii erittäin hyvin. Toiseksi, näiden laitteiden tila loppuu jatkuvasti, sinun on seurattava sitä jatkuvasti.
Tämä osa, jossa on Logstash ja Graylog, todella kohoaa. Siksi sinun on päästävä siitä eroon. Sinun on valittava yksi.
Päätimme jättää Logstash ja Kibana. Koska meillä on turvallisuusosasto. Mikä on yhteys? Yhteys on siinä, että Kibana ilman X-Packia ja ilman Shieldia ei salli erilaista pääsyoikeuksia lokeihin. Siksi he ottivat Graylogin. Siinä on kaikki. En pidä siitä, mutta se toimii. Ostimme uuden laitteiston, asensimme sinne tuoreen Graylogin ja siirsimme kaikki tiukat lokit erilliseen Graylogiin. Olemme ratkaisseet ongelman erityyppisillä samoilla aloilla organisatorisesti.
Mitä uudessa Graylogissa tarkalleen ottaen on. Kirjoitimme juuri kaiken telakointiasemaan. Otimme joukon palvelimia, otimme käyttöön kolme Kafka-instanssia, 7 Graylog-palvelinta version 2.3 (koska halusin Elasticsearchin version 5). Kaikki tämä nousi esille kiintolevyltä tulleissa raidoissa. Näimme indeksointinopeuden jopa 100 140 viestiä sekunnissa. Näimme luvun, että XNUMX teratavua dataa viikossa.
Ja taas harava! Meillä on kaksi myyntiä tulossa. Olemme siirtäneet yli 6 miljoonaa viestiä. Meillä Graylogilla ei ole aikaa pureskella. Jotenkin pitää taas selvitä.
Näin selvisimme. Lisätty muutama palvelin ja SSD. Tällä hetkellä elämme näin. Nyt pureskelemme jo 160 XNUMX viestiä sekunnissa. Emme ole vielä saavuttaneet rajaa, joten on epäselvää, kuinka paljon voimme realistisesti saada siitä irti.
Nämä ovat tulevaisuuden suunnitelmamme. Näistä todellakin tärkein on luultavasti korkea saatavuus. Meillä ei ole sitä vielä. Useita autoja on asennettu samalla tavalla, mutta toistaiseksi kaikki menee yhden auton kautta. On tarpeen käyttää aikaa vikasietotilan määrittämiseen niiden välille.
Kerää mittareita Graylogista.
Aseta nopeusrajoitus, jotta meillä on yksi hullu API, joka ei tapa meitä kaistanleveyttä ja kaikkea muuta.
Ja lopuksi allekirjoita jonkinlainen SLA kehittäjien kanssa, jotta voimme palvella niin paljon. Jos kirjoitat enemmän, niin anteeksi.
Ja kirjoittaa dokumentteja.
Lyhyesti, tulokset kaikesta, mitä olemme kokeneet. Ensinnäkin standardit. Toiseksi syslog on kakku. Kolmanneksi rsyslog toimii täsmälleen niin kuin se on kirjoitettu diaan. Ja mennään kysymyksiin.
kysymykset.
Kysymys: Miksi he päättivät olla ottamatta ... (filebeat?)
Vastata: Pitää kirjoittaa tiedostoon. En todellakaan halunnut. Kun API kirjoittaa tuhansia viestejä sekunnissa, vaikka kierrät kerran tunnissa, tämä ei silti ole vaihtoehto. Voit kirjoittaa putkeen. Mihin kehittäjät kysyivät minulta: "Mitä tapahtuu, jos prosessi, jossa kirjoitamme, kaatuu"? En vain löytänyt mitä vastata heille, ja sanoin: "No, okei, älkäämme tehkö sitä."
Kysymys: Mikset vain kirjoita lokeja HDFS:ään?
VastataV: Tämä on seuraava vaihe. Ajattelimme sitä heti alussa, mutta koska sen käsittelemiseen ei tällä hetkellä ole resursseja, se roikkuu pitkän aikavälin ratkaisussamme.
Kysymys: Sarakemuoto olisi sopivampi.
Vastata: Ymmärrän. Olemme "puolta" molemmin käsin.
Kysymys: Kirjoitat rsyslogiin. Sekä TCP että UDP ovat saatavilla siellä. Mutta jos UDP, kuinka takaat toimituksen?
VastataV: On kaksi kohtaa. Ensin kerron heti kaikille, että emme takaa tukkien toimitusta. Sillä kun kehittäjät tulevat ja sanovat: "Aloitamme taloustietojen kirjoittamisen sinne, ja laitat ne jonnekin meille, jos jotain tapahtuu", vastaamme heille: "Hienoa! Aloitetaan socketiin kirjoittamisen esto ja tehdään se transaktioissa, jotta taatusti laitat sen pistorasiaan puolestamme ja varmistat, että saimme sen toiselta puolelta. Ja tällä hetkellä kaikki tulevat heti tarpeettomiksi. Ja jos ei, niin mitä kysymyksiä meillä on? Jos et halua taata kirjoitusta pistorasiaan, niin miksi takaamme toimituksen? Teemme parhaamme. Pyrimme todella toimittamaan mahdollisimman paljon ja mahdollisimman hyvin, mutta emme anna 100% takuuta. Siksi sinun ei tarvitse kirjoittaa sinne taloustietoja. Tätä varten on olemassa tapahtumatietokantoja.
Kysymys: Kun API luo jonkin viestin lokiin ja siirtää ohjauksen mikropalveluihin, oletko törmännyt ongelmaan, että viestit eri mikropalveluista saapuvat väärässä järjestyksessä? Tästä johtuen syntyy hämmennystä.
VastataV: On normaalia, että ne tulevat eri järjestyksessä. Sinun on oltava valmis tähän. Koska mikään verkkotoimitus ei takaa tilausta sinulle, tai sinun on käytettävä erityisiä resursseja tähän. Jos otamme tiedostovarastot, jokainen API tallentaa lokit omaan tiedostoonsa. Pikemminkin rsyslog hajottaa ne siellä oleviksi hakemistoiksi. Jokaisella API:lla on siellä omat lokinsa, joihin voit mennä katsomaan ja sitten vertailla niitä tämän lokin aikaleiman avulla. Jos he menevät katsomaan Graylogista, siellä ne lajitellaan aikaleiman mukaan. Siellä kaikki järjestyy.
Kysymys: Aikaleima voi vaihdella millisekuntien mukaan.
Vastata: API luo itse aikaleiman. Tämä on itse asiassa koko pointti. Meillä on NTP. API luo aikaleiman jo itse viestiin. Sitä ei ole lisätty rsyslogilla.
Kysymys: Vuorovaikutus palvelinkeskusten välillä ei ole kovin selkeää. Palvelinkeskuksen puitteissa on selvää kuinka lokit kerättiin ja käsiteltiin. Millaista on datakeskusten välinen vuorovaikutus? Vai elääkö jokainen datakeskus omaa elämäänsä?
Vastata: Melkein. Meillä on jokainen maa yhdessä datakeskuksessa. Meillä ei tällä hetkellä ole leviämistä, joten yksi maa on sijoitettu eri palvelinkeskuksiin. Siksi niitä ei tarvitse yhdistää. Jokaisen keskuksen sisällä on hirsirele. Tämä on Rsyslog-palvelin. Itse asiassa kaksi hallintakonetta. Ne on asetettu samalla tavalla. Mutta toistaiseksi liikenne kulkee vain yhden niistä läpi. Hän kirjaa kaiken aggregaatin. Siinä on levyjono varmuuden vuoksi. Hän puristaa lokit ja lähettää ne keskustietokeskukseen (Singapore), missä ne myrkytetään jo Graylogissa. Ja jokaisella datakeskuksella on oma tiedostomuisti. Jos yhteys katkeaa, meillä on kaikki lokit siellä. He jäävät sinne. Siellä ne säilytetään.
Kysymys: Saatko sieltä lokit epänormaaleissa tilanteissa?
Vastata: Voit mennä sinne (tiedostovarastoon) ja katsoa.
Kysymys: Kuinka valvot, ettet menetä lokeja?
Vastata: Olemme itse asiassa menettämässä heidät, ja seuraamme sitä. Valvonta aloitettiin kuukausi sitten. Go API:iden käyttämässä kirjastossa on mittareita. Hän osaa laskea, kuinka monta kertaa hän epäonnistui socketin kirjoittamisessa. Siellä on tällä hetkellä hankala heuristiikka. Siellä on puskuri. Se yrittää kirjoittaa siitä viestin socketiin. Jos puskuri vuotaa yli, se alkaa pudottaa niitä. Ja hän laskee, kuinka monta hän pudotti niitä. Jos laskurit alkavat vuotaa siellä yli, tiedämme siitä. He ovat nyt tulossa myös Prometheukseen, ja voit nähdä kaaviot Grafanassa. Voit määrittää hälytyksiä. Mutta ei ole vielä selvää, kenelle ne lähetetään.
Kysymys: Elasticsearchissa tallennat lokit redundanssilla. Kuinka monta kopiota sinulla on?
Vastata: Yksi kopio.
Kysymys: Onko se vain yksi rivi?
Vastata: Tämä on master ja kopio. Tiedot tallennetaan kahtena kappaleena.
Kysymys: Muutitko rsyslog-puskurin kokoa jotenkin?
Vastata: Kirjoitamme datagrammit mukautettuun unix-liitäntään. Tämä asettaa meille välittömästi 128 kilotavun rajoituksen. Emme voi kirjoittaa siihen enempää. Olemme kirjoittaneet tämän standardiin. Kuka haluaa päästä varastoon, he kirjoittavat 128 kilotavua. Lisäksi kirjastot katkaisivat ja laittavat lipun, että viesti on katkaistu. Meillä on itse viestin standardissa erityinen kenttä, joka näyttää, katkesiko se tallennuksen aikana vai ei. Joten meillä on mahdollisuus seurata tätä hetkeä.
Kysymys: Kirjoitatko rikki JSON?
Vastata: Rikkoutunut JSON hylätään joko välityksen aikana, koska paketti on liian suuri. Tai Graylog hylätään, koska se ei pysty jäsentämään JSONia. Mutta tässä on vivahteita, jotka on korjattava, ja ne liittyvät enimmäkseen rsyslogiin. Olen jo täyttänyt siellä muutaman numeron, joita on vielä työstettävä.
Kysymys: Miksi Kafka? Oletko kokeillut RabbitMQ:ta? Harmalogi ei lähde yhteen sellaisissa kuormissa?
Vastata: Se ei toimi Graylogin kanssa. Ja Graylog muotoutuu. Se on hänelle todella ongelmallista. Hän on sellainen asia. Ja itse asiassa sitä ei tarvita. Kirjoitan mieluummin rsyslogista suoraan elasticsearchiin ja katson sitten Kibanaa. Mutta meidän on ratkaistava ongelma vartijoiden kanssa. Tämä on mahdollinen variantti kehitystyöstämme, kun heitämme pois Graylogin ja käytämme Kibanaa. Logstashissa ei ole järkeä. Koska voin tehdä saman rsyslogin kanssa. Ja siinä on moduuli elasticsearchiin kirjoittamista varten. Graylogin kanssa yritämme elää jotenkin. Me jopa muokkasimme sitä hieman. Mutta parantamisen varaa on vielä.
Tietoja Kafkasta. Näin se tapahtui historiallisesti. Kun saavuin, se oli jo siellä, ja siihen kirjoitettiin jo lokeja. Nostimme juuri klusteriamme ja siirsimme siihen lokit. Hallitsemme häntä, tiedämme miltä hänestä tuntuu. Mitä tulee RabbitMQ:hen... meillä on ongelmia RabbitMQ:n kanssa. Ja RabbitMQ kehittyy meille. Meillä on se tuotannossa, ja sen kanssa oli ongelmia. Nyt ennen myyntiä hänet shamanisoitiin ja hän alkaisi työskennellä normaalisti. Mutta ennen sitä en ollut valmis julkaisemaan sitä tuotantoon. On vielä yksi kohta. Graylog voi lukea AMQP 0.9 -versiota ja rsyslog kirjoittaa AMQP 1.0 -versiota. Eikä ole olemassa yhtä ainoaa ratkaisua, joka voisi tehdä molemmat kesken. On joko yksi tai toinen. Joten toistaiseksi vain Kafka. Mutta on myös vivahteita. Koska käyttämämme rsyslog-version omkafka voi menettää koko viestipuskurin, jonka se keräsi rsyslogista. Niin kauan kuin siedämme sitä.
Kysymys: Käytätkö Kafkaa, koska sinulla oli se? Ei käytetty muuhun tarkoitukseen?
Vastata: Kafka, jota Data Science -tiimi käytti. Tämä on täysin erillinen projekti, josta en valitettavasti voi sanoa mitään. En tiedä. Häntä johti Data Science -tiimi. Kun lokit alkoivat, he päättivät käyttää sitä, jotta eivät laittaisi omia. Nyt olemme päivittäneet Graylogin ja olemme menettäneet yhteensopivuuden, koska Kafkasta on vanha versio. Meidän piti tehdä omamme. Samalla pääsimme eroon näistä neljästä aihepiiristä jokaisessa API:ssa. Teimme yhden leveän topin kaikille live-lähetyksille, yhden leveän leveän topin kaikille lavastusille ja kuvasimme vain kaiken siellä. Graylog haravoi kaiken tämän rinnakkain.
Kysymys: Miksi tarvitsemme tätä shamanismia pistorasialla? Oletko kokeillut käyttää syslog lokiohjainta säilöille.
Vastata: Kun esitimme tämän kysymyksen, meillä oli kireät suhteet satamaan. Se oli docker 1.0 tai 0.9. Docker itse oli outo. Toiseksi, jos työnnät siihen myös lokit... Minulla on vahvistamaton epäilys, että se välittää kaikki lokit itsensä läpi, telakka-daemonin kautta. Jos yksi API menee hulluksi, muut API:t törmäävät siihen, että ne eivät voi lähettää stdout- ja stderr-tiedostoja. En tiedä mihin tämä johtaa. Minulla on sellaisella tunnetasolla epäilykseni, ettei Dockerin syslog-ajuria tarvitse käyttää tässä paikassa. Toimintatestausosastollamme on oma Graylog-klusteri lokeilla. He käyttävät Docker-ajureita ja kaikki näyttää olevan kunnossa. Mutta he kirjoittavat heti GELF:in Graylogille. Sillä hetkellä kun aloitimme tämän kaiken, tarvitsimme sen toimivan. Ehkä myöhemmin, kun joku tulee ja sanoo, että se on toiminut normaalisti sata vuotta, niin kokeillaan.
Kysymys: Toimitat datakeskusten välillä rsyslogin avulla. Miksei Kafkassa?
Vastata: Teemme näin, ja näin se todella on. kahdesta syystä. Jos kanava on kokonaan kuollut, kaikki lokimme eivät edes puristetussa muodossa kiivetä sen läpi. Ja kafka antaa heille mahdollisuuden yksinkertaisesti hävitä prosessissa. Tällä tavalla pääsemme eroon näiden tukkien tarttumisesta. Käytämme vain Kafkaa tässä tapauksessa suoraan. Jos meillä on hyvä kanava ja haluamme vapauttaa sen, käytämme heidän rsyslogiaan. Mutta itse asiassa voit asettaa sen niin, että se pudottaa sen, mitä se ei päässyt läpi. Tällä hetkellä käytämme vain rsyslog-toimitusta suoraan jonnekin, jonnekin Kafkaan.
Lähde: will.com