Juri Bushmelev „Rake Map on Log Collection and Delivery Field“ – aruande tõlgendus

Logid on olulised süsteemi osad, mis aitavad mõista, kas see töötab (või ei tööta) nagu oodatud. Mikroteenuste arhitektuuri tingimustes logide haldamine muutub eraldi distsipliiniks. Tuleb lahendada mitmed küsimused:

• kuidas kirjutada logisid rakendusest;
• kuhu logisid kirjutada;
• kuidas edastada logisid säilitamiseks ja töötlemiseks;
• kuidas logisid töödelda ja säilitada.

Tänapäevaste konteineritehnoloogiate kasutamine lisab ülesande lahendamiseks juurde uusi takistusi.

Just sellest räägib Yuri Bushmelevi ettekande "Logide kogumise ja edastamise takistuste kaart" sisu.

Kellele see huvi pakub, palun lugege edasi.

Minu nimi on Yuri Bushmelev. Töösklen Lazadas. Täna räägin sellest, kuidas me oma logisid koostame, kuidas me neid kogume ja mida me nende sisse kirjutame.

Kust me tuleme? Kes me oleme? Lazada on nr 1 veebipood kuues Kagu-Aasia riigis. Kõik need riigid on jaotatud meie andmekeskuste vahel. Praegu on meil kokku 4 andmekeskust. Miks see oluline on? Sest mõned lahendused sõltusid sellest, et andmekeskuste vahel on väga nõrk side. Meil on mikroteenuste arhitektuur. Olin üllatunud, et meil on juba 80 mikroteenust. Kui ma logide ülesande ette võtsin, oli neid vaid 20. Pluss on meil ka üsna suur tükk PHP pärand, millega on samuti keeruline elada. Kõik see genereerib meile hetkel üle 6 miljoni sõnumi minutis kogu süsteemis. Edasi näitan, kuidas me sellega toime tuleme ja miks see nii on.

Selle 6 miljoni sõnumiga tuleb kuidagi elada. Mida me peame nendega tegema? 6 miljonit sõnumit, mille peame:

• rakendusest edastama
• vastu võtma
• analüüsimiseks ja säilitamiseks edastama.
• analüüsida
• mingil viisil säilitama.

Kui kolm miljonit sõnumit ilmus, oli mul umbes sama nägu. Sest alustasime mingitest sendidest. On selge, et sinna kirjutatakse rakenduse logisid. Näiteks, ei saanud andmebaasile ühendust, sain andmebaasile ühendust, kuid ei suutnud midagi lugeda. Kuid peale selle kirjutab iga meie mikroteenus ka access-logi. Iga päring, mis mikroteenusele saabub, salvestatakse logis. Miks me seda teeme? Arendajad soovivad omada jälgimisvõimet. Igas access-logis on olemas field traceid, mille abil eriline liides loob kõigi seotud tegevuste ahela ja ilusasti kuvab jälgimist. Jälgimine näitab, kuidas päring kulges, ja see aitab meie arendajatel kiiremini tegeleda igasuguste määratlemata probleemidega.

Kuidas sellega elada? Praegu räägin lühidalt võimalustest — kuidas üldse seda probleemi lahendatakse. Kuidas lahendada logide kogumise, edastamise ja salvestamise ülesanne.

Kuidas rakendusest kirjutada? Selge, et on erinevaid viise. Eelkõige on olemas parim praktika, nagu ütlevad moodne seltskond. On olemas ka vana kool kahes variandis, nagu vanad emad rääkisid. On ka teisi viise.

Logide kogumisega on suhteliselt sama olukord. Selle konkreetse osa lahendamise variante ei ole nii palju. Need on juba rohkem, kuid ikka mitte nii palju.

Kuid kohaletoimetamise ja sellele järgnevate analüüsidega — variatsioonide arv hakkab plahvatama. Ma ei hakka praegu iga varianti kirjeldama. Arvan, et peamised variantid on tuttavad kõigile, kes on teemaga huvitatud.

Ma näitan, kuidas me seda Lazadas tegime ja kuidas see kõik algas.

Aasta tagasi tulin Lazasse ja mind suunati logide projekti. Seal oli umbes nii. Rakenduse logi kirjutati stdout-i ja stderr-i. Kõik tehti moodsalt. Kuid siis arendajad viskasid selle standardvoogudest välja ja infrastruktuuri spetsialistid peavad sellega kuidagi toime tulema. Infrastruktuuri spetsialistide ja arendajate vahel on veel väljaandjad, kes ütlesid: "eee… noh, okei, paneme need lihtsalt shelliga faili, ja kõik". Ja kuna kõik see on konteineris, siis pakiti see otse konteineris, kaardistati sisse kataloog ja pandi see sinna. Arvan, et kõigile on enam-vähem selge, mida sellest välja tuli.

Vaadates pisut kaugemale, kuidas me neid logisid edastasime. Keegi valis td-agent'i, mis on tegelikult fluentd, kuid mitte päris fluentd. Ma ei saanud kunagi aru nende kahe projekti suhetest, kuid nad tundusid räävatavat samast asjast. See fluentd, kirjutatud Ruby keeles, luges logifailid, parseeris need JSON-iks mingite regulaaravaldiste järgi. Siis edastas need Kafka'sse. Ja Kafka-s oli iga API jaoks 4 erinevat teemat. Miks 4? Sest on live, on staging, ja kuna on stdout ja stderr. Arendajad genereerivad neid, kuid infrastruktuuri inimesed peavad need Kafka-s looma. Veelgi enam, Kafka'd kontrollis teine osakond. Seega tuli pilet luua, et nad loovad iga API jaoks 4 teemat. Kõik unustasid selle. Kokkuvõttes oli verevaht ja segadus.

Mida me edasi selle kõikimisega tegime? Me edastasime selle Kafka'sse. Edasi läks pool logidest Logstash'i. Teine pool jagunes. Osa läks ühte Graylog'i, osa – teise Graylog'i. Lõppkokkuvõttes jõudis see kõik ühte Elasticsearch'i klastrisse. See tähendab, et kogu see segadus lõpuks langes sinna. Nii ei peaks tegema!

Nii see välja näeb, kui vaadata kaugelt ülevalt. Nii ei tohiks teha! Siin on numbritega kohe tähistatud probleemsed kohad. Neid on tegelikult rohkem, kuid 6 on tõeliselt probleemsed, millega peab midagi ette võtma. Nendest räägin nüüd eraldi.

Siin (1,2,3) kirjutatakse meil failid ja vastavalt on siin kohe kolm takistust.

Esiteks (1) — me peame need kuhugi kirjutama. Ei oleks hea anda API-le võimalust otse faili kirjutada. Soovitav oleks, et API oleks konteineris isoleeritud, ja veel parem – et see oleks read-only. Ma olen süsteemihaldur, seega on mul natuke alternatiivne vaade nendele asjadele.

Teine punkt (2,3) - me saame palju päringuid API-sse. API kirjutab palju andmeid faili. Failid kasvavad. Me peame neid roteerima. Sest muidu ei jätku diskiruumi. Roteerimine on halb, sest need on shell'i kaudu katalooge suunatud. Me ei saa seda kuidagi roteerida. Rakendusele ei saa öelda, et see avaks descriptor'id uuesti. Sest arendajad vaatavad su nagu lollile: "Millised descriptor'id? Me kirjutame ju stdout'i". Infrastruktuuri inimesed tegid logrotate'is copytruncate, mis teeb lihtsalt faili koopia ja kärbib originaali. Seega, nende kopeerimisprotsesside vahel on tavaliselt diskiruumi puudus.

(4) Meil oli erinevaid formaate erinevates API-des. Need erinesid veidi, kuid regexp'e tuli kirjutada erinevaid. Kuna kogu see asi oli hallatav Puppet'i kaudu, siis seal oli suur hulk klasse oma probleemidega. Peale selle suutis td-agent suure osa ajast mälu süüa, olla aeglane, ta võis lihtsalt näida, et töötab, ja mitte midagi teha. Väljastpoolt oli võimatu mõista, et ta ei tee midagi. Parimal juhul ta kukub kokku ja keegi tõstab ta hiljem uuesti üles. Täpsemalt, tuleb alert ja keegi läheb käsitsi selle uuesti töösse.

(6) Ja kõige hullem oli elasticsearch. Sest see oli vana versioon. Meil polnud sel hetkel eraldi master'e. Meil olid heterogeensed logid, millel väljad võisid kattuda. Erinevad logid erinevatest rakendustest võisid kirjutada sama välja nimedega, kuid andmed sees võisid olla erinevad. Näiteks üks logi tuleb Integer'iga väljas, näiteks level. Teine logi tuleb String'iga väljas level. Ilma staatilise mappimise puudumisel tekib selline suurepärane olukord. Kui pärast indeksite roteerimist elasticsearch'i saab esimene sõnum String'iga, siis elame normaalselt. Aga kui esimesena tuleb Integer, siis kõik järgnevad sõnumid, mis tulevad String'iga, lihtsalt jäetakse kõrvale. Sest välja tüüp ei ühti.

Me hakkasime endale neid küsimusi esitama. Otsustasime, et ei hakka süüdlasi otsima.

Aga midagi on tõesti vaja teha! Ilmselge on see, et peame kehtestama standardid. Mõned standardid olid meil juba olemas. Mõned kehtestasime pisut hiljem. Õnneks olime selleks ajaks juba kinnitanud kõigi API-de jaoks ühtse logide formaadi. See on kirjas teenuste koostööstandardites. Järelikult peavad need, kes soovivad logisid saada, kirjutama need just sellesse formaati. Kui keegi ei kirjuta logisid sellel kujul, siis me ei suuda midagi garanteerida.

Edasi, sooviks kehtestada ühtse standardi logide kirjutamise, saatmise ja kogumise viiside jaoks. Nimelt, kuhu need kirjutada ja millega neid saata. Ideaalne olukord oleks see, kui projektides kasutatakse üht ja sama teeki. Meil on eraldi loggingi teek Go jaoks ja eraldi teek PHP jaoks. Kõik, kes meil on, peavad neid kasutama. Praeguseks võiks öelda, et meil see õnnestub umbes 80%. Kuid mõned jätkavad kaktuste söömist.

Ja seal (slaidil) hakkab vaevu selguma "SLA logide saatmiseks". Seda veel ei ole, kuid me töötame selle kallal. Sest see on väga mugav, kui infrastruktuur ütleb, et kui kirjutate sellises formaadis sellisesse kohta ja mitte enam kui N sõnumit sekundis, siis me toimetame need tõenäosusega, et see jõuab sinna. See vabastab palju peavalu. Kui SLA on, siis on see lihtsalt suurepärane!

Kuidas me probleemi lahendama hakkasime? Peamine takistus oli td-agent. Ei olnud selge, kuhu meie logid jäävad. Kas neid toimetatakse? Kas neid kogutakse? Kus nad üldse on? Seetõttu otsustasime esimese asjana td-agenti asendada. Lühidalt olen siin üles tähendanud, mille vastu see asendada.

Fluentd. Esiteks olen ma sellega varasemal töökohal kokku puutunud ja sealgi kukkus see vahepeal kokku. Teiseks on see sama, ainult suunatud.

Filebeat. Miks see meie jaoks mugav oli? Sest see on kirjutatud Go keeles ja meil on Go osas suur ekspertiis. Seega, kui on vajadus, saame seda enda vajadustele kohandada. Seetõttu me seda ei valinud. Et isegi ei tekiks kiusatust seda enda jaoks ümber kirjutama hakata.

Ilmselge lahendus süsteemiadministraatori jaoks on igasugused sisselogid sellises koguses (syslog-ng/rsyslog/nxlog).

Või kirjutada midagi enda, kuid selle me kõrvale jätsime, samuti ka filebeat'i. Kui midagi kirjutada, siis on parem kirjutada midagi kasulikku äri jaoks. Logide edastamiseks on parem võtta midagi valmis.

Seetõttu on valik tegelikult piiratud syslog-ng ja rsyslog vahel. Kaldusin rsyslogi poole, lihtsalt seetõttu, et meil oli Puppetis juba rsyslogi jaoks klassid, ja ma ei leidnud nende vahel ilmset erinevust. Seal on syslog ja siin on syslog. Jah, kellelgi on dokumentatsioon halvem, kellelgi parem. Üks oskab nii, aga teine — teisiti.

Veidi rsyslogist. Esiteks on see äge, sest tal on palju mooduleid. Tal on arusaadav RainerScript (kaasaegne konfigureerimiskeel). Suurepärane boonus on see, et me saime seda formaalselt simuleerida td-agent'i käitumist, ja rakendustes ei muutunud midagi. See tähendab, et me vahetame td-agent'i rsyslog'i vastu, ja kõik muud asjad jäävad samaks. Ja kohe saame töötava kohaletoimetamise. Edasi, mmnormalize — see on fantastiline asi rsyslogis. See võimaldab logisid analüüsida, kuid mitte Grok'i ja regexp'i abil. See loob abstraktse süntaksipuude. See analüüsib logisid umbes nagu kompilaator analüüsib allikaid. See võimaldab töötada väga kiiresti, tarvitama vähe CPU-d ja on tõeliselt äge asi. Seal on palju muid boonuseid. Ma ei hakka neist rääkima.

Rsyslogil on ka palju puudusi. Need on umbes samad, mis boonused. Peamised probleemid — tuleb osata seda ette valmistada ja tuleb valida õige versioon.

Otsustasime, et kirjutame logid unix-soketisse. Esiteks mitte /dev/log, kuna seal on meil segadus süsteemilogidest, seal on journald selles pipeline'is. Seetõttu kirjutame kohandatud soketisse. Me ühendame selle eraldi reeglikogumiga. Mitte midagi segada. Kõik on läbipaistev ja arusaadav. Nii me tegelikult tegime. Kataloog nendega soketitega on standardiseeritud ja edastatakse kõikidesse konteineritesse. Konteinerid saavad näha neile vajalikku soket, avada ja sinna kirjutada.

Miks mitte fail? Kuna kõik lugesid artiklit Badushka'st, mis üritas edastada faili dockerisse, ja avastas, et pärast rsyslogi taaskäivitamist muutub failide descriptor, ja docker kaotab selle faili. Ta hoiab lahti midagi muud, kuid enam mitte seda soket, kuhu kirjutatakse. Otsustasime, et saame selle probleemi ringiga ümber minna, ja samal ajal vältida lukustamise probleemi.

Rsyslog teeb slaidil näidatud toimingud ja saadab logid kas reléesse või Kafka'sse. Kafka vastab vanale meetodile. Relé — üritasin kasutada puhtalt rsyslogi logide kohaletoimetamiseks. Ilma sõnumijärjekorrata, tavaliste rsyslogi vahenditega. Üldiselt see töötab.

Kuid on nüansse selle osas, kuidas neid hiljem sellesse ossa (Logstash/Graylog/ES) paigutada. See osa (rsyslog-rsyslog) kasutatakse andakeskuste vahel. Siin on kompressitud tcp link, mis võimaldab säästa ribalaiust ja seega suurendada tõenäosust, et saame mõningaid logisid teiselt andakeskuselt olukordades, kus kanal on ummistunud. Kuna meil on Indoneesia, kus kõik on halvasti. Seal on see pidev probleem.

Mõtlesime, kuidas me saame jälgida, kui tõenäoliselt jõuavad logid, mida oleme rakendusest salvestanud, teise otsa? Otsustasime luua metrikad. Rsyslogil on oma statistika kogumise moodul, kus on mõned loendurid. Näiteks võib see näidata Teile järjekorra suurust või palju sõnumeid on tulnud mingisse tegevusse. Nendest saab midagi võtta. Pluss, sellel on kohandatavad loendurid, mida saab seadistada, ja see näitab näiteks, kui palju sõnumeid on salvestanud mingi API. Edasi, kirjutasin rsyslog_exporter'i Pythonis ja saatsime kõik Prometheusesse ja koostasime graafikud. Graylogi metrikad oleksid olnud väga soovitavad, kuid seni pole me neid seadistanud.

Milliste probleemidega kokku puutusime? Probleemid tekkisid seetõttu, et avastasime (ÄKKI!), et meie Live API saadab 50k sõnumit sekundis. See on ainult Live API, ilma stagingita. Ja Graylog näitab meile ainult 12 tuhat sõnumit sekundis. Ja tekkis mõistlik küsimus, kus siis ülejäänud on? Sellest tõstsime järelduse, et Graylog lihtsalt ei suuda hakkama. Vaatasime ja tõepoolest, Graylog Elasticsearchiga ei suutnud seda voogu taluda.

Edasi, teised avastused, mille tegime protsessi käigus.

Socket'i kirjutamine on blokeeritud. Kuidas see juhtus? Kui ma kasutasin rsyslogit kohaletoimetamiseks, siis mingil hetkel kukkus meil kanal andakeskuste vahel kokku. Ühes kohas seisis kohaletoimetamine, teises kohas seisis kohaletoimetamine. Kõik see jõudis masinani koos API'ga, mis kirjutavad rsyslog socket'isse. Seal täitis järjekord. Siis täitus järjekord Unix socket'i kirjutamiseks, mis on vaikimisi 128 paketti. Ja järgmine write() rakenduses blokeerub. Kui me vaatasime Go rakendustes kasutatavat teeki, oli seal öeldud, et socket'isse kirjutamine toimub mitteblokeerivas režiimis. Olime kindlad, et midagi ei blokeeru. Sest me lugesime. artiklit Badushka'st, mis sellest kirjutati. Aga on üks moment. Selle kutsumise ümber oli lõputu tsükkel, milles pidevalt ettevõteti proovida sõnumit soketi panna. Seda me ei märganud. Ainus lahendus oli raamatukogu ümber kirjutamine. Sel ajal on see paar korda muutunud, kuid nüüd oleme eemaldanud kõik lukud kõikides alamüsteemides. Seetõttu saab rsyslogi peatada ja midagi ei juhtu.

On vaja jälgida järjekordade suurust, mis aitab vältida nende lõksude sisse astumist. Esiteks, saame jälgida, millal hakkame sõnumeid kaotama. Teiseks, saame jälgida, et meil on üldiselt probleemid kohaletoimetamisega.

Ja veel üks ebameeldiv moment — amplifikatsioon 10 korda mikroteenuste arhitektuuris — see on väga lihtne. Meil ei ole palju sissetulevaid päringuid, kuid nende sõnumite edasiviimise tõttu graafikus, access-logide tõttu, tõstame me logide koormust tegelikult umbes kümme korda. Kahjuks ei jõudnud ma täpsed numbrid välja arvutada, kuid mikroteenused — need ongi sellised. Seda tuleb silmas pidada. Tundub, et hetkel on logide kogumise alamüsteem Lazadas kõige koormatud.

Kuidas lahendada elasticsearchi probleem? Kui on vaja kiiresti saada logid ühte kohta, et mitte joosta kõikide masinate vahel ja neid sealt kokku koguda, kasutage failide salvestust. See töötab garanteeritult. Seda saab teha mistahes serverist. Tuleb lihtsalt sinna kettaid paigutada ja syslog paigaldada. Pärast seda on teil ühes kohas kõik logid olemas. Edasi saab juba rahulikult seadistada elasticsearchi, graylogi, midagi muud. Kuid teil on juba kõik logid ja lisaks saate neid hoida nii kaua, kui ketta mahtudest piisab.

Minu ettekande hetkel nägi skeem välja selline. Faili ei kirjutanud me praktiliselt enam. Praegu toimetame tõenäoliselt viimased osad välja. Kohalikud masinad, millel API-d käivitatakse, enam failidesse ei kirjuta. Esiteks, on olemas failide salvestus, mis töötab väga hästi. Teiseks, nendel masinatel lõpeb pidevalt ruum, seda tuleb pidevalt jälgida.

See osa Logstashi ja Graylogi kohta tõepoolest häirib. Seetõttu tuleb sellest vabaneda. Tuleb valida midagi ühte.

Oleme otsustanud loobuda Logstashist ja Kibanast. Kaheks, et meil on turbedo. Mis seos on? Seos on selles, et Kibana ilma X-Packi ja Shieldita ei võimalda pääs õigusi logidele. Seetõttu valisime Graylogi. Seal on kõik olemas. Ta mulle ei meeldi, aga ta töötab. Ostisime uut riistvara, installisime sinna värske Graylogi ja tõstsime kõik logid rangete formaatidega eraldi Graylogi. Me lahendasime sama tüüpi väljade korralduse probleemi.

Mis siis uude Graylogi kuulub? Kirjutasime kõik Dockerisse. Võtsime palju servereid, paigaldasime kolm Kafka instantsi, 7 serverit Graylog versiooniga 2.3 (sest tahtsime Elasticsearch versiooni 5). Kõik see tõsteti HDD RAID-ide peale. Nägime indekseerimise kiirusena kuni 100 tuhat sõnumit sekundis. Nägime numbrit, et 140 terabaiti andmeid nädalas.

Ja jälle komistus! Meil on tulekul kaks müüki. Meie suurus on üle 6 miljoni sõnumi. Graylog ei suuda enam töötada. Peame kuidagi ellu jääma.

Jõudsime ellu nii. Lisame veel paar serverit ja SSD-d. Hetkel elame sellisel moel. Praegu suudame juba töödelda 160 tuhat sõnumit sekundis. Me pole veel latti tabanud, seega pole selge, kui palju me sellest tegelikult välja saame.

Sellised on meie tulevikuplaanid. Neist on tõenäoliselt kõige olulisem kõrge saadavus. Meil seda veel pole. Mitmed masinad on seadistatud sama moodi, aga kõik läheb ühe masina kaudu. Peame kulutama aega, et seadistada vahepealset varundust nende vahel.

Koguda mõõdikud Graylogist.

Käivitada kiiruspiirang, et üks hull API meilt ribalaiust ja kõike muud ei tapaks.

Ja lõpuks, kirjutada mõni SLA arendajatega, et saame teenindada nii palju. Kui saadate rohkem, siis vabandust.

Ja kirjutada dokumentatsioon.

Kokkuvõttes, mida me oleme kogenud. Esiteks, standardid. Teiseks, syslog - kook. Kolmandaks, rsyslog töötab just nii, nagu slaidil öeldud. Ja liigume küsimustele üle.

Küsimused.

Küsimus: Miks siis ikkagi ei otsustanud võtta... (filebeat?)

Vastus: Tuleb kirjutada faili. Väga ei tahtnud. Kui sul on API, mis kirjutab tuhandeid sõnumeid sekundis, siis isegi kui sa kord tunni jooksul keerad, pole see ikkagi variant. Sa saad kirjutada torusse. Mida arendajad mulle küsisid: "Ja mis juhtub, kui protsess, kuhu me kirjutame, kukub?" Ma lihtsalt ei leidnud, mida vastata, ja ütlesin: "Noh, okei, ärme tee siis nii."

Küsimus: Miks te ei kirjuta logisid lihtsalt HDFS-i?

Vastus: See on järgmine etapp. Me oleme selle üle mõelnud alguses, aga kuna praegu pole ressursse sellega tegeleda, jääb see meie pikaajalisse lahendusse.

Küsimus: Veergude formaat oleks sobivam.

Vastus: Ma saan kõigest aru. Me oleme selle poolt mõlema käega.

Küsimus: Te kirjutate rsyslog-i. Seal saab kasutada nii TCP-d kui ka UDP-d. Aga kui kasutate UDP-d, siis kuidas te garanteerite kohaletoimetamise?

Vastus: On kaks momenti. Esiteks, ma ütlen kohe kõigile, et me ei garanteeri logide kohaletoimetamist. Sest kui arendajad tulevad ja ütlevad: „Aga äkki hakkame sinna kirjutama finantsandmeid ja teie hoiustate need kuskile, juhuks kui midagi juhtub”, siis me vastame neile „Suurepärane! Laske teil alustada soketisse kirjutamise blokkeerimist ja teha seda tehingutes, et me tagaksime, et te panete meile need soketti ja veenduge, et me saime need sealt.” Ja selle hetkel ei ole kellelgi enam soovi seda teha. Kui ei ole soovi, siis millised on meie küsimused? Kui te ei taha garanteerida kirjutamist soketti, siis miks peaksime meie garantii andma kohaletoimetamiseks? Me teeme parima pingutuse. Me tõesti püüame kohaletoimetada nii palju ja nii hästi kui võimalik, kuid me ei anna 100% garantiisid. Seetõttu ärge kirjutage sinna finantsandmeid. Selle jaoks on andmebaasid tehingutega.

Küsimus: Kui API genereerib mõne teate logis ja edastab juhtimise mikroteenustele, siis kas te ei ole kokku puutunud probleemiga, et erinevatelt mikroteenustelt saavate teadete järjekord on vale? Selle tõttu tekib segadus.

Vastus: On normaalne, et nad tulevad erinevas järjekorras. Sellega tuleb valmis olla. Sest ükski võrgu kohaletoimetamine ei garanteeri järjekorda või tuleb sellele spetsiaalselt ressursse kulutada. Kui võtta failihoiustused, siis iga API salvestab logid oma faili. Tegelikult jagab rsyslog need kataloogidesse. Igal API-l on seal oma logid, kuhu saab minna ja vaadata, ja siis timestampi põhjal saab neid omavahel seostada. Kui nad otsivad Graylog-st, siis seal nad sorteeritakse timestampi järgi. Seal on kõik hästi.

Küsimus: Timestamp võib erineda millisekundite kaupa.

Vastus: Timestamp genereerib ise API. Selles ongi kogu asi. Meil on NTP. API genereerib timestampi juba ise sõnumis. Seda ei lisa rsyslog.

Küsimus: Ei ole väga selge, kuidas and keskkonnad omavahel suhtlevad. Andmekeskuse sees on selge, kuidas logisid koguti ja töödeldi. Kuidas toimub suhtlemine andmekeskuste vahel? Kas iga andmekeskus elab oma elu?

Vastus: Peaaegu. Igal riigil on oma andmekeskus. Meil ei ole praegu jaotust, et sama riik oleks erinevates andmekeskustes. Seetõttu ei pea neid ühendama. Igas keskuses on Log Relay. See on Rsyslog server. Tegelikult on kaks haldustööd masinat. Need on ühetaoliselt seadistatud. Kuid hetkel läheb liiklus läbi ainult ühe neist. See kogub kõiki logisid. Sellel on ketta järjekord igaks juhuks. See tihendab logisid ja saadab need keskmisse andmekeskusesse (Singapur), kus need saadetakse edasi Graylogi. Ja igas andmekeskuses on oma failide salvestus. Juhul, kui ühendus kaob, on meil kõik logid seal. Need jäävad sinna. Need salvestatakse.

Küsimus: Kas sa saad sealt ekstreemsetes olukordades logisid?

Vastus: Saab minna sinna (failide salvestusse) ja vaadata.

Küsimus: Kuidas te jälgite, et te ei kaota logisid?

Vastus: Me tegelikult kaotame neid ja me jälgime seda. Jälgimist alustati kuu aega tagasi. Raamatukogus, mida kasutab Go API, on mõõdikud. See oskab lugeda, mitu korda ta ei saanud socketisse kirjutada. Seal on hetkel nutikas heuristika. Seal on puhver. See proovib kirjutada sellest sõnumit socketisse. Kui puhver täitub, hakkab see neid loobuma. Ja loendab, kui palju ta on loobunud. Kui loendurid hakkavad täituma, saame sellest teada. Need saadetakse ka Prometheusesse, ja Grafanas saab vaadata graafikuid. Saate seadistada teateid. Kuid hetkel ei ole selge, kellele need saata.

Küsimus: Kas Elasticsearchis hoiate logisid koos varundamisega? Kui palju teil on koopiaid?

Vastus: Üks koopiate.

Küsimus: See on ainult üks koopia?

Vastus: See on master ja koopia. Andmed on hoitud kahes eksemplaris.

Küsimus: Oled sa kuidagi Rsyslogi puhvri suurust seadistanud?

Vastus: Me kirjutame andmegramme kohandatud unix socketisse. See seab meile kohe piiranguks 128 kilobaiti. Me ei saa sinna rohkem kirjutada. Oleme selle standardisse kirja pannud. Kes tahab salvestustesse jõuda, need kirjutavad 128 kilobaiti. Raamatukogud kärbivad, ja panevad lipu, et sõnum on kärbitud. Meie sõnumi standardis on eriline väli, mis näitab, kas see on kirjutamise käigus kärbitud või mitte. Seega on meil võimalik jälgida ka seda hetke.

Küsimus: Kas kirjutate vigaseid JSON-e?

Vastus: Vigane JSON jäetakse kõrvale kas relay ajal, sest pakett on liiga suur. Või viskab Graylog selle kõrvale, sest ei suuda JSON-i parsida. Kuid siin on nüansse, mida tuleb fikseerida, ja need on enamikul juhtudel seotud rsyslog-iga. Olen juba esitanud seal mitu probleemi, millega tuleb veel töötada.

Küsimus: Miks Kafka? Kas olete proovinud RabbitMQ-d? Kas Graylog ei toimi selliste koormuste juures?

Vastus: Meie jaoks ei toimi Graylog. Aga Graylog meie jaoks toimib. Sellega on tõeliselt probleeme. See on üsna eriline asi. Ja tegelikult pole seda vaja. Eelistaksin kirjutada rsyslogist otse Elasticsearchi ja vaadata siis Kibana't. Kuid peame sedalaadi küsimuse turvaekspertidega klaarima. See on võimalik variant meie arenguks, kui viskame Graylogi välja ja kasutame Kibana't. Logstash'i kasutamine pole mõtet. Sest ma saan sama asja teha rsyslogiga. Ja sellel on moodul Elasticsearchi kirjutamiseks. Graylogiga proovime kuidagi edasi elada. Oleme seda isegi natuke optimeerinud. Kuid seal on veel ruumi paranemiseks.

Kafkast. Ajalooliselt on see nii välja kujunenud. Kui ma tulin, oli see juba olemas ja logisid kirjutati sinna juba. Me lihtsalt tõime oma klastrisse ja kolisime sinna logid. Me haldame seda, me teame, kuidas tal läheb. RabbitMQ kohta... meil ei lähe RabbitMQ hästi. Aga RabbitMQ meile sobib. Meil on see tootmises ja seal on olnud probleeme. Praegu me uuendasime seda enne kampaaniat ja see hakkas normaalselt tööle. Aga enne seda ma ei olnud valmis seda tootmisesse laskma. On veel üks moment. Graylog oskab lugeda AMQP 0.9 versiooni, kuid rsyslog oskab kirjutada AMQP 1.0 versiooni. Ja ei ole ühtegi lahendust, mis oskaks mõlemat. On kas üks või teine. Seega sellel hetkel ainult Kafka. Aga seal on ka omad nüansid. Kuna omkafka selle rsyslog versiooni puhul, mida me kasutame, võib kaotada kogu sõnumite puhvri, mille ta rsyslogist välja võttis. Seni oleme sellega leppinud.

Küsimus: Kas te kasutate Kafkat, kuna see oli teil olemas? Kas seda kasutatakse veel millegi muu jaoks?

Vastus: Kafkat, mis meil oli, kasutab Data Science'i meeskond. See on täiesti eraldi projekt, millest ma, kahjuks, midagi rohkem ei tea. Ta oli Data Science'i meeskonna halduses. Kui logid süsteemi toodi, otsustati seda kasutada, et mitte installida veel ühte. Nüüd, kui me oleme Graylogi uuendanud, kaotasime ühilduvuse, kuna seal on vana Kafka versioon. Me pidime oma looma. Samuti saime lahti nendest neljast teema kohta iga API kohta. Me tegime ühe laia teema kõigi live'i jaoks, ühe laia teema kõigi stagingute jaoks ja lihtsalt saame sinna kõik logid. Graylog korjab kõike paralleelselt.

Küsimus: Miks on vajalik see soketiga tegelemine? Kas olete proovinud kasutada konteineritele log-draiverit syslog.

Vastus: Kui me selle küsimusega tegelema hakkasime, olid meie suhted Dockeriga pingelised. Tookord oli see Docker 1.0 või 0.9. Docker ise oli kummaline. Teiseks, kui veel logisid ka sinna panna... Mul on kontrollimatu kahtlus, et ta laseb kõik logid end läbi, läbi Docker daemon'i. Kui meil üks API nässu läheb, siis teised API-d jäävad kinni, kuna nad ei saa saata stdout ja stderr-i. Ma ei tea, kuhu see viib. Tunne ütleb, et ei ole vaja syslog-draiverit Dockeris sellistes olukordades kasutada. Meie funktsionaalse testimise osakonnal on oma väike Graylog klaster logide jaoks. Nad kasutavad Docker'i log-draivereid ja seal tundub isegi kõik toimivat hästi. Kuid nad kirjutavad GELF-i kohe Graylogi. Tookord, kui me kõike seda korraldasime, vajasime, et see lihtsalt töötaks. Võib-olla hiljem, kui keegi ütleb, et see on sada aastat kenasti töötanud, siis proovime uuesti.

Küsimus: Te teete andmekeskuste vahel kohaletoimetamist rsyslogi kaudu. Miks mitte Kafka kaudu?

Vastus: Me teeme tegelikult nii üht kui teist. Kahes põhjusest. Kui kanal on täielikult purustatud, siis ei pääse meie logid isegi kokku surutud kujul sellest läbi. Kafka võimaldab neid protsessis lihtsalt kaotada. Selle meetodi abil vabaneme logide kinni jäämisest. Kui kasutame lihtsalt Kafka-d otse. Kui meie kanal on hea ja soovime seda vabastada, siis kasutame rsyslogi. Aga tegelikult võib selle seadistada nii, et ta ise viskab ära, mis ei pääse läbi. Praeguseks kasutame mõnes kohas otse rsyslogi kohaletoimetamist, mõnes Kafka-d.

Allikas: habr.com