{"id":53590,"date":"2019-12-05T00:00:00","date_gmt":"2019-12-04T21:00:00","guid":{"rendered":"https:\/\/prohoster.info\/blog\/blog_prohoster\/kak-my-v-tsian-ukroshhali-terabajty-logov"},"modified":"2020-02-18T14:01:30","modified_gmt":"2020-02-18T11:01:30","slug":"kak-my-v-tsian-ukroshhali-terabajty-logov","status":"publish","type":"post","link":"https:\/\/prohoster.info\/it\/blog\/administrirovanie\/kak-my-v-tsian-ukroshhali-terabajty-logov","title":{"rendered":"Come abbiamo gestito i terabyte di log in CIAN","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

\"Come
\n
\nCiao a tutti, mi chiamo Alessandro, lavoro in CIAN come ingegnere e mi occupo di amministrazione di sistema e automazione dei processi infrastrutturali. Nei commenti a uno dei nostri articoli precedenti ci hanno chiesto di raccontare come raccogliamo 4 TB di log al giorno e cosa ne facciamo. S\u00ec, abbiamo molti log, e per il loro trattamento \u00e8 stato creato un cluster infrastrutturale dedicato, che ci permette di risolvere i problemi in modo tempestivo. In questo articolo parler\u00f2 di come abbiamo adattato questo sistema nel corso di un anno per gestire un flusso di dati in costante crescita.
\n<\/a><\/noindex><\/p>\n

Da dove siamo partiti<\/h3>\n

\n\"Come
\n
\nNegli ultimi anni, il carico su cian.ru \u00e8 cresciuto rapidamente, e nel terzo trimestre del 2018 il sito ha raggiunto 11,2 milioni di utenti unici al mese. In quel periodo, nei momenti critici, abbiamo perso fino al 40% dei log, il che ci impediva di gestire rapidamente gli incidenti e ci faceva perdere molto tempo e risorse per risolverli. Spesso non riuscivamo nemmeno a trovare la causa del problema, il che si ripresentava dopo un certo periodo. Era un incubo, e bisognava fare qualcosa.<\/p>\n

All'epoca, per la conservazione dei log, utilizzavamo un cluster di 10 nodi dati con ElasticSearch versione 5.5.2 con impostazioni standard per gli indici. \u00c8 stato implementato pi\u00f9 di un anno fa come una soluzione popolare e accessibile: in quel momento, il flusso di log non era cos\u00ec elevato, quindi non c'era motivo di inventare configurazioni personalizzate.\u00a0<\/p>\n

La gestione dei log in entrata era garantita da Logstash su porte diverse su cinque coordinatori ElasticSearch. Un indice, indipendentemente dalle dimensioni, era composto da cinque shard. Era organizzata una rotazione oraria e giornaliera, risultando in circa 100 nuovi shard nel cluster ogni ora. Finch\u00e9 non c'era un numero eccessivo di log, il cluster gestiva la situazione e nessuno prestava attenzione alle sue impostazioni.\u00a0<\/p>\n

Problemi di rapida crescita<\/h3>\n

\nIl volume dei log generati cresceva rapidamente, poich\u00e9 si sovrapponevano due processi. Da una parte, il numero di utenti del servizio aumentava. Dall'altra, iniziavamo a migrare attivamente verso un'architettura a microservizi, suddividendo i nostri vecchi monoliti in C# e Python. Decine di nuovi microservizi, che sostituivano parti del monolite, generavano notevolmente pi\u00f9 log per il cluster infrastrutturale.\u00a0<\/p>\n

\u00c8 proprio la scalabilit\u00e0 che ci ha portato a un punto in cui il cluster \u00e8 diventato praticamente ingestibile. Quando i log hanno iniziato a fluire a una velocit\u00e0 di 20.000 messaggi al secondo, la frequente rotazione inutile ha aumentato il numero di shard a 6.000, e su una singola nodo gravavano pi\u00f9 di 600 shard.\u00a0<\/p>\n

Questo ha portato a problemi con l'allocazione della memoria. Quando un nodo falliva, iniziava la migrazione simultanea di tutti gli shard, raddoppiando il traffico e sovraccaricando gli altri nodi, rendendo praticamente impossibile la scrittura di dati nel cluster. In quel periodo siamo rimasti privi di log. E con il problema di server<\/a> perdevamo 1\/10 del cluster in generale. A complicare le cose contribuiva l'elevato numero di indici di piccole dimensioni.<\/p>\n

Senza i log, non comprendevamo le cause degli incidenti e avremmo potuto ripetere gli stessi errori in futuro, cosa inaccettabile per la nostra squadra, poich\u00e9 tutti i nostri processi sono progettati per evitare di ripetere gli stessi problemi. Per questo avevamo bisogno di un completo volume di log e di una loro consegna quasi in tempo reale, poich\u00e9 il team di ingegneri di guardia monitorava non solo gli avvisi dalle metriche, ma anche dai log. Per dare un\u2019idea dell\u2019entit\u00e0 del problema, all'epoca il volume totale dei log era di circa 2 TB al giorno.\u00a0<\/p>\n

Abbiamo fissato l'obiettivo di escludere completamente la perdita di log e di ridurre il tempo di consegna al cluster ELK a un massimo di 15 minuti in caso di imprevisti (su questo dato ci siamo basati in seguito come KPI interno).<\/p>\n

Nuovo meccanismo di rotazione e nodi hot-warm<\/h3>\n

\n\"Come
\n
\nAbbiamo iniziato la trasformazione del cluster aggiornando la versione di ElasticSearch da 5.5.2 a 6.4.3. Il nostro cluster della versione 5 si \u00e8 nuovamente bloccato, e abbiamo deciso di spegnerlo e aggiornare completamente \u2014 tanto i log non ci sono. Quindi, questo passaggio lo abbiamo completato in poche ore.<\/p>\n

La trasformazione pi\u00f9 significativa in questa fase \u00e8 stata l'implementazione di tre nodi con un coordinatore come buffer intermedio di Apache Kafka. Il broker dei messaggi ci ha liberato dalla perdita di log durante i problemi con ElasticSearch. Contemporaneamente, abbiamo aggiunto 2 nodi al cluster e siamo passati a un'architettura hot-warm con tre nodi \"caldi\", dislocati in diverse rack nel data center. Su di essi abbiamo reindirizzato i log che non potevano essere persi in nessun caso \u2014 nginx, e anche i log di errore delle applicazioni. Gli altri nodi ricevevano log minori \u2014 debug, warning, ecc., e dopo 24 ore venivano trasferiti i log \"importanti\" dai nodi \"caldi\".<\/p>\n

Per non aumentare il numero di indici di piccole dimensioni, siamo passati da una rotazione basata sul tempo a un meccanismo di rollover. Nei forum c'era molta informazione sul fatto che la rotazione in base alla dimensione dell'indice fosse molto inaffidabile, quindi abbiamo deciso di utilizzare la rotazione in base al numero di documenti nell'indice. Abbiamo analizzato ogni indice e registrato il numero di documenti dopo il quale doveva scattare la rotazione. In questo modo abbiamo raggiunto una dimensione ottimale del shard \u2014 non oltre 50 GB.\u00a0<\/p>\n

Ottimizzazione del cluster<\/h3>\n

\n\"Come
\n
\nTuttavia, non siamo riusciti a eliminare completamente i problemi. Sfortunatamente, continuavano a comparire piccoli indici: non raggiungevano il volume stabilito, non venivano ruotati e venivano eliminati da una pulizia globale degli indici pi\u00f9 vecchi di tre giorni, poich\u00e9 abbiamo rimosso la rotazione per data. Questo portava a perdite di dati perch\u00e9 l'indice scompariva completamente dal cluster e il tentativo di scrittura in un indice inesistente rompeva la logica del curator che usavamo per la gestione. L'alias per la scrittura veniva trasformato in un indice e rompeva la logica del rollover, causando una crescita incontrollata di alcuni indici fino a 600 GB.\u00a0<\/p>\n

Ad esempio, per la configurazione del rollover:<\/p>\n

curator-elk-rollover.yaml\n\n---\nactions:\n  1:\n    action: rollover\n    options:\n      name: \"nginx_write\"\n      conditions:\n        max_docs: 100000000\n  2:\n    action: rollover\n    options:\n      name: \"python_error_write\"\n      conditions:\n        max_docs: 10000000\n<\/code><\/pre>\n
In assenza di un alias di rollover si verificava un errore:<\/p>\n
ERROR     alias \"nginx_write\" not found.\nERROR     Failed to complete action: rollover.  : Unable to perform index rollover with alias \"nginx_write\".\n<\/code><\/pre>\n
Abbiamo rimandato la risoluzione di questo problema a un'iterazione successiva e ci siamo occupati di un altro aspetto: siamo passati alla logica pull di Logstash, che si occupa dell'elaborazione dei log in ingresso (rimozione delle informazioni superflue e arricchimento). L'abbiamo posizionato in un container Docker, avviato tramite docker-compose, e abbiamo collocato anche logstash-exporter, che invia le metriche a Prometheus per monitorare in tempo reale il flusso dei log. In questo modo abbiamo potuto modificare agevolmente il numero di istanze di Logstash responsabili dell'elaborazione di ciascun tipo di log.<\/p>\n
Mentre perfezionavamo il cluster, il traffico su cian.ru \u00e8 aumentato fino a 12,8 milioni di utenti unici al mese. Di conseguenza, le nostre trasformazioni non riuscivano a tenere il passo con i cambiamenti in produzione, e ci siamo trovati di fronte al problema delle nodi 'caldi' che non riuscivano a gestire il carico, rallentando l'intera consegna dei log. I dati 'caldi' venivano ricevuti senza interruzioni, ma per la consegna degli altri era necessario intervenire manualmente e effettuare un rollover per distribuire uniformemente gli indici.\u00a0<\/p>\n
Tuttavia, la scalabilit\u00e0 e la modifica delle impostazioni degli istanze di logstash nel cluster sono state complicate dal fatto che si trattava di un docker-compose locale, e tutte le operazioni venivano eseguite manualmente (per aggiungere nuovi endpoint, era necessario passare manualmente attraverso tutti i server e fare docker-compose up -d ovunque).<\/p>\n
Ridefinizione dei log<\/h3>\n
\nA settembre di quest'anno continuavamo a smantellare il monolite, il carico sul cluster aumentava, mentre il flusso di log si avvicinava a 30.000 messaggi al secondo.\u00a0<\/p>\n
\"Come
\n
\nLa prossima iterazione \u00e8 iniziata con l'aggiornamento dell'hardware. Da cinque coordinatori siamo passati a tre, abbiamo sostituito i nodi dei dati e abbiamo guadagnato sia in costi che in capacit\u00e0 di archiviazione. Per i nodi utilizziamo due configurazioni:\u00a0<\/p>\n