l'articolo su Badushka<\/a><\/noindex>, che ne parlava. Ma c'\u00e8 un problema. Intorno a questa chiamata c'era un ciclo infinito, in cui si tentava continuamente di inviare un messaggio nel socket. Questo non lo abbiamo notato. Abbiamo dovuto riscrivere la libreria. Da allora \u00e8 cambiata diverse volte, ma adesso ci siamo liberati dai blocchi in tutti i sottosistemi. Quindi, possiamo fermare rsyslog senza che nulla si interrompa.<\/p>\n<\/p>\n
\u00c8 necessario monitorare la dimensione delle code, il che aiuta a evitare di inciampare in questi problemi. Innanzitutto, possiamo monitorare quando iniziamo a perdere messaggi. In secondo luogo, possiamo monitorare se abbiamo a che fare con problemi di consegna.<\/p>\n
<\/p>\n
E c'\u00e8 anche un aspetto sgradevole: l'amplificazione dieci volte nell'architettura a microservizi \u00e8 molto facile. Non abbiamo molti richieste in entrata, ma a causa del grafo dove questi messaggi si muovono, a causa dei log di accesso, aumentiamo davvero il carico sui log circa dieci volte. Purtroppo non ho avuto il tempo di calcolare le cifre esatte, ma i microservizi sono cos\u00ec. Bisogna tenerne conto. Risulta che attualmente il sottosistema di raccolta dei log \u00e8 il pi\u00f9 sovraccarico in Lazada. <\/p>\n
<\/p>\n
<\/p>\n
Come risolvere il problema di elasticsearch? Se \u00e8 necessario ottenere rapidamente i log in un unico luogo, per non dover girovagare tra tutte le macchine e raccoglierli, utilizzare uno storage di file. Questo funziona garantito. Pu\u00f2 essere creato da qualsiasi server. \u00c8 sufficiente attaccare dischi e installare syslog. Dopo di ci\u00f2, avrete garantito tutti i log in un unico luogo. Poi potete impostare elasticsearch, graylog o qualcos'altro. Ma avrete gi\u00e0 tutti i log, e, per di pi\u00f9, potrete conservarli a seconda della capacit\u00e0 dei dischi.<\/p>\n
<\/p>\n
<\/p>\n
Al momento della mia presentazione, lo schema era cos\u00ec. Abbiamo praticamente smesso di scrivere su file. Ora, probabilmente, disattiveremo il resto. Sulle macchine locali, su cui sono eseguite le API, smetteremo di scrivere su file. In primo luogo, c'\u00e8 uno storage di file che funziona molto bene. In secondo luogo, su queste macchine il posto finisce sempre, bisogna monitorarlo costantemente.<\/p>\n
<\/p>\n
Questa parte con Logstash e Graylog \u00e8 davvero problematica. Quindi dobbiamo liberarci di essa. \u00c8 necessario scegliere una sola cosa.<\/p>\n
<\/p>\n
<\/p>\n
Abbiamo deciso di eliminare Logstash e Kibana. Perch\u00e9 abbiamo un dipartimento di sicurezza. Qual \u00e8 il legame? La connessione \u00e8 che Kibana senza X-Pack e Shield non consente di limitare i diritti di accesso ai log. Pertanto, abbiamo scelto Graylog. Ha tutto ci\u00f2 che serve. Non mi piace, ma funziona. Abbiamo acquistato nuovo hardware, installato Graylog recente e trasferito tutti i log con formati rigorosi in un Graylog separato. Abbiamo risolto il problema con i diversi tipi di campi identici a livello organizzativo.<\/p>\n
<\/p>\n
<\/p>\n
Ci\u00f2 che entra nel nuovo Graylog. Abbiamo semplicemente registrato tutto in docker. Abbiamo preso una serie di server, distribuito tre istanze di Kafka, 7 server Graylog versione 2.3 (perch\u00e9 volevamo Elasticsearch versione 5). Tutto questo su RAID di HDD. Abbiamo visto una velocit\u00e0 di indicizzazione fino a 100.000 messaggi al secondo. Abbiamo visto che 140 terabyte di dati vengono elaborati a settimana. <\/p>\n
<\/p>\n
<\/p>\n
E di nuovo problemi! Abbiamo due saldi in arrivo. Siamo passati a 6 milioni di messaggi. Graylog non riesce a elaborare. Dobbiamo trovare un modo per sopravvivere. <\/p>\n
<\/p>\n
<\/p>\n
Siamo sopravvissuti in questo modo. Abbiamo aggiunto un po' di server e SSD. Attualmente viviamo in questo modo. Ora, stiamo elaborando gi\u00e0 160.000 messaggi al secondo. Non abbiamo ancora raggiunto i limiti, quindi per il momento non \u00e8 chiaro quanto realmente riusciremo a ottenere da questo. <\/p>\n
<\/p>\n
<\/p>\n
Questi sono i nostri piani per il futuro. Tra di essi, probabilmente, la cosa pi\u00f9 importante \u00e8 l'alta disponibilit\u00e0. Al momento non ce l'abbiamo. Alcune macchine sono configurate allo stesso modo, ma tutto passa ancora attraverso una macchina. Dobbiamo prendere tempo per impostare il failover tra di loro.<\/p>\n
<\/p>\n
Raccogliere le metriche da Graylog.<\/p>\n
<\/p>\n
Impostare un rate limit in modo che una API impazzita non ci uccida la larghezza di banda e tutto il resto.<\/p>\n
<\/p>\n
E infine, firmare un SLA con gli sviluppatori, con cui possiamo garantire questo grado di servizio. Se scrivete di pi\u00f9, ci dispiace.<\/p>\n
<\/p>\n
E scrivere la documentazione.<\/p>\n
<\/p>\n
<\/p>\n
In breve, un riepilogo di tutto ci\u00f2 che abbiamo vissuto. Prima di tutto, gli standard. In secondo luogo, syslog \u00e8 come una torta. In terzo luogo, rsyslog funziona proprio cos\u00ec come indicato nella slide. Passiamo ora alle domande.<\/p>\n
<\/p>\n
Domande<\/strong>.<\/p>\n<\/p>\n
Domanda<\/strong>: Perch\u00e9 alla fine avete deciso di non prendere\u2026 (filebeat?)<\/p>\n<\/p>\n
Risposta<\/strong>: \u00c8 necessario scrivere su file. Non volevo proprio. Quando l'API scrive migliaia di messaggi al secondo, anche se ruoti ogni ora, non \u00e8 comunque un'opzione. Si pu\u00f2 scrivere in pipe. Gli sviluppatori mi hanno chiesto: \u00abE se il processo su cui scriviamo si blocca?\u00bb Non sapevo cosa rispondere e ho detto: \u00abVa bene, evitiamo di farlo\u00bb.<\/p>\n<\/p>\n
Domanda<\/strong>: Perch\u00e9 non scrivete semplicemente i log in HDFS?<\/p>\n<\/p>\n
Risposta<\/strong>: Questo \u00e8 il prossimo passo. Ci abbiamo pensato fin dall'inizio, ma attualmente non abbiamo risorse per gestirlo, quindi rimane una soluzione a lungo termine.<\/p>\n<\/p>\n
Domanda<\/strong>: Un formato colonnare sarebbe pi\u00f9 appropriato.<\/p>\n<\/p>\n
Risposta<\/strong>: Capisco tutto. Noi siamo \"a favore\" con entrambe le mani. <\/p>\n<\/p>\n
Domanda<\/strong>: Scrivete in rsyslog. Ci si pu\u00f2 connettere sia via TCP che UDP. Ma se usate UDP, come garantite la consegna?<\/p>\n<\/p>\n
Risposta<\/strong>: Ci sono due aspetti. Primo, dico subito a tutti che non garantiamo la consegna dei log. Perch\u00e9 quando gli sviluppatori arrivano e dicono: \u00abIniziamo a scrivere dati finanziari l\u00ec e voi li terrete da qualche parte nel caso succeda qualcosa\u00bb, noi rispondiamo: \u00abOttimo! Cominciate a bloccarvi mentre scrivete nel socket e a farlo in transazioni, in modo da garantirci che li mettiate nel socket e che noi li riceviamo dall'altro lato.\u00bb E in quel momento tutti si tirano indietro. Se non volete garantire la scrittura nel socket, perch\u00e9 dovremmo garantire la consegna? Facciamo del nostro meglio. Ci impegniamo realmente a consegnare il pi\u00f9 possibile e nel modo migliore, ma non offriamo garanzie al 100%. Quindi non scrivete dati finanziari l\u00ec. Ci sono database con transazioni per questo.<\/p>\n<\/p>\n
Domanda<\/strong>: Quando l'API genera un messaggio nel log e passa il controllo ai microservizi, avete riscontrato problemi con l'arrivo dei messaggi in ordine errato? Questo crea confusione.<\/p>\n<\/p>\n
Risposta<\/strong>: \u00c8 normale che arrivino in ordine diverso. Bisogna essere pronti a questo. Perch\u00e9 qualsiasi consegna su rete non garantisce l'ordine, o bisogna spendere risorse specifiche per farlo. Se consideriamo gli archivi file, ogni API salva i log nel proprio file. In effetti, rsyslog li organizza in cartelle. Ogni API ha i propri log, dove si pu\u00f2 andare a controllare, e poi si possono confrontare per timestamp. Se guardano in Graylog, l\u00ec saranno ordinati per timestamp. Tutto sar\u00e0 in ordine.<\/p>\n<\/p>\n
Domanda<\/strong>: Il timestamp pu\u00f2 differire di millisecondi.<\/p>\n<\/p>\n
Risposta<\/strong>: Il timestamp \u00e8 generato dall'API stessa. Questo \u00e8, in realt\u00e0, il punto. Noi abbiamo NTP. L'API genera il timestamp gi\u00e0 nel messaggio. Non lo aggiunge rsyslog.<\/p>\n<\/p>\n
Domanda<\/strong>: Non \u00e8 chiaro come avviene l'interazione tra i data center. All'interno del data center \u00e8 chiaro come sono stati raccolti e elaborati i log. Come avviene l'interazione tra i data center? Oppure ogni data center vive la propria vita?<\/p>\n<\/p>\n
Risposta<\/strong>: Quasi. Ogni paese \u00e8 situato in un singolo data center. Attualmente non abbiamo distribuzioni che mettano un paese in diversi data center. Quindi non \u00e8 necessario unirli. All'interno di ogni centro c'\u00e8 un Log Relay. \u00c8 un server Rsyslog. In realt\u00e0 ci sono due macchine di gestione. Sono configurate in modo identico. Ma per ora il traffico passa attraverso una di esse. Questa aggrega i log. Ha una coda su disco per ogni evenienza. Comprime i log e li invia al data center centrale (a Singapore), dove poi vengono inviati a Graylog. E in ogni data center c'\u00e8 il proprio storage file. In caso di perdita di connessione, abbiamo tutti i log l\u00ec. Rimarranno l\u00e0. Saranno salvati.<\/p>\n<\/p>\n
Domanda<\/strong>: In situazioni straordinarie, ricevete i log da l\u00ec?<\/p>\n<\/p>\n
Risposta<\/strong>: Si pu\u00f2 andare l\u00ec (nello storage file) e controllare.<\/p>\n<\/p>\n
Domanda<\/strong>: Come monitorate di non perdere log?<\/p>\n<\/p>\n
Risposta<\/strong>: In realt\u00e0, li perdiamo e ne monitoriamo la perdita. Abbiamo avviato il monitoraggio un mese fa. Nella libreria utilizzata dall'API Go, ci sono metriche. \u00c8 in grado di contare quante volte non \u00e8 riuscita a scrivere nel socket. Attualmente c'\u00e8 un'astuzia. C'\u00e8 un buffer. Cerca di scrivere messaggi in esso nel socket. Se il buffer si riempie, inizia a eliminarli. E conta quanti ne ha eliminati. Se i contatori iniziano a riempirsi, ne veniamo a conoscenza. Questi dati arrivano anche a Prometheus e si possono visualizzare grafici in Grafana. \u00c8 possibile impostare avvisi. Ma per ora non \u00e8 chiaro a chi inviarli.<\/p>\n<\/p>\n
Domanda<\/strong>: In Elasticsearch, conservate i log con il backup. Quante repliche hai?<\/p>\n<\/p>\n
Risposta<\/strong>: Una replica.<\/p>\n<\/p>\n
Domanda<\/strong>: \u00c8 solo una replica?<\/p>\n<\/p>\n
Risposta<\/strong>: Questo \u00e8 un master e una replica. I dati sono memorizzati in due copie.<\/p>\n<\/p>\n
Domanda<\/strong>: Hai modificato in qualche modo la dimensione del buffer di rsyslog? <\/p>\n<\/p>\n
Risposta<\/strong>: Scriviamo datagrammi in un socket Unix personalizzato. Questo ci impone immediatamente un limite di 128 kilobyte. Non possiamo scrivere pi\u00f9 di questo. L'abbiamo specificato nello standard. Chi vuole entrare negli storage deve scrivere 128 kilobyte. Le librerie, tra l'altro, troncano e impostano un flag che indica che il messaggio \u00e8 stato troncato. Nel nostro standard del messaggio c'\u00e8 un campo speciale che mostra se \u00e8 stato troncato durante la scrittura. Quindi abbiamo la possibilit\u00e0 di tracciare anche questo aspetto.<\/p>\n<\/p>\n
Domanda<\/strong>: Scrivete JSON danneggiati? <\/p>\n<\/p>\n
Risposta<\/strong>: Un JSON danneggiato verr\u00e0 scartato o durante il relay, perch\u00e9 il pacchetto \u00e8 troppo grande. Oppure verr\u00e0 scartato da Graylog, perch\u00e9 non riesce a fare il parsing del JSON. Ma ci sono delle sfumature che devono essere sistemate, e sono per lo pi\u00f9 legate a rsyslog. Ho gi\u00e0 inserito alcune issue l\u00ec su cui dobbiamo ancora lavorare.<\/p>\n<\/p>\n
Domanda<\/strong>: Perch\u00e9 Kafka? Hai provato RabbitMQ? Graylog non funziona con questi carichi?<\/p>\n<\/p>\n
Risposta<\/strong>: Con Graylog non funziona. Ma Graylog funziona con noi. \u00c8 davvero complicato. \u00c8 una cosa particolare. E, in realt\u00e0, non \u00e8 necessario. Preferirei scrivere da rsyslog direttamente in Elasticsearch e poi vedere Kibana. Ma dobbiamo risolvere la questione con i responsabili della sicurezza. Questa \u00e8 una possibile direzione per il nostro sviluppo, quando elimineremo Graylog e utilizzeremo Kibana. Non avrebbe senso usare Logstash. Perch\u00e9, posso fare tutto ci\u00f2 con rsyslog. E ha un modulo per scrivere in Elasticsearch. Stiamo cercando di convivere con Graylog. L'abbiamo anche ottimizzato un po'. Ma c'\u00e8 ancora margine per miglioramenti.<\/p>\n<\/p>\n
Per quanto riguarda Kafka. \u00c8 cos\u00ec storicamente. Quando sono arrivato, c'era gi\u00e0 e ci scrivevano gi\u00e0 i log. Abbiamo semplicemente alzato il nostro cluster e ci siamo trasferiti con i log. Lo gestiamo, sappiamo come si comporta. Per quanto riguarda RabbitMQ... con RabbitMQ non funziona. E noi abbiamo un RabbitMQ funzionante. \u00c8 in produzione, e c'erano problemi. Ora lo abbiamo sistemato prima della vendita, e ha iniziato a funzionare correttamente. Ma prima non ero pronto a rilasciarlo in produzione. C'\u00e8 anche un altro punto. Graylog sa leggere la versione AMQP 0.9, mentre rsyslog sa scrivere la versione AMQP 1.0. E non esiste alcuna soluzione che sia in grado di gestire entrambe le versioni. Ci sono o l'uno o l'altro. Quindi al momento solo Kafka. Ma ci sono anche alcune sfide. Perch\u00e9 omkafka, la versione di rsyslog che stiamo utilizzando, pu\u00f2 perdere l'intero buffer dei messaggi che ha estratto da rsyslog. Al momento conviviamo con questo. <\/p>\n
<\/p>\n
Domanda<\/strong>: Utilizzate Kafka perch\u00e9 era gi\u00e0 presente? Non viene utilizzato per altri scopi?<\/p>\n<\/p>\n
Risposta<\/strong>: La Kafka che c'era viene utilizzata dal team di Data Science. \u00c8 un progetto completamente separato, di cui purtroppo non posso dire nulla. Non sono al corrente. Era sotto la gestione del team di Data Science. Quando hanno avviato i log, hanno deciso di utilizzarla per non doverne installare un'altra. Ora abbiamo aggiornato Graylog, e abbiamo perso la compatibilit\u00e0, perch\u00e9 c'era una vecchia versione di Kafka. Abbiamo dovuto creare la nostra. Allo stesso tempo, ci siamo liberati di quei quattro topic per ogni API. Abbiamo creato un ampio topic per tutto il live, un ampio topic per tutto lo staging e semplicemente ci buttiamo tutto dentro. Graylog estrae tutto questo in parallelo.<\/p>\n<\/p>\n
Domanda<\/strong>: Perch\u00e9 \u00e8 necessario questo rito sciamanico con i socket? Hai provato a utilizzare il driver di log syslog per i contenitori?<\/p>\n<\/p>\n
Risposta<\/strong>: Al momento in cui ci ponemmo questa domanda, i nostri rapporti con Docker erano tesi. Era Docker 1.0 o 0.9. Docker era strano di per s\u00e9. In secondo luogo, se dovessimo anche registrare i log... Ho un sospetto non verificato che faccia passare tutti i log attraverso di s\u00e9, tramite il demone di Docker. Se un API impazzisce, le altre API non possono inviare stdout e stderr. Non so a cosa porter\u00e0 questo. Ho la sensazione che non sia necessario utilizzare il driver syslog di Docker in quel contesto. Il nostro dipartimento di test funzionali ha il proprio piccolo cluster Graylog con log. Utilizzano i driver di log di Docker e sembra che funzioni bene. Ma scrivono direttamente in Graylog in formato GELF. Quando abbiamo iniziato tutto questo, dovevamo solo che funzionasse. Forse poi, quando qualcuno dir\u00e0 che funziona bene da anni, proveremo.<\/p>\n<\/p>\n
Domanda<\/strong>: Fai il trasporto tra i datacenter utilizzando rsyslog. Perch\u00e9 non con Kafka?<\/p>\n<\/p>\n
Risposta<\/strong>: Facciamo cos\u00ec e cos\u00ec in realt\u00e0. Per due motivi. Se il canale \u00e8 completamente danneggiato, i nostri log, anche in forma compressa, non riescono a passarvi attraverso. Kafka consente semplicemente di perderli nel processo. In questo modo ci liberiamo dall'intasamento di questi log. In questo caso, utilizziamo Kafka direttamente. Se il nostro canale \u00e8 buono e vogliamo liberarlo, utilizziamo rsyslog. Ma in realt\u00e0 pu\u00f2 essere configurato in modo tale da scartare ci\u00f2 che non passa. Al momento utilizziamo direttamente la consegna di rsyslog in alcune situazioni e Kafka in altre.<\/p>\nFonte: 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
![\"Riproduci](\"https:\/\/img.youtube.com\/vi\/NAeedJv-S3I\/hqdefault.jpg\")
\r\n