I logs sò una parte impurtante di u sistema, chì vi permettenu di capisce chì u travagliu (o ùn funziona micca) cum'è previstu. In e cundizioni di l'architettura di microserviziu, u travagliu cù logs diventa una disciplina separata di l'Olimpiadi Speciali. Ci hè parechje prublemi chì deve esse trattatu:
- cumu scrive logs da l'applicazione;
- induve scrive logs;
- cumu furnisce logs per u almacenamentu è u processu;
- cumu processà è almacenà logs.
L'usu di tecnulugii di cuntainerizazione attualmente populari aghjunghjenu a sabbia in cima à u rake in u campu di l'opzioni di risolve i prublemi.
Appena questu hè a trascrizione di u rapportu di Yuri Bushmelev "Map of a rake in the field of collecting and delivering logs"
Quale importa, per piacè sottu à u ghjattu.
Mi chjamu Yuri Bushmelev. U travagliu per Lazada. Oghje vi parlerà di cumu avemu fattu i nostri logs, cumu l'avemu cullucatu, è ciò chì avemu scrittu quì.
Da induve simu? Quale simu? Lazada hè u venditore in linea n ° 1 in sei paesi in l'Asia sudorientale. Tutti sti paesi sò distribuiti trà i centri di dati. Ci hè avà centri di dati in totale 4. Perchè hè questu impurtante? Perchè certe decisioni sò dovute à u fattu chì ci hè un ligame assai debule trà i centri. Avemu una architettura di microserviziu. Eru sorpresu di truvà chì avemu digià 80 microservices. Quandu aghju principiatu u compitu cù i logs, ci era solu 20. In più, ci hè un pezzu abbastanza grande di legatu PHP, chì aghju ancu avè da vive è mette. Tuttu chistu genera per noi à u mumentu più di 6 milioni di missaghji per minutu in tuttu u sistema in tuttu. In più vi mustraraghju cumu si pruvemu à campà cun questu, è perchè questu hè cusì.
Avete à campà cù sti 6 milioni di missaghji in qualchì modu. Chì duvemu fà cun elli? 6 milioni di missaghji necessarii:
- mandate da l'app
- accetta per a consegna
- consegna per analisi è almacenamentu.
- analizà
- magazzinu in qualchì modu.
Quandu ci era trè milioni di missaghji, aghju avutu circa u listessu sguardu. Perchè avemu principiatu cù qualchi centesimi. Hè chjaru chì i logs di l'applicazione sò scritti quì. Per esempiu, ùn pudia micca cunnette à a basa di dati, puderia cunnette à a basa di dati, ma ùn pudia micca leghje qualcosa. Ma in più di questu, ognunu di i nostri microservizi scrive ancu un logu d'accessu. Ogni dumanda chì arriva à u microserviziu casca in u logu. Perchè facemu questu? I sviluppatori volenu esse capace di traccia. Ogni logu d'accessu cuntene u campu di traceid, secondu a quale una interfaccia speciale poi unwinds tutta a catena è bella mostra a traccia. A traccia mostra cumu a dumanda hè andata, è questu aiuta i nostri sviluppatori à trattà cù qualsiasi basura scunnisciuta più veloce.
Cumu campà cun ellu? Avà descriveraghju brevemente u campu di l'opzioni - cumu si risolve stu prublema in generale. Cumu risolve u prublema di cullizzioni, trasferimentu è almacenà logs.
Cumu scrive da l'applicazione? Hè chjaru chì ci sò modi diffirenti. In particulare, ci hè una bona pratica, cum'è i camaradi di moda ci dicenu. Ci hè dui tipi di scola antica, cum'è i missiavu dicenu. Ci sò altre manere.
Cù a cullizzioni di logs, a situazione hè apprussimatamente a stessa. Ùn ci sò tante opzioni per risolve sta parte particulare. Ci sò più di elli, ma micca tantu.
Ma cù a consegna è l'analisi sussegwente, u nùmeru di variazioni cumencia à splode. Ùn descriveraghju micca ogni opzione avà. Pensu chì l'opzioni principali sò ben cunnisciuti da tutti quelli chì anu interessatu in u tema.
Vi mustraraghju cumu l'avemu fattu in Lazada è cumu tuttu principia.
Un annu fà, aghju vinutu à Lazada è hè statu mandatu à u prugettu di log. Era cusì quì. U log da l'applicazione hè statu scrittu à stdout è stderr. Tuttu era fattu in modu di moda. Ma dopu i sviluppatori l'anu cacciatu fora di i flussi standard, è dopu i specialisti di l'infrastruttura l'hà da capisce in qualchì manera. Trà i spezialisti di l'infrastruttura è i sviluppatori, ci sò ancu liberatori chì anu dettu: "uh ... bè, imboccheremu solu in un schedariu cù una cunchiglia, è basta". E postu chì tuttu questu hè in un cuntainer, l'anu impannillatu ghjustu in u cuntinuu stessu, mappatu u repertoriu in l'internu è u mettenu quì. Pensu chì hè abbastanza evidente per tutti ciò chì hè accadutu.
Fighjemu un pocu più. Cumu avemu mandatu sti logs. Qualchissia hà sceltu td-agent, chì hè veramente fluente ma micca abbastanza fluente. Ùn aghju micca capitu ancu a rilazioni di sti dui prughjetti, ma parenu esse di listessa cosa. È questu fluentd, scrittu in Ruby, leghje i fugliali di log, li analizò in JSON utilizendu alcune espressioni regulari. Allora sò stati mandati à Kafka. Inoltre, in Kafka, avemu avutu 4 temi separati per ogni API. Perchè 4? Perchè ci hè live, ci hè staging, è perchè ci hè stdout è stderr. I sviluppatori li pruducenu, è i travagliadori di l'infrastruttura anu da creà in Kafka. Inoltre, Kafka era cuntrullata da un altru dipartimentu. Dunque, era necessariu di creà un bigliettu in modu chì anu creatu 4 temi quì per ogni api. Tutti l'anu scurdatu. In generale, era basura è rifiuti.
Chì avemu fattu dopu? L'avemu mandatu à Kafka. Più luntanu da Kafka, a mità di i ghjurnali volanu à Logstash. L'altra mità di i ghjurnali sò stati spartuti. Certi volonu versu un Graylog, alcuni à un altru Graylog. In u risultatu, tuttu questu volò in un cluster Elasticsearch. Vale à dì, tuttu stu mess hè cascatu à a fine quì. Ùn ci vole micca fà !
Questu hè ciò chì pare quandu si vede da sopra. Ùn ci vole micca fà ! Quì, i zoni prublemi sò immediatamente marcati cù numeri. Ci hè veramente più di elli, ma 6 sò veramente problematiche, cù quale qualcosa deve esse fattu. Diceraghju di elli per separatamente avà.
Quì (1,2,3) scrivemu i schedari è, per quessa, ci sò trè razzii quì à una volta.
U primu (1) hè chì avemu bisognu di scriveli in qualchì locu. Ùn hè micca sempre desideratu di dà una API a capacità di scrive direttamente à un schedariu. Hè desiderate chì l'API sia isolata in un cuntainer, è ancu megliu, chì sia in lettura solu. Sò un amministratore di sistema, cusì aghju una vista ligeramente alternativa di queste cose.
U sicondu puntu (2,3) hè chì avemu assai richieste chì venenu à l'API. L'API scrive assai dati in un schedariu. I schedari sò in crescita. Avemu bisognu di rotà. Perchè altrimenti ùn puderete micca salvà alcun discu. A rotazione hè male perchè sò rediretti via a cunchiglia à un repertoriu. Ùn ci hè manera chì pudemu rotà. Ùn pudete micca dì à l'applicazione di riapertura di e maniglie. Perchè i sviluppatori vi guardaranu cum'è un stupidu: "Quali descrittori? In generale scrivemu à stdout. I quadri facianu copytruncate in logrotate, chì solu face una copia di u schedariu è trunks l'uriginale. Per quessa, trà questi prucessi di copia, u spaziu di discu di solitu si esaurisce.
(4) Avemu avutu diversi formati in diverse API. Eranu pocu sfarente, ma regexp avia da esse scrittu in modu diversu. Siccomu era tuttu gestitu da Puppet, ci era un grande gruppu di classi cù i so propri blatte. In più, td-agent a maiò parte di u tempu puderia manghjà memoria, esse stupidu, puderia finta solu chì travagliava è ùn fà nunda. Esternamente, era impussibule di capisce chì ùn facia nunda. À u megliu, cascà, è qualchissia u ripiglià dopu. Più precisamente, una alerta volarà, è qualcunu andarà à alzà cù e so mani.
(6) È a più basura è rifiuti - era elasticsearch. Perchè era una versione antica. Perchè ùn avemu micca maestri dedicati à quellu tempu. Avemu avutu logs eterogenei chì i campi puderanu sovrappone. Diversi logs di diverse applicazioni puderanu esse scritti cù i stessi nomi di campu, ma à u stessu tempu ci puderianu esse dati diffirenti in l'internu. Questu hè, un logu vene cun un Integer in un campu, per esempiu, livellu. Un altru logu vene cun una String in u campu di livellu. In l'absenza di cartografia statica, una cosa cusì maravigliosa risulta. Se, dopu a rotazione di l'indici, un missaghju cù una stringa ghjunse prima in elasticsearch, allora campemu nurmale. È se u primu hè ghjuntu cù Integer, allora tutti i missaghji successivi chì sò ghjunti cù String sò simpliciamente scartati. Perchè u tipu di campu ùn currisponde micca.
Avemu cuminciatu à dumandà sti dumande. Avemu decisu di ùn circà i culpabili.
Ma qualcosa deve esse fattu! A cosa ovvia hè chì avemu bisognu di stabilisce standard. Avemu digià avutu qualchi standard. Certi avemu purtatu un pocu dopu. Fortunatamente, un unicu formatu di logu per tutte l'API era digià appruvatu à quellu tempu. Hè scrittu direttamente in i normi di interazzione di serviziu. In cunsiquenza, quelli chì volenu riceve logs duveranu scrive in stu formatu. Se qualchissia ùn scrive micca logs in stu formatu, allora ùn guarantimu nunda.
In più, mi piacerebbe avè un standard unicu per i metudi di arregistramentu, consegna è cullizzioni di logs. In verità, induve scriveli, è cumu furnisce. A situazione ideale hè quandu i prughjetti utilizanu a listessa biblioteca. Ci hè una biblioteca di logging separata per Go, ci hè una biblioteca separata per PHP. Tutti l'avemu, ognunu deve aduprà. À u mumentu, diceraghju chì avemu successu da 80 per centu. Ma certi cuntinueghjanu à manghjà cactus.
È quì (nantu à a diapositiva) u "SLA for log delivery" hè à pocu pressu à cumparisce. Ùn ci hè ancu, ma avemu travagliatu. Perchè hè assai còmuda quandu infra dici chì s'è vo scrivite in tali è tali furmatu à tali è tali locu è micca di più cà N missaghji per seconda, allura vi prubabilmente avaremu da quì. Si caccià assai mal di testa. Se ci hè un SLA, allora hè fantasticu!
Cumu avemu principiatu à risolve u prublema? U rake principale era cun td-agent. Ùn era chjaru induve andanu i nostri logs. Sò mandati ? Vannu ? Induve sò in ogni modu ? Dunque, hè statu decisu di rimpiazzà td-agent cù u primu articulu. Opzioni per ciò chì rimpiazzà, aghju brevemente delineatu quì.
Fluente. Prima, l'aghju scontru in un travagliu precedente, è ancu periòdicamenti ci hè cascatu. Siconda, questu hè u listessu, solu in u prufilu.
filebeat. Cumu era bonu per noi? U fattu chì ellu hè in Go, è avemu una grande cumpetenza in Go. In cunsiquenza, s'ellu hè qualcosa, puderemu in qualchì manera aghjunghje à noi stessi. Hè per quessa chì ùn avemu micca pigliatu. Cusì ùn ci sia mancu tentazione di principià a riscrittura per sè stessu.
A suluzione ovvia per u sysadmin hè ogni tipu di syslogs in questa quantità (syslog-ng/rsyslog/nxlog).
O scrivite qualcosa di u vostru propiu, ma l'avemu scartatu, è ancu filebeat. Sè vo scrivite qualcosa, allora hè megliu scrive qualcosa utile per l'affari. Per trasmette logs, hè megliu piglià qualcosa pronta.
Dunque, l'scelta hè stata in realtà una scelta trà syslog-ng è rsyslog. Aghju inclinatu versu rsyslog solu perchè avemu digià avutu classi per rsyslog in Puppet, è ùn aghju micca truvatu una differenza ovvia trà elli. Cosa hè syslog, ciò chì hè syslog. Iè, una certa documentazione hè peghju, qualchì megliu. Sapi stu modu, è u face in modu diversu.
È un pocu di rsyslog. Prima, hè bellu perchè hà assai moduli. Havi un RainerScript leggibile da l'omu (lingua muderna di cunfigurazione). Un bonus fantasticu hè chì pudemu emulà u cumpurtamentu di td-agent cù i so strumenti standard, è nunda hà cambiatu per l'applicazioni. Vale à dì, cambiamu td-agent à rsyslog, è ùn tocca micca tuttu u restu. È subitu ricevemu una consegna di travagliu. Dopu, mmnormalize hè a cosa bella di rsyslog. Permette di analizà i logs, ma micca cù Grok è regexp. Face un arbre di sintassi astratta. Analizeghja i logs in u listessu modu chì un compilatore analizza u codice fonte. Questu permette di travaglià assai veloce, manghja pocu CPU, è, in generale, hè solu una cosa assai fresca. Ci hè una mansa di altri bonus. Ùn aghju micca aspittà nantu à elli.
rsyslog hà assai più svantaghji. Sò quasi uguali à i bonus. I prublemi principali sò chì avete bisognu di pudè cocilu, è avete bisognu di selezziunà una versione.
Avemu decisu chì scriveremu logs in un socket Unix. È micca in /dev/log, perchè ci avemu un miss di logs di sistema, ci hè journald in questa pipeline. Allora scrivemu à un socket persunalizatu. L'attacheremu à un regule separatu. Ùn interferemu micca in nunda. Tuttu serà trasparente è capiscibile. Allora avemu fattu veramente. U repertoriu cù questi sockets hè standardizatu è trasmessu à tutti i cuntenituri. I cuntenituri ponu vede u socket chì anu bisognu, apre è scrivite.
Perchè micca un schedariu? Perchè tutti anu lettu , chì hà pruvatu à rinvià u schedariu à docker, è hà truvatu chì dopu avè riavviatu rsyslog, u descrittore di u schedariu cambia, è docker perde stu schedariu. Mantene aperta qualcosa altru, ma micca u listessu socket induve scrivenu. Avemu decisu chì avemu da passà stu prublema, è, à u stessu tempu, bypassà u prublema di bluccatu.
Rsyslog face l'azzioni indicati nantu à a diapositiva è manda logs à relay o à Kafka. Kafka seguita u vechju modu. Rayleigh - Pruvatu d'utilizà rsyslog puru per furnisce i logs. Senza Message Queue, utilizendu strumenti rsyslog standard. In fondu, funziona.
Ma ci sò sfumature di cumu si mette in più tardi in questa parte (Logstash/Graylog/ES). Questa parte (rsyslog-rsyslog) hè aduprata trà i datacenters. Eccu un ligame tcp cumpressatu, chì permette di salvà a larghezza di banda è, in cunseguenza, in qualchì manera aumentà a probabilità chì ricevemu qualchi logs da un altru centru di dati quandu u canali hè pienu. Perchè avemu l'Indonesia, induve tuttu hè male. Hè quì chì si trova u prublema constante.
Avemu pensatu à cumu monitoremu veramente, cù quale probabilità i logs chì avemu arregistratu da l'applicazione ghjunghjenu à quellu fine? Avemu decisu di inizià a metrica. Rsyslog hà u so propiu modulu di cullizzioni di statistiche, chì hà qualchì tipu di cuntatori. Per esempiu, vi pò mustrà a taglia di a fila, o quanti missaghji sò ghjunti in tali è tali azzione. Pudete digià piglià qualcosa da elli. In più, hà cuntatori persunalizati chì pudete cunfigurà, è vi mostrarà, per esempiu, u numeru di missaghji chì certi API hà registratu. In seguitu, aghju scrittu rsyslog_exporter in Python, è avemu mandatu tuttu à Prometheus è trama. Vulemu veramente e metriche di Graylog, ma finu à avà ùn avemu micca avutu u tempu di stallà.
Chì sò i prublemi ? U prublema hè ghjuntu cù u fattu chì avemu scupertu (SUDDENLY!) Chì i nostri API Live scrivenu 50k missaghji per seconda. Questu hè solu l'API Live senza staging. È Graylog ci mostra solu 12 mila missaghji per seconda. È una quistione raghjone hè ghjunta, induve sò i resti? Da quale avemu cunclusu chì Graylog simpricimenti ùn pò micca affruntà. Avemu guardatu, è, veramente, Graylog cù Elasticsearch ùn hà micca maestru di stu flussu.
Dopu, altre scuperte chì avemu fattu nantu à a strada.
I scrive à u socket sò bluccati. Cumu hè accadutu ? Quandu aghju utilizatu rsyslog per a consegna, in un certu puntu avemu ruttu u canali trà i centri di dati. A consegna hè ghjunta in un locu, a consegna hè stata in un altru locu. Tuttu chistu hè vinutu à una macchina cù API chì scrivenu à u socket rsyslog. Ci era una fila. Allora a fila per scrive à u socket Unix si riempia, chì per difettu hè 128 pacchetti. È u prossimu scrive () in i blocchi di l'applicazione. Quandu avemu vistu a biblioteca chì usemu in l'applicazioni Go, hè statu scrittu quì chì a scrittura à u socket si faci in modu senza bloccu. Eramu sicuri chì nunda era bluccatu. Perchè avemu lettu chì hà scrittu annantu à questu. Ma ci hè un mumentu. Ci era ancu un ciclu infinitu intornu à sta chjama, in quale ci era un tentativu constante di spinghje un missaghju in u socket. Ùn l'avemu micca nutatu. Aviu avutu à riscrive a biblioteca. Da tandu, hà cambiatu parechje volte, ma avà avemu sbarazzatu di chjusi in tutti i sottosistemi. Dunque, pudete piantà rsyslog è nunda cascarà.
Hè necessariu di monitorà a dimensione di e fila, chì aiuta micca à passà nantu à questu rake. Prima, pudemu monitorà quandu avemu principiatu à perde i missaghji. Siconda, pudemu monitorà chì avemu basicamente prublemi cù a consegna.
È un altru mumentu dispiacevule - l'amplificazione di 10 volte in una architettura di microserviziu hè assai faciule. Ùn avemu micca parechje dumande in entrata, ma per via di u graficu longu à quale sti messagi scorri più, per via di i logs d'accessu, in realtà aumentanu a carica nantu à i logs da circa deci volte. Sfurtunatamente, ùn aghju micca u tempu di calculà i numeri esatti, ma i microservizii sò ciò chì sò. Questu deve esse tenutu in mente. Risulta chì in u mumentu u subsistema di cullizzioni di log hè u più carricu in Lazada.
Cumu risolve u prublema elasticsearch? Sè avete bisognu di ottene rapidamente logs in un locu, per ùn curriri à traversu tutte e machini è cullà quì, aduprate l'almacenamiento di schedari. Questu hè garantitu per travaglià. Hè fattu da ogni servitore. Basta à appiccicà i dischi è mette syslog. Dopu à quessa, vi sò guarantiti à avè tutti i logs in un locu. Allora serà pussibule cunfigurà lentamente elasticsearch, graylog, o qualcosa altru. Ma avete digià tutti i logs, è, in più, pudete almacenà, in quantu ci sò abbastanza arrays di discu.
À u mumentu di u mo rapportu, u schema hà cuminciatu à vede cusì. Avemu praticamente cessatu di scrive à u schedariu. Avà, assai prubabile, spegneremu i resti. Nant'à e macchine lucali chì eseguenu l'API, cessemu di scrive à i schedari. Prima, ci hè un archiviu di schedari, chì travaglia assai bè. Siconda, sti machini sò in permanenza senza spaziu, avete bisognu di monitorà constantemente.
Questa parte cù Logstash è Graylog, veramente s'alza. Dunque, avete bisognu di sbarazzà. Avete da sceglie unu.
Avemu decisu di abbandunà Logstash è Kibana. Perchè avemu un dipartimentu di sicurità. Cosa hè a cunnessione? A cunnessione hè chì Kibana senza X-Pack è senza Shield ùn permettenu micca di diferenzià i diritti d'accessu à i logs. Dunque, anu pigliatu Graylog. Hà tuttu. Ùn mi piace micca, ma funziona. Avemu compru novu hardware, installatu un Graylog frescu quì, è movemu tutti i logs cù formati stretti à un Graylog separatu. Avemu risoltu u prublema cù sfarenti tippi di i stessi campi organizativamente.
Ciò chì esattamente hè inclusu in u novu Graylog. Avemu scrittu solu tuttu in u docker. Avemu pigliatu una mansa di servitori, sbulicatu trè casi Kafka, 7 servitori Graylog versione 2.3 (perchè vulia a versione 5 di Elasticsearch). Tuttu chistu hè statu risuscitatu nantu à raids da u HDD. Avemu vistu una rata di indexazione di finu à 100 mila missaghji per seconda. Avemu vistu a figura chì 140 terabytes di dati à settimana.
È dinò un rake ! Avemu duie vendite chì venenu. Avemu passatu oltre 6 milioni di posti. Avemu Graylog ùn hà micca tempu per masticari. In qualchì modu avete da sopravvive di novu.
Questu hè cumu sopravvivemu. Aghjunghjite uni pochi di più servitori è SSD. À u mumentu campemu cusì. Avà avemu digià masticatu 160k missaghji per seconda. Ùn avemu micca toccu u limitu, dunque ùn hè micca chjaru quantu pudemu esce realisticamente da ellu.
Quessi sò i nostri piani per u futuru. Di questi, veramente, u più impurtante hè probabilmente alta dispunibilità. Ùn l'avemu ancu. Parechje vitture sò stallate in u listessu modu, ma finu à quì tuttu passa per una vittura. Hè necessariu di passà u tempu per stabilisce un failover trà elli.
Cullate metriche da Graylog.
Fate un limitu di tarifa per avè una API loca chì ùn ci uccide micca a larghezza di banda è tuttu u restu.
È infine, firmate un tipu di SLA cù i sviluppatori in modu chì pudemu serve cusì. Se scrivi più, allora scusate.
È scrive a documentazione.
In breve, i risultati di tuttu ciò chì avemu avutu. Prima, i normi. Siconda, syslog hè una torta. In terzu, rsyslog funziona esattamente cumu hè scrittu nantu à a diapositiva. È andemu à e dumande.
I vostri dumanni.
A vostra dumanda: Perchè anu decisu di ùn piglià ... (filebeat ?)
Risposte: Hè bisognu di scrive à un schedariu. Ùn vulia micca veramente. Quandu a vostra API scrive millaie di messagi per seconda, ancu s'è vo rotate una volta à l'ora, questu ùn hè micca sempre una opzione. Pudete scrive à pipa. À quale i sviluppatori m'hà dumandatu: "Chì succede se u prucessu in quale scrivemu casca"? Ùn aghju micca truvatu ciò chì risponde à elli, è disse: "Bè, ok, ùn facemu micca cusì".
A vostra dumanda: Perchè ùn scrive micca solu logs à HDFS?
RisposteA: Questu hè u prossimu passu. L'avemu pensatu à u principiu, ma postu chì ùn ci hè micca risorse per trattà cun questu in u mumentu, pende in a nostra suluzione à longu andà.
A vostra dumanda: Un formatu di culonna seria più apprupriatu.
Risposte: Capiscu. Semu "per" cù e duie mani.
A vostra dumanda: Scrivite à rsyslog. TCP è UDP sò dispunibuli quì. Ma se UDP, allora cumu guarantisci a consegna?
RisposteA: Ci sò dui punti. Prima, dicu subitu à tutti chì ùn guarantimu micca a consegna di logs. Perchè quandu i sviluppatori venenu è dicenu: "Cominciamu à scrive dati finanziarii quì, è l'avete da mette in un locu per noi in casu chì qualcosa succede", li rispundiamu: "Great! Cuminciamu à bluccà à scrive à u socket, è fate in transazzione, cusì chì vi sò guarantiti di mette in u socket per noi è assicuratevi chì avemu ricevutu da l'altra parte. È in questu mumentu, tutti diventanu subitu innecessariu. È se no, allora chì dumande avemu? Se ùn vulete micca guarantiscia una scrittura à u socket, allora perchè guarantimu a consegna? Facemu u megliu sforzu. Pruvemu veramente di furnisce u più pussibule è u megliu pussibule, ma ùn demu micca una garanzia di 100%. Dunque, ùn avete micca bisognu di scrive dati finanziarii quì. Ci sò basa di dati transazzione per questu.
A vostra dumanda: Quandu l'API genera un messagiu à u logu è trasferisce u cuntrollu à i microservizi, avete scontru u prublema chì i missaghji da i diversi microservizi arrivanu in l'ordine sbagliatu? Per quessa, a cunfusione nasce.
RisposteA: Hè normale chì venenu in un ordine diversu. Avete da esse prontu per questu. Perchè ogni spedizione di rete ùn guarantisci micca l'ordine per voi, o avete bisognu di gastru risorse speciali in questu. Se pigliamu l'almacenamiento di schedari, allora ogni API salva logs in u so propiu schedariu. Piuttostu, rsyslog li decompone in cartulari quì. Ogni API hà i so propri logs quì, induve pudete andà à circà, è poi pudete paragunà cù u timestamp in questu logu. Se vanu à circà in Graylog, allora seranu ordinati per timestamp. Tuttu sarà bè quì.
A vostra dumanda: Timestamp pò varià di millisecondi.
Risposte: L'horodatage est généré par l'API elle-même. Questu, in fattu, hè tuttu u puntu. Avemu NTP. L'API genera un timestamp digià in u messagiu stessu. Ùn hè micca aghjuntu da rsyslog.
A vostra dumanda: L'interazzione trà i centri di dati ùn hè micca assai chjaru. In u quadru di u centru di dati, hè chjaru cumu i logs sò stati cullati è processati. Cumu hè l'interazzione trà i centri di dati? O ogni centru di dati vive a so propria vita?
Risposte: Quasi. Avemu ogni paese situatu in un centru di dati. Attualmente ùn avemu micca diffusione, cusì chì un paese hè situatu in diversi centri di dati. Per quessa, ùn ci hè bisognu di cumminà elli. Dentru ogni centru ci hè un Log Relay. Questu hè un servitore Rsyslog. In fatti, dui machini di gestione. Sò stallati di listessa manera. Ma per avà, u trafficu passa solu per unu di elli. Ella registra tuttu l'agregatu. Hà una fila di discu per u casu. Ella pressu i logs è li manda à u centru di dati cintrali (Singapore), induve più sò digià avvelenati in Graylog. È ogni centru di dati hà u so propiu almacenamentu di schedari. In casu avemu persu a cunnessione, avemu tutti i logs quì. Staranu quì. Ci seranu guardati.
A vostra dumanda: Avete logs da quì durante situazioni anormali?
Risposte: Pudete andà quì (à l'almacenamiento di u schedariu) è vede.
A vostra dumanda: Cumu monitorà chì ùn perde micca logs?
Risposte: In realtà li perdemu, è u monitoremu. U monitoraghju hà iniziatu un mese fà. A biblioteca chì l'API Go usanu hà metrica. Ella pò cuntà quante volte hà fallutu scrive à u socket. Ci hè in u mumentu un heuristicu complicatu. Ci hè un buffer quì. Prova à scrive un missaghju da ellu à u socket. Se u buffer overflows, principia à caccià. È cunta quanti li hà cascatu. Sì i cuntatori cumincianu à sbulicà quì, avemu da sapè. Avà sò ancu ghjunti à prometheus, è pudete vede i grafici in Grafana. Pudete stabilisce alerti. Ma ùn hè ancu chjaru à quale li mandà.
A vostra dumanda: In elasticsearch, guardate logs cù redundancy. Quante repliche avete?
Risposte: Una replica.
A vostra dumanda: Hè solu una linea ?
Risposte: Questu hè u maestru è a replica. I dati sò guardati in duplicate.
A vostra dumanda: Avete aghjustatu a dimensione di u buffer rsyslog in qualchì modu?
Risposte: Scrivemu datagrammi à un socket Unix persunalizatu. Questu impone immediatamente una limitazione di 128 kilobyte nantu à noi. Ùn pudemu micca scrive più in questu. Avemu scrittu questu in u standard. Quale vole entre in u almacenamentu, scrive 128 kilobytes. Biblioteche, in più, tagliate, è mette una bandiera chì u messagiu hè tagliatu. Avemu un campu speciale in u standard di u missaghju stessu, chì mostra s'ellu hè statu tagliatu durante a registrazione o micca. Allora avemu l'uppurtunità di seguità stu mumentu.
Quistione: Scrivite JSON rottu ?
Risposte: JSON rottu serà scartatu sia durante u relay perchè u pacchettu hè troppu grande. O Graylog serà abbandunatu, perchè ùn serà micca capace di analizà JSON. Ma ci sò sfumature quì chì deve esse riparatu, è sò soprattuttu ligati à rsyslog. Aghju digià cumpletu uni pochi di questioni quì, chì anu da esse travagliatu.
Quistione: Perchè Kafka ? Avete pruvatu RabbitMQ? Graylog ùn aghjunghje micca sottu à tali carichi?
Risposte: Ùn funziona micca cù Graylog. È Graylog piglia forma. Hè veramente problematicu per ellu. Hè un tipu di cosa. È, in fattu, ùn hè micca necessariu. Preferite scrive da rsyslog direttamente à elasticsearch è poi fighjà Kibana. Ma avemu bisognu di risolve u prublema cù i guardiani di sicurità. Questa hè una variante pussibule di u nostru sviluppu quandu scacciemu Graylog è usemu Kibana. Logstash ùn hà micca sensu. Perchè possu fà u listessu cù rsyslog. È hà un modulu per scrive in elasticsearch. Cù Graylog circhemu di campà in qualchì modu. Avemu ancu aghjustatu un pocu. Ma ci hè sempre spaziu per migliurà.
À propositu di Kafka. Hè cusì chì hè accadutu storicamente. Quandu sò ghjuntu, era digià quì, è i logs eranu digià scritti. Avemu appena risuscitatu u nostru cluster è movemu logs in questu. U gestionemu, sapemu cumu si sente. In quantu à RabbitMQ... avemu avutu prublemi cù RabbitMQ. È RabbitMQ si sviluppa per noi. L'avemu in a pruduzzione, è ci sò stati prublemi cù questu. Avà, prima di a vendita, saria shamanizatu, è principia à travaglià nurmale. Ma prima, ùn era micca prontu à liberà in a produzzione. Ci hè un puntu più. Graylog pò leghje a versione AMQP 0.9 è rsyslog pò scrive a versione AMQP 1.0. È ùn ci hè micca una solu suluzione chì pò fà tramindui à mezu. Ci hè o unu o l'altru. Dunque, à u mumentu solu Kafka. Ma ci sò ancu sfumature. Perchè l'omkafka di a versione di rsyslog chì usemu pò perde tuttu u buffer di missaghju chì hà scupertu da rsyslog. Finu à chì l'avemu sottumessu.
Quistione: Aduprate Kafka perchè l'avete? Ùn hè micca usatu per qualsiasi altru scopu?
Risposte: Kafka, chì hè stata utilizata da a squadra di Data Science. Questu hè un prughjettu cumpletamente separatu, di quale, sfurtunatamenti, ùn possu micca dì nunda. Ùn a sò micca. Hè stata guidata da a squadra di Data Science. Quandu i logs cuminciaru, decisu di usà, per ùn mette micca u so propiu. Avà avemu aghjurnatu Graylog, è avemu persu a cumpatibilità, perchè ci hè una versione antica di Kafka. Avemu avutu à fà u nostru. À u listessu tempu, avemu liberatu di sti quattru temi per ogni API. Avemu fattu una cima larga per tutti i live, una cima larga larga per tutte e mette in scena è avemu ghjustu sparatu tuttu quì. Graylog razzia tuttu questu in parallelu.
Quistione: Perchè avemu bisognu di stu sciamanisimu cù sockets ? Avete pruvatu à utilizà u driver di log di syslog per i cuntenituri.
Risposte: À l'epica quandu avemu fattu sta quistione, avemu avutu relazioni tense cù u docker. Era docker 1.0 o 0.9. Docker stessu era stranu. Siconda, s'è vo ancu shove logs in questu ... Aghju un suspettu micca verificatu chì passa tutti i logs per ellu stessu, attraversu u daemon docker. Se avemu una API chì andava pazza, allora u restu di l'API si mette in u fattu chì ùn ponu micca mandà stdout è stderr. Ùn sò micca induve questu portarà. Aghju un suspettu à u livellu di sensu chì ùn hè micca necessariu di utilizà u docker syslog driver in questu locu. U nostru dipartimentu di teste funzionale hà u so propiu cluster Graylog cù logs. Usanu i driver di docker log è tuttu pare esse bè quì. Ma scrivenu immediatamente GELF à Graylog. À u mumentu chì avemu principiatu tuttu questu, avemu bisognu di travaglià solu. Forse dopu, quandu qualcunu vene è dice chì hà travagliatu nurmale per centu anni, pruveremu.
Quistione: Consegna trà centri di dati cù rsyslog. Perchè micca nantu à Kafka?
Risposte: Facemu questu, è cusì hè veramente. Per dui motivi. Se u canali hè mortu cumplettamente, tutti i nostri logs, ancu in una forma compressa, ùn cullà micca per ellu. E kafka li permette di perdiri simpricimenti in u prucessu. In questu modu, sguassemu di l'attaccamentu di sti logs. Avemu solu aduprà Kafka in questu casu direttamente. Se avemu un bonu canali è vulete liberà, allora usemu u so rsyslog. Ma in fatti, pudete stallà in modu chì sguassate ciò chì ùn hà micca passatu. À u mumentu, usemu solu a consegna rsyslog direttamente in qualchì locu, in un locu Kafka.
Source: www.habr.com