{"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 a CIAN domato terabyte di log","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 miei articoli passati ci \u00e8 stato chiesto di spiegare da dove prendiamo 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 separato che ci consente di risolvere i problemi rapidamente. In questo articolo parler\u00f2 di come nel corso di un anno l'abbiamo adattato per lavorare con 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 molto rapidamente, e nel terzo trimestre del 2018 la visitabilit\u00e0 della risorsa ha raggiunto 11,2 milioni di utenti unici al mese. In quegli anni, nei momenti critici, perdevamo fino al 40% dei log, il che ci impediva di affrontare rapidamente gli incidenti e ci faceva perdere molto tempo ed energie per risolverli. Inoltre, spesso non riuscivamo a trovare la causa del problema, che si ripresentava dopo qualche tempo. Era un vero incubo, e dovevamo fare qualcosa.<\/p>\n

A quel tempo, per memorizzare i log, usavamo un cluster di 10 data node con ElasticSearch versione 5.5.2 con configurazioni degli indici standard. \u00c8 stato implementato pi\u00f9 di un anno fa come una soluzione popolare e accessibile: all'epoca il flusso di log non era cos\u00ec grande, quindi non aveva senso creare configurazioni personalizzate.\u00a0<\/p>\n

Il trattamento dei log in ingresso era assicurato da Logstash su diverse porte su cinque coordinatori ElasticSearch. Un indice, indipendentemente dalle dimensioni, consisteva di cinque shard. Era organizzata una rotazione oraria e giornaliera, risultando in circa 100 nuovi shard ogni ora nel cluster. Finch\u00e9 i log non erano troppo numerosi, il cluster gestiva la situazione e nessuno si soffermava sulle sue impostazioni.\u00a0<\/p>\n

Problemi di crescita rapida<\/h3>\n

\nIl volume di log generati cresceva molto rapidamente, poich\u00e9 si sovrapponevano due processi. Da un lato, il numero di utenti del servizio aumentava. Dall'altro, abbiamo iniziato a passare attivamente a un'architettura a microservizi, suddividendo i nostri vecchi monoliti in C# e Python. Diverse 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 una situazione in cui il cluster \u00e8 diventato praticamente ingovernabile. Quando i log hanno iniziato ad arrivare a una velocit\u00e0 di 20.000 messaggi al secondo, una rotazione frequente e inutile ha aumentato il numero di shard a 6.000, con oltre 600 shard per nodo.\u00a0<\/p>\n

Questo ha portato a problemi di allocazione della memoria, e quando un nodo falliva, si verificava un trasferimento simultaneo di tutti gli shard, moltiplicando il traffico e sovraccaricando gli altri nodi, rendendo praticamente impossibile scrivere dati nel cluster. E in quel periodo siamo rimasti senza log. E quando si verificava un problema con server<\/a> perdevamo 1\/10 del cluster in linea di massima. Un gran numero di indici di piccole dimensioni complicava ulteriormente la situazione.<\/p>\n

Senza log non capivamo le cause dell'incidente e, prima o poi, avremmo potuto ricadere negli stessi errori, e nella nostra ideologia di squadra ci\u00f2 era inaccettabile, poich\u00e9 tutti i nostri meccanismi di lavoro sono progettati proprio per evitare di ripetere gli stessi problemi. Per questo avevamo bisogno di avere accesso a tutti i log e di riceverli quasi in tempo reale, poich\u00e9 il team di ingegneri di guardia monitorava gli allerta non solo dalle metriche, ma anche dai log. Per far comprendere l'entit\u00e0 del problema, a quel punto il volume totale dei log era di circa 2 TB al giorno.\u00a0<\/p>\n

Abbiamo stabilito l'obiettivo di eliminare completamente la perdita di log e ridurre il tempo di consegna nel cluster ELK a un massimo di 15 minuti in caso di emergenze (su questo valore ci siamo poi basati come KPI interno).<\/p>\n

Il 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 quinta versione \u00e8 crollato di nuovo e abbiamo deciso di spegnerlo e aggiornare completamente\u2014 tanto non ci sono log. Quindi, questo passaggio lo abbiamo effettuato in sole poche ore.<\/p>\n

La trasformazione pi\u00f9 significativa in questa fase \u00e8 stata l'implementazione di Apache Kafka su tre nodi con un coordinatore come buffer intermedio. 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\" posizionati in diverse rack nel data center. Su di essi abbiamo reindirizzato i log, che non possono essere persi in nessun caso \u2014 nginx, cos\u00ec come i log degli errori 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 per dimensione dell'indice \u00e8 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 deve scattare il rollover. In questo modo abbiamo raggiunto una dimensione ottimale per lo shard \u2014 non superiore a 50 GB.\u00a0<\/p>\n

Ottimizzazione del cluster<\/h3>\n

\n\"Come
\n
\nTuttavia, non ci siamo liberati completamente dei problemi. Sfortunatamente, comparivano comunque piccoli indici: non raggiungevano il volume stabilito, non venivano ruotati e venivano eliminati tramite una pulizia globale degli indici pi\u00f9 vecchi di tre giorni, poich\u00e9 avevamo rimosso la rotazione per data. Ci\u00f2 portava a una perdita di dati poich\u00e9 l'indice scompariva completamente dal cluster, e il tentativo di scrivere in un indice inesistente rompeva la logica del curator che usavamo per la gestione. L'alias per la scrittura si trasformava 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\u00a0\u00a01:\n\u00a0\u00a0\u00a0\u00a0action: rollover\n\u00a0\u00a0\u00a0\u00a0options:\n\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0name: \"nginx_write\"\n\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0conditions:\n\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0max_docs: 100000000\n\u00a0\u00a02:\n\u00a0\u00a0\u00a0\u00a0action: rollover\n\u00a0\u00a0\u00a0\u00a0options:\n\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0name: \"python_error_write\"\n\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0conditions:\n\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0max_docs: 10000000\n<\/code><\/pre>\n
In assenza di rollover, alias si \u00e8 verificato un errore:<\/p>\n
ERROR \u00a0 \u00a0 alias \"nginx_write\" not found.\nERROR \u00a0 \u00a0 Failed to complete action: rollover.\u00a0 : Unable to perform index rollover with alias \"nginx_write\".\n<\/code><\/pre>\n
Abbiamo rimandato la soluzione di questo problema alla prossima iterazione e ci siamo occupati di un'altra questione: siamo passati alla logica di lavoro pull di Logstash, che si occupa dell'elaborazione dei log in ingresso (rimuovendo informazioni superflue e arricchendo i dati). Lo abbiamo inserito in Docker, che gestiamo tramite docker-compose, e l\u00ec abbiamo collocato logstash-exporter, che invia metriche a Prometheus per il monitoraggio in tempo reale del flusso di log. In questo modo ci siamo dati la possibilit\u00e0 di modificare agevolmente il numero di istanze logstash responsabili dell'elaborazione di ciascun tipo di log.<\/p>\n
Mentre raffinavamo il cluster, il traffico su cian.ru \u00e8 aumentato fino a 12,8 milioni di utenti unici al mese. Di conseguenza, ci siamo trovati con il fatto che le nostre trasformazioni non riuscivano a tenere il passo con le modifiche in produzione, e ci siamo scontrati con il problema che le nodi \"calde\" non erano in grado di gestire il carico e rallentavano l'intera consegna dei log. I dati \"caldi\" li ricevevamo senza problemi, ma per la consegna degli altri dovevamo intervenire manualmente e fare un rollover, per distribuire uniformemente gli indici.\u00a0<\/p>\n
Nel contempo, la scalabilit\u00e0 e la modifica delle impostazioni delle istanze logstash nel cluster erano 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 su tutti i server e eseguire everywhere docker-compose up -d).<\/p>\n
Ridimensionamento dei log<\/h3>\n
\nA settembre di quest'anno continuavamo ancora a disgregare il monolite, il carico sul cluster aumentava, e il flusso di log si avvicinava a 30.000 messaggi al secondo.\u00a0<\/p>\n
\"Come
\n
\nAbbiamo iniziato la prossima iterazione con l'aggiornamento dell'hardware. Da cinque coordinatori siamo passati a tre, abbiamo sostituito le nodi dati e abbiamo ottenuto vantaggi sia in termini di costi che di spazio di archiviazione. Per le nodi utilizziamo due configurazioni:\u00a0<\/p>\n