articolul despre B\u0103du\u0219ic\u0103<\/a><\/noindex>, care a scris despre asta. Dar exist\u0103 un detaliu. \u00cen jurul acestei apel\u0103ri a fost un ciclu infinit, \u00een care \u00eencercam constant s\u0103 trimitem un mesaj \u00een socket. Asta nu am observat. A trebuit s\u0103 rescriem biblioteca. De atunci, a suferit c\u00e2teva modific\u0103ri, dar acum ne-am eliberat de blocaje \u00een toate subsistemele. De aceea, putem opri rsyslog, \u0219i nimic nu se va pr\u0103bu\u0219i.<\/p>\n<\/p>\n
Trebuie s\u0103 monitoriz\u0103m dimensiunea cozilor, ceea ce ajut\u0103 s\u0103 nu c\u0103dem \u00een aceste capcane. \u00cen primul r\u00e2nd, putem monitoriza c\u00e2nd \u00eencepem s\u0103 pierdem mesaje. \u00cen al doilea r\u00e2nd, putem monitoriza c\u0103 avem, \u00een principiu, probleme cu livrarea.<\/p>\n
<\/p>\n
\u0218i un alt aspect nepl\u0103cut \u2014 amplificarea de 10 ori \u00een arhitectura microserviciilor \u2014 este foarte u\u0219oar\u0103. Nu avem at\u00e2t de multe cereri de intrare, dar din cauza grafului, pe care aceste mesaje \u00eel urmeaz\u0103 mai departe, din cauza jurnalelor de acces, cre\u0219tem efectiv \u00eenc\u0103rc\u0103tura din jurnal de aproximativ zece ori. Din p\u0103cate, nu am reu\u0219it s\u0103 calculez cifrele exacte, dar microserviciile sunt a\u0219a. Trebuie s\u0103 \u021binem cont de acest lucru. Rezultatul este c\u0103, \u00een prezent, subsistemul de colectare a jurnaleleor este cel mai solicitat \u00een Lazada. <\/p>\n
<\/p>\n
<\/p>\n
Cum rezolv\u0103m problema elasticsearch? Dac\u0103 trebuie s\u0103 ob\u021bine\u021bi rapid jurnalele \u00eentr-un singur loc, f\u0103r\u0103 a alerga prin toate ma\u0219inile \u0219i a le aduna, folosi\u021bi un sistem de stocare a fi\u0219ierelor. Asta func\u021bioneaz\u0103 garantat. Se poate face din orice server. Trebuie pur \u0219i simplu s\u0103 conecta\u021bi ni\u0219te discuri \u0219i s\u0103 instala\u021bi syslog. Dup\u0103 asta, ve\u021bi avea toate jurnalele \u00eentr-un singur loc. Apoi, pute\u021bi configura cu r\u0103bdare elasticsearch, graylog, sau altceva. Dar deja ve\u021bi avea toate jurnalele \u0219i, \u00een plus, le pute\u021bi stoca at\u00e2ta timp c\u00e2t v\u0103 permit unit\u0103\u021bile de disc.<\/p>\n
<\/p>\n
<\/p>\n
La momentul prezent\u0103rii mele, schema ar\u0103ta astfel. Practic am \u00eencetat s\u0103 scriem \u00een fi\u0219iere. Probabil, \u00een cur\u00e2nd, vom deconecta resturile. Pe ma\u0219inile locale, pe care sunt pornite API-urile, nu vom mai scrie \u00een fi\u0219iere. \u00cen primul r\u00e2nd, exist\u0103 un sistem de stocare a fi\u0219ierelor care func\u021bioneaz\u0103 foarte bine. \u00cen al doilea r\u00e2nd, pe aceste ma\u0219ini se termin\u0103 constant spa\u021biul, trebuie s\u0103-l monitoriz\u0103m constant.<\/p>\n
<\/p>\n
Aceast\u0103 parte cu Logstash \u0219i Graylog, pur \u0219i simplu ne complic\u0103 via\u021ba. De aceea, trebuie s\u0103 ne eliber\u0103m de ea. Trebuie s\u0103 alegem ceva unul.<\/p>\n
<\/p>\n
<\/p>\n
Am decis s\u0103 renun\u021b\u0103m la Logstash \u0219i Kibana. Pentru c\u0103 avem un departament de securitate. Care este leg\u0103tura? Leg\u0103tura este c\u0103 Kibana f\u0103r\u0103 X-Pack \u0219i f\u0103r\u0103 Shield nu permite delimitarea drepturilor de acces la loguri. A\u0219a c\u0103 am ales Graylog. Are tot ce avem nevoie. Nu-mi place, dar func\u021bioneaz\u0103. Am achizi\u021bionat hardware nou, am instalat Graylog proasp\u0103t acolo \u0219i am mutat toate logurile cu formate stricte \u00eentr-un Graylog separat. Am rezolvat problema cu diferitele tipuri de c\u00e2mpuri identice din punct de vedere organiza\u021bional.<\/p>\n
<\/p>\n
<\/p>\n
Ce include, de fapt, noul Graylog? Am notat totul \u00een Docker. Am luat o mul\u021bime de servere, am desf\u0103\u0219urat trei instan\u021be Kafka, \u0219apte servere Graylog versiunea 2.3 (pentru c\u0103 ne doream versiunea 5 de Elasticsearch). Totul a fost ridicat pe RAID-uri din HDD-uri. Am observat o rat\u0103 de indexare de p\u00e2n\u0103 la 100.000 de mesaje pe secund\u0103. Am v\u0103zut c\u0103 avem 140 terabyte de date pe s\u0103pt\u0103m\u00e2n\u0103. <\/p>\n
<\/p>\n
<\/p>\n
Iar\u0103\u0219i am dat peste acelea\u0219i probleme! Avem dou\u0103 v\u00e2nz\u0103ri \u00een a\u0219teptare. Am ajuns la 6 milioane de mesaje. Graylog-ul nostru nu reu\u0219e\u0219te s\u0103 proceseze totul. Trebuie s\u0103 g\u0103sim o modalitate de a supravie\u021bui din nou. <\/p>\n
<\/p>\n
<\/p>\n
A\u0219a am supravie\u021buit. Am ad\u0103ugat \u00eenc\u0103 c\u00e2teva servere \u0219i SSD-uri. \u00cen acest moment, tr\u0103im \u00een felul acesta. Acum reu\u0219im s\u0103 proces\u0103m deja 160.000 de mesaje pe secund\u0103. \u00cenc\u0103 nu am atins limita, deci nu este clar c\u00e2t de mult vom putea extrage din acest sistem. <\/p>\n
<\/p>\n
<\/p>\n
A\u0219a arat\u0103 planurile noastre pentru viitor. Dintre acestea, cel mai important este, probabil, disponibilitatea mare. Momentan nu o avem. C\u00e2teva ma\u0219ini sunt configurate identic, dar totul trece \u00een continuare printr-o singur\u0103 ma\u0219in\u0103. Trebuie s\u0103 ne aloc\u0103m timp pentru a configura failover-ul \u00eentre ele.<\/p>\n
<\/p>\n
Colectarea metricilor din Graylog.<\/p>\n
<\/p>\n
Implementarea limit\u0103rii ratei pentru ca o API care a luat-o razna s\u0103 nu ne afecteze l\u0103\u021bimea de band\u0103 \u0219i celelalte aspecte.<\/p>\n
<\/p>\n
\u0218i, \u00een final, semnarea unui SLA cu dezvoltatorii, \u00een care s\u0103 stabilim c\u0103 putem gestiona un anumit volum. Dac\u0103 scrie\u021bi mai mult, ne pare r\u0103u.<\/p>\n
<\/p>\n
\u0218i redactarea documenta\u021biei.<\/p>\n
<\/p>\n
<\/p>\n
Pe scurt, concluziile a tot ce am trecut. \u00cen primul r\u00e2nd, standarde. \u00cen al doilea r\u00e2nd, syslog - este tort. \u00cen al treilea r\u00e2nd, rsyslog func\u021bioneaz\u0103 exact a\u0219a cum este prezentat pe diapozitiv. \u0218i haide\u021bi s\u0103 trecem la \u00eentreb\u0103ri.<\/p>\n
<\/p>\n
\u00centreb\u0103ri<\/strong>.<\/p>\n<\/p>\n
\u00centrebare<\/strong>: De ce a\u021bi decis totu\u0219i s\u0103 nu lua\u021bi... (filebeat?)<\/p>\n<\/p>\n
R\u0103spuns<\/strong>: Trebuie s\u0103 scriem \u00een fi\u0219ier. Nu ne-am dorit deloc. C\u00e2nd API-ul t\u0103u scrie mii de mesaje pe secund\u0103, chiar dac\u0103 roti\u021bi fi\u0219ierul o dat\u0103 pe or\u0103, tot nu este o op\u021biune. Se poate scrie \u00een pipe. La care dezvoltatorii m-au \u00eentrebat: \u201eCe se \u00eent\u00e2mpl\u0103 dac\u0103 procesul \u00een care scriem se opre\u0219te\u201d? Pur \u0219i simplu nu am g\u0103sit un r\u0103spuns \u0219i am spus: \u201eBine, atunci s\u0103 nu facem a\u0219a.\u201d<\/p>\n<\/p>\n
\u00centrebare<\/strong>: De ce nu scrie\u021bi jurnalele direct \u00een HDFS?<\/p>\n<\/p>\n
R\u0103spuns<\/strong>: Aceasta este urm\u0103toarea etap\u0103. Ne-am g\u00e2ndit la ea \u00eenc\u0103 de la \u00eenceput, dar, av\u00e2nd \u00een vedere c\u0103 \u00een prezent nu avem resurse pentru a ne ocupa de asta, este \u0219i va r\u0103m\u00e2ne o solu\u021bie pe termen lung.<\/p>\n<\/p>\n
\u00centrebare<\/strong>: Formatul pe coloane ar fi mai potrivit.<\/p>\n<\/p>\n
R\u0103spuns<\/strong>: \u00cen\u021beleg totul. Suntem \"pentru\" din toate punctele de vedere. <\/p>\n<\/p>\n
\u00centrebare<\/strong>: Scrie\u021bi \u00een rsyslog. Acolo sunt disponibile at\u00e2t TCP, c\u00e2t \u0219i UDP. Dar dac\u0103 folosi\u021bi UDP, cum garanta\u021bi livrarea?<\/p>\n<\/p>\n
R\u0103spuns<\/strong>: Exist\u0103 dou\u0103 aspecte. Primul, le spun imediat tuturor c\u0103 nu garant\u0103m livrarea jurnalelor. Deoarece atunci c\u00e2nd dezvoltatorii vin \u0219i spun: \u201eHaide\u021bi s\u0103 \u00eencepem s\u0103 scriem date financiare acolo, iar voi le ve\u021bi stoca undeva \u00een caz c\u0103 se \u00eent\u00e2mpl\u0103 ceva\u201d, le r\u0103spundem \u201eExcelent! Haide\u021bi s\u0103 face\u021bi bloc\u0103ri la scrierea \u00een socket \u0219i s\u0103 face\u021bi acest lucru \u00een tranzac\u021bii, astfel \u00eenc\u00e2t s\u0103 ne asigura\u021bi c\u0103 a\u021bi pus asta \u00een socket \u0219i v-a\u021bi asigurat c\u0103 noi am primit acea informa\u021bie de cealalt\u0103 parte.\u201d \u0218i \u00een acel moment, toat\u0103 lumea devine imediat dezinteresat\u0103. \u0218i dac\u0103 nu sunt interesa\u021bi, ce \u00eentreb\u0103ri mai avem noi? Dac\u0103 nu dori\u021bi s\u0103 garanta\u021bi scrierea \u00een socket, de ce ar trebui s\u0103 garant\u0103m livrarea? Facem eforturi maxime. Ne str\u0103duim cu adev\u0103rat s\u0103 livr\u0103m c\u00e2t mai mult \u0219i c\u00e2t mai bine, dar nu oferim 100% garan\u021bie. A\u0219adar, nu este nevoie s\u0103 scrie\u021bi date financiare acolo. Exist\u0103 baze de date pentru tranzac\u021bii.<\/p>\n<\/p>\n
\u00centrebare<\/strong>: Atunci c\u00e2nd API-ul genereaz\u0103 un mesaj \u00een jurnal \u0219i pred\u0103 controlul microserviciilor, v-a\u021bi confruntat vreodat\u0103 cu problema c\u0103 mesajele de la diferite microservicii sosesc \u00een ordine gre\u0219it\u0103? Din aceast\u0103 cauz\u0103 apare confuzia.<\/p>\n<\/p>\n
R\u0103spuns<\/strong>: Este normal ca acestea s\u0103 soseasc\u0103 \u00een ordine diferit\u0103. Trebuie s\u0103 fi\u021bi preg\u0103ti\u021bi pentru asta. Deoarece orice livrare pe re\u021bea nu v\u0103 garanteaz\u0103 ordinea sau trebuie s\u0103 investe\u0219ti special resurse pentru asta. Dac\u0103 ne uit\u0103m la stoc\u0103rile de fi\u0219iere, fiecare API \u00ee\u0219i salveaz\u0103 jurnalele \u00een fi\u0219ierul s\u0103u. De fapt, rsyslog le organizeaz\u0103 pe categorii. Fiecare API are jurnalele sale, la care se poate merge \u0219i verifica, iar apoi, \u00een acest jurnal, se pot corela \u00een func\u021bie de timestamp. Dac\u0103 se uit\u0103 \u00een Graylog, acolo se vor sorta dup\u0103 timestamp. Totul va fi bine.<\/p>\n<\/p>\n
\u00centrebare<\/strong>: Timestamp-ul poate diferi cu c\u00e2teva milisecunde.<\/p>\n<\/p>\n
R\u0103spuns<\/strong>: Timestamp-ul este generat de API. Asta este, de fapt, toat\u0103 esen\u021ba. Avem NTP. API-ul genereaz\u0103 timestamp-ul chiar \u00een mesaj. Nu este ad\u0103ugat de rsyslog.<\/p>\n<\/p>\n
\u00centrebare<\/strong>: Nu este foarte clar cum interac\u021bioneaz\u0103 centrele de date. \u00cen cadrul centrului de date este clar cum s-au colectat \u0219i procesat logurile. Cum are loc interac\u021biunea \u00eentre centrele de date? Sau fiecare centru de date \u00ee\u0219i duce via\u021ba separat?<\/p>\n<\/p>\n
R\u0103spuns<\/strong>: Aproape. Fiecare \u021bar\u0103 se afl\u0103 \u00eentr-un singur centru de date. Momentan nu avem dispersie, astfel \u00eenc\u00e2t o \u021bar\u0103 s\u0103 fie g\u0103zduit\u0103 \u00een mai multe centre de date. Deci nu trebuie s\u0103 le integr\u0103m. \u00cen interiorul fiec\u0103rui centru exist\u0103 un Log Relay. Acesta este un server Rsyslog. De fapt, sunt dou\u0103 ma\u0219ini de management. Sunt configurate identic. Dar momentan, traficul trece prin una dintre ele. Aceasta agreg\u0103 toate logurile. Are o coad\u0103 de discuri pentru orice eventualitate. Compresioneaz\u0103 logurile \u0219i le trimite \u00een centrul de date central (cel din Singapore), unde sunt trimise mai departe \u00een Graylog. \u0218i \u00een fiecare centru de date exist\u0103 un storage de fi\u0219iere propriu. \u00cen cazul \u00een care pierdem conexiunea, avem toate logurile acolo. Ele vor r\u0103m\u00e2ne acolo. Vor fi p\u0103strate.<\/p>\n<\/p>\n
\u00centrebare<\/strong>: \u00cen situa\u021bii neplanificate, ob\u021bine\u021bi loguri de acolo?<\/p>\n<\/p>\n
R\u0103spuns<\/strong>: Po\u021bi merge acolo (la storage-ul de fi\u0219iere) \u0219i verifica.<\/p>\n<\/p>\n
\u00centrebare<\/strong>: Cum monitoriza\u021bi c\u0103 nu pierde\u021bi loguri?<\/p>\n<\/p>\n
R\u0103spuns<\/strong>: De fapt, le pierdem \u0219i monitoriz\u0103m acest lucru. Monitorizarea a fost activat\u0103 acum o lun\u0103. \u00cen biblioteca utilizat\u0103 de Go API, exist\u0103 metrici. Aceasta poate contabiliza de c\u00e2te ori nu a reu\u0219it s\u0103 scrie \u00een socket. Momentan exist\u0103 o heuristica sofisticat\u0103. Exist\u0103 un buffer. Acesta \u00eencearc\u0103 s\u0103 scrie din el un mesaj \u00een socket. Dac\u0103 bufferul se umple, \u00eencepe s\u0103 le abandoneze. \u0218i contabilizeaz\u0103 c\u00e2te a abandonat. Dac\u0103 acolo \u00eencep s\u0103 se umple contoarele, afl\u0103m despre asta. Acestea sosesc acum \u0219i \u00een Prometheus, iar \u00een Grafana po\u021bi vedea graficele. Se pot configura alerte. Dar momentan nu este clar cui s\u0103 le trimitem.<\/p>\n<\/p>\n
\u00centrebare<\/strong>: \u00cen Elasticsearch, p\u0103stra\u021bi logurile cu redundan\u021b\u0103. C\u00e2te replici ave\u021bi?<\/p>\n<\/p>\n
R\u0103spuns<\/strong>: O replic\u0103.<\/p>\n<\/p>\n
\u00centrebare<\/strong>: Asta este doar o replic\u0103?<\/p>\n<\/p>\n
R\u0103spuns<\/strong>: Este un master \u0219i o replic\u0103. Datele sunt stocate \u00een dou\u0103 exemplare.<\/p>\n<\/p>\n
\u00centrebare<\/strong>: A\u021bi ajustat cumva dimensiunea bufferului Rsyslog? <\/p>\n<\/p>\n
R\u0103spuns<\/strong>: Scriem datagrame \u00eentr-un socket unix personalizat. Asta ne impune imediat o limitare de 128 kilobi\u021bi. Nu putem scrie mai mult de at\u00e2t. Acest lucru este stipulat \u00een standard. Cei care vor s\u0103 intre \u00een storaje, scriu 128 kilobi\u021bi. Bibliotecile, de altfel, taie mesajul \u0219i marcheaz\u0103 faptul c\u0103 mesajul a fost t\u0103iat. \u00cen standardul mesajului nostru exist\u0103 un c\u00e2mp special care arat\u0103 dac\u0103 acesta a fost t\u0103iat la scriere sau nu. A\u0219adar, avem posibilitatea de a urm\u0103ri \u0219i acest aspect.<\/p>\n<\/p>\n
\u00centrebare<\/strong>: Scrie\u021bi JSON-uri defecte? <\/p>\n<\/p>\n
R\u0103spuns<\/strong>: JSON-ul defect va fi respins fie \u00een timpul relay-ului, pentru c\u0103 pachetul este prea mare. Fie va fi respins de Graylog, pentru c\u0103 nu va putea s\u0103 parseze JSON-ul. Dar aici sunt nuan\u021be care trebuie rezolvate, \u0219i acestea sunt \u00een mare parte legate de rsyslog. Am deja c\u00e2teva issue completate acolo, la care trebuie s\u0103 mai lucr\u0103m.<\/p>\n<\/p>\n
\u00centrebare<\/strong>: De ce Kafka? A\u021bi \u00eencercat RabbitMQ? Nu se descurc\u0103 Graylog cu astfel de \u00eenc\u0103rc\u0103ri?<\/p>\n<\/p>\n
R\u0103spuns<\/strong>: La noi nu func\u021bioneaz\u0103 cu Graylog. Dar Graylog-ul nostru func\u021bioneaz\u0103. Este o chestiune complicat\u0103. De fapt, el nu este necesar. A\u0219 prefera s\u0103 scriu din rsyslog direct \u00een elasticsearch \u0219i s\u0103 vizualizez apoi \u00een Kibana. Dar trebuie s\u0103 rezolv\u0103m problema cu cei de la securitate. Aceasta este o posibil\u0103 direc\u021bie de dezvoltare pentru noi, c\u00e2nd vom elimina Graylog-ul \u0219i vom folosi Kibana. Nu ar avea sens s\u0103 folosim Logstash. Pentru c\u0103, pot face toate acestea cu rsyslog. \u0218i acesta are un modul pentru a scrie \u00een elasticsearch. Cu Graylog \u00eencerc\u0103m cumva s\u0103 coabit\u0103m. Chiar l-am optimizat pu\u021bin. Dar mai este loc pentru \u00eembun\u0103t\u0103\u021biri.<\/p>\n<\/p>\n
Despre Kafka. A\u0219a a fost istoric. C\u00e2nd am venit, ea era deja acolo \u0219i se scriau deja jurnale \u00een ea. Noi ne-am ridicat clusterele \u0219i am mutat log-urile \u00een ea. Noi ne ocup\u0103m de managementul s\u0103u, \u0219tim cum se simte. Despre RabbitMQ... nu ne iese cu RabbitMQ. Pe de alt\u0103 parte, RabbitMQ func\u021bioneaz\u0103 pentru noi. Avem \u00een produc\u021bie \u0219i au fost probleme cu el. Acum, \u00eenainte de v\u00e2nzarea de reduceri, l-am optimizat \u0219i a \u00eenceput s\u0103 func\u021bioneze corect. Dar \u00eenainte de asta, nu m\u0103 sim\u021beam preg\u0103tit s\u0103-l pun \u00een produc\u021bie. Mai este \u00eenc\u0103 un aspect. Graylog poate citi versiunea AMQP 0.9, iar rsyslog poate scrie versiunea AMQP 1.0. Nu exist\u0103 nicio solu\u021bie care s\u0103 poat\u0103 gestiona ambele. Fie este una, fie cealalt\u0103. A\u0219adar, \u00een acest moment, doar Kafka. Dar au \u0219i ele nuan\u021bele lor. Pentru c\u0103 omkafka la versiunea rsyslog pe care o folosim poate pierde tot buffer-ul de mesaje pe care l-a extras din rsyslog. P\u00e2n\u0103 acum ne-am adaptat la asta. <\/p>\n
<\/p>\n
\u00centrebare<\/strong>: Folosi\u021bi Kafka pentru c\u0103 era deja la voi? Nu este folosit\u0103 pentru alte scopuri?<\/p>\n<\/p>\n
R\u0103spuns<\/strong>: Kafka, care era, este folosit\u0103 de echipa de Data Science. Este un proiect complet separat, despre care, din p\u0103cate, nu pot spune nimic. Nu sunt la curent. A fost \u00een administrarea echipei de Data Science. C\u00e2nd au \u00eenceput s\u0103 utilizeze log-uri, au decis s\u0103 o foloseasc\u0103, pentru a nu fi nevoie s\u0103 instaleze \u00eenc\u0103 una. Acum am actualizat Graylog \u0219i compatibilitatea s-a pierdut, deoarece era o versiune veche de Kafka. A trebuit s\u0103 ne configur\u0103m propria versiune. De asemenea, ne-am desf\u0103cut aceste patru subiecte pentru fiecare API. Am creat un subiect larg pentru tot live, un subiect larg pentru toate staging-urile \u0219i pur \u0219i simplu trimitem tot acolo. Graylog le extrage pe toate acestea \u00een paralel.<\/p>\n<\/p>\n
\u00centrebare<\/strong>: De ce este necesar\u0103 toat\u0103 aceast\u0103 magie cu socket-urile? A\u021bi \u00eencercat s\u0103 folosi\u021bi driverul log syslog pentru containere.<\/p>\n<\/p>\n
R\u0103spuns<\/strong>: La acel moment c\u00e2nd ne ocupam de aceast\u0103 problem\u0103, rela\u021bia noastr\u0103 cu Docker era tensioat\u0103. Era Docker 1.0 sau 0.9. Docker, \u00een sine, era ciudat. \u00cen al doilea r\u00e2nd, dac\u0103 ad\u0103ug\u0103m \u0219i loguri \u00een el... Am o suspiciune neconfirmat\u0103 c\u0103 acesta trece toate logurile prin el, prin demonul Docker. Dac\u0103 un API devine instabil, celelalte API-uri dau peste problema c\u0103 nu pot trimite stdout \u0219i stderr. Nu \u0219tiu unde va duce asta. Am o intui\u021bie c\u0103 nu ar trebui s\u0103 folosim driverul syslog Docker \u00een acest context. Departamentul nostru de testare func\u021bional\u0103 are propriul cluster mic Graylog cu loguri. Ei folosesc driverele de loguri ale Docker-ului \u0219i se pare c\u0103 la ei merge totul bine. Dar ei scriu GELF direct \u00een Graylog. La acel moment, c\u00e2nd am \u00eenceput totul, aveam nevoie s\u0103 func\u021bioneze pur \u0219i simplu. Poate mai t\u00e2rziu, c\u00e2nd cineva va veni \u0219i va spune c\u0103 func\u021bioneaz\u0103 bine de o sut\u0103 de ani, vom \u00eencerca.<\/p>\n<\/p>\n
\u00centrebare<\/strong>: Face\u021bi livrarea \u00eentre centrele de date pe rsyslog. De ce nu pe Kafka?<\/p>\n<\/p>\n
R\u0103spuns<\/strong>: Facem \u0219i a\u0219a, \u0219i a\u0219a, de fapt. Din dou\u0103 motive. Dac\u0103 canalul este complet distrus, atunci toate logurile noastre, chiar \u0219i \u00een format comprimat, nu trec. Iar Kafka permite pur \u0219i simplu pierderea acestora \u00een proces. Prin acest mod ne eliber\u0103m de blocajele acestor loguri. Folosim direct Kafka \u00een acest caz. Dac\u0103 avem un canal bun \u0219i vrem s\u0103-l eliber\u0103m, atunci folosim rsyslog-ul. Dar, de fapt, se poate configura astfel \u00eenc\u00e2t s\u0103 elimine automat ceea ce nu a trecut. \u00cen acest moment folosim livrarea rsyslog direct \u00een unele locuri, iar \u00een altele Kafka.<\/p>\nSursa: habr.com<\/a><\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"\u041b\u043e\u0433\u0438 \u2014 \u0432\u0430\u0436\u043d\u0430\u044f \u0447\u0430\u0441\u0442\u044c \u0441\u0438\u0441\u0442\u0435\u043c\u044b, \u043f\u043e\u0437\u0432\u043e\u043b\u044f\u044e\u0449\u0430\u044f \u043f\u043e\u043d\u044f\u0442\u044c, \u0447\u0442\u043e \u043e\u043d\u0430 \u0440\u0430\u0431\u043e\u0442\u0430\u0435\u0442 (\u043b\u0438\u0431\u043e \u043d\u0435 \u0440\u0430\u0431\u043e\u0442\u0430\u0435\u0442), \u043a\u0430\u043a \u043e\u0436\u0438\u0434\u0430\u0435\u0442\u0441\u044f. \u0412 \u0443\u0441\u043b\u043e\u0432\u0438\u044f\u0445 \u043c\u0438\u043a\u0440\u043e\u0441\u0435\u0440\u0432\u0438\u0441\u043d\u043e\u0439 \u0430\u0440\u0445\u0438\u0442\u0435\u043a\u0442\u0443\u0440\u044b \u0440\u0430\u0431\u043e\u0442\u0430 \u0441 \u043b\u043e\u0433\u0430\u043c\u0438 \u0441\u0442\u0430\u043d\u043e\u0432\u0438\u0442\u0441\u044f \u043e\u0442\u0434\u0435\u043b\u044c\u043d\u043e\u0439 \u0434\u0438\u0441\u0446\u0438\u043f\u043b\u0438\u043d\u043e\u0439 \u0441\u043f\u0435\u0446\u0438\u0430\u043b\u044c\u043d\u043e\u0439 \u043e\u043b\u0438\u043c\u043f\u0438\u0430\u0434\u044b. \u041d\u0443\u0436\u043d\u043e \u0440\u0435\u0448\u0438\u0442\u044c \u0441\u0440\u0430\u0437\u0443 \u043a\u0443\u0447\u0443 \u0432\u043e\u043f\u0440\u043e\u0441\u043e\u0432: \u043a\u0430\u043a \u043f\u0438\u0441\u0430\u0442\u044c \u043b\u043e\u0433\u0438 \u0438\u0437 \u043f\u0440\u0438\u043b\u043e\u0436\u0435\u043d\u0438\u044f; \u043a\u0443\u0434\u0430 \u043f\u0438\u0441\u0430\u0442\u044c \u043b\u043e\u0433\u0438; \u043a\u0430\u043a \u0434\u043e\u0441\u0442\u0430\u0432\u043b\u044f\u0442\u044c \u043b\u043e\u0433\u0438 \u0434\u043b\u044f \u0445\u0440\u0430\u043d\u0435\u043d\u0438\u044f \u0438 \u043e\u0431\u0440\u0430\u0431\u043e\u0442\u043a\u0438; \u043a\u0430\u043a \u043e\u0431\u0440\u0430\u0431\u0430\u0442\u044b\u0432\u0430\u0442\u044c \u0438 \u0445\u0440\u0430\u043d\u0438\u0442\u044c \u043b\u043e\u0433\u0438. \u041f\u0440\u0438\u043c\u0435\u043d\u0435\u043d\u0438\u0435 \u043f\u043e\u043f\u0443\u043b\u044f\u0440\u043d\u044b\u0445 \u043d\u044b\u043d\u0435 […]<\/p>\n","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"author":1,"featured_media":24507,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[688],"tags":[],"class_list":["post-32723","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-administrirovanie"],"aioseo_notices":[],"aioseo_head":"\n\t\t\n\t
![\"Reda\u021bi](\"https:\/\/img.youtube.com\/vi\/NAeedJv-S3I\/hqdefault.jpg\")
\r\n