Logs binne in wichtich part fan it systeem, sadat jo begripe dat it wurket (of wurket net) lykas ferwachte. Under de betingsten fan mikroservicearsjitektuer wurdt wurkjen mei logs in aparte dissipline fan 'e Special Olympiade. D'r binne in protte problemen dy't oanpakt wurde moatte:
- hoe te skriuwen logs út de applikaasje;
- wêr te skriuwen logs;
- hoe te leverjen logs foar opslach en ferwurking;
- hoe te ferwurkjen en opslaan logs.
It gebrûk fan op it stuit populêre kontenerisaasjetechnologyen foeget sân ta oan 'e rake op it mêd fan opsjes foar probleemoplossing.
Krekt oer dit is it transkripsje fan it rapport fan Yuri Bushmelev "Kaart fan in rake op it mêd fan it sammeljen en leverjen fan logs"
Wa makket it út, asjebleaft ûnder de kat.
Myn namme is Yuri Bushmelev. Ik wurkje foar Lazada. Hjoed sil ik prate oer hoe't wy ús logs makken, hoe't wy se sammele, en wat wy dêr skriuwe.
Wêr komme wy wei? Wa binne wy? Lazada is de #1 online retailer yn seis lannen yn Súdeast-Aazje. Al dizze lannen binne ferdield ûnder datasintra. D'r binne no yn totaal 4 datasintra. Wêrom is dit wichtich? Want guon besluten kamen troch it feit dat der in tige swakke skeakel is tusken de sintra. Wy hawwe in microservice-arsjitektuer. Ik wie ferrast om te finen dat wy al 80 mikrotsjinsten hawwe. Doe't ik begon mei de taak mei logs, wiene d'r mar 20. Plus, d'r is in frij grut stik PHP-legacy, dêr't ik ek mei libje moat en mei. Dit alles genereart foar ús op it stuit mear as 6 miljoen berjochten per minuut foar it systeem as gehiel. Fierder sil ik sjen litte hoe't wy besykje te libjen mei dit, en wêrom dit is sa.
Jo moatte op ien of oare manier mei dizze 6 miljoen berjochten libje. Wat moatte wy dwaan mei harren? 6 miljoen berjochten nedich:
- ferstjoere fan app
- akseptearje foar levering
- leverje foar analyse en opslach.
- analysearje
- winkel ien of oare manier.
Doe't d'r trije miljoen berjochten wiene, hie ik sawat itselde uterlik. Want wy begûnen mei wat pennies. It is dúdlik dat dêr applikaasje logs skreaun wurde. Bygelyks, koe net ferbine mei de databank, koe ferbine mei de databank, mar koe net lêze wat. Mar njonken dit skriuwt elk fan ús mikrotsjinsten ek in tagongslogboek. Elk fersyk dat oankomt by de mikrotsjinst falt yn it log. Wêrom dogge wy dit? Untwikkelders wolle kinne trace. Elk tagongslogboek befettet it traceid-fjild, neffens dêr't in spesjale ynterface dan de heule ketting ûntwikkelt en it spoar prachtich toant. It spoar lit sjen hoe't it fersyk gie, en dit helpt ús ûntwikkelders omgean mei elk ûnbekend jiskefet flugger.
Hoe libje mei it? No sil ik it fjild fan opsjes koart beskriuwe - hoe't dit probleem oer it algemien wurdt oplost. Hoe kinne jo it probleem oplosse fan it sammeljen, oerdragen en opslaan fan logs.
Hoe skriuw ik út 'e applikaasje? It is dúdlik dat der ferskate manieren binne. Benammen d'r is bêste praktyk, lykas modieuze kameraden ús fertelle. Der binne twa soarten fan âlde skoalle, sa't pakes seinen. Der binne oare manieren.
Mei it sammeljen fan logs is de situaasje sawat itselde. D'r binne net safolle opsjes foar it oplossen fan dit bepaalde diel. Der binne mear fan harren, mar noch net safolle.
Mar mei levering en folgjende analyze begjint it oantal fariaasjes te eksplodearjen. Ik sil no elke opsje net beskriuwe. Ik tink dat de wichtichste opsjes goed bekend binne foar elkenien dy't ynteressearre wie yn it ûnderwerp.
Ik sil jo sjen litte hoe't wy it dien hawwe by Lazada en hoe't it allegear begon.
In jier lyn kaam ik nei Lazada en waard stjoerd nei it logprojekt. Dêr wie it sa. It log fan 'e applikaasje waard skreaun nei stdout en stderr. Alles waard dien op in modieuze manier. Mar doe smieten de ûntwikkelders it út 'e standertstreamen, en dan sille ynfrastruktuerspesjalisten it op ien of oare manier útfine. Tusken ynfrastruktuerspesjalisten en ûntwikkelders binne d'r ek releasers dy't seine: "uh ... no, litte wy se gewoan yn in bestân mei in shell ferpakke, en dat is it." En om't dit alles yn in kontener is, ferpakten se it krekt yn 'e kontener sels, mapden de map deryn en sette it dêr. Ik tink dat it foar elkenien frij dúdlik is wat der bard is.
Lit ús efkes fierder sjen. Hoe wy levere dizze logs. Immen keas td-agent, dy't eins floeiend is, mar net hielendal floeiend. Ik begryp de relaasje fan dizze twa projekten noch net, mar se lykje oer itselde te gean. En dizze floeiende, skreaun yn Ruby, lês logbestannen, parsearde se yn JSON mei guon reguliere útdrukkingen. Doe waarden se nei Kafka stjoerd. Boppedat hienen wy yn Kafka 4 aparte ûnderwerpen foar elke API. Wêrom 4? Om't der live is, is der staging, en om't der stdout en stderr is. Ûntwikkelers produsearje se, en ynfrastruktuer arbeiders moatte meitsje se yn Kafka. Boppedat waard Kafka kontrolearre troch in oare ôfdieling. Dêrom wie it nedich om in kaartsje te meitsjen sadat se dêr 4 ûnderwerpen makken foar elke api. Elkenien fergeat it. Yn it algemien wie it jiskefet en ôffal.
Wat hawwe wy der fierder mei dien? Wy stjoerde it nei kafka. Fierder fan Kafka ôf fleach de helte fan de stammen nei Logstash. De oare helte fan de logs waarden dield. Guon fleagen nei de iene Graylog, guon nei in oare Graylog. Dêrtroch fleach dit alles yn ien Elasticsearch-kluster. Dat is, al dy rommel foel dêr op 't lêst. Dat hoege jo net te dwaan!
Dit is hoe't it liket as fan boppen sjoen. Dat hoege jo net te dwaan! Hjir binne de probleemgebieten fuortendaliks markearre mei sifers. Der binne eins mear fan, mar 6 binne echt problematysk, dêr't wat mei dien wurde moat. Ik sil der no apart oer fertelle.
Hjir (1,2,3) skriuwe wy triemmen en dêrtroch binne d'r hjir trije harken tagelyk.
De earste (1) is dat wy se earne skriuwe moatte. It is net altyd winsklik om in API de mooglikheid te jaan om direkt nei in bestân te skriuwen. It is winsklik dat de API wurdt isolearre yn in kontener, en noch better, dat it is read-allinnich. Ik bin in systeembehearder, dus ik haw in bytsje alternative werjefte fan dizze dingen.
It twadde punt (2,3) is dat wy in protte oanfragen hawwe dy't nei de API komme. De API skriuwt in protte gegevens nei in bestân. De triemmen groeie. Wy moatte se draaie. Want oars kinne jo dêr gjin skiven opslaan. Rotearje se is min omdat se wurde omlaat fia de shell nei in map. D'r is gjin manier wêrop wy it kinne draaie. Jo kinne de applikaasje net fertelle om de handgrepen opnij te iepenjen. Om't de ûntwikkelders jo sjogge as in gek: "Wat beskriuwers? Wy skriuwe oer it algemien nei stdout. De kaders makke copytruncate yn logrotate, dy't gewoan in kopy fan it bestân makket en it orizjineel trunk. Dêrtroch rint skiifromte normaal tusken dizze kopiearjen prosessen op.
(4) Wy hiene ferskate formaten yn ferskate API's. Se wiene wat oars, mar regexp moast oars skreaun wurde. Sûnt it waard allegear beheard troch Puppet, der wie in grutte boskje klassen mei harren eigen kakkerlakken. Plus, td-agent koe meastentiids ûnthâld ite, dom wêze, hy koe gewoan dwaan as hy wurke en neat dwaan. Uterlik wie it net te begripen dat er neat die. Op syn bêst sil er falle, en immen sil him letter ophelje. Mear krekter, in warskôging sil yn fleane, en immen sil gean en ferheegje it mei har hannen.
(6) En it measte jiskefet en ôffal - it wie elastysk sykjen. Want it wie in âlde ferzje. Want wy hienen doe gjin tawijde masters. Wy hiene heterogene logs wêrfan de fjilden oerlaapje koenen. Ferskillende logs fan ferskate applikaasjes kinne skreaun wurde mei deselde fjildnammen, mar tagelyk kinne d'r ferskate gegevens binnen wêze. Dat is, ien log komt mei in Integer yn in fjild, bygelyks, nivo. In oar log komt mei in String yn it nivo fjild. By it ûntbrekken fan statyske mapping blykt sa'n prachtich ding. As, nei yndeksrotaasje, earst in berjocht mei in tekenrige yn elasticsearch kaam, dan libje wy normaal. En as de earste oankaam mei Integer, dan wurde alle folgjende berjochten dy't oankamen mei String gewoanwei wegere. Omdat it fjild type net oerien.
Wy begûnen dizze fragen te stellen. Wy besletten net te sykjen nei de skuldige.
Mar der moat wat dien wurde! It foar de hân lizzende ding is dat wy noarmen moatte fêststelle. Wy hiene al wat noarmen. Guon brochten wy efkes letter. Gelokkich wie in inkeld logformaat foar alle API's op dat stuit al goedkard. It is skreaun direkt yn de tsjinst ynteraksje noarmen. Dêrom moatte dejingen dy't logboeken ûntfange wolle se yn dit formaat skriuwe. As immen gjin logs yn dit formaat skriuwt, dan garandearje wy neat.
Fierder wol ik in inkele standert hawwe foar de metoaden foar it opnimmen, leverjen en sammeljen fan logs. Eigentlik, wêr't se se skriuwe, en hoe se se leverje. De ideale situaasje is as projekten deselde bibleteek brûke. D'r is in aparte logbibleteek foar Go, d'r is in aparte biblioteek foar PHP. Elkenien dy't wy hawwe, elkenien moat se brûke. Op dit stuit soe ik sizze dat wy mei 80 prosint slagje. Mar guon bliuwe kaktussen ite.
En dêr (op 'e slide) begjint de "SLA foar levering fan logboeken" amper te ferskinen. It is der noch net, mar wy wurkje der oan. Want it is hiel handich as ynfra seit dat as je yn sa’n en sa’n opmaak op sa’n en sa’n plak skriuwe en net mear as N berjochten per sekonde, dan leverje wy it dêr nei alle gedachten. It nimt in soad hoofdpijn fuort. As d'r in SLA is, dan is it gewoan geweldich!
Hoe binne wy begon it probleem op te lossen? De wichtichste rake wie mei td-agent. It wie ûndúdlik wêr't ús logs hinne geane. Binne se levere? Gean se? Wêr binne se dochs? Dêrom waard besletten om td-agent te ferfangen troch it earste item. Opsjes foar wat it ferfange mei, haw ik hjir koart sketst.
Fluentd. Earst kaam ik him by in eardere baan tsjin, en hy foel dêr ek periodyk. Twad, dit is itselde, allinnich yn profyl.
filebeat. Hoe wie it goed foar ús? It feit dat hy is yn Go, en wy hawwe in grutte ekspertize yn Go. Dêrtroch, as der wat is, kinne wy it op ien of oare manier oan ússels tafoegje. Dêrom hawwe wy it net nommen. Sadat der net iens in ferlieding wêze soe om it foar josels te herskriuwen.
De foar de hân lizzende oplossing foar de sysadmin is alle soarten syslogs yn dizze kwantiteit (syslog-ng/rsyslog/nxlog).
Of skriuw wat fan jo eigen, mar wy hawwe it wegere, lykas filebeat. As jo wat skriuwe, dan is it better om wat nuttich te skriuwen foar bedriuw. Om logs te leverjen, is it better om wat klear te nimmen.
Dêrom kaam de kar eins del op in kar tusken syslog-ng en rsyslog. Ik leane nei rsyslog gewoan om't wy al klassen hiene foar rsyslog yn Puppet, en ik fûn gjin dúdlik ferskil tusken har. Wat is syslog, wat is syslog. Ja, guon dokumintaasje is slimmer, wat better. Hy wit dizze manier, en hy docht it oars.
En in bytsje oer rsyslog. Earst is it cool, om't it in protte modules hat. It hat in minsklik lêsber RainerScript (moderne konfiguraasjetaal). In geweldige bonus is dat wy it gedrach fan td-agent koene emulearje mei syn standert ark, en neat is feroare foar applikaasjes. Dat is, wy feroarje td-agent nei rsyslog, en reitsje al it oare noch net. En daliks krije wy in wurkjende levering. Folgjende, mmnormalize is it coole ding oer rsyslog. It makket it mooglik om te parse logs, mar net mei Grok en regexp. It makket in abstrakte syntaksisbeam. It parseart logs op in protte deselde manier as in kompiler boarnekoade parseart. Hjirmei kinne jo heul rap wurkje, lytse CPU ite, en yn 't algemien is it gewoan in heul cool ding. Der binne in boskje oare bonussen. Ik scil net by hjarren dwaen.
rsyslog hat folle mear neidielen. Se binne oer itselde as bonussen. De wichtichste problemen binne dat jo moatte kinne koken it, en jo moatte selektearje in ferzje.
Wy besletten dat wy logs skriuwe yn in unix-socket. En net yn /dev/log, om't wy dêr in puinhoop fan systeemlogboeken hawwe, is d'r journald yn dizze pipeline. Dus litte wy skriuwe nei in oanpaste socket. Wy sille it hechtsje oan in aparte regelset. Lit ús neat bemuoie. Alles sil transparant en begryplik wêze. Dat diene wy eins. De map mei dizze sockets wurdt standerdisearre en trochstjoerd nei alle konteners. Containers kinne de socket sjen dy't se nedich binne, iepenje en skriuwe.
Wêrom gjin triem? Want elkenien hat lêzen , dy't besocht de triem troch te stjoeren nei docker, en fûn dat nei it opnij starte fan rsyslog, de triembeskriuwing feroaret, en docker ferliest dit bestân. Hy hâldt wat oars iepen, mar net deselde socket dêr't se skriuwe. Wy besletten dat wy dit probleem sille omgean, en tagelyk it blokkearjende probleem omgean.
Rsyslog docht de aksjes oanjûn op 'e slide en stjoert logs nei estafette of Kafka. Kafka folget de âlde wei. Rayleigh - Ik besocht suver rsyslog te brûken om logs te leverjen. Sûnder Message Queue, mei help fan standert rsyslog-ark. Yn prinsipe wurket it.
Mar d'r binne nuânses mei hoe't jo se letter yn dit diel stopje (Logstash / Graylog / ES). Dit diel (rsyslog-rsyslog) wurdt brûkt tusken datacenters. Hjir is in komprimearre tcp-keppeling, wêrmei jo bânbreedte kinne besparje en, sadwaande, op ien of oare manier de kâns fergrutsje dat wy wat logs fan in oar datasintrum sille ûntfange as it kanaal fol is. Want wy hawwe Yndoneezje, dêr't alles min is. Dat is wêr't it konstante probleem leit.
Wy tochten oer hoe't wy eins kontrolearje, mei hokker kâns berikke de logs dy't wy fan 'e applikaasje opnommen hawwe dat ein? Wy besletten om metriken te begjinnen. Rsyslog hat in eigen statistyksammelmodule, dy't in soarte fan tellers hat. It kin jo bygelyks de grutte fan de wachtrige sjen litte, of hoefolle berjochten binnenkamen foar sa en sa aksje. Jo kinne al wat fan harren nimme. Plus, it hat oanpaste tellers dy't jo kinne konfigurearje, en it sil sjen litte jo, bygelyks, it oantal berjochten dat guon API hat opnommen. Dêrnei skreau ik rsyslog_exporter yn Python, en wy stjoerde it allegear nei Prometheus en plotten. Wy woenen wirklik Graylog-metriken, mar oant no hawwe wy gjin tiid hân om se yn te stellen.
Wat binne de problemen? It probleem ûntstie mei it feit dat wy fûnen út (YNOLLEN!) Dat ús Live API's 50k berjochten per sekonde skriuwe. Dit is allinich Live API sûnder staging. En Graylog lit ús mar 12 tûzen berjochten per sekonde sjen. En der kaam in ridlike fraach op, wêr binne de oerbliuwsels? Dêrút hawwe wy konkludearre dat Graylog gewoan net kin omgean. Wy seagen, en yndie, Graylog mei Elasticsearch behearske dizze stream net.
Folgjende, oare ûntdekkingen dy't wy hawwe makke ûnderweis.
Skriuwen nei socket wurde blokkearre. Hoe is it bard? Doe't ik rsyslog brûkte foar levering, hawwe wy op in stuit it kanaal tusken de datasintra brutsen. De levering kaam op it iene plak op, de levering kaam op in oar plak. Dit alles is delkommen op in masine mei API's dy't skriuwe nei de rsyslog-socket. Der stie in wachtrige. Dan foltôge de wachtrige foar it skriuwen nei de unix-socket, dy't standert 128 pakketten is. En de folgjende skriuw() yn 'e applikaasjeblokken. Doe't wy seagen nei de bibleteek dy't wy brûke yn Go-applikaasjes, waard dêr skreaun dat it skriuwen nei de socket yn net-blokkearjende modus bart. Wy wiene der wis fan dat neat wie blokkearre. Om't wy hawwe lêzen dy't der oer skreau. Mar der is in momint. D'r wie ek in ûneinige lus om dizze oprop hinne, wêrby't in konstant besocht waard om in berjocht yn 'e socket te triuwen. Wy hawwe him net opmurken. Ik moast de bibleteek opnij skriuwe. Sûnt dy tiid is it ferskate kearen feroare, mar no hawwe wy slûzen yn alle subsystemen kwyt. Dêrom kinne jo stopje rsyslog en neat sil falle.
It is needsaaklik om de grutte fan 'e wachtrigen te kontrolearjen, wat helpt om net op dizze rake te stappen. Earst kinne wy kontrolearje wannear't wy berjochten begjinne te ferliezen. As twadde kinne wy kontrolearje dat wy yn prinsipe problemen hawwe mei levering.
En in oar onaangenaam momint - fersterking troch 10 kear yn in microservice-arsjitektuer is heul maklik. Wy hawwe net safolle ynkommende oanfragen, mar troch de grafyk wêrop dizze berjochten fierder rinne, fanwegen de tagongslogs, ferheegje wy de lading op 'e logs eins mei sa'n tsien kear. Spitigernôch hie ik gjin tiid om de krekte nûmers te berekkenjen, mar mikrotsjinsten binne wat se binne. Dit moat yn gedachten hâlden wurde. It docht bliken dat op it stuit it logkolleksje subsysteem it meast laden is yn Lazada.
Hoe kinne jo it probleem fan elastysk sykjen oplosse? As jo logs fluch op ien plak moatte krije, om net oer alle masines te rinnen en se dêr te sammeljen, brûk dan bestân opslach. Dit is garandearre om te wurkjen. It wurdt dien fan elke server. Jo moatte gewoan skiven dêr plakke en syslog sette. Dêrnei binne jo garandearre dat jo alle logs op ien plak hawwe. Dan sil it mooglik wêze om stadich te konfigurearjen elasticsearch, greylog, of wat oars. Mar jo sille al alle logs hawwe, en boppedat kinne jo se opslaan, foarsafier't d'r genôch skiif-arrays binne.
Yn 'e tiid fan myn rapport begon it skema der sa út te sjen. Wy binne praktysk opholden mei skriuwen nei it bestân. No sille wy wierskynlik de oerbliuwsels útsette. Op lokale masines dy't de API útfiere, sille wy ophâlde mei skriuwen nei bestannen. Earst is d'r bestânsopslach, dy't heul goed wurket. Twads, dizze masines wurde hieltyd út romte, jo moatte konstant tafersjoch op it.
Dit diel mei Logstash en Graylog, it sjit echt. Dêrom moatte jo it kwytreitsje. Jo moatte kieze ien.
Wy besletten om te fallen Logstash en Kibana. Want wy hawwe in feiligens ôfdieling. Wat is de ferbining? De ferbining is dat Kibana sûnder X-Pack en sûnder Shield net tastean jo te ûnderskieden tagongsrjochten ta de logs. Dêrom namen se Graylog. It hat it allegear. Ik fyn it net leuk, mar it wurket. Wy kochten nije hardware, ynstallearre in frisse Graylog dêr, en ferhuze alle logs mei strang formaten nei in aparte Graylog. Wy hawwe oplost it probleem mei ferskate soarten fan deselde fjilden organisatoarysk.
Wat is krekt opnommen yn 'e nije Graylog. Wy hawwe krekt alles yn 'e docker skreaun. Wy namen in boskje servers, rôle trije Kafka-eksimplaren út, 7 Graylog-tsjinners ferzje 2.3 (om't ik Elasticsearch ferzje 5 woe). Dit alles waard opbrocht op ynfallen fan de HDD. Wy seagen in yndeksearjen fan maksimaal 100 tûzen berjochten per sekonde. Wy seagen it sifer dat 140 terabytes oan gegevens per wike.
En wer in hark! Wy hawwe twa ferkeap kommende. Wy binne ferpleatst foarby 6 miljoen berjochten. Wy Graylog hat gjin tiid om te kauwen. Op ien of oare manier moatte jo wer oerlibje.
Dit is hoe't wy oerlibbe. In pear mear servers en SSD's tafoege. Op it stuit libje wy sa. No kauwen wy al 160k berjochten per sekonde. Wy hawwe de limyt noch net berikt, dus it is ûndúdlik hoefolle wy der realistysk út kinne krije.
Dit binne ús plannen foar de takomst. Fan dizze, echt, it wichtichste is wierskynlik hege beskikberens. Wy hawwe it noch net. Ferskate auto's binne op deselde wize opset, mar oant no ta giet alles troch ien auto. It is nedich om tiid te besteegjen om in failover tusken har op te stellen.
Sammelje metriken fan Graylog.
Meitsje in taryflimyt sadat wy ien gekke API hawwe dy't ús bânbreedte en al it oare net deadet.
En as lêste, tekenje in soarte fan SLA mei ûntwikkelders, sadat wy safolle kinne tsjinje. As jo mear skriuwe, sorry dan.
En skriuw dokumintaasje.
Koartsein, de resultaten fan alles wat wy hawwe belibbe. Earst, de noarmen. Twad, syslog is taart. Tredde, rsyslog wurket krekt sa't it is skreaun op 'e dia. En litte wy nei de fragen komme.
Jo fragen.
de fraach: Wêrom hawwe se besletten net te nimmen ... (filebeat?)
Reply: Moatte skriuwe nei in triem. Ik woe eins net. As jo API tûzenen berjochten per sekonde skriuwt, sels as jo ien kear yn 'e oere rotearje, is dit noch altyd gjin opsje. Jo kinne skriuwe nei pipe. Dêrfoar fregen de ûntwikkelders my: "Wat sil barre as it proses wêryn wy skriuwe falt"? Ik fûn gewoan net wat ik se antwurdzje moast en sei: "Nou, ok, litte wy dat net dwaan."
de fraach: Wêrom skriuwe jo net gewoan logs nei HDFS?
ReplyA: Dit is de folgjende poadium. Wy tochten der oan it begjin oer, mar om't d'r op it stuit gjin middels binne om dermei om te gean, hinget it yn ús oplossing op lange termyn.
de fraach: In kolomformaat soe geskikter wêze.
Reply: Ik begryp it. Wy binne "foar" mei beide hannen.
de fraach: Jo skriuwe nei rsyslog. Sawol TCP as UDP binne dêr beskikber. Mar as UDP, hoe garandearje jo dan levering?
ReplyA: Der binne twa punten. Earst fertel ik elkenien fuortendaliks dat wy de levering fan logs net garandearje. Want as de ûntwikkelders komme en sizze: "Litte wy dêr finansjele gegevens begjinne te skriuwen, en jo sille it earne foar ús pleatse foar it gefal dat der wat bart," antwurdzje wy har, "Geweldich! Litte wy begjinne te blokkearjen op skriuwen nei de socket, en doch it yn transaksjes, sadat jo garandearre binne om it yn 'e socket foar ús te setten en derfoar te soargjen dat wy it fan' e oare kant krigen. En op dit stuit wurdt elkenien fuortendaliks net nedich. En sa net, hokker fragen hawwe wy dan? As jo net wolle garandearje in skriuwe nei de socket, dan wêrom soene wy garandearje levering? Wy meitsje de bêste ynspannings. Wy besykje echt safolle mooglik en sa goed mooglik te leverjen, mar wy jouwe gjin 100% garânsje. Dêrom hoege jo dêr gjin finansjele gegevens te skriuwen. D'r binne transaksjedatabases foar dit.
de fraach: As de API wat berjocht genereart nei it log en kontrôle oerdracht oan mikrotsjinsten, hawwe jo it probleem tsjinkaam dat berjochten fan ferskate mikrotsjinsten yn 'e ferkearde folchoarder komme? Hjirtroch ûntstiet betizing.
ReplyA: It is normaal dat se yn in oare folchoarder komme. Jo moatte wêze klear foar dit. Omdat eltse netwurk levering net garandearje oarder foar jo, of jo moatte besteegje spesjale middels op dit. As wy triem opslach nimme, dan bewarret elke API logs yn syn eigen bestân. Leaver, rsyslog ûntbrekt se dêr yn mappen. Elke API hat dêr syn eigen logs, wêr't jo kinne gean en sjen, en dan kinne jo se fergelykje mei it tiidstempel yn dit log. As se yn Graylog geane te sykjen, dan wurde se dêr op tiidstempel sortearre. Alles sil dêr goed komme.
de fraach: Tiidstempel kin fariearje troch millisekonden.
Reply: It tiidstempel wurdt oanmakke troch de API sels. Dit, yn feite, is it hiele punt. Wy hawwe NTP. De API genereart al in tiidstempel yn it berjocht sels. It wurdt net tafoege troch rsyslog.
de fraach: Ynteraksje tusken datasintra is net heul dúdlik. Yn it ramt fan it datasintrum is dúdlik hoe't de logs sammele en ferwurke binne. Hoe is de ynteraksje tusken datasintra? Of libbet elk datasintrum syn eigen libben?
Reply: hast. Wy hawwe elk lân yn ien datasintrum. Wy hawwe op it stuit gjin sprieding, sadat ien lân yn ferskate datasintra wurdt pleatst. Dêrom is it net nedich om se te kombinearjen. Binnen elk sintrum is d'r in Log Relay. Dit is in Rsyslog-tsjinner. Yn feite, twa behear masines. Se wurde op deselde manier ynsteld. Mar foar no giet it ferkear gewoan troch ien fan har. Se logt alles aggregaten. It hat in skiif wachtrige krekt yn gefal. Se drukt de logs en stjoert se nei it sintrale datasintrum (Singapore), wêr't se fierder al fergiftige binne yn Graylog. En elk datasintrum hat syn eigen bestannen opslach. As wy de ferbining ferlern hawwe, hawwe wy alle logs dêr. Se sille dêr bliuwe. Se wurde dêr opslein.
de fraach: Krijst dêr logboeken fan by abnormale situaasjes?
Reply: Jo kinne dêr gean (nei de triem opslach) en sjoch.
de fraach: Hoe kontrolearje jo dat jo gjin logs ferlieze?
Reply: Wy binne eins ferlieze se, en wy binne tafersjoch op it. Monitoring begûn in moanne lyn. De bibleteek dy't de Go API's brûke hat metriken. Se kin telle hoefolle kearen se mislearre te skriuwen oan socket. Dêr is op it stuit in lestige heuristyk. Dêr is in buffer. It besiket in berjocht fan it te skriuwen nei socket. As de buffer oerstreamt, begjint it se te fallen. En hy telt hoefolle hy se liet falle. As de loketten dêr oerrinne, sille wy it witte. Se komme no ek nei prometheus, en jo kinne de grafiken sjen yn Grafana. Jo kinne warskôgings ynstelle. Mar it is noch net dúdlik nei wa't se stjoere moatte.
de fraach: Yn elasticsearch bewarje jo logs mei oerstalligens. Hoefolle replika's hawwe jo?
Reply: Ien replika.
de fraach: Is it mar ien rigel?
Reply: Dit is de master en replika. De gegevens wurde opslein yn duplikaat.
de fraach: Hawwe jo de grutte fan 'e rsyslog-buffer op ien of oare manier oanpast?
Reply: Wy skriuwe datagrammen nei in oanpaste unix-socket. Dit legt ús daliks in beheining op fan 128 kilobytes. Mear kinne wy der net yn skriuwe. Wy hawwe dit yn 'e standert skreaun. Wa wol yn opslach, se skriuwe 128 kilobytes. Biblioteken, boppedat, ôfsnien, en sette in flagge dat it berjocht wurdt ôfsnien. Wy hawwe in spesjaal fjild yn 'e standert fan it berjocht sels, dat lit sjen oft it ûnder it opnimmen ôfsnien is of net. Sa hawwe wy de kâns om dit momint te folgjen.
Fraach: Skriuwst brutsen JSON?
Reply: Broken JSON sil wurde ferwidere tidens it relais, om't it pakket te grut is. Of Graylog sil falle, om't it JSON net kin parse wurde. Mar d'r binne hjir nuânses dy't reparearre wurde moatte, en se binne meast bûn oan rsyslog. Ik haw dêr al in pear nûmers ynfolle, dêr't noch oan wurke wurde moat.
Fraach: Wêrom Kafka? Hawwe jo RabbitMQ besocht? Graylog net optelle ûnder sokke loads?
Reply: It slagget net mei Graylog. En Graylog nimt foarm oan. It is echt problematysk foar him. Hy is sa'n ding. En yn feite is it net nedich. Ik skriuw leaver fan rsyslog direkt nei elasticsearch en sjoch dan Kibana. Mar wy moatte it probleem regelje mei de befeiligers. Dit is in mooglike fariant fan ús ûntwikkeling as wy Graylog útsmite en Kibana brûke. Logstash sil gjin sin meitsje. Omdat ik kin dwaan itselde mei rsyslog. En it hat in module om te skriuwen nei elasticsearch. Mei Graylog besykje wy op ien of oare manier te libjen. Wy hawwe it sels in bytsje oanpast. Mar der is noch romte foar ferbettering.
Oer Kafka. Sa barde it histoarysk. Doe't ik oankaam, wie it der al, en der waarden al logboeken op skreaun. Wy hawwe gewoan ús kluster ophelle en logs deryn ferpleatst. Wy beheare him, wy witte hoe't hy fielt. Wat RabbitMQ oanbelanget ... wy hawwe problemen mei RabbitMQ. En RabbitMQ ûntwikkelet foar ús. Wy hawwe it yn produksje, en der wiene problemen mei it. No, foar de ferkeap, soe hy sjamanisearre wurde, en hy soe normaal begjinne te wurkjen. Mar dêrfoar wie ik net ree om it yn produksje frij te litten. Der is noch ien ding. Graylog kin AMQP 0.9 ferzje lêze en rsyslog kin AMQP 1.0 ferzje skriuwe. En d'r is net ien oplossing dy't beide yn 't midden kin dwaan. D'r is ien of oare. Dus foar no allinnich Kafka. Mar der binne ek nuânses. Om't omkafka fan 'e ferzje fan rsyslog dy't wy brûke kin de hiele berjochtbuffer ferlieze dy't it ophelle út rsyslog. Salang't wy der mei opsette.
Fraach: Brûke jo Kafka om't jo it hiene? Net brûkt foar in oar doel?
Reply: Kafka, dat waard brûkt troch de Data Science team. Dit is in folslein apart projekt, dêr't ik, spitigernôch, neat oer sizze kin. Ik wit net. Se waard bestjoerd troch it team fan Data Science. Doe't de logs begûnen, besleaten se it te brûken, om har eigen net te setten. No hawwe wy Graylog bywurke, en wy hawwe kompatibiliteit ferlern, om't d'r in âlde ferzje fan Kafka is. Wy moasten ús eigen meitsje. Tagelyk hawwe wy dizze fjouwer ûnderwerpen foar elke API loslitten. Wy makken ien brede top foar alle live, ien brede brede top foar alle staging en wy sjitte dêr gewoan alles. Graylog rakes dit alles parallel.
Fraach: Wêrom hawwe wy dit sjamanisme mei sockets nedich? Hawwe jo besocht it syslog log-bestjoerder te brûken foar konteners.
Reply: Yn 'e tiid dat wy dizze fraach stelden, hienen wy spannende relaasjes mei de docker. It wie docker 1.0 of 0.9. Docker sels wie nuver. As twadde, as jo der ek logs yn skowe ... Ik haw in net ferifiearre fermoeden dat it alle logs troch himsels passeart, fia de docker-daemon. As wy ien API hawwe dy't gek is, dan sille de rest fan 'e API's yn it feit komme dat se stdout en stderr net kinne stjoere. Ik wit net wêr't dit liede sil. Ik haw in fermoeden op it nivo fan gefoel dat it net nedich is om de docker syslog-bestjoerder op dit plak te brûken. Us funksjonele testôfdieling hat in eigen Graylog-kluster mei logs. Se brûke docker log-bestjoerders en alles liket dêr goed te wêzen. Mar se skriuwe daliks GELF oan Graylog. Op it stuit dat wy dit alles begongen hiene wy it nedich om gewoan te wurkjen. Miskien letter, as der ien komt en seit dat it al hûndert jier normaal wurket, sille wy besykje.
Fraach: Jo leverje tusken datasintra mei rsyslog. Wêrom net op Kafka?
Reply: Wy dogge dit, en dit is hoe't it echt is. Om twa redenen. As it kanaal folslein dea is, dan sille al ús logs, sels yn in komprimearre foarm, der net troch klimme. En kafka lit se gewoan ferlieze yn it proses. Op dizze manier krije wy it plakjen fan dizze logs kwyt. Wy brûke gewoan Kafka yn dit gefal direkt. As wy in goed kanaal hawwe en it wolle frijmeitsje, dan brûke wy har rsyslog. Mar yn feite kinne jo it ynstelle sadat it falt wat it net trochkaam. Op it stuit brûke wy gewoan rsyslog levering direkt earne, earne Kafka.
Boarne: www.habr.com