Logid on süsteemi oluline osa, mis aitab mõista, kas see töötab (või ei tööta) nagu oodatud. Mikroteenuste arhitektuuri tingimustes muutub logidega tegelemine iseseiseks distsipliiniks, millel on oma ametlik olümpia. Peame lahendama hulga küsimusi:
- kuidas kirjutada logisid rakendusest;
- kuhu kirjutada logisid;
- kuidas edastada logisid salvestamiseks ja töötlemiseks;
- kuidas logisid töödelda ja salvestada.
Kasutatavate populaarsete konteineritehnoloogiate ilmumine lisab lahenduse leevendamisele veelgi rohkem komponente.
Just sellest räägib Juri Bushmlevi ettekande tõlgendus "Labyrindid logide kogumise ja edastamise alal".
Huvitav, palun vaata edasi.
Mina olen Juri Bushmlev. Töötab Lazadas. Täna räägin, kuidas me oma logisid koostasime, kuidas me neid kogusime ja mida me sinna kirjutame.
Kust me oleme? Kes me oleme? Lazada on number 1 e-poe platvorm kuues Kagu-Aasia riigis. Kõik need riigid on jaotatud meie andmekeskuste vahel. Praegu on meil kokku 4 andmekeskust. Miks see on oluline? Sest mõned lahendused olid tingitud sellest, et andmekeskuste vahel on väga nõrk ühendus. Meil on mikroteenuste arhitektuur. Olles üllatunud, avastasin, et meil on juba 80 mikroteenust. Kui ma logide ülesande alustasin, oli neid ainult 20. Lisaks on meil suur osa PHP pärandist, millega tuleb ka leppida. Kõik see genereerib praeguseks rohkem kui 6 miljonit teadet minutis kogu süsteemi kohta. Edasi näitan, kuidas me sellega elama püüame ja miks see on nii.
Neid 6 miljonit teadet tuleb kuidagi hallata. Mida me nendega peame tegema? 6 miljonit teadet, mille tuleb:
- saata rakendusest
- vastu võtta edastamiseks
- edastada analüüsiks ja salvestamiseks.
- analüüsida
- kuidagi salvestada.
Kui kolmes miljonis teadet oli, oli mu nägu umbes selline. Sest alustasime mingitest tillukestest numbritest. On selge, et sinna kirjutatakse rakenduste logisid. Näiteks, ei saanud andmebaasiga ühendada, sain andmebaasiga ühendada, kuid ei saanud midagi lugeda. Kuid lisaks sellele kirjutab iga meie mikroteenus ka juurdepääsulogi. Iga päring, mis jõuab mikroteenusesse, langeb logisse. Miks me seda teeme? Arendajad soovivad jälgimise võimalust. Igas juurdepääsulogis on väljakutset ideaal tunnus, mille kaudu eriline liides rollib kogu ahelat ja näitab jälgimist. Jälgimine näitab, kuidas päring liikuda, ja see aitab meie arendajatel kiiresti toime tulla igasuguste tuvastamata asjaoludega.
Kuidas sellega elada? Nüüd räägin lühidalt valikutest — kuidas see probleem üldiselt lahendatakse. Kuidas lahendada logide kogumise, edastamise ja salvestamise ülesanne.
Kuidas kirjutada rakendusest? Selge, et on erinevaid viise. Eelkõige on olemas parim praktika, nagu moodne rahvas ütleb. On ka vana kool mitmesugustes vormides, nagu vanaisad rääkisid. On ka teisi viise.
Logide kogumise osas on olukord umbes sama. Selle konkreetse osa lahendamiseks ei ole palju variantsioonide. Need on ju hakanud rohkemaks saama, kuid ikka veel on neid vähe.
Kuid edastamise ja edasise analüüsi osas -- variantide arv hakkab plahvatama. Ma ei hakka nüüd iga varianti kirjeldama. Arvan, et põhivariandid on kõigile tuttavad, kes on selle temaatikaga kursis.
Klassides näitan, kuidas me Lazadas seda teostasime ja kuidas kõik see algas.
Aasta tagasi tulin Lazadasse ja mind saadeti logide projekti peale. Seal oli olukord umbes selline. Log rakendusest kirjutati stdout- ja stderr-isse. Kõik läks moodsa moe järgi. Kuid edaspidi viskavad arendajad selle standardvoogudest välja, ja edaspidi saavad infrastruktuuri spetsialistid sellega hakkama. Infrastruktuuri spetsialistide ja arendajate vahel on veel vabatahtlikud, kes ütlesid: "öö... noh, laske meil lihtsalt see faili pakkida shelliga ja kõik". Kuna see kõik on konteineris, siis pakiti see otse konteinerisse, ning kaust suunati sisse ja pandi sinna. Usun, et kõigile on enam-vähem selge, mis sellest välja tuli.
Vaadakem nüüd natuke edasi, kuidas me neid logisid edastasime. Keegi valis td-agendi, mis tegelikult on fluentd, kuid ei ole päris fluentd. Ma ei saanud aru, mis suhe nende kahe projekti vahel on, kuid nad paistavad tegelevat sama asjaga. Ja see fluentd, mis on kirjutatud Rubys, luges logifailid, parsis need JSON-iks mingite regulaarsete väljendite kaudu. Siis saatis need Kafka'sse. Samuti oli ipi kohta 4 eraldi teemat. Miks 4? Sest on live, on testimisruum, ja seetõttu on stdout ja stderr. Arendajad genereerivad neid, ja infrastruktuuri spetsialistid peavad need Kafka'sse looma. Ja Kafka kontrollis teine osakond. Seega tuli luua pilet, et nad saaksid iga ipi jaoks 4 teemat luua. Kõik unustasid sellest. Kokkuvõttes oli see üks õudus ja itsitamine.
Mida me selle kõikaga tegime? Me saatsime selle Kafka süsteemi. Sealt edasi läks pool logidest Logstashi. Teine pool jagunes. Üks osa läks ühte Graylogi, teine osa põrutas teise Graylogi. Kõik see sattus lõpuks ühte Elasticsearch klastrisse. See tähendab, kogu see segadus langes lõpuks sinna. Nii ei tohi teha!
Nii see välja näeb, kui vaadata kõrvalt. Nii ei tohi teha! Siin on numbritega kohe ära märgitud probleemsed kohad. Tegelikult neid on rohkem, aga kuus neist on tõeliselt probleemsed, millega tuleb midagi ette võtta. Nendest räägin nüüd eraldi.
Siin (1,2,3) kirjutatakse meil faile ja seega on siin kohe kolm peamist probleemi.
Esimene (1) — meil on neid kuidagi kuhugi kirjutada. Alati ei soovi anda API-le võimalust otse faili kirjutada. Soovitav on, et API oleks isoleeritud konteineris, ja veel parem — kui see oleks read-only. Mina olen süsteemiadministraator, seega on mul nende asjade üle veidi alternatiivne vaade.
Teine punkt (2,3) — me saame API-sse palju päringuid. API kirjutab palju andmeid faili. Failid kasvavad. Me peame neid rotatsioonima. Sest vastasel juhul ei ole diskiruumi piisavalt. Rotatsioon on halb, sest need on shelli kaudu redirigeeritud katalooge. Me ei saa seda rotatsioonida. Ei saa öelda rakendusele, et see avaks descriptorid uuesti. Sest arendajad vaatavad sind nagu lollile: „Millistest deskriptoritest? Me kirjutame üldse stdout’i.” Infrastruktuuriinimesed tegid copytruncate logrotate’is, mis teeb lihtsalt faili koopia ja truncates originaali. Seega, nende kopeerimise protsesside vahel lõppeb tavaliselt ketta ruum.
(4) Meil oli erinevaid formaate erinevates API-des. Need erinesid veidi, kuid erinevaid regexp-sid tuli kirjutada. Kuna seda haldati Puppetiga, oli seal suur klasside kogum oma veidrustega. Pluss veel, et td-agent suutis suure osa ajast mälu süüa, venida ja isegi lihtsalt teeselda, et ta töötab, kuid mitte midagi ei teinud. Väljastpoolt oli võimatu mõista, et ta mitte midagi ei tee. Parimal juhul kukkus ta kokku ja keegi tõstis ta hiljem jälle üles. Täpsemalt ütlemata, tuli alert ja keegi läks käsitsi uuesti üles tõstma.
(6) Ja kõige hullem oligi Elasticsearch. Sest see oli vana versioon. Kuna meil ei olnud tol ajal eraldatud meistreid. Meil olid heterogeensed logid, mille omadused võisid kattuda. Erinevad logid erinevatest rakendustest võisid olla kirjutatud samade väljade nimedega, aga sees võisid olla erinevad andmed. Näiteks, üks logi tuleb Integeriga väljal, näiteks level. Teine logi tuleb Stringiga väljal level. Ilma staatilise mappimiseta saavad tekkida sellised toredad asjad. Kui pärast Elasticsearchi indeksi rotatsiooni tuleb esimesena sõnum, mis on string, siis elame normaalselt. Aga kui esimene sõnum on Integeriga, siis kõik järgnevad sõnumid, mis tulevad stringiga, lihtsalt lükatakse kõrvale. Sest välja tüüp ei kattu.
Me hakkasime endalt neid küsimusi küsima. Otsustasime mitte otsida süüdlasi.
Aga midagi tuleb siiski ette võtta! Ilmselge asi — tuleb luua standardid. Mõned standardid olid juba olemas. Mõned kehtestasime pisut hiljem. Õnneks oli tol hetkel juba kinnitatud ühtne logiformaat kõikidele API-dele. See on kirjas teenuste koostöö standardites. Seega, need, kes tahavad logisid saada, peavad need kirjutama sellele formaadile. Kui keegi ei kirjuta logisid selle formaadi järgi, siis ei garanteeri me midagi.
Edasi, tahaksime kehtestada ühtse standardi logide kirjutamise, toimetamise ja kogumise viiside kohta. Täpselt, kuhu neid kirjutada ja millega neid toimetada. Ideaalne olukord on, kui projektides kasutatakse ühte ja sama teeki. On olemas eraldi logimise teek Go jaoks, eraldi teek PHP jaoks. Kõik, kes meie juures on — peavad neid kasutama. Hetkel ütleksin, et umbes 80% meil see õnnestub. Kuid mõned jätkavad kaktuste söömisega.
Ja seal (slaidil) hakkab vaevu paistma „SLA logide tarnimiseks”. Seda pole veel, kuid me töötame selle nimel. Sest see on väga mugav, kui infrastruktuuri inimesed ütlevad, et kui te kirjutate sellisesse formaati sellesse kohta ja mitte rohkem kui N sõnumit sekundis, siis me toimetame selle sinna tõenäosusega. See vabastab palju peavalu. Kui SLA on olemas, siis on see lihtsalt suurepärane!
Kuidas me probleemiga hakkasime tegelema? Peamine probleem oli td-agentiga. Ei olnud selge, kuhu meie logid kaovad. Kas need toimetatakse? Kas need kogutakse? Kus need üldse on? Seetõttu otsustati esimesena asendada td-agent. Valikute kohta, millega seda asendada, olen siin lühidalt üles kirjutanud.
Fluentd. Esiteks olen sellega varem kokku puutunud, ja seal see aeg-ajalt tõrkus. Teiseks, see on sama asi, ainult spetsiifilisemalt.
Filebeat. Miks see meie jaoks mugav oli? Sest see on kirjutatud Go-s, ja meil on Go-s suur ekspertüritus. Seega, kui midagi vajasime, saime seda edasi arendada. Seetõttu me seda ei võtnud. Et meie jaoks polnud mingit kiusatust seda oma vajadustele kohandama hakkata.
Selge valik systadminile jäävad igasugused logide töötlemise teenused (syslog-ng/rsyslog/nxlog).
Või kirjutada midagi oma, kuid me sellest loobusime, samuti filebeatist. Kui midagi kirjutada, siis on parem luua midagi kasulikku äri jaoks. Logide edastamiseks on parem võtta midagi valmis.
Seega langes valik sisuliselt syslog-ng ja rsyslog vahel. Kaldusin rsyslogi poole, kuna meil olid Puppetis juba rsyslogi klassid, ja ma ei leidnud nende vahel selget erinevust. Seal on syslog ja siin on syslog. Jah, kellelgi on halvem dokumentatsioon, kellelgi parem. Üks suudab seda, teine seda.
Ja natuke rsyslogist. Esiteks, see on tore, sest sellel on palju mooduleid. Sellel on arusaadav RainerScript (kaasaegne konfiguratsioonikeel). Suurepärane boonuse on see, et me suutsime selle oma vahenditega emuleerida td-agent'i käitumist, nii et rakendusele ei muutunud midagi. See tähendab, et asendame td-agent'i rsyslogiga ja kõik muu jääb muutmata. Ja kohe saame töötava edastuse. Edasi, mmnormalize — see on geniaalne asi rsyslogis. See võimaldab logisid analüüsida, kuid mitte Groki ja regexpiga. See loob abstraktse süntaksipuu. See analüüsib logisid umbes nagu compiler analüüsib lähtekoodi. See võimaldab töötada väga kiiresti, tarbida vähe CPU-d ja on üldiselt väga äge asi. Seal on tohutult muid boonusfunktsioone. Ma ei peatuks nende juures.
Rsynlogil on veel palju puudusi. Need on enamasti samad, mis boonused. Peamised probleemid on seotud selle ettevalmistamisega ja vajaliku versiooni valimisega.
Otsustasime, et kirjutame logid unix socketisse. Ja mitte /dev/log-i, sest seal on meil kapp süsteemsete logide vahel, seal on journald selles kanalis. Seega, kirjutame kohandatud socketisse. Ühendame selle eraldi reeglistikuga. Me ei sega midagi. Kõik on selge ja arusaadav. Just nii me tegime. See sokettide kataloog on standardiseeritud ja edastatud kõikidesse konteineritesse. Konteinerid saavad näha neile vajalikku socketit, avada ja sinna kirjutada.
Miks mitte fail? Sest kõik on lugenud , kus prooviti faile Dockerisse edastada ja leiti, et pärast rsyslogi taaskäivitamist muutub failide descriptor ning Docker kaotab selle faili. Ta hoiab avatud midagi muud, kuid mitte seda socketit, kuhu kirjutatakse. Otsustasime, et lahendame selle probleemi, ja samal ajal lahendame ka lukustamise probleem.
Rsyslog teostab slaidil näidatud tegevusi ja saadab logid kas ralia või Kafkasse. Kafka vastab vanale meetodile. Ralia — proovisin kasutada ainult rsyslogi logide edastamiseks. Ilma sõnumijärjekorrata, tavaliste rsyslogi vahenditega. Üldiselt see toimib.
Aga on nüansse, kuidas need siis tegelikult sinna ossa (Logstash/Graylog/ES) saada. See osa (rsyslog-rsyslog) kasutatakse andmekeskuste vahel. Siin on kompressiooniga tcp-link, mis säästab ribalaiust ja seega suurendab tõenäosust, et me saame logisid teistest andmekeskustest, kui kanal on ummistunud. Sest meil on Indoneesia, kus kõik on halvasti. Seal on see pidev probleem.
Mõtleme sellele, kuidas me saame jälgida, kui tõenäoliselt logid, mida me rakendusest salvestame, siia lõpuni jõuavad? Otsustasime luua statistikat. Rsynlogil on oma statistika kogumise moodul, kus on mõned loendurid. Näiteks võib see näidata, kui suur on järjekord või kui palju sõnumeid on tulnud teatud toimingusse. Need on midagi, millest saame lähtuvalt midagi teha. Lisaks on tal kohandatavad loendurid, mida saab seadistada ja see näitab teile, näiteks, kui palju sõnumeid mõni API on salvestanud. Edasi, kirjutasin rsyslog_exporter'i Pythonis, ja saatsime kõik Prometheusesse ja ehitasime graafikud. Graylogi mõõdikute seadmine oli väga soovitav, kuid hetkel pole me seda veel teinud.
Millised probleemid tekkisid? Probleemid tekkisid seetõttu, et me avastasime (ÜLLATAVALT!), et meie Live API kirjutavad 50k sõnumit sekundis. See on ainult Live API ilma staginguta. Graylog näitab meile ainult 12 tuhat sõnumit sekundis. Ja tekkis põhjendatud küsimus, aga kus on ülejäänud? Millest tegime järelduse, et Graylog lihtsalt ei suuda sellega toime tulla. Vaadates, tõepoolest, Graylog ja Elasticsearch ei suuda seda voogu taluda.
Edasi, muud avastused, millega me protsessi käigus kokku puutusime.
Socketi kirjutamine on blokeeritud. Kuidas see juhtus? Kui ma kasutasin rsyslog'i andmete edastamiseks, purunes ühel hetkel kanal andmekeskuste vahel. Üks edastus seiskus, teine seiskus. Kõik see jõudis masinani API'ga, mis kirjutab rsyslog'i socketisse. Seal täitus järjekord. Siis täitus järjekord Unix socket'i kirjutamiseks, mis on vaikimisi 128 paketti. Ja järgmine write() rakenduses blokeerus. Kui me vaatasime raamatukogu, mida kasutame Go rakendustes, oli seal kirjas, et socket'i kirjutamine toimub mitteblokeerivas režiimis. Me olime kindlad, et midagi ei blokeeru. Sest me lugesime, , mis sellest kirjutas. Aga seal on üks nüanss. Selle kutse ümber oli veel lõputu tsükkel, kus pidevalt üritati sõnumit socket'isse suruda. Seda me ei märganud. Pidiime raamatukogu ümber kirjutama. Sellest ajast on see mitmel korral muutunud, kuid praegu oleme kõikidest allüksustest blokeeringutest vabanenud. Seega saab rsyslog'i peatada, ja midagi ei kuku alla.
Peame jälgima järjekordade suurust, mis aitab vältida nende ämbrite peale astumist. Esiteks, me saame jälgida, millal hakkame sõnumeid kaotama. Teiseks, saame jälgida, kas meil on üldiselt probleeme edastamisega.
Ja veel üks ebameeldiv hetk — amplifikatsioon 10 korda mikroteenuste arhitektuuris — see on väga lihtne. Meil ei ole nii palju sisendeid, kuid nende sõnumitega edasiviiv graaf, access-log'id tõttu, suurendab tegelikult logide koormust umbes kümme korda. Kahjuks ei jõudnud ma täpseid numbreid arvestada, kuid mikroteenused — need on sellised. Seda tuleb silmas pidada. Tundub, et praegu on logide kogumise allüksus — kõige koormatum Lazadas.
Kuidas lahendada elasticsearch'i probleem? Kui on vaja kiiresti logisid ühte kohta saada, et mitte joosta ringi kõigis masinates ja ei koguda neid seal, kasuta failide salvestust. See töötab garanteeritult. See tehakse igast serverist. Pead lihtsalt sinna kettad panema ja syslog'i seadma. Pärast seda on sul garanteeritult kõik logid ühes kohas. Edasi saab rahulikult seadistada elasticsearch'i, graylog'i, või midagi muud. Kuid sul on juba kõik logid, ja sa võid neid hoida, kui palju kettaribad piisavad.
Minu ettekande hetkeks nägi skeem välja selline. Faili me praktiliselt ei kirjuta. Praegu tõenäoliselt lülitame viimased välja. Kohalikud masinad, kus API-d käivituvad, me ei hakka enam failidesse kirjutama. Esiteks on olemas failide salvestus, mis töötab väga hästi. Teiseks, neil masinatel on pidevalt ruum otsa saanud, tuleb seda pidevalt jälgida.
See osa Logstashist ja Graylogist ajab tõeliselt närvi. Seetõttu tuleb sellest vabaneda. Tuleb valida midagi ühte.
Me otsustasime Logstash'i ja Kibana eemaldada. Sest meil on turbosakonn, mis seondub. Side on selles, et Kibana ilma X-Pack'i ja Shieldita ei võimalda logide juurdepääsu õiguste piiramist. Seetõttu võtsime Graylog'i. Seal on kõik olemas. Mulle see ei meeldi, aga see töötab. Ostime uue riistvara, installisime sinna värske Graylog'i ja kandsime kõik logid ranged formaadid eraldi Graylog'i. Me lahendasime probleemid erinevate sama tüüpi väljadega organisatsiooniliselt.
Mis tegelikult uude Graylog'i kuulub. Me lihtsalt panime kõik Dockerisse. Võtsime hulk servereid, jaotatäit 3 instantsi Kafka'd, 7 serverit Graylog'i versioonis 2.3 (sest soovisin Elasticsearch'i versiooni 5). Kõik see tõsteti RAID-idega HDD-dest. Nägime indekseerimismäära kuni 100 000 sõnumit sekundis. Nägime numbrit, et 140 terabaidi andmeid nädalas.
Ja jälle ämbrid! Meil on tulemas kaks allahindlust. Me kasutasime üle 6 miljoni sõnumi. Meie Graylog ei jõua neid töötlema. Peame jälle ellu jääma.
Ellu jäime me nii. Lisades veel mõned serverid ja SSD-d. Praegu elame sellest viisist. Nüüd töötleme juba 160k sõnumit sekundis. Me ei ole veel piirini jõudnud, seega ei ole selge, kui palju me tegelikult suudame sellest välja pigistada.
Siin on meie tulevikuplaanid. Nendest on tegelikult kõige tähtsam, võib-olla, kõrge saadavus. Meil seda praegu ei ole. Mitmed masinad on seadistatud ühtlaselt, kuid kõik liigub praegu läbi ühe masina. Tuleb aega võtta, et seadistada nende vahel failover.
Koguda mõõdikud Graylog'ilt.
Seada kiirus piirang, et üks, hull API, ei hävitaks meie ribalaiust ja kõike muud.
Ja lõpuks, kirjuta mõni SLA arendajatega, et me saame teenindada nii palju. Kui kirjutate rohkem, siis kahjuks ei saa.
Ja kirjutada dokumentatsioon.
Lühidalt, kokkuvõte kõigest, mida oleme läbi elanud. Esiteks, standardid. Teiseks, syslog — tort. Kolmandaks, rsyslog töötab just nii, nagu slaidil on kirjutatud. Ja nüüd liikume küsimuste juurde.
Küsimused.
Küsimus: Miks ikkagi otsustasite mitte võtta… (filebeat?)
Vastus: Tuleb kirjutada faili. Väga ei tahtnud. Kui teie API kirjutab tuhandeid teateid sekundis, siis isegi kui sa kord tunnis rotatsiooni teed, pole see ikkagi variant. Võib kirjutada pipe'i. Selle peale küsisid arendajad: "Mis juhtub, kui protsess, kuhu me kirjutame, kukub?" Ma ei leidnud sellele vastust ja ütlesin: "Noh, ok, siis me ei tee seda."
Küsimus: Miks te ei kirjuta logisid lihtsalt HDFS-i?
Vastus: See on järgmine etapp. Me mõtlesime selle üle alguses, kuid kuna hetkel ei ole ressursse selleks tegeleda, siis see jääb meil pikemaajalisse lahendusse.
Küsimus: Veergude formaat oleks sobivam.
Vastus: Ma saan kõigest aru. Me oleme selle poolt.
Küsimus: Te kirjutate rsyslogi. Seal on nii TCP kui ka UDP. Aga kui UDP, siis kuidas te garanteerite kohaletoimetamise?
Vastus: On kaks momenti. Esiteks, ütlen kohe, et me ei garanteeri logide kohaletoimetamist. Sest kui arendajad tulevad ja ütlevad: "Kuidas oleks, kui hakkame kirjutama finantsandmeid ja teie panete need kuhugi, ettevaatusabinõuna, kui midagi juhtub," siis me vastame: "Suurepärane! Laske teil luua blokeering kirjutamiseks soketisse ja teha seda tehingute kaupa, et me saaksime kindlustada, et te meile selle soketisse edastate ja olete veendunud, et me saime selle teiselt poolt." Ja sel hetkel kaob kõigil huvi. Kui te ei taha garanteerida kirjutamist soketisse, siis miks peaksime meie garantii andma? Me püüame anda parimat, aga me ei anna 100% garantiid. Seega, ärge kirjutage sinna finantsandmeid. Selleks on andmebaasid tehingutega.
Küsimus: Kui API genereerib mingi teate logis ja edastab juhtimise mikroteenustele, kas olete kokku puutunud probleemiga, et teated erinevatest mikroteenustest jõuavad vale järjestuses? Seetõttu tekib segadus.
Vastus: On normaalne, et need tulevad erinevas järjekorras. Selleks tuleb valmistuda. Sest kettetoimetamine ei garanteeri järjekorda, või tuleb selleks spetsiaalselt ressursse investeerida. Kui vaatame failisalvestusi, siis iga API salvestab logid oma faili. Täpsemalt öeldes, rsyslog jagab need kaustadesse. Igal API-l on oma logid, kuhu saab minna ja vaadata ning hiljem timestamp'i järgi neid kokku viia. Kui nad vaatavad Graylogis, siis seal need järjestatakse timestamp'i järgi. Kõik on korras.
Küsimus: Timestamp võib erineda millisekondide võrra.
Vastus: Timestamp genereerib ise API. Selles ongi kogu asi. Meil on NTP. API genereerib timestamp'i juba sõnumis. Seda ei lisa rsyslog.
Küsimus: Ei ole väga selge andmekeskuste vahelise koostöö osas. Andmekeskuse raames on aru saada, kuidas logid koguti, töödeldi. Kuidas toimub koostöö andmekeskuste vahel? Kas iga andmekeskus elab oma elu?
Vastus: Peaaegu. Igas riigis on mingi andmekeskus. Meil ei ole hetkel hajutamist, et ühes riigis oleks mitu andmekeskust. Seega ei pea neid ühendama. Iga keskuse sees on Log Relay. See on Rsyslog server. Tegelikult on seal kaks haldusmasinat. Need on ühtmoodi seadistatud. Kuid praegu läheb lihtsalt liiklus läbi ühe neist. See kogub kõik logid. Sellel on disk queue igaks juhuks. See tihendab logisid ja saadab need kesksetesse andmekeskustesse (Singapur), kus need saadetakse edasi Graylogi. Ja igas andmekeskuses on oma failide salvestus. Kui meil kaob ühendus, siis on meil kõik logid seal. Need jäävad sinna. Need säilivad.
Küsimus: Äärmuslikes olukordades saate sealt logid?
Vastus: Võib minna sinna (failisüsteemi) ja vaadata.
Küsimus: Kuidas te jälgite, et te ei kaota logisid?
Vastus: Tegelikult me kaotame neid ja me jälgime seda. Jälgimine käivitus kuu aega tagasi. Go API-s kasutatavas teegis on meetrika. See suudab arvutada, mitu korda tal ei õnnestunud soketisse kirjutada. Seal on hetkel nutikas heuristika. Seal on buffer. See püüab kirjutada selle kaudu sõnumi soketisse. Kui buffer täitub, hakkab see neid langetama. Ja loendab, kui palju ta on langetanud. Kui seal hakkavad loendurid täituma, saame sellest teada. Need jõuavad ka prometheus'e kaudu ning Grafanas saab vaadata graafikuid. Saame seada teavitusi. Kuid praegu pole selge, kellele neid saata.
Küsimus: Elasticsearchis hoidsite logisid varukoopiate kaupa. Kui palju teil on koopiaid?
Vastus: Üks koopia.
Küsimus: See on kõigest üks koopia?
Vastus: See, see, what this master and replica are. Data is stored in two instances.
Küsimus: Have you somehow adjusted the rsyslog buffer size?
Vastus: We write datagrams to a custom Unix socket. This immediately imposes a limit of 128 kilobytes. We cannot write more than that. We have specified this in the standard. Those who want to reach the storages write 128 kilobytes. Libraries, by the way, truncate and set a flag indicating that the message has been truncated. In our standard message, there is a special field that shows whether it was truncated when written or not. So we have the ability to track this moment.
Question: Do you write broken JSON?
Vastus: Broken JSON will be discarded either during relay due to oversized packet or will be discarded by Graylog because it cannot parse the JSON. But there are nuances that need fixing, and they are mostly linked to rsyslog. I have filled out several issues there that still need work.
Question: Why Kafka? Have you tried RabbitMQ? Is Graylog not working under such loads?
Vastus: We have issues with Graylog. Graylog has issues with us. It's a peculiar thing. And, to be honest, it's not necessary. I would prefer to write directly from rsyslog to Elasticsearch and then check Kibana. But we need to settle issues with the security team. This is a possible direction for our development, where we might discard Graylog and use Kibana. Using Logstash wouldn’t make sense. Because I can accomplish the same functionalities with rsyslog. And it has a module for writing to Elasticsearch. We're trying to coexist with Graylog. We've even slightly tuned it. But there's still room for improvement.
Regarding Kafka. It historically happened that way. When I came, it was already there, and logs were already being written to it. We just raised our cluster and migrated logs into it. We manage it; we know how it feels. On RabbitMQ... we don't get along with RabbitMQ. But RabbitMQ works fine for us. We have it in production, and there were problems with it. Just before the sale, it was tuned, and it started working properly. But before that, I was not ready to release it to production. There's another point. Graylog can read version AMQP 0.9, while rsyslog can write version AMQP 1.0. And there is no solution that can handle both. It's either one or the other. So at this moment, only Kafka is available. But that also has its nuances. Because the omkafka of the version of rsyslog that we are using can lose the entire buffer of messages that it pulled from rsyslog. For now, we’re living with it.
Question: You use Kafka because it was available? Not for any other purposes?
Vastus: The Kafka that existed is used by the Data Science team. It's a completely separate project that I unfortunately cannot comment on. I'm not aware of its details. It was under the management of the Data Science team. When logs were introduced, they decided to use it so as not to set up a separate one. Now we've upgraded Graylog, and we've lost compatibility because there's an old version of Kafka. We had to set up our own. In the process, we eliminated those four topics for each API. We created one wide topic for all live activities, one wide topic for all staging and just shoot everything into it. Graylog extracts everything in parallel.
Question: Why this sorcery with sockets? Have you tried using a syslog log driver for containers?
Vastus: When we were asking ourselves this question, our relationship with Docker was strained. It was Docker 1.0 or 0.9. Docker itself was strange. Secondly, if you also push logs into it… I have an unverified suspicion that it passes all logs through itself, through the Docker daemon. If one API goes haywire, other APIs get stuck because they cannot send stdout and stderr. I don't know what it will lead to. I have a hunch that we should not use the Docker syslog driver at this point. Our functional testing department has its own little Graylog cluster with logs. They use Docker log drivers and supposedly everything is fine there. But they write GELF directly into Graylog. At that time, when we were doing all this, we needed it to just work. Maybe later, if someone comes and says it has been working fine for ages, we will give it a try.
Question: You make delivery between data centers on rsyslog. Why not on Kafka?
Vastus: Me teeme nii ja naa tegelikult. Kahel põhjusel. Kui kanal on täiesti katki, siis ei mahtu meie logid isegi kokkusurutud kujul sinna. Kafka võimaldab neid lihtsalt kaduma läinud protsessi jooksul. Sel viisil vabanevad me nendest logide ummistustest. Me kasutame antud juhul otse Kafka't. Kui meil on hea kanal ja soovime seda vabastada, siis kasutame nende rsyslog'i. Kuid tegelikult saab seda seadistada nii, et see viskab ise välja, mis ei mahtu. Praegu kasutame mõnes kohas otse rsyslog'i kohaletoimetamist, mõnes Kafka't.
Allikas: habr.com
