l'articolo su Badushka<\/a><\/noindex>, che ha scritto a riguardo. Ma c'\u00e8 un momento. Attorno a questa chiamata c'era un ciclo infinito, in cui si tentava costantemente di inserire un messaggio nel socket. Questo non lo abbiamo notato. Abbiamo dovuto riscrivere la libreria. Da allora \u00e8 cambiata diverse volte, ma ora ci siamo liberati dei blocchi in tutti i sottosistemi. Pertanto, possiamo fermare rsyslog, e nulla cadr\u00e0.<\/p>\n<\/p>\n
\u00c8 necessario monitorare la dimensione delle code, il che aiuta a non inciampare in queste trappole. In primo luogo, possiamo monitorare quando iniziamo a perdere messaggi. In secondo luogo, possiamo monitorare se abbiamo problemi di consegna.<\/p>\n
<\/p>\n
E c'\u00e8 anche una sgradevole questione: l'amplificazione di 10 volte in un'architettura a microservizi \u00e8 molto semplice. Non abbiamo cos\u00ec tante richieste in ingresso, ma a causa del grafo attraverso il quale questi messaggi vengono inviati, a causa dei log di accesso, aumentiamo realmente il carico dei log di circa dieci volte. Purtroppo non ho avuto tempo di calcolare i numeri esatti, ma i microservizi sono cos\u00ec. Questo \u00e8 da tenere a mente. Risulta che al momento 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 ricevere rapidamente i log in un unico posto, per non dover andare in giro per tutte le macchine e raccoglierli, utilizzare uno storage di file. Questo funziona garantito. Pu\u00f2 essere fatto da qualsiasi server. Basta semplicemente inserire dei dischi e impostare syslog. Dopo di che avrete garantito tutti i log in un solo posto. Dopo sar\u00e0 possibile configurare con calma elasticsearch, graylog o qualcos'altro. Ma avrete gi\u00e0 tutti i log e, tra l'altro, potete conservarli quanto basta le risorse di disco.<\/p>\n
<\/p>\n
<\/p>\n
Al momento della mia presentazione, lo schema \u00e8 diventato cos\u00ec. Abbiamo praticamente smesso di scrivere nei file. Adesso, probabilmente, disconneteremo i resti. Sulle macchine locali, su cui sono avviati gli API, non scriveremo pi\u00f9 nei file. In primo luogo, c'\u00e8 uno storage di file che funziona molto bene. In secondo luogo, su queste macchine lo spazio finisce costantemente, \u00e8 necessario monitorarlo continuamente.<\/p>\n
<\/p>\n
Questa parte con Logstash e Graylog \u00e8 veramente fastidiosa. Pertanto, dobbiamo liberarci di essa. \u00c8 necessario scegliere una sola opzione.<\/p>\n
<\/p>\n
<\/p>\n
Abbiamo deciso di abbandonare Logstash e Kibana. Perch\u00e9 abbiamo un reparto sicurezza. Qual \u00e8 il nesso? Il nesso \u00e8 che Kibana senza X-Pack e senza Shield non consente di differenziare i diritti di accesso ai log. Perci\u00f2 abbiamo scelto Graylog. Ha tutto ci\u00f2 di cui abbiamo bisogno. A me non piace, ma funziona. Abbiamo acquistato nuovo hardware, installato un Graylog fresco e trasferito tutti i log con formati rigidi in un Graylog separato. Abbiamo risolto il problema con i diversi tipi di campi identici a livello organizzativo.<\/p>\n
<\/p>\n
<\/p>\n
Cosa comprende effettivamente il nuovo Graylog. Abbiamo semplicemente registrato tutto in Docker. Abbiamo preso un bel po' di server, distribuito tre istanze di Kafka, 7 server Graylog versione 2.3 (perch\u00e9 volevamo Elasticsearch versione 5). Tutto questo \u00e8 stato caricato su RAID di HDD. Abbiamo visto un tasso di indicizzazione fino a 100 mila messaggi al secondo. Abbiamo visto che i dati ammontano a 140 terabyte a settimana. <\/p>\n
<\/p>\n
<\/p>\n
E di nuovo ostacoli! Abbiamo davanti a noi due vendite straordinarie. Siamo passati a 6 milioni di messaggi. Graylog non riesce a elaborare in tempo. Dobbiamo trovare un modo per sopravvivere di nuovo. <\/p>\n
<\/p>\n
<\/p>\n
Siamo sopravvissuti in questo modo. Abbiamo aggiunto qualche server e SSD in pi\u00f9. Attualmente viviamo in questo modo. Ora stiamo elaborando gi\u00e0 160.000 messaggi al secondo. Non abbiamo ancora raggiunto il limite, quindi non \u00e8 chiaro fin dove possiamo realmente spingerci. <\/p>\n
<\/p>\n
<\/p>\n
Ecco quali sono i nostri piani per il futuro. Tra di essi, davvero, la cosa pi\u00f9 importante \u00e8 probabilmente l'alta disponibilit\u00e0. Finora non ce l'abbiamo. Alcune macchine sono configurate allo stesso modo, ma tutto passa ancora attraverso una macchina. Dobbiamo investire tempo per impostare un failover tra di loro.<\/p>\n
<\/p>\n
Raccogliere metriche da Graylog.<\/p>\n
<\/p>\n
Implementare un rate limit affinch\u00e9 un'API impazzita non ci distrugga la larghezza di banda e tutto il resto.<\/p>\n
<\/p>\n
E infine, firmare qualche SLA con gli sviluppatori, in modo da evidenziare che possiamo gestire solo un certo volume. Se ne scrivete di pi\u00f9, ci dispiace.<\/p>\n
<\/p>\n
E redigere la documentazione.<\/p>\n
<\/p>\n
<\/p>\n
In sintesi, ecco i risultati di tutto ci\u00f2 che abbiamo vissuto. Prima di tutto, gli standard. In secondo luogo, syslog \u2014 un capolavoro. In terzo luogo, rsyslog funziona proprio come scritto nella diapositiva. E ora passiamo alle domande.<\/p>\n
<\/p>\n
Domande<\/strong>.<\/p>\n<\/p>\n
Domanda<\/strong>: Perch\u00e9 alla fine avete deciso di non usare\u2026 (filebeat?)<\/p>\n<\/p>\n
Risposta<\/strong>: \u00c8 necessario scrivere su file. Molto controvoglia. Quando hai un'API che scrive migliaia di messaggi al secondo, anche se ruoti ogni ora, non \u00e8 comunque una soluzione praticabile. Si pu\u00f2 scrivere su pipe. A questo punto, gli sviluppatori mi hanno chiesto: \"E se il processo in cui scriviamo si interrompe?\" Non ho trovato cosa rispondere e ho detto: \"Va bene, non facciamolo\".<\/p>\n<\/p>\n
Domanda<\/strong>: Perch\u00e9 non scrivete i log direttamente in HDFS?<\/p>\n<\/p>\n
Risposta<\/strong>: Questo \u00e8 il prossimo passo. Ci abbiamo pensato all'inizio, ma poich\u00e9 al momento non ci sono risorse per occuparci di questo, resta una soluzione a lungo termine.<\/p>\n<\/p>\n
Domanda<\/strong>: Il formato colonnare sarebbe pi\u00f9 appropriato.<\/p>\n<\/p>\n
Risposta<\/strong>: Capisco tutto. Siamo \"a favore\" con entrambe le mani. <\/p>\n<\/p>\n
Domanda<\/strong>: Scrivete in rsyslog. Qui si pu\u00f2 usare sia TCP che UDP. Ma se usate UDP, come garantite la consegna?<\/p>\n<\/p>\n
Risposta<\/strong>: Ci sono due aspetti. Prima di tutto, dico subito a tutti che non garantiamo la consegna dei log. Perch\u00e9 quando i programmatori vengono e dicono: \u00abIniziamo a scrivere i dati finanziari l\u00ec, e voi li archivierete da qualche parte nel caso succeda qualcosa\u00bb, noi rispondiamo: \u00abOttimo! Iniziate a bloccarvi nella scrittura nel socket e fatelo in transazioni, per assicurarvi di metterlo nel socket e di essere certi che noi dall'altra parte lo abbiamo ricevuto.\u00bb E in quel momento a tutti non interessa pi\u00f9. E se non interessa, quali domande possono avere nei nostri confronti? Se non volete garantire la scrittura nel socket, perch\u00e9 dovremmo garantire la consegna? Noi facciamo il massimo sforzo. Ci impegniamo davvero a consegnare il pi\u00f9 possibile e nel miglior modo possibile, ma non diamo il 100% di garanzia. Pertanto, non scrivete l\u00ec i dati finanziari. Per questo ci sono database con transazioni.<\/p>\n<\/p>\n
Domanda<\/strong>: Quando l'API genera un messaggio nei log e passa il controllo ai microservizi, non vi siete mai imbattuti nel problema che i messaggi dai diversi microservizi arrivano nell'ordine sbagliato? 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 di rete non garantisce l'ordine, o si deve spendere risorse specifiche per questo. Se consideriamo i file di archiviazione, ogni API salva i log nel proprio file. In realt\u00e0, rsyslog li organizza in cartelle. Ogni API ha i propri log, dove si pu\u00f2 andare a vedere e poi confrontarli per timestamp. Se vanno a vedere in Graylog, l\u00ec saranno ordinati per timestamp. Tutto andr\u00e0 bene.<\/p>\n<\/p>\n
Domanda<\/strong>: Il timestamp pu\u00f2 differire di millisecondi.<\/p>\n<\/p>\n
Risposta<\/strong>: Il timestamp viene generato dall'API stessa. Questa \u00e8 tutta la questione. Abbiamo NTP. L'API genera il timestamp gi\u00e0 nel messaggio. Non \u00e8 rsyslog a aggiungerlo.<\/p>\n<\/p>\n
Domanda<\/strong>: Non \u00e8 molto chiara l'interazione tra i data center. All'interno del data center \u00e8 chiaro come vengono raccolti e elaborati i log. Come avviene l'interazione tra i data center? O ogni data center vive di vita propria?<\/p>\n<\/p>\n
Risposta<\/strong>: Quasi. Ogni paese si trova in un unico data center. Al momento non abbiamo una distribuzione tale che un paese sia ospitato in pi\u00f9 data center. Quindi non c'\u00e8 bisogno di 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 allo stesso modo. Ma al momento tutto il traffico passa attraverso una di esse. Essa aggrega tutti i log. Ha una coda su disco per ogni evenienza. Comprime i log e li invia al data center centrale (quello di Singapore), dove vengono poi inviati a Graylog. E in ogni data center c'\u00e8 il proprio storage di file. In caso di perdita di connessione, abbiamo tutti i log l\u00ec. Resteranno l\u00ec. Saranno salvati.<\/p>\n<\/p>\n
Domanda<\/strong>: In situazioni di emergenza ricevete log da l\u00ec?<\/p>\n<\/p>\n
Risposta<\/strong>: Si pu\u00f2 andare l\u00ec (nello storage di file) e controllare.<\/p>\n<\/p>\n
Domanda<\/strong>: Come monitorate di non perdere i log?<\/p>\n<\/p>\n
Risposta<\/strong>: In realt\u00e0 li perdiamo, e lo monitoriamo. Il monitoraggio \u00e8 stato avviato un mese fa. Nella libreria utilizzata da Go API, ci sono delle metriche. \u00c8 in grado di contare quante volte non \u00e8 riuscita a scrivere nel socket. Attualmente c'\u00e8 un'euristica ingegnosa. C'\u00e8 un buffer. Prova a scrivere un messaggio dal buffer nel socket. Se il buffer si riempie, inizia a scartare i messaggi. E conta quanti ne ha scartati. Se i contatori iniziano a riempirsi, lo veniamo a sapere. Ora tutto questo arriva anche in Prometheus, e in Grafana \u00e8 possibile vedere i grafici. \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 ridondanza. Quante repliche avete?<\/p>\n<\/p>\n
Risposta<\/strong>: Una replica.<\/p>\n<\/p>\n
Domanda<\/strong>: Solo una replica?<\/p>\n<\/p>\n
Risposta<\/strong>: Questo \u00e8 il master e la replica. I dati sono conservati in due esemplari.<\/p>\n<\/p>\n
Domanda<\/strong>: Avete 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 subito un limite di 128 kilobyte. Non possiamo scrivere pi\u00f9 di questo. Abbiamo registrato questo nello standard. Chi vuole accedere agli storage deve scrivere 128 kilobyte. Le librerie, tra l'altro, accorciano e impostano un flag che indica che il messaggio \u00e8 stato accorciato. Nel nostro standard del messaggio stesso c'\u00e8 un campo speciale che mostra se \u00e8 stato accorciato durante la scrittura o meno. Quindi abbiamo la possibilit\u00e0 di monitorare 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, a causa di un pacchetto troppo grande. Oppure verr\u00e0 scartato da Graylog, perch\u00e9 non sar\u00e0 in grado di analizzare il JSON. Ma ci sono delle sfumature che devono essere sistemate, e in gran parte sono legate a rsyslog. Ho gi\u00e0 segnalato alcuni problemi l\u00ec, su cui dobbiamo ancora lavorare.<\/p>\n<\/p>\n
Domanda<\/strong>: Perch\u00e9 Kafka? Avete provato RabbitMQ? Graylog non funziona con questi carichi?<\/p>\n<\/p>\n
Risposta<\/strong>: Con Graylog non ci siamo. Ma Graylog funziona per noi. \u00c8 davvero problematico. \u00c8 una cosa particolare. E, in effetti, non \u00e8 necessario. Preferirei scrivere direttamente da rsyslog in elasticsearch e poi guardare in 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 esattamente la stessa cosa con rsyslog. E ha un modulo per scrivere in elasticsearch. Con Graylog stiamo cercando di convivere. L'abbiamo anche un po' ottimizzato. Ma c'\u00e8 ancora spazio per i miglioramenti.<\/p>\n<\/p>\n
Riguardo a Kafka. \u00c8 cos\u00ec storicamente. Quando sono arrivato, era gi\u00e0 presente e ci si scrivevano gi\u00e0 i log. Abbiamo semplicemente avviato il nostro cluster e ci siamo trasferiti l\u00ec con i log. Lo gestiamo, sappiamo come si comporta. Per quanto riguarda RabbitMQ... non ci stiamo trovando bene con RabbitMQ. Ma con RabbitMQ le cose vanno bene. Un production server ce l'abbiamo, e ci sono stati problemi. Prima dei saldi, l'abbiamo sistemato e ha iniziato a funzionare correttamente. Ma prima di ci\u00f2 non ero pronto a rilasciarlo in produzione. C'\u00e8 anche un altro aspetto. Graylog sa leggere la versione AMQP 0.9, mentre rsyslog sa scrivere la versione AMQP 1.0. E non c'\u00e8 una soluzione che faccia entrambe le cose. O una o l'altra. Pertanto, al momento stiamo usando solo Kafka. Ma ci sono anche delle peculiarit\u00e0. Perch\u00e9 omkafka, nella versione di rsyslog che stiamo usando, pu\u00f2 perdere tutto il buffer dei messaggi che ha estratto da rsyslog. Al momento ci stiamo convivendo. <\/p>\n
<\/p>\n
Domanda<\/strong>: Usate Kafka solo perch\u00e9 ce l'avevate gi\u00e0? Non \u00e8 utilizzato per altre finalit\u00e0?<\/p>\n<\/p>\n
Risposta<\/strong>: Kafka, che gi\u00e0 avevate, \u00e8 utilizzato dal team Data Science. Questo \u00e8 un progetto completamente separato, di cui purtroppo non posso dire nulla. Non sono aggiornato. Era sotto la gestione del team Data Science. Quando hanno iniziato a raccogliere i log, hanno deciso di usarlo per non dover installare il proprio. Ora abbiamo aggiornato Graylog e abbiamo perso la compatibilit\u00e0, perch\u00e9 c'era una vecchia versione di Kafka. Abbiamo dovuto crearne uno nostro. Allo stesso tempo, ci siamo liberati di quei quattro topic per ogni API. Ne abbiamo creato uno ampio per tutto il live, uno ampio per tutto il staging e semplicemente ci buttiamo tutto. Graylog lo estrapola tutto in parallelo.<\/p>\n<\/p>\n
Domanda<\/strong>: Perch\u00e9 c'\u00e8 bisogno di questa magia con i socket? Avete provato a utilizzare il log-driver syslog per i container?<\/p>\n<\/p>\n
Risposta<\/strong>: Al momento in cui ci stavamo ponendo questa domanda, il nostro rapporto con Docker era teso. Si trattava di Docker 1.0 o 0.9. Docker in s\u00e9 era strano. In secondo luogo, se ci si mettevano anche i log... Ho il sospetto non verificato che faccia passare tutti i log attraverso di s\u00e9, attraverso il demone di Docker. Se una delle nostre API va in crisi, le altre API si bloccano perch\u00e9 non riescono a inviare stdout e stderr. Non so a cosa porter\u00e0. Ho la sensazione che in questo caso non si debba usare il driver syslog di Docker. Il nostro dipartimento di testing funzionale ha il suo cluster di Graylog con i log. Usano i driver di log di Docker e l\u00ec sembra che tutto vada bene. Ma scrivono direttamente in Graylog in formato GELF. Al momento in cui stava per iniziare tutto questo, avevamo bisogno che funzionasse e basta. Forse poi, quando qualcuno dir\u00e0 che funziona bene da un secolo, ci proveremo.<\/p>\n<\/p>\n
Domanda<\/strong>: Perch\u00e9 fate la consegna tra i data center con rsyslog? Perch\u00e9 non con Kafka?<\/p>\n<\/p>\n
Risposta<\/strong>: In realt\u00e0 facciamo entrambe le cose. Per due motivi. Se il canale \u00e8 completamente danneggiato, tutti i log, anche in formato compresso, non riescono a passare. Kafka ci permette semplicemente di perderli nel processo. In questo modo evitiamo che questi log si bloccano. In questo caso, usiamo Kafka direttamente. Se il nostro canale \u00e8 buono e vogliamo liberarlo, allora usiamo rsyslog. Ma in realt\u00e0 \u00e8 possibile configurarlo in modo che scarti da solo quanto non passa. Al momento usiamo semplicemente rsyslog direttamente 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
![\"Guarda](\"https:\/\/img.youtube.com\/vi\/NAeedJv-S3I\/hqdefault.jpg\")
\r\n