Logid on süsteemi oluline osa, mis võimaldab teil mõista, et see töötab (või ei tööta) ootuspäraselt. Mikroteenuste arhitektuuri tingimustes muutub eriolümpiaadi omaette distsipliiniks palkidega töötamine. On palju probleeme, mis vajavad lahendamist:
- kuidas rakendusest logisid kirjutada;
- kuhu logisid kirjutada;
- kuidas tarnida palke ladustamiseks ja töötlemiseks;
- kuidas logisid töödelda ja säilitada.
Praegu populaarsete konteinertehnoloogiate kasutamine lisab probleemide lahendamise võimaluste vallas reha otsa liiva.
Just see on Juri Bušmelevi raporti "Reha kaart palkide kogumise ja kohaletoimetamise alal" ärakiri.
Keda huvitab, palun kassi alla.
Minu nimi on Juri Bušmelev. Töötan Lazada heaks. Täna räägin sellest, kuidas me oma palke tegime, kuidas neid kogusime ja mida sinna kirjutame.
Kust me pärit oleme? Kes me oleme? Lazada on Interneti-jaemüüja # 1 kuues Kagu-Aasia riigis. Kõik need riigid on jaotatud andmekeskuste vahel. Andmekeskusi on nüüd kokku 4. Miks see oluline on? Sest mõned otsused olid tingitud sellest, et keskuste vahel on väga nõrk side. Meil on mikroteenuste arhitektuur. Üllatusega avastasin, et meil on juba 80 mikroteenust. Kui logidega ülesannet alustasin, oli neid ainult 20. Lisaks on päris suur tükk PHP-pärandit, millega pean ka elama ja taluma. Kõik see genereerib meile hetkel üle 6 miljoni sõnumi minutis kogu süsteemi kohta. Edasi näitan, kuidas me püüame sellega elada ja miks see nii on.
Nende 6 miljoni sõnumiga tuleb kuidagi elada. Mida me peaksime nendega tegema? Vaja on 6 miljonit sõnumit:
- saatke rakendusest
- tarnimiseks vastu võtta
- tarnida analüüsiks ja ladustamiseks.
- analüüsida
- kuidagi poodi.
Kui sõnumeid oli kolm miljonit, oli mul umbes sama välimus. Sest alustasime mõne sendiga. Selge see, et sinna kirjutatakse rakenduste logisid. Näiteks ei saanud andmebaasiga ühendust, sai andmebaasiga ühendust, aga ei saanud midagi lugeda. Kuid peale selle kirjutab iga meie mikroteenus ka juurdepääsulogi. Iga mikroteenindusse saabunud päring langeb logisse. Miks me seda teeme? Arendajad tahavad, et neil oleks võimalik jälgida. Iga juurdepääsulogi sisaldab traceid-välja, mille järgi eriliides kerib seejärel kogu ahela lahti ja kuvab jälje kaunilt. Jälg näitab, kuidas taotlus läks, ja see aitab meie arendajatel tundmatu prügiga kiiremini toime tulla.
Kuidas sellega elada? Nüüd kirjeldan lühidalt valikute valdkonda - kuidas see probleem üldiselt lahendatakse. Kuidas lahendada palkide kogumise, teisaldamise ja ladustamise probleem.
Kuidas rakendusest kirjutada? On selge, et on erinevaid viise. Eelkõige on olemas parim tava, nagu moodsad kamraadid meile räägivad. Vana kooli on kahte tüüpi, nagu vanaisad ütlesid. On ka teisi viise.
Palkide kogumisega on olukord ligikaudu sama. Selle konkreetse osa lahendamiseks pole nii palju võimalusi. Neid on veel, aga veel mitte nii palju.
Kuid tarnimise ja sellele järgneva analüüsiga hakkab variatsioonide arv plahvatuslikult kasvama. Ma ei kirjelda nüüd iga võimalust. Arvan, et peamised võimalused on kõigile, kes teema vastu huvi tundsid, hästi teada.
Näitan teile, kuidas me seda Lazadas tegime ja kuidas see kõik alguse sai.
Aasta tagasi tulin Lazadasse ja mind saadeti palgiprojekti. Seal oli niimoodi. Rakenduse logi kirjutati stdout ja stderr. Kõik oli tehtud moepäraselt. Siis aga viskasid arendajad selle standardvoogudest välja ja siis saavad taristuspetsialistid selle kuidagi välja. Taristuspetsialistide ja arendajate vahel on ka väljastajaid, kes ütlesid: "ah ... noh, mähime nad lihtsalt kestaga faili ja kõik." Ja kuna see kõik on konteineris, mähkisid nad selle otse konteinerisse, kaardistasid selle sees oleva kataloogi ja panid selle sinna. Ma arvan, et see on kõigile üsna ilmne, mis juhtus.
Vaatame veidi kaugemale. Kuidas me need palgid kohale toimetasime. Keegi valis td-agendi, mis on tegelikult fluentd, kuid mitte päris ladus. Ma ei mõista siiani nende kahe projekti seost, kuid need näivad olevat sama asjaga. Ja see fluentd, mis on kirjutatud Ruby keeles, luges logifaile, sõelus need mõne regulaaravaldise abil JSON-i. Siis saadeti nad Kafkasse. Lisaks oli meil Kafkas iga API jaoks 4 eraldi teemat. Miks 4? Kuna on live, on lavastus ja kuna on olemas stdout ja stderr. Arendajad toodavad neid ja infrastruktuuri töötajad peavad need Kafkas looma. Veelgi enam, Kafkat kontrollis teine osakond. Seetõttu oli vaja luua pilet, et nad lõid sinna iga api jaoks 4 teemat. Kõik unustasid selle. Üldiselt oli see prügi ja prügi.
Mida me sellega edasi tegime? Saatsime selle kafkale. Kafkast edasi lendasid pooled palgid Logstashi. Teine pool palkidest jagati. Mõned lendasid ühte Graylogi, mõned teise Graylogi. Selle tulemusena lendas see kõik ühte Elasticsearchi klastrisse. See tähendab, et kogu see segadus langes lõpuks sinna. Sa ei pea seda tegema!
Selline näeb see välja ülalt vaadates. Sa ei pea seda tegema! Siin on probleemsed kohad kohe numbritega tähistatud. Neid on tegelikult rohkem, aga 6 on päris probleemsed, millega tuleb midagi ette võtta. Ma räägin neist nüüd eraldi.
Siin (1,2,3) kirjutame failid ja vastavalt sellele on siin korraga kolm reha.
Esimene (1) on see, et me peame need kuhugi kirjutama. Alati ei ole soovitav anda API-le otse faili kirjutamise võimalust. Soovitav on, et API oleks isoleeritud konteineris ja veelgi parem, et see oleks kirjutuskaitstud. Olen süsteemiadministraator, seega on mul nendest asjadest veidi alternatiivne vaade.
Teine punkt (2,3) on see, et API-le tuleb palju taotlusi. API kirjutab faili palju andmeid. Failid kasvavad. Peame neid pöörama. Sest muidu ei saa sinna ühtegi plaati salvestada. Nende pööramine on halb, sest need suunatakse kesta kaudu kataloogi. Me ei saa seda kuidagi pöörata. Rakendusel ei saa käskida käepidemeid uuesti avada. Sest arendajad vaatavad sind nagu lolli: “Millised kirjeldused? Üldiselt kirjutame stdoutile. Raamistikud, mis on tehtud copytruncate logrotate'iks, teeb failist lihtsalt koopia ja koondab originaali. Seetõttu saab nende kopeerimisprotsesside vahel kettaruum tavaliselt otsa.
(4) Meil oli erinevates API-des erinevad vormingud. Need olid veidi erinevad, kuid regexp tuli kirjutada erinevalt. Kuna seda kõike juhtis Puppet, siis oli suur kamp oma prussakatega klasse. Lisaks võis td-agent enamasti mälust süüa, olla rumal, võis lihtsalt teeselda, et töötab ja mitte midagi teha. Väliselt oli võimatu aru saada, et ta midagi ei tee. Parimal juhul ta kukub ja keegi võtab ta hiljem üles. Täpsemalt lendab sisse hoiatus ja keegi läheb ja tõstab selle kätega üles.
(6) Ja kõige rohkem prügi ja jäätmeid – see oli elasticsearch. Sest see oli vana versioon. Sest meil polnud tol ajal pühendunud meistreid. Meil olid heterogeensed palgid, mille põllud võisid kattuda. Erinevate rakenduste erinevaid logisid saaks kirjutada samade väljanimedega, kuid samal ajal võivad sees olla erinevad andmed. See tähendab, et ühes logis on täisarv väljal, näiteks tase. Teise logiga on taseme väljal string. Staatilise kaardistamise puudumisel selgub selline imeline asi. Kui pärast indeksi pööramist saabus elasticsearchis kõigepealt stringiga teade, siis elame normaalselt. Ja kui esimene saabus täisarvuga, siis kõik järgmised sõnumid, mis saabusid Stringiga, visatakse lihtsalt kõrvale. Kuna välja tüüp ei ühti.
Hakkasime neid küsimusi esitama. Otsustasime, et ei hakka süüdlasi otsima.
Aga midagi on vaja ette võtta! Ilmselge on see, et me peame kehtestama standardid. Meil olid juba mõned standardid. Mõned tõime veidi hiljem. Õnneks kinnitati juba sel ajal kõigi API-de jaoks ühtne logivorming. See on kirjutatud otse teenuse interaktsiooni standarditesse. Sellest lähtuvalt peaksid need, kes soovivad logisid saada, kirjutama need selles vormingus. Kui keegi selles formaadis logisid ei kirjuta, siis me ei garanteeri midagi.
Lisaks sooviksin ühtset standardit logide salvestamise, kohaletoimetamise ja kogumise meetodite kohta. Tegelikult, kuhu neid kirjutada ja kuidas neid edastada. Ideaalne olukord on siis, kui projektid kasutavad sama raamatukogu. Go jaoks on eraldi logiteek, PHP jaoks on eraldi teek. Kõik, mis meil on, peaksid neid kasutama. Hetkel ütleks, et meil õnnestub 80 protsenti. Kuid mõned jätkavad kaktuste söömist.
Ja seal (slaidil) hakkab vaevu ilmuma "SLA logi kohaletoimetamiseks". See pole veel olemas, kuid me töötame selle kallal. Sest see on väga mugav, kui infra ütleb, et kui sa kirjutad sellises ja sellises formaadis sellisesse ja sellisesse kohta ja mitte rohkem kui N sõnumit sekundis, siis me toimetame selle suure tõenäosusega kohale. See võtab ära palju peavalu. Kui SLA on olemas, on see lihtsalt suurepärane!
Kuidas me probleemi lahendama hakkasime? Põhireha oli td-agendiga. Oli ebaselge, kuhu meie palgid lähevad. Kas need tarnitakse? Kas nad lähevad? Kus nad üldse on? Seetõttu otsustati td-agent asendada esimese elemendiga. Võimalusi, millega seda asendada, kirjeldasin siin lühidalt.
Fluentd. Esiteks puutusin ma temaga kokku eelmisel töökohal ja ka ta kukkus seal perioodiliselt. Teiseks on see sama, ainult profiilis.
filebeat. Kuidas see meile hea oli? Asjaolu, et ta on Go-s ja meil on Go valdkonnas suured teadmised. Vastavalt sellele, kui midagi, võiksime selle kuidagi endale lisada. Sellepärast me seda ei võtnud. Et ei tekiks isegi kiusatust hakata seda enda jaoks ümber kirjutama.
Sysadmini jaoks on ilmselgeks lahenduseks kõikvõimalikud syslogid selles koguses (syslog-ng/rsyslog/nxlog).
Või kirjutage midagi oma, aga me jätsime selle kõrvale, nagu ka filebeat. Kui kirjutate midagi, siis on parem kirjutada midagi äri jaoks kasulikku. Palkide kohaletoimetamiseks on parem võtta midagi valmis.
Seetõttu taandus valik tegelikult valikule syslog-ng ja rsyslogi vahel. Ma kaldusin rsyslogi poole lihtsalt seetõttu, et meil olid juba Puppetis rsyslogi klassid ja ma ei leidnud nende vahel ilmset erinevust. Mis on syslog, mis on syslog. Jah, mõni dokumentatsioon on halvem, mõni parem. Ta teab seda teed ja teeb seda teisiti.
Ja natuke rsyslogist. Esiteks on see lahe, kuna sellel on palju mooduleid. Sellel on inimloetav RainerScript (kaasaegne konfiguratsioonikeel). Suurepärane boonus on see, et saame jäljendada td-agendi käitumist selle standardsete tööriistadega ja rakenduste jaoks pole midagi muutunud. See tähendab, et muudame td-agendi rsyslogiks ega puuduta veel kõike muud. Ja kohe saame töökorras tarne. Järgmiseks on mmnormalize rsyslogi lahe asi. See võimaldab teil logisid sõeluda, kuid mitte Groki ja regexpi abil. See loob abstraktse süntaksipuu. See parsib logisid samamoodi nagu kompilaator lähtekoodi. See võimaldab teil töötada väga kiiresti, süüa vähe CPU-d ja üldiselt on see lihtsalt väga lahe asi. Seal on hunnik muid boonuseid. Ma ei hakka neil pikemalt peatuma.
rsyslogil on palju rohkem puudusi. Need on umbes samad kui boonused. Peamised probleemid on selles, et peate oskama seda küpsetada ja peate valima versiooni.
Otsustasime, et kirjutame logid unixi pesasse. Ja mitte kaustas /dev/log, sest seal on meil süsteemilogide segadus, selles konveieris on journald. Nii et kirjutame kohandatud pesasse. Lisame selle eraldi reeglistikule. Ärgem segagem midagi. Kõik saab olema läbipaistev ja arusaadav. Nii me tegelikult tegimegi. Nende pistikupesadega kataloog on standardiseeritud ja edastatakse kõikidesse konteineritesse. Konteinerid näevad vajalikku pistikupesa, avavad ja kirjutavad sinna.
Miks mitte faili? Sest kõik on lugenud , mis üritas faili dockerisse edastada ja leidis, et pärast rsyslogi taaskäivitamist muutub faili deskriptor ja docker kaotab selle faili. Ta hoiab lahti midagi muud, aga mitte sama pesa, kuhu nad kirjutavad. Otsustasime, et läheme sellest probleemist mööda ja samal ajal ka blokeerimisprobleemist.
Rsyslog teeb slaidil näidatud toimingud ja saadab logid kas releele või Kafkale. Kafka järgib vanaviisi. Rayleigh – proovisin logide edastamiseks kasutada puhast rsyslogi. Ilma sõnumijärjekorrata, kasutades standardseid rsyslogi tööriistu. Põhimõtteliselt see toimib.
Kuid on nüansse, kuidas neid hiljem sellesse osasse toppida (Logstash/Graylog/ES). Seda osa (rsyslog-rsyslog) kasutatakse andmekeskuste vahel. Siin on tihendatud tcp link, mis võimaldab säästa ribalaiust ja vastavalt sellele kuidagi suurendada tõenäosust, et saame mõnest teisest andmekeskusest logid, kui kanal on täis. Sest meil on Indoneesia, kus kõik on halvasti. Seal peitubki pidev probleem.
Mõtlesime, kuidas me tegelikult jälgime, kui suure tõenäosusega rakendusest salvestatud logid selleni jõuavad? Otsustasime alustada mõõdikutega. Rsyslogil on oma statistika kogumise moodul, millel on mingisugused loendurid. Näiteks võib see näidata teile järjekorra suurust või seda, kui palju sõnumeid sellise ja sellise toimingu jaoks saabus. Nendelt saab juba midagi võtta. Lisaks on sellel kohandatud loendurid, mida saate konfigureerida, ja see näitab teile näiteks sõnumite arvu, mille mõni API on salvestanud. Järgmiseks kirjutasin Pythonis rsyslog_exporter ja saatsime selle kõik Prometheusele ja joonistasime. Tahtsime väga Graylogi mõõdikuid, kuid seni pole meil olnud aega neid seadistada.
Millised on probleemid? Probleem tekkis sellega, et saime teada (ÄKKI!), et meie Live API-d kirjutavad 50 12 sõnumit sekundis. See on ainult reaalajas API ilma lavastuseta. Ja Graylog näitab meile ainult XNUMX tuhat sõnumit sekundis. Ja tekkiski mõistlik küsimus, et kus on jäänused? Millest järeldasime, et Graylog lihtsalt ei saa hakkama. Vaatasime ja tõepoolest, Graylog koos Elasticsearchiga ei suutnud seda voogu juhtida.
Järgmiseks muud avastused, mille oleme sellel teel teinud.
Pistikupesasse kirjutamine on blokeeritud. Kuidas see juhtus? Kui kasutasin kohaletoimetamiseks rsyslogi, siis mingil hetkel lõhkusime andmekeskuste vahelise kanali. Kättetoimetamine tõusis ühes kohas, kohaletoimetamine tõusis teises kohas. Kõik see on taandunud masinale, millel on API-d, mis kirjutavad rsyslogi pesasse. Tekkis järjekord. Seejärel täitus unixi pesasse kirjutamise järjekord, mis vaikimisi on 128 paketti. Ja järgmine write() rakendusplokkides. Kui vaatasime teeki, mida Go rakendustes kasutame, siis seal oli kirjas, et pesasse kirjutamine toimub mitteblokeerivas režiimis. Olime kindlad, et midagi ei blokeeritud. Sest me oleme lugenud kes sellest kirjutas. Kuid on hetk. Selle kõne ümber oli ka lõpmatu silmus, mille käigus üritati pidevalt sõnumit pistikupessa suruda. Me ei märganud teda. Pidin raamatukogu ümber kirjutama. Sellest ajast on see mitu korda muutunud, kuid nüüd oleme kõigis alamsüsteemides lukkudest lahti saanud. Seetõttu võite rsyslogi peatada ja midagi ei kuku.
Tuleb jälgida järjekordade suurust, mis aitab sellele rehale mitte astuda. Esiteks saame jälgida, millal hakkame sõnumeid kaotama. Teiseks saame jälgida, et meil on põhimõtteliselt probleeme kohaletoimetamisega.
Ja veel üks ebameeldiv hetk - 10-kordne võimendamine mikroteenuse arhitektuuris on väga lihtne. Meil ei ole nii palju sissetulevaid päringuid, kuid graafiku tõttu, mida mööda need sõnumid edasi jooksevad, suurendame juurdepääsulogide tõttu logide koormust umbes kümme korda. Kahjuks ei jõudnud ma täpseid numbreid välja arvutada, aga mikroteenused on mis nad on. Seda tuleb meeles pidada. Selgub, et hetkel on Lazadas kõige rohkem koormatud palgikogumise alamsüsteem.
Kuidas lahendada elastsearch probleemi? Kui teil on vaja logid kiiresti ühes kohas hankida, et mitte kõigist masinatest läbi jooksta ja neid sinna koguda, kasutage failisalvestust. See toimib garanteeritult. Seda tehakse mis tahes serverist. Peate lihtsalt kettad sinna kleepima ja syslogi panema. Pärast seda on teil garanteeritud, et kõik palgid on ühes kohas. Siis on võimalik aeglaselt konfigureerida elasticsearch, graylog või midagi muud. Kuid teil on juba kõik logid ja pealegi saate neid salvestada, kui kettamassiivid on piisavalt.
Minu aruande ajal hakkas skeem välja nägema selline. Peaaegu lõpetasime faili kirjutamise. Nüüd suure tõenäosusega lülitame jäänused välja. Kohalikes masinates, kus töötab API, lõpetame failidesse kirjutamise. Esiteks on failide salvestusruum, mis töötab väga hästi. Teiseks, nendel masinatel saab pidevalt ruum otsa, peate seda pidevalt jälgima.
See Logstashi ja Graylogiga osa on tõesti hüppeline. Seetõttu peate sellest vabanema. Sa pead valima ühe.
Otsustasime Logstashi ja Kibana maha jätta. Sest meil on turvaosakond. Mis on seos? Seos on selles, et Kibana ilma X-Packita ja ilma Shieldita ei võimalda logidele juurdepääsuõigusi eristada. Seetõttu võtsid nad Graylogi. Sellel on kõik olemas. Mulle ei meeldi, aga töötab. Ostsime uue riistvara, paigaldasime sinna värske Graylogi ja kolisime kõik rangete vormingutega logid eraldi Graylogi. Oleme organisatsiooniliselt lahendanud probleemi erinevate samade valdkondade tüüpidega.
Mis täpselt uues Graylogis sisaldub. Kirjutasime just kõik dokkerisse. Võtsime hunniku servereid, käivitasime kolm Kafka eksemplari, 7 Graylogi serveri versiooni 2.3 (sest ma tahtsin Elasticsearchi versiooni 5). Kõik see tõstatati HDD-lt tehtud haarangute käigus. Nägime indekseerimiskiirust kuni 100 tuhat sõnumit sekundis. Nägime arvu, et 140 terabaiti andmemahtu nädalas.
Ja jälle reha! Meil on tulemas kaks müüki. Oleme jõudnud üle 6 miljoni postituse. Meil Graylogil pole aega närida. Kuidagi tuleb jälle ellu jääda.
Nii jäime ellu. Lisatud on veel mõned serverid ja SSD-d. Hetkel me elame nii. Nüüd närime juba 160 XNUMX sõnumit sekundis. Me ei ole veel piiri saavutanud, seega on ebaselge, kui palju me sellest reaalselt välja saame.
Need on meie tulevikuplaanid. Tõesti, neist kõige olulisem on ilmselt kõrge saadavus. Meil pole seda veel. Mitu autot on samamoodi seadistatud, kuid seni käib kõik ühe auto kaudu. Nendevahelise tõrkesiirde seadistamiseks on vaja aega kulutada.
Koguge Graylogist mõõdikuid.
Tehke kiiruspiirang, et meil oleks üks hull API, mis ei tapa meid ribalaiust ega kõike muud.
Ja lõpuks sõlmige arendajatega SLA, et saaksime nii palju teenindada. Kui rohkem kirjutad, siis vabandust.
Ja kirjutage dokumente.
Lühidalt kõige selle tulemused, mida oleme kogenud. Esiteks standardid. Teiseks on syslog kook. Kolmandaks töötab rsyslog täpselt nii, nagu see slaidil kirjas. Ja asume küsimuste juurde.
küsimused.
Küsimus: Miks nad otsustasid mitte võtta ... (filebeat?)
Vastus: tuleb faili kirjutada. Ma tõesti ei tahtnud. Kui teie API kirjutab tuhandeid sõnumeid sekundis, isegi kui pöörlete kord tunnis, pole see ikkagi valik. Saate kirjutada torusse. Mille peale arendajad küsisid minult: "Mis juhtub, kui protsess, mille käigus kirjutame, kukub ära"? Ma lihtsalt ei leidnud, mida neile vastata ja ütlesin: "Noh, okei, ärgem tehkem seda."
Küsimus: Miks te lihtsalt HDFS-i logisid ei kirjuta?
VastusV: See on järgmine samm. Mõtlesime sellele kohe alguses, aga kuna hetkel pole sellega tegelemiseks ressursse, jääb see meie pikaajalise lahenduse vahele.
Küsimus: veeruvorming oleks sobivam.
Vastus: saan aru. Oleme kahe käega "poolt".
Küsimus: Sa kirjutad rsyslogi. Seal on saadaval nii TCP kui ka UDP. Aga kui UDP, siis kuidas garanteerite kohaletoimetamise?
VastusV: On kaks punkti. Esiteks ütlen kohe kõigile, et me ei garanteeri palkide kohaletoomist. Sest kui arendajad tulevad ja ütlevad: "Hakkame sinna finantsandmeid kirjutama ja paned need meile kuhugi, kui midagi peaks juhtuma," vastame neile: "Tore! Alustame pesasse kirjutamise blokeerimist ja teeme seda tehingutes, et saaksite selle kindlasti meie eest pessa panna ja veenduda, et saime selle teiselt poolt kätte. Ja sel hetkel muutuvad kõik kohe ebavajalikuks. Ja kui ei, siis millised küsimused meil on? Kui te ei taha garanteerida pistikupessa kirjutamist, siis miks me garanteerime kohaletoimetamise? Anname endast parima. Püüame tõesti tarnida nii palju kui võimalik ja nii hästi kui võimalik, kuid me ei anna 100% garantiid. Seetõttu ei pea te sinna finantsandmeid kirjutama. Selleks on olemas tehingute andmebaasid.
Küsimus: Kui API genereerib logisse mõne teate ja annab juhtimise üle mikroteenustele, kas olete kokku puutunud probleemiga, et sõnumid erinevatest mikroteenustest saabuvad vales järjekorras? Selle tõttu tekib segadus.
VastusV: See on normaalne, et need tulevad erinevas järjekorras. Peate selleks valmis olema. Kuna mis tahes võrgu kohaletoimetamine ei taga teile tellimust või peate kulutama selleks eriressursse. Kui võtame failimälu, salvestab iga API logid oma faili. Pigem lagundab rsyslog need sealseteks kataloogideks. Igal API-l on seal oma logid, kuhu saab minna vaatama ja siis saab neid selles logis ajatempli järgi võrrelda. Kui nad lähevad Graylogi otsima, siis seal sorteeritakse nad ajatempli järgi. Seal saab kõik korda.
Küsimus: ajatempel võib millisekundite kaupa erineda.
Vastus: ajatempli genereerib API ise. See on tegelikult kogu mõte. Meil on NTP. API loob ajatempli juba sõnumis endas. Seda ei lisa rsyslog.
Küsimus: Andmekeskuste vaheline suhtlus ei ole väga selge. Andmekeskuse raames on selgelt näha, kuidas logisid koguti ja töödeldi. Kuidas on andmekeskuste vaheline suhtlus? Või elab iga andmekeskus oma elu?
Vastus: Peaaegu. Iga riik asub ühes andmekeskuses. Meil ei ole praegu levitamist, nii et üks riik on paigutatud erinevatesse andmekeskustesse. Seetõttu pole vaja neid kombineerida. Iga keskuse sees on logirelee. See on Rsyslogi server. Tegelikult kaks juhtimismasinat. Need on seadistatud samamoodi. Kuid praegu käib liiklus lihtsalt ühest neist läbi. Ta logib kõik agregaadid. Sellel on igaks juhuks kettajärjekord. Ta pressib palke ja saadab need kesksesse andmekeskusesse (Singapur), kus neid juba Graylogis mürgitatakse. Ja igal andmekeskusel on oma failide salvestusruum. Kui ühendus katkeb, on meil kõik logid seal. Sinna nad jäävadki. Neid hoitakse seal.
Küsimus: Kas sa saad sealt ebanormaalsete olukordade ajal palke?
Vastus: võite minna sinna (failihoidlasse) ja vaadata.
Küsimus: Kuidas jälgida, et logid kaotsi ei läheks?
Vastus: Me kaotame need tegelikult ja me jälgime seda. Järelevalve algas kuu aega tagasi. Go API-de kasutataval teegil on mõõdikud. Ta suudab kokku lugeda, mitu korda tal ei õnnestunud pesasse kirjutada. Praegu on seal keeruline heuristika. Seal on puhver. See proovib kirjutada sellest pesasse sõnumi. Kui puhver ületab, hakkab see neid maha jätma. Ja ta loeb, kui palju ta neid maha lasi. Kui loendurid hakkavad seal üle ajama, saame sellest teada. Nad on nüüd tulemas ka Prometheusesse ja Grafanas näete graafikuid. Saate seadistada hoiatusi. Kellele neid saata, pole aga veel selge.
Küsimus: elasticsearchis salvestate liiasusega palke. Mitu koopiat teil on?
Vastus: Üks koopia.
Küsimus: Kas see on ainult üks rida?
Vastus: See on juht ja koopia. Andmed salvestatakse kahes eksemplaris.
Küsimus: Kas sa muutsid kuidagi rsyslogi puhvri suurust?
Vastus: kirjutame datagrammid kohandatud unixi pesasse. See seab meile kohe 128 kilobaidi piirangu. Me ei saa sellesse rohkem kirjutada. Oleme selle standardisse kirjutanud. Kes tahab hoiule pääseda, kirjutab 128 kilobaiti. Lisaks lõikavad raamatukogud ära ja panevad lipu, et sõnum on ära lõigatud. Meil on sõnumi enda standardis spetsiaalne väli, mis näitab, kas see katkes salvestamise ajal või mitte. Seega on meil võimalus seda hetke jälgida.
küsimus: Kas kirjutate katkist JSON-i?
Vastus: Katkine JSON visatakse kas edastamise ajal kõrvale, kuna pakett on liiga suur. Või Graylog loobutakse, kuna see ei saa JSON-i sõeluda. Kuid siin on nüansse, mis vajavad parandamist, ja need on enamasti seotud rsyslogiga. Olen seal juba paar numbrit täitnud, millega tuleb veel tööd teha.
küsimus: Miks Kafka? Kas olete proovinud RabbitMQ-d? Hallpall ei anna sellise koormuse all kokku?
Vastus: Graylogiga see ei õnnestu. Ja Graylog võtab kuju. See on tema jaoks tõesti problemaatiline. Ta on omamoodi asi. Ja tegelikult pole seda vaja. Ma pigem kirjutan rsyslogist otse elasticsearchi ja vaatan siis Kibanat. Kuid me peame selle küsimuse turvameestega lahendama. See on meie arenduse võimalik variant, kui viskame Graylogi välja ja kasutame Kibanat. Logstashil pole mõtet. Sest ma saan sama teha ka rsyslogiga. Ja sellel on moodul elasticsearchi kirjutamiseks. Graylogiga üritame kuidagi elada. Me isegi muutsime seda natuke. Kuid arenguruumi on veel.
Kafka kohta. Nii see ajalooliselt juhtus. Kui kohale jõudsin, oli see juba olemas ja sinna kirjutati juba logisid. Tõstsime just oma klastri üles ja teisaldasime sinna palke. Me juhime teda, me teame, mida ta tunneb. Mis puutub RabbitMQ-sse... meil on RabbitMQ-ga probleeme. Ja RabbitMQ areneb meie jaoks. Meil on see tootmises ja sellega oli probleeme. Nüüd, enne müüki, oleks ta šamaniseeritud ja ta hakkaks normaalselt töötama. Kuid enne seda polnud ma valmis seda tootmisse laskma. Üks punkt on veel. Graylog saab lugeda AMQP 0.9 versiooni ja rsyslog kirjutada AMQP 1.0 versiooni. Ja pole ühtegi lahendust, mis suudaks mõlemat keskel teha. On kas üht või teist. Nii et praegu ainult Kafka. Kuid on ka nüansse. Kuna meie kasutatava rsyslogi versiooni omkafka võib kaotada kogu sõnumipuhvri, mille ta rsyslogist üles võttis. Niikaua kui me selle välja kannatame.
küsimus: Kas kasutate Kafkat, sest teil oli see? Kas pole muuks otstarbeks kasutatud?
Vastus: Kafka, mida kasutas Data Science'i meeskond. See on täiesti eraldi projekt, mille kohta ma kahjuks midagi öelda ei oska. Ma ei tea. Teda juhtis andmeteaduse meeskond. Kui palgid hakkasid, otsustasid nad seda kasutada, et mitte oma panna. Nüüd oleme Graylogi värskendanud ja oleme kaotanud ühilduvuse, kuna on olemas Kafka vana versioon. Pidime ise tegema. Samal ajal saime iga API puhul neist neljast teemast lahti. Tegime ühe laia ülaosa kõigile otse-eetris, ühe laia laia ülaosa kõigi lavastuste jaoks ja pildistame kõike seal. Graylog rehab seda kõike paralleelselt.
küsimus: Milleks meile seda pistikupesadega šamanismi vaja on? Kas olete proovinud konteinerite jaoks kasutada syslogi logidraiverit?
Vastus: Sel ajal, kui me selle küsimuse esitasime, olid meil dokiga pingelised suhted. See oli docker 1.0 või 0.9. Docker ise oli imelik. Teiseks, kui sa sinna ka palke topid... Mul on kontrollimata kahtlus, et see laseb kõik palgid ise läbi dokkedeemoni. Kui meil on üks API hulluks minemas, siis ülejäänud API-d satuvad sellesse, et nad ei saa saata stdout ja stderr. Ma ei tea, kuhu see välja viib. Mul on tunde tasandil kahtlus, et selles kohas pole vaja dockeri syslogi draiverit kasutada. Meie funktsionaalse testimise osakonnal on oma logidega klaster Graylog. Nad kasutavad dockeri logi draivereid ja tundub, et kõik on korras. Aga nad kirjutavad kohe Graylogile GELFi. Sel hetkel, kui me seda kõike alustasime, oli meil vaja, et see lihtsalt toimiks. Ehk hiljem, kui keegi tuleb ja ütleb, et sada aastat on normaalselt toiminud, siis proovime.
küsimus: edastate andmekeskuste vahel rsyslogi abil. Miks mitte Kafkas?
Vastus: Me teeme seda ja nii see tegelikult on. Kahel põhjusel. Kui kanal on täiesti surnud, siis kõik meie palgid, isegi kokkusurutud kujul, sellest läbi ei roni. Ja kafka võimaldab neil selle käigus lihtsalt kaotada. Nii saame lahti nende palkide kinnijäämisest. Me kasutame sel juhul lihtsalt Kafkat. Kui meil on hea kanal ja tahame selle vabastada, siis kasutame nende rsyslogi. Kuid tegelikult saate selle seadistada nii, et see kaotab selle, mida ta läbi ei saanud. Hetkel kasutame lihtsalt rsyslogi kohaletoimetamist otse kuhugi, kuskile Kafkasse.
Allikas: www.habr.com