I log sono una parte importante del sistema e ti consentono di capire se funziona (o non funziona) come previsto. In un'architettura a microservizi, lavorare con i log diventa una disciplina separata per un'Olimpiade speciale. È necessario risolvere una serie di domande in una volta:
- come scrivere i log da un'applicazione;
- dove scrivere i log;
- come fornire i log per l'archiviazione e l'elaborazione;
- come elaborare e archiviare i log.
L’uso delle tecnologie di containerizzazione attualmente più diffuse aggiunge sabbia sopra il rastrello al campo delle opzioni per risolvere il problema.
Questo è esattamente ciò di cui parla la trascrizione del rapporto di Yuri Bushmelev “Mappa dei rastrelli nel campo della raccolta e consegna dei tronchi”.
Chi se ne frega, per favore sotto il gatto.
Il mio nome è Yuri Bushmelev. Lavoro a Lazada. Oggi parlerò di come abbiamo realizzato i nostri log, di come li abbiamo raccolti e di cosa scriviamo lì.
Da dove veniamo? Chi siamo noi? Lazada è il rivenditore online numero 1 in sei paesi del sud-est asiatico. Tutti questi paesi sono distribuiti tra i nostri data center. Attualmente ci sono 4 data center in totale. Perché è importante? Perché alcune decisioni sono dovute al fatto che esiste un legame molto debole tra i centri. Abbiamo un'architettura a microservizi. Sono stato sorpreso di scoprire che disponiamo già di 80 microservizi. Quando ho iniziato l'attività con i log, ce n'erano solo 20. Inoltre c'è un pezzo piuttosto grande di eredità PHP, con cui devo convivere e sopportare. Tutto ciò genera attualmente più di 6 milioni di messaggi al minuto per l'intero sistema. Successivamente mostrerò come stiamo cercando di convivere con tutto ciò e perché è così.
Devi in qualche modo convivere con questi 6 milioni di messaggi. Cosa dovremmo fare con loro? 6 milioni di messaggi di cui hai bisogno:
- invia dall'app
- accettare per la consegna
- consegnare per analisi e archiviazione.
- analizzare
- conservarlo in qualche modo.
Quando sono apparsi tre milioni di messaggi, avevo più o meno lo stesso aspetto. Perché abbiamo iniziato con pochi centesimi. È chiaro che i registri dell'applicazione sono scritti lì. Ad esempio, non sono riuscito a connettermi al database, sono riuscito a connettermi al database ma non sono riuscito a leggere nulla. Ma oltre a questo, ciascuno dei nostri microservizi scrive anche un registro di accesso. Ogni richiesta che arriva al microservizio viene registrata nel log. Perché stiamo facendo questo? Gli sviluppatori vogliono essere in grado di tracciare. Ogni registro di accesso contiene un campo traceid, utilizzando il quale un'interfaccia speciale svolge poi l'intera catena e visualizza magnificamente la traccia. La traccia mostra come è andata la richiesta e questo aiuta i nostri sviluppatori a gestire rapidamente eventuali rifiuti non identificati.
Come convivere con questo? Ora descriverò brevemente il campo delle opzioni: come viene generalmente risolto questo problema. Come risolvere il problema della raccolta, trasmissione e archiviazione dei log.
Come scrivere da un'applicazione? È chiaro che ci sono diverse modalità. In particolare, esistono le migliori pratiche, come ci dicono i nostri compagni alla moda. Esistono due tipi di vecchia scuola, come ci hanno raccontato i nostri nonni. Ci sono altri modi.
La situazione con la raccolta dei registri è più o meno la stessa. Non ci sono molte opzioni per risolvere questa parte particolare. Ce ne sono già di più, ma ancora non così tanti.
Ma con la consegna e la successiva analisi, il numero delle variazioni comincia ad esplodere. Non descriverò ora ciascuna opzione. Penso che le opzioni principali siano ben note a tutti coloro che sono interessati all'argomento.
Ti mostrerò come abbiamo fatto a Lazada e come tutto è iniziato effettivamente.
Un anno fa sono arrivato a Lazada e sono stato inviato a un progetto sui tronchi. Era qualcosa del genere. Il registro dell'applicazione è stato scritto su stdout e stderr. Tutto è stato fatto in modo alla moda. Ma poi gli sviluppatori lo hanno eliminato dai flussi standard e in qualche modo gli specialisti delle infrastrutture lo capiranno. Tra gli specialisti delle infrastrutture e gli sviluppatori, ci sono anche dei releaser che hanno detto: “ehm... okay, incartiamoli in un file con una shell e basta”. E poiché tutto questo era in un contenitore, lo hanno avvolto proprio nel contenitore stesso, hanno mappato il catalogo all'interno e lo hanno messo lì. Penso che sia abbastanza ovvio per tutti cosa ne è venuto fuori.
Per ora guardiamo un po' oltre. Come abbiamo consegnato questi log? Qualcuno ha scelto td-agent, che in realtà è fluente, ma non del tutto fluente. Ancora non capisco la relazione tra questi due progetti, ma sembrano riguardare più o meno la stessa cosa. E questo fluente, scritto in Ruby, leggeva i file di registro, li analizzava in JSON usando una sorta di regolarità. Poi li ho inviati a Kafka. Inoltre, in Kafka avevamo 4 argomenti separati per ciascuna API. Perché 4? Perché c'è il live, c'è la messa in scena e perché ci sono stdout e stderr. Gli sviluppatori li creano e gli sviluppatori di infrastrutture devono crearli in Kafka. Inoltre Kafka era controllato da un altro dipartimento. Pertanto è stato necessario creare un ticket in modo che venissero creati 4 topic per ogni api. Tutti se ne sono dimenticati. In generale, c'era spazzatura e confusione.
Cosa ne abbiamo fatto dopo? L'abbiamo inviato a Kafka. Quindi metà dei tronchi di Kafka sono volati a Logstash. L'altra metà dei tronchi è stata divisa. Alcuni volarono su un Graylog, altri su un altro Graylog. Di conseguenza, tutto questo è andato in un unico cluster Elasticsearch. Cioè, tutto questo casino è finito lì. Non farlo!
Ecco come appare se lo guardi dall'alto. Non farlo! Qui le aree problematiche vengono immediatamente contrassegnate con numeri. In realtà ce ne sono di più, ma 6 sono quelli davvero problematici per i quali è necessario fare qualcosa. Te ne parlerò separatamente ora.
Qui (1,2,3) scriviamo file e, di conseguenza, qui ci sono tre rastrelli contemporaneamente.
Il primo (1) è che dobbiamo scriverli da qualche parte. Non sarebbe sempre auspicabile dare all'API la possibilità di scrivere direttamente su un file. È auspicabile che l'API sia isolata in un contenitore o, meglio ancora, che sia di sola lettura. Sono un amministratore di sistema, quindi ho una visione leggermente alternativa di queste cose.
Il secondo punto (2,3) è che abbiamo molte richieste in arrivo all'API. L'API scrive molti dati in un file. I file stanno crescendo. Dobbiamo ruotarli. Perché altrimenti non potrai fare scorta di dischi lì. Ruotarli è negativo perché vengono effettuati reindirizzando attraverso la shell alla directory. Non c'è modo di rivederlo. Non puoi dire all'applicazione di riaprire gli handle. Perché gli sviluppatori ti guarderanno come se fossi uno stupido: “Quali descrittori? Generalmente scriviamo a stdout. Gli sviluppatori dell'infrastruttura hanno creato copytruncate in logrotate, che crea semplicemente una copia del file e trascrive l'originale. Di conseguenza, tra questi processi di copia solitamente si esaurisce lo spazio su disco.
(4) Avevamo formati diversi in API diverse. Erano leggermente diversi, ma l'espressione regolare doveva essere scritta diversamente. Dato che tutto questo era controllato da Puppet, c'erano un gran numero di classi con i propri scarafaggi. Inoltre, la maggior parte delle volte td-agent potrebbe divorare la memoria, essere stupido, potrebbe semplicemente fingere che funzioni e non fare nulla. Dall'esterno era impossibile capire che non stesse facendo nulla. Nella migliore delle ipotesi, cadrà e qualcuno lo raccoglierà più tardi. Più precisamente, arriverà un avviso e qualcuno andrà ad alzarlo con le mani.
(6) E la maggior parte dei rifiuti e dei rifiuti era elasticsearch. Perché era una vecchia versione. Perché a quel tempo non avevamo maestri dedicati. Avevamo log eterogenei i cui campi potevano sovrapporsi. Registri diversi di applicazioni diverse potrebbero essere scritti con gli stessi nomi di campo, ma al loro interno potrebbero essere presenti dati diversi. Cioè, un log viene fornito con Integer nel campo, ad esempio level. Un altro registro viene fornito con String nel campo del livello. In assenza di mappatura statica, questa è una cosa meravigliosa. Se, dopo aver ruotato l'indice in elasticsearch, arriva prima un messaggio con una stringa, allora viviamo normalmente. Ma se il primo è arrivato da Integer, tutti i messaggi successivi arrivati da String vengono semplicemente scartati. Perché il tipo di campo non corrisponde.
Abbiamo iniziato a porci queste domande. Abbiamo deciso di non cercare i colpevoli.
Ma bisogna fare qualcosa! La cosa ovvia è che dobbiamo stabilire degli standard. Avevamo già alcuni standard. Alcuni li abbiamo iniziati un po' più tardi. Fortunatamente già allora era stato approvato un unico formato di log per tutte le API. È scritto direttamente negli standard per l'interazione tra i servizi. Pertanto chi desidera ricevere i log dovrà scriverli in questo formato. Se qualcuno non scrive i log in questo formato, non garantiamo nulla.
Successivamente, vorrei creare uno standard unificato per i metodi di registrazione, consegna e raccolta dei log. In realtà, dove scriverli e come consegnarli. La situazione ideale è quando i progetti utilizzano la stessa libreria. Esiste una libreria di registrazione separata per Go e una libreria separata per PHP. Tutti quelli che abbiamo dovrebbero usarli. Al momento direi che abbiamo un successo pari all’80%. Ma alcune persone continuano a mangiare cactus.
E lì (sulla diapositiva) inizia a malapena ad apparire lo "SLA per la consegna dei registri". Non esiste ancora, ma ci stiamo lavorando. Perché è molto conveniente quando l'infrastruttura dice che se scrivi in questo e quell'altro formato in questo e quell'altro posto e non più di N messaggi al secondo, molto probabilmente lo consegneremo in questo e quell'altro posto. Questo allevia molti mal di testa. Se esiste uno SLA, allora è assolutamente meraviglioso!
Come abbiamo iniziato a risolvere il problema? Il problema principale era con td-agent. Non era chiaro dove fossero finiti i nostri registri. Vengono consegnati? Stanno andando? Dove sono comunque? Pertanto, si è deciso di sostituire il primo punto con td-agent. Ho brevemente delineato le opzioni con cosa sostituirlo qui.
Fluente. In primo luogo, l'ho incontrato in un lavoro precedente e anche lui periodicamente cadeva lì. In secondo luogo, questa è la stessa cosa, solo di profilo.
Filebeat. Quanto è stato conveniente per noi? Perché è in Go e abbiamo molta esperienza in Go. Di conseguenza, se accadesse qualcosa, potremmo in qualche modo aggiungerlo noi stessi. Ecco perché non l'abbiamo preso. In modo che non ci sia nemmeno la tentazione di iniziare a riscriverlo da solo.
La soluzione ovvia per l'amministratore di sistema sono tutti i tipi di syslog in questa quantità (syslog-ng/rsyslog/nxlog).
Oppure scrivi qualcosa di tuo, ma lo abbiamo scartato, così come filebeat. Se scrivi qualcosa, è meglio scrivere qualcosa di utile per il business. Per consegnare i registri, è meglio prendere qualcosa di già pronto.
Pertanto, la scelta in realtà è ricaduta sulla scelta tra syslog-ng e rsyslog. Mi sono orientato verso rsyslog semplicemente perché avevamo già classi per rsyslog in Puppet e non ho trovato un'ovvia differenza tra loro. Cos'è syslog, cos'è syslog. Sì, alcuni hanno una documentazione peggiore, altri una migliore. Questo può farlo in questo modo e l'altro può farlo in modo diverso.
E qualcosa su rsyslog. Prima di tutto, è bello perché ha molti moduli. Ha RainerScript leggibile dall'uomo (un linguaggio di configurazione moderno). È un fantastico vantaggio poter emulare il comportamento di td-agent utilizzando strumenti standard e nulla è cambiato per le applicazioni. Cioè, cambiamo td-agent in rsyslog e per ora lasciamo stare tutto il resto. E riceviamo immediatamente una consegna funzionante. Successivamente, mmnormalize è una cosa fantastica in rsyslog. Ti consente di analizzare i log, ma non di utilizzare Grok e regexp. Crea un albero di sintassi astratto. Analizza i log più o meno allo stesso modo in cui un compilatore analizza i sorgenti. Ciò ti consente di lavorare molto velocemente, consumare poca CPU e, in generale, è davvero una cosa interessante. Ci sono un sacco di altri bonus. Non mi soffermerò su di loro.
rsyslog presenta molti altri svantaggi. Sono più o meno gli stessi dei bonus. I problemi principali sono che devi sapere come cucinarlo e devi selezionare la versione.
Abbiamo deciso di scrivere i log su un socket Unix. E non in /dev/log, perché lì abbiamo un pasticcio di log di sistema, journald è in questa pipeline. Quindi scriviamo su un socket personalizzato. Lo allegheremo a un set di regole separato. Non interferiamo con nulla. Tutto sarà trasparente e comprensibile. Questo è esattamente quello che abbiamo fatto. La directory con questi socket viene standardizzata e inoltrata a tutti i container. I contenitori possono vedere il socket di cui hanno bisogno, aprirlo e scrivervi.
Perché non un file? Perché lo leggono tutti , che ha tentato di inoltrare un file alla finestra mobile e si è scoperto che dopo aver riavviato rsyslog, il descrittore di file è cambiato e la finestra mobile ha perso questo file. Mantiene aperto qualcos'altro, ma non la presa su cui stanno scrivendo. Abbiamo deciso che avremmo risolto questo problema e, allo stesso tempo, avremmo risolto il problema del blocco.
Rsyslog esegue le azioni indicate nella diapositiva e invia i log al relè o a Kafka. Kafka segue la vecchia maniera. Relay: ho provato a utilizzare rsyslog puro per fornire i log. Senza Message Queue, utilizzando gli strumenti rsyslog standard. Fondamentalmente funziona.
Ma ci sono delle sfumature su come inserirli in questa parte (Logstash/Graylog/ES). Questa parte (rsyslog-rsyslog) viene utilizzata tra i data center. Ecco un collegamento TCP compresso, che ci consente di risparmiare larghezza di banda e, di conseguenza, aumentare in qualche modo la probabilità di ricevere alcuni registri da un altro data center quando il canale è intasato. Perché abbiamo l’Indonesia, dove tutto va male. È qui che risiede il problema costante.
Abbiamo pensato a come possiamo effettivamente monitorare quanto è probabile che i log che abbiamo registrato dall'applicazione raggiungano la fine? Abbiamo deciso di creare metriche. rsyslog ha il proprio modulo di raccolta statistiche, che contiene alcuni tipi di contatori. Ad esempio, può mostrarti la dimensione della coda o quanti messaggi sono arrivati in una determinata azione. Puoi già prendere qualcosa da loro. Inoltre, dispone di contatori personalizzati che possono essere configurati e ti mostrerà, ad esempio, il numero di messaggi registrati da alcune API. Successivamente, ho scritto rsyslog_exporter in Python e abbiamo inviato tutto a Prometheus e creato grafici. Volevamo davvero le metriche Graylog, ma non abbiamo ancora avuto il tempo di impostarle.
Quali erano i problemi? I problemi sono sorti quando abbiamo scoperto (IMPROVVISAMENTE!) che le nostre API Live scrivevano 50 messaggi al secondo. Questa è solo un'API live senza gestione temporanea. E Graylog ci mostra solo 12mila messaggi al secondo. E è sorta una domanda ragionevole: dove sono i resti? Da cui abbiamo concluso che Graylog semplicemente non può farcela. Abbiamo esaminato e, in effetti, Graylog ed Elasticsearch non sono riusciti a gestire questo flusso.
Successivamente, altre scoperte che abbiamo fatto lungo il percorso.
Le scritture sul socket sono bloccate. Come è successo? Mentre utilizzavo rsyslog per la consegna, a un certo punto il canale tra i data center si è interrotto. La consegna si è fermata in un posto, la consegna si è fermata in un altro posto. Tutto questo ha raggiunto la macchina con API che scrivono sul socket rsyslog. C'era una coda lì. Quindi la coda per la scrittura sul socket UNIX, che per impostazione predefinita è di 128 pacchetti, si è riempita. E il successivo write() nell'applicazione è bloccato. Quando abbiamo esaminato la libreria che utilizziamo nelle applicazioni Go, è stato scritto lì che la scrittura sul socket avviene in modalità non bloccante. Eravamo sicuri che nulla fosse bloccato. Perché leggiamo chi ne ha scritto. Ma c'è un momento. C'era anche un ciclo infinito attorno a questa chiamata, in cui c'era un tentativo costante di inserire un messaggio nel socket. Non l'abbiamo notato. Ho dovuto riscrivere la libreria. Da allora è cambiato più volte, ma ora abbiamo eliminato i blocchi in tutti i sottosistemi. Pertanto, puoi interrompere rsyslog e nulla si bloccherà.
È necessario monitorare la dimensione delle code, il che aiuta a evitare di calpestare questo rastrello. Innanzitutto, possiamo monitorare quando iniziamo a perdere messaggi. In secondo luogo, possiamo monitorare se abbiamo problemi con la consegna.
E un altro momento spiacevole: l'amplificazione di 10 volte in un'architettura a microservizi è molto semplice. Non abbiamo molte richieste in arrivo, ma a causa del grafico lungo il quale questi messaggi viaggiano più lontano, a causa dei log di accesso, aumentiamo effettivamente il carico dei log di circa dieci volte. Sfortunatamente non ho avuto il tempo di calcolare i numeri esatti, ma i microservizi sono quello che sono. Questo deve essere tenuto presente. Si scopre che al momento il sottosistema di raccolta dei registri è il più caricato in Lazada.
Come risolvere il problema dell'elasticsearch? Se è necessario ottenere rapidamente i registri in un unico posto, in modo da non correre su tutte le macchine e raccoglierli lì, utilizzare l'archiviazione dei file. Il funzionamento è garantito. Può essere fatto da qualsiasi server. Devi solo attaccare i dischi lì e installare syslog. Successivamente, avrai la garanzia di avere tutti i registri in un unico posto. Quindi puoi configurare lentamente elasticsearch, greylog e qualcos'altro. Ma avrai già tutti i registri e, inoltre, potrai archiviarli finché ci sono abbastanza array di dischi.
Al momento del mio rapporto, lo schema cominciò ad assomigliare a questo. Abbiamo praticamente smesso di scrivere sul file. Ora, molto probabilmente, spegneremo il resto. Sui computer locali che eseguono l'API, interromperemo la scrittura sui file. Innanzitutto c'è l'archiviazione dei file, che funziona molto bene. In secondo luogo, queste macchine sono costantemente a corto di spazio e devono essere costantemente monitorate.
Questa parte con Logstash e Graylog decolla davvero. Pertanto, dobbiamo sbarazzarcene. Devi scegliere una cosa.
Abbiamo deciso di eliminare Logstash e Kibana. Perché abbiamo un dipartimento di sicurezza. Quale connessione? Il collegamento è che Kibana senza X-Pack e senza Shield non consente di differenziare i diritti di accesso ai log. Ecco perché abbiamo preso Graylog. Ha tutto. Non mi piace, ma funziona. Abbiamo acquistato nuovo hardware, installato un nuovo Graylog e trasferito tutti i registri con formati rigorosi su un Graylog separato. Abbiamo risolto il problema a livello organizzativo con diversi tipi di campi identici.
Cosa è incluso esattamente nel nuovo Graylog. Abbiamo appena scritto tutto nella finestra mobile. Abbiamo preso un sacco di server, implementato tre istanze Kafka, 7 server Graylog versione 2.3 (perché volevamo Elasticsearch versione 5). Tutto questo è stato rilevato durante i raid dall'HDD. Abbiamo riscontrato una velocità di indicizzazione fino a 100mila messaggi al secondo. Abbiamo visto la cifra di 140 terabyte di dati a settimana.
E ancora il rastrello! Abbiamo due vendite in arrivo. Abbiamo superato i 6 milioni di messaggi. Graylog non ha tempo per masticare. In qualche modo dobbiamo sopravvivere di nuovo.
È così che siamo sopravvissuti. Abbiamo aggiunto alcuni altri server e SSD. Al momento viviamo in questo modo. Ormai stiamo già masticando 160mila messaggi al secondo. Non abbiamo ancora raggiunto il limite, quindi non è chiaro quanto potremo effettivamente ricavarne.
Questi sono i nostri piani per il futuro. Di questi, il più importante è probabilmente l’elevata disponibilità. Non ce l'abbiamo ancora. Diverse auto sono configurate allo stesso modo, ma finora tutto passa attraverso un'unica macchina. Ci vuole tempo per impostare il failover tra di loro.
Raccogli i parametri da Graylog.
Stabilisci un limite di velocità in modo da avere un'API pazzesca che non uccida la nostra larghezza di banda e tutto il resto.
E infine, firma una sorta di SLA con gli sviluppatori in modo che possiamo servire così tanto. Se scrivi di più, allora mi dispiace.
E scrivi la documentazione.
In breve, il risultato di tutto ciò che abbiamo vissuto. Innanzitutto, gli standard. In secondo luogo, syslog è una torta. In terzo luogo, rsyslog funziona esattamente come è scritto sulla diapositiva. E passiamo alle domande.
domande.
domanda: Perché hai deciso di non prendere... (filebeat?)
risposta: Dobbiamo scrivere su un file. Non volevo davvero. Quando la tua API scrive migliaia di messaggi al secondo, anche se la ruoti una volta all'ora, questa non è ancora un'opzione. Puoi scrivere in pipe. Al che gli sviluppatori mi hanno chiesto: "Cosa succederà se il processo su cui stiamo scrivendo si blocca?" Semplicemente non ho trovato cosa rispondere e ho detto: "Bene, ok, non facciamolo".
domanda: Perché non scrivi semplicemente i log su HDFS?
risposta: Questa è la fase successiva. Ci abbiamo pensato fin dall'inizio, ma poiché al momento non ci sono risorse per farlo, la nostra soluzione a lungo termine è bloccata.
domanda: il formato colonna sarebbe più adatto.
risposta: Capisco. Siamo a favore con entrambe le mani.
domanda: Stai scrivendo su rsyslog. Lì puoi usare sia TCP che UDP. Ma se UDP, come garantisci la consegna?
risposta: Ci sono due punti. Innanzitutto dico subito a tutti che non garantiamo la consegna dei log. Perché quando gli sviluppatori vengono e dicono: "Cominciamo a scrivere i dati finanziari lì, e tu li metterai da qualche parte per noi nel caso succeda qualcosa", noi rispondiamo loro: "Fantastico! Cominciamo a bloccare la scrittura sul socket, e facciamolo nelle transazioni, in modo che tu abbia la garanzia di inserirlo nel socket per noi e assicurarci che lo riceviamo dall'altra parte." E in questo momento tutti immediatamente non ne hanno più bisogno. Se non è necessario, quali domande dovremmo porre? Se non vuoi garantire la scrittura su un socket, allora perché dobbiamo garantire la consegna? Stiamo facendo del nostro meglio. Cerchiamo davvero di fornire il più possibile e nel miglior modo possibile, ma non diamo una garanzia al 100%. Pertanto, non è necessario scrivere lì i dati finanziari. Esistono database con transazioni per questo.
domanda: quando l'API genera alcuni messaggi nel registro e trasferisce il controllo ai microservizi, hai riscontrato il problema che i messaggi provenienti da diversi microservizi arrivano nell'ordine sbagliato? Ciò causa confusione.
risposta: È normale che arrivino in ordini diversi. Devi essere preparato per questo. Perché qualsiasi consegna in rete non garantisce l'ordine, oppure è necessario spendere risorse speciali per questo. Se prendiamo archivi di file, ciascuna API salva i log nel proprio file. O meglio, rsyslog li ordina in directory. Ogni API ha i propri log, dove puoi andare a cercare, e poi puoi confrontarli utilizzando il timestamp in questo log. Se vanno a cercare in Graylog, vengono ordinati lì per timestamp. Andrà tutto bene lì.
domanda: Il timestamp può variare in millisecondi.
risposta: Il timestamp viene generato dall'API stessa. Questo è, in effetti, il punto. Abbiamo NTP. L'API genera un timestamp nel messaggio stesso. rsyslog non lo aggiunge.
domanda: L'interazione tra i data center non è molto chiara. All'interno del data center è chiaro come sono stati raccolti ed elaborati i registri. Come avviene l'interazione tra data center? Oppure ogni data center vive una vita propria?
risposta: Quasi. Nel nostro paese, ogni paese si trova in un data center. Al momento non disponiamo di una ripartizione tale per cui un paese si trova in diversi data center. Pertanto non è necessario combinarli. Ogni centro ha al suo interno un Log Relay. Questo è un server Rsyslog. In realtà due macchine gestionali. Hanno lo stesso atteggiamento. Ma per ora il traffico passa solo attraverso uno di essi. Aggrega tutti i log. Ha una coda su disco per ogni evenienza. Scarica i log e li invia al data center centrale (Singapore), dove vengono poi inviati a Graylog. E ogni data center ha il proprio spazio di archiviazione dei file. Nel caso in cui la nostra connessione venga persa, abbiamo tutti i log lì. Rimarranno lì. Verranno archiviati lì.
domanda: In caso di situazioni anomale, ricevete i log da lì?
risposta: Puoi andare lì (all'archivio file) e guardare.
domanda: Come controlli che non si perdano i registri?
risposta: In realtà li stiamo perdendo e lo stiamo monitorando. Il monitoraggio è stato avviato un mese fa. La libreria utilizzata dalle API Go dispone di metriche. Può contare quante volte non è riuscita a scrivere su un socket. Attualmente esiste un'euristica intelligente in questo caso. C'è un buffer lì. Tenta di scrivere un messaggio da esso al socket. Se il buffer trabocca, inizia a rilasciarli. E conta quanti ne ha lasciati cadere. Se lì i contatori cominciano a traboccare, lo sapremo. Ora stanno arrivando anche su Prometeo e potete vedere i grafici in Grafana. Puoi impostare avvisi. Ma non è ancora chiaro a chi inviarli.
domanda: In elasticsearch memorizzi i log con ridondanza. Quante repliche hai?
risposta: Una linea.
domanda: Questa è solo una riga?
risposta: Questo è il master e la replica. I dati vengono memorizzati in due copie.
domanda: Hai modificato in qualche modo la dimensione del buffer rsyslog?
risposta: Scriviamo datagrammi su un socket unix personalizzato. Questo ci impone immediatamente un limite di 128 kilobyte. Non possiamo scriverne altro. Lo abbiamo scritto nello standard. Coloro che vogliono entrare nello spazio di archiviazione scrivono 128 kilobyte. Le biblioteche, inoltre, vengono tagliate e viene posta una bandiera che il messaggio è tagliato. Il nostro standard per il messaggio stesso prevede un campo speciale che mostra se è stato tagliato o meno durante la registrazione. Quindi abbiamo l’opportunità di seguire anche questo momento.
Domanda: Scrivi JSON non funzionante?
risposta: JSON danneggiato verrà scartato durante l'inoltro perché il pacchetto è troppo grande. Oppure Graylog verrà scartato perché non è in grado di analizzare JSON. Ma ci sono delle sfumature che devono essere risolte e sono per lo più legate a rsyslog. Ho già compilato diverse questioni lì, su cui c'è ancora bisogno di lavorare.
Domanda: Perché Kafka? Hai provato RabbitMQ? Graylog fallisce sotto tali carichi?
risposta: Per noi non funziona con Graylog. E Graylog per noi sta prendendo forma. È davvero problematico. E' una cosa particolare. E, in effetti, non ce n'è bisogno. Preferirei scrivere da rsyslog direttamente su elasticsearch e poi guardare Kibana. Ma dobbiamo risolvere la questione con le guardie di sicurezza. Questa è una possibile opzione per il nostro sviluppo, quando elimineremo Graylog e utilizzeremo Kibana. Non ha senso usare Logstash. Perché posso fare la stessa cosa con rsyslog. E ha un modulo per scrivere su elasticsearch. Stiamo cercando di convivere in qualche modo con Graylog. L'abbiamo anche messo a punto un po'. Ma c’è ancora spazio per miglioramenti.
A proposito di Kafka. Così è avvenuto storicamente. Quando sono arrivato, era già lì e vi venivano già scritti i registri. Abbiamo semplicemente generato il nostro cluster e spostato i log al suo interno. Noi siamo il suo management, sappiamo come si sente. Per quanto riguarda RabbitMQ... per noi non funziona con RabbitMQ. E RabbitMQ sta prendendo forma per noi. Lo abbiamo in produzione e ci sono stati problemi con esso. Ora, prima della vendita, lo avrebbero affascinato e avrebbe ripreso a lavorare normalmente. Ma prima non ero pronto per metterlo in produzione. C'è un altro punto. Graylog può leggere la versione AMQP 0.9 e rsyslog può scrivere la versione AMQP 1.0. E non esiste un’unica soluzione intermedia che possa fare entrambe le cose. O l'uno o l'altro. Quindi per ora solo Kafka. Ma ha anche le sue sfumature. Perché l'omkafka della versione di rsyslog che utilizziamo può perdere l'intero buffer dei messaggi che ha prelevato da rsyslog. Per ora sopportiamo.
Domanda: Stai usando Kafka perché lo avevi già? Non più utilizzato per nessuno scopo?
risposta: Kafka, che era, è utilizzato dal team di Data Science. Questo è un progetto completamente separato, sul quale purtroppo non posso dire nulla. Non lo so. È stato gestito dal team di Data Science. Quando sono stati creati i log, abbiamo deciso di utilizzarlo per non installarne uno nostro. Ora abbiamo aggiornato Graylog e abbiamo perso la compatibilità perché ha una vecchia versione di Kafka. Abbiamo dovuto iniziare da soli. Allo stesso tempo, abbiamo eliminato questi quattro argomenti per ciascuna API. Abbiamo creato un argomento ampio per tutti i live, un argomento ampio e ampio per tutti gli allestimenti e abbiamo messo tutto lì. Graylog elimina tutto questo in parallelo.
Domanda: Perché abbiamo bisogno di questo sciamanesimo con le prese? Hai provato a utilizzare il driver di registro syslog per i contenitori?
risposta: Nel momento in cui abbiamo posto questa domanda, il nostro rapporto con il portuale era teso. Era Docker 1.0 o 0.9. Lo stesso Docker era strano. In secondo luogo, se ci inserisci anche i log... ho il sospetto non verificato che passi tutti i log attraverso se stesso, attraverso il demone docker. Se un'API impazzisce, le altre API rimangono bloccate nel fatto che non possono inviare stdout e stderr. Non so dove questo porterà. Ho il sospetto a livello di sensazione che non sia necessario utilizzare il driver syslog Docker in questo posto. Il nostro reparto di test funzionali dispone di un proprio cluster Graylog con log. Usano i driver di registro Docker e sembra che tutto vada bene lì. Ma scrivono immediatamente GELF a Graylog. Nel momento in cui abbiamo iniziato tutto questo, avevamo solo bisogno che funzionasse. Forse più tardi, quando qualcuno verrà e dirà che funziona bene da cento anni, ci proveremo.
Domanda: esegui la consegna tra data center utilizzando rsyslog. Perché non Kafka?
risposta: In realtà facciamo entrambe le cose. Per due ragioni. Se il canale è completamente morto, tutti i nostri log, anche in forma compressa, non lo attraverseranno. E Kafka ti permette semplicemente di perderli nel processo. In questo modo eliminiamo questi registri che rimangono bloccati. In questo caso stiamo usando direttamente Kafka. Se abbiamo un buon canale e vogliamo liberarlo, allora usiamo il loro rsyslog. Ma in realtà, puoi configurarlo in modo che esso stesso lasci cadere ciò che non è passato. Al momento utilizziamo semplicemente la consegna rsyslog direttamente da qualche parte e Kafka da qualche parte.
Fonte: habr.com