IT knowledge base
CTRL+F per cercare la tua parola chiave

Yuri Bushmelev "Mappa del rastrello sul campo di raccolta e consegna dei tronchi" - trascrizione del rapporto

I log sono una parte importante del sistema, consentendoti di capire se funziona (o non funziona) come previsto. In un'architettura di microservizi, lavorare con i log diventa una disciplina separata di un'Olimpiade speciale. Devi risolvere un sacco di domande in una volta:

  • come scrivere i log dall'applicazione;
  • dove scrivere i log;
  • come consegnare i log per l'archiviazione e l'elaborazione;
  • come elaborare e memorizzare i log.

L'uso delle tecnologie di containerizzazione attualmente popolari aggiunge sabbia al rastrello al campo delle opzioni per risolvere il problema.

Questo è esattamente ciò che la trascrizione del rapporto di Yuri Bushmelev "Mappa dei rastrelli sul campo di raccolta e consegna dei tronchi"

Chi se ne frega, per favore, sotto il gatto.

Mi chiamo Yuri Bushmelev. Lavoro per Lazada. Oggi parlerò di come abbiamo realizzato i nostri log, come li abbiamo raccolti e cosa scriviamo lì.

Da dove veniamo? Chi siamo noi? Lazada è il negozio online n. 1 in sei paesi del sud-est asiatico. Tutti questi paesi sono distribuiti su data center. Ora ci sono 4 data center in totale, perché è importante? Perché alcune decisioni sono dovute al fatto che c'è un legame molto debole tra i centri. Abbiamo un'architettura di microservizi. Sono stato sorpreso di scoprire che abbiamo già 80 microservizi. Quando ho iniziato l'attività con i registri, ce n'erano solo 20. Inoltre c'è una parte abbastanza grande dell'eredità PHP con cui devi anche convivere e sopportare. Tutto ciò genera per noi al momento più di 6 milioni di messaggi al minuto nel sistema nel suo insieme. Inoltre mostrerò come stiamo cercando di conviverci e perché è così.

Con questi 6 milioni di messaggi devi in ​​qualche modo vivere. Cosa dovremmo fare con loro? 6 milioni di messaggi di cui hai bisogno:

  • invia da app
  • accettare per la consegna
  • consegnare per l'analisi e l'archiviazione.
  • analizzare
  • in qualche modo conservare.

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 è stato possibile connettersi al database, è stato possibile connettersi al database, ma non è stato possibile leggere qualcosa. Ma oltre a questo, ognuno dei nostri microservizi scrive anche un log di accesso. Ogni richiesta che arriva al microservizio va al log. Perché stiamo facendo questo? Gli sviluppatori vogliono essere in grado di tracciare. Ogni log di accesso contiene un campo traceid, in base al quale un'interfaccia speciale svolge ulteriormente l'intera catena e mostra magnificamente la traccia. Trace mostra come è andata la richiesta e aiuta i nostri sviluppatori a gestire rapidamente qualsiasi stronzata non identificata.

Come conviverci? Ora descriverò brevemente il campo delle opzioni: come viene generalmente risolto questo problema. Come risolvere il problema della raccolta, del trasferimento e dell'archiviazione dei log.

Come scrivere dall'applicazione? È chiaro che ci sono modi diversi. In particolare c'è la best practice, come ci raccontano le nostre compagne di moda. C'è una vecchia scuola in due forme, come dicevano i nonni. Ci sono altri modi.

La situazione è più o meno la stessa con la raccolta dei log. Non ci sono molte opzioni per risolvere questa parte particolare. Ce ne sono già di più, ma non così tanti.

Ma con la consegna e la successiva analisi, il numero di varianti inizia a esplodere. Non descriverò ogni opzione ora. Penso che le opzioni principali siano ascoltate da tutti coloro che erano interessati all'argomento.

Ti mostrerò come l'abbiamo fatto a Lazada e come è iniziato tutto.

Un anno fa sono venuto a Lazada e mi hanno mandato a un progetto sui tronchi. Lì c'era qualcosa del genere. Il log dell'applicazione è stato scritto su stdout e stderr. Tutto è stato fatto in modo alla moda. Ma poi gli sviluppatori l'hanno buttato fuori dai flussi standard e poi gli specialisti dell'infrastruttura lo capiranno in qualche modo. Ci sono anche releasers tra specialisti di infrastrutture e sviluppatori che hanno detto: "uh... beh, avvolgiamoli in un file con una shell, e basta". E poiché tutto questo è nel contenitore, l'abbiamo avvolto proprio nel contenitore stesso, mappato la directory all'interno e l'abbiamo messo lì. Penso che sia più o meno ovvio per tutti cosa ne è venuto fuori.

Vediamo un po' più avanti per ora. Come abbiamo consegnato questi log. Qualcuno ha scelto td-agent, che in realtà è fluente ma non del tutto fluente. Continuo a non capire la relazione tra questi due progetti, ma sembrano essere più o meno la stessa cosa. E questo fluente, scritto in Ruby, leggeva i file di registro, li analizzava in JSON secondo un programma regolare. Poi li ho mandati a Kafka. Inoltre, in Kafka, avevamo 4 argomenti separati per ogni API. Perché 4? Perché c'è il live, c'è la messa in scena, e perché c'è lo stdout e lo stderr. Gli sviluppatori li allevano e gli ingegneri dell'infrastruttura devono crearli in Kafka. Inoltre, Kafka era controllato da un altro dipartimento. Pertanto, era necessario creare un ticket in modo che creassero 4 argomenti lì per ogni API. Tutti se ne sono dimenticati. In generale, c'erano spazzatura e rifiuti.

Cosa abbiamo fatto dopo con questo? Abbiamo inviato questo a Kafka. Quindi metà dei tronchi è volata dal kafka a Logstash. L'altra metà dei registri è stata condivisa. Alcuni sono volati su un Graylog, altri su un altro Graylog. Di conseguenza, tutto questo è volato in un cluster Elasticsearch. Cioè, tutto questo casino è finito lì. Non farlo!

Ecco come appare visto dall'alto. Non farlo! Qui le aree problematiche sono immediatamente contrassegnate da numeri. In realtà ce ne sono di più, ma 6 - questi sono davvero molto problematici, con i quali devi fare qualcosa. Ve ne parlerò separatamente.

Qui (1,2,3) scriviamo file e, di conseguenza, ci sono tre rake contemporaneamente.

Il primo (1) è che dobbiamo scriverli da qualche parte. Non voglio sempre dare all'API la possibilità di scrivere direttamente su un file. È auspicabile che l'API sia isolata in un contenitore o, ancora meglio, che sia di sola lettura. Sono un amministratore di sistema, quindi ho una visione leggermente alternativa di queste cose.

Il secondo punto (2,3): abbiamo molte richieste in arrivo all'API. L'API scrive molti dati in un file. I file crescono. Dobbiamo ruotarli. Perché altrimenti non ci saranno abbastanza dischi lì. Ruotarli è sbagliato perché vengono reindirizzati dalla shell a una directory. Non possiamo testarlo in alcun modo. Non puoi dire all'applicazione di riaprire i descrittori. Perché gli sviluppatori ti guarderanno come un idiota: “Quali descrittori? In genere scriviamo a stdout." Le infrastrutture hanno fatto copytruncate in logrotate, che semplicemente copia il file e tronca l'originale. Di conseguenza, tra questi processi di copia e di solito esaurisce lo spazio su disco.

(4) Avevamo formati diversi in API diverse. Erano leggermente diversi, ma regexp doveva essere scritto in modo diverso. Poiché tutto questo era controllato da Puppet, c'era un grande fascio di classi con i propri scarafaggi. Inoltre, td-agent poteva mangiare la memoria per la maggior parte del tempo, essere stupido, poteva semplicemente fingere che funzionasse e non fare nulla. Era impossibile capire dall'esterno che non stava facendo nulla. Nella migliore delle ipotesi, cadrà e qualcuno lo raccoglierà più tardi. Più precisamente, arriverà un avviso e qualcuno alzerà la mano.

(6) E il più spazzatura e spreco - era elasticsearch. Perché quella era la vecchia versione. Perché a quel tempo non avevamo maestri dedicati. Avevamo log eterogenei con campi che potevano sovrapporsi. Diversi log di diverse applicazioni potrebbero essere scritti con gli stessi nomi di campo, ma allo stesso tempo potrebbero esserci dati diversi all'interno. Cioè, un registro viene fornito con Integer in un campo, ad esempio livello. Un altro registro viene fornito con una stringa 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. E se il primo è arrivato con Integer, tutti i messaggi successivi arrivati ​​da String vengono semplicemente scartati. Perché il tipo del campo non corrisponde.

Abbiamo iniziato a fare queste domande. Abbiamo deciso di non guardare alla colpa.

Ma bisogna fare qualcosa! La cosa ovvia è introdurre degli standard. Avevamo già degli standard. Abbiamo iniziato un po' più tardi. Fortunatamente, in quel momento era già stato approvato un formato di registro unificato per tutte le API. È enunciato direttamente negli standard di interazione del servizio. Di conseguenza, chi desidera ricevere i log deve scriverli in questo formato. Se qualcuno non scrive i log in questo formato, non garantiamo nulla.

Inoltre, vorrei creare uno standard unificato per la registrazione, la consegna e la raccolta dei log. In realtà, dove scriverli e come consegnarli. La situazione ideale è quando i progetti utilizzano la stessa libreria. C'è una libreria di log separata per Go, c'è una libreria separata per PHP. Tutti quelli che abbiamo, tutti dovrebbero usarli. Al momento, direi che lo stiamo facendo dell'80%. Ma alcune persone continuano a mangiare cactus.

E lì (sulla diapositiva) inizia a malapena a emergere lo "SLA per la consegna dei registri". Non è ancora disponibile, ma ci stiamo lavorando. Perché è molto conveniente quando l'infra dice che se scrivi in ​​questo o quell'altro formato in questo o quell'altro posto e non più di N messaggi al secondo, allora probabilmente lo consegneremo lì. Rimuove un mucchio di mal di testa. Se c'è uno SLA, allora è semplicemente fantastico!

Come abbiamo iniziato a risolvere il problema? Il rake principale era con td-agent. Non era chiaro dove stavano andando i nostri registri. Vengono consegnati? stanno andando? Dove sono? Pertanto, il primo punto è stato deciso di sostituire td-agent. Le opzioni su cosa sostituirlo con, ho brevemente abbozzato qui.

Fluente. In primo luogo, l'ho incontrato in un lavoro precedente, e anche lui periodicamente cadeva lì. In secondo luogo, è la stessa cosa, solo di profilo.

Filebeat. Come è stato conveniente per noi? Il fatto che sia in Go e abbiamo molta esperienza in Go. Di conseguenza, semmai, potremmo in qualche modo aggiungerlo per noi stessi. Pertanto, non l'abbiamo preso. In modo che nemmeno ci fosse la tentazione di iniziare a riscriverlo per te stesso.

La soluzione ovvia per l'amministratore di sistema è ogni tipo di syslog in tale quantità (syslog-ng / rsyslog / nxlog).

Oppure scrivi qualcosa di tuo, ma l'abbiamo scartato, così come il filebeat. Se scrivi qualcosa, è meglio scrivere qualcosa di utile per la tua attività. Per la consegna dei registri, è meglio prendere qualcosa di già pronto.

Quindi la scelta in realtà si riduceva a una scelta tra syslog-ng e rsyslog. Mi sono rivolto a rsyslog semplicemente perché avevamo già classi per rsyslog in Puppet e non riuscivo a trovare un'ovvia differenza tra loro. Cos'è syslog, cos'è syslog. Sì, alcuni hanno una documentazione peggiore, altri hanno una documentazione migliore. Lui sa come farlo, e lo fa in modo diverso.

E un po' di rsyslog. Innanzitutto, è bello perché ha molti moduli. Ha un RainerScript leggibile dall'uomo (linguaggio di configurazione moderno). Un fantastico bonus che potremmo emulare il comportamento di td-agent con i suoi mezzi regolari, e nulla è cambiato per le applicazioni. Cioè, cambiamo td-agent in rsyslog e per ora non tocchiamo il resto. E otteniamo subito una consegna funzionante. Successivamente, mmnormalize è una cosa fantastica di rsyslog. Ti consente di analizzare i log, ma non con Grok e regexp. Crea un albero di sintassi astratto. Analizza i log in modo simile a come un compilatore analizza i codici sorgente. Questo ti permette di lavorare molto velocemente, consumare un po' di CPU e, in generale, è una cosa molto interessante. Ci sono tonnellate di altri bonus. Non mi soffermerò su di loro.

Rsyslog ha anche un sacco di difetti. Sono più o meno gli stessi dei bonus. I problemi principali sono che devi sapere come cucinarlo e devi selezionare una versione.

Abbiamo deciso di scrivere i log nel socket unix. E non in / dev / log, perché c'è un casino di log di sistema, c'è journald in questa pipeline. Quindi scriviamo su un socket personalizzato. Lo allegheremo a un set di regole separato. Non interferiamo con niente. Tutto sarà trasparente e comprensibile. Così abbiamo effettivamente fatto. La directory con questi socket è standardizzata e inoltrata a tutti i contenitori. I container possono vedere il socket di cui hanno bisogno, aprirlo e scriverci sopra.

Perché non un file? Perché tutti hanno letto l' articolo su Badushechka , che ha provato a inoltrare un file alla finestra mobile, e si è scoperto che dopo aver riavviato rsyslog, il descrittore di file cambia e la finestra mobile perde questo file. Tiene aperto qualcos'altro, ma non lo stesso socket dove scrivono. Abbiamo deciso che ignoreremo questo problema e, allo stesso tempo, ignoreremo il problema del blocco.

Rsyslog esegue le azioni mostrate nella diapositiva e invia i registri a relay oa Kafka. Kafka segue la vecchia maniera. Relè: ho provato a utilizzare rsyslog puro per fornire i registri. Senza Message Queue, funzionalità rsyslog standard. Fondamentalmente, funziona.

Ma ci sono sfumature su come inserirli più avanti in questa parte (Logstash / Graylog / ES). Questa parte (rsyslog-rsyslog) viene utilizzata tra i datacenter. Ecco un collegamento tcp compresso, che consente di risparmiare larghezza di banda e, di conseguenza, aumentare in qualche modo la probabilità che riceveremo alcuni registri da un altro data center quando il canale è intasato. Perché abbiamo l'Indonesia, dove tutto va male. Questo è dove questo problema costante è.

Abbiamo pensato a come monitoriamo effettivamente, con quale probabilità i log che abbiamo registrato dall'applicazione raggiungono tale fine? Abbiamo deciso di aggiungere metriche. Rsyslog ha il proprio modulo di raccolta delle statistiche, che ha una sorta di contatori. Ad esempio, può mostrarti la dimensione della coda o quanti messaggi sono arrivati ​​in questa o quell'azione. Puoi già prendere qualcosa da loro. Inoltre, ha contatori personalizzati che puoi configurare e ti mostrerà, ad esempio, il numero di messaggi che alcune API hanno scritto. Successivamente, ho scritto rsyslog_exporter in Python e abbiamo inviato tutto a Prometheus e creato i grafici. Volevo davvero le metriche Graylog, ma finora non abbiamo avuto il tempo di configurarle.

Quali sono i problemi con? I problemi sono sorti con il fatto che abbiamo scoperto (di punto in bianco!) Che le nostre API Live scrivono 50k messaggi al secondo. Questa è solo l'API Live senza staging. E Graylog ci mostra solo 12mila messaggi al secondo. E una domanda ragionevole è sorta, dove sono gli avanzi? Da cui abbiamo concluso che Graylog semplicemente non ce la fa. Abbiamo esaminato e, in effetti, Graylog con Elasticsearch non ha padroneggiato questo flusso.

Successivamente, ci sono altre scoperte che abbiamo fatto nel processo.

La scrittura sul socket è bloccata. Come è successo? Quando ho usato rsyslog per la consegna, a un certo punto il canale tra i data center si è interrotto. La consegna è aumentata in un posto, la consegna è aumentata in un altro posto. Tutto questo è dovuto alla macchina con l'API che scrive sul socket rsyslog. La coda è piena. Quindi è stata riempita la coda per la scrittura sul socket unix, che per impostazione predefinita è di 128 pacchetti. E il prossimo write() nell'applicazione sta bloccando. Quando abbiamo esaminato la libreria che usiamo nelle applicazioni Go, è stato scritto che la scrittura sul socket avviene in modalità non bloccante. Eravamo sicuri che nulla fosse bloccato. Perché abbiamo letto un articolo su Badushechka , che 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 in un socket. Non lo abbiamo notato. Ho dovuto riscrivere la libreria. Da allora, è cambiato più volte, ma ora ci siamo sbarazzati dei blocchi in tutti i sottosistemi. Pertanto, puoi interrompere rsyslog e nulla andrà in crash.

È necessario monitorare la dimensione delle code, il che aiuta a non calpestare questo rake. Innanzitutto, possiamo monitorare quando iniziamo a perdere messaggi. In secondo luogo, possiamo controllare che, in linea di principio, abbiamo problemi con la consegna.

E un altro momento spiacevole: l'amplificazione di 10 volte in un'architettura di microservizi è molto semplice. Non abbiamo molte richieste in entrata, ma a causa del grafico lungo il quale questi messaggi scorrono ulteriormente, a causa dei log di accesso, aumentiamo effettivamente il carico sui log di una decina di volte. Sfortunatamente, non ho avuto il tempo di calcolare i numeri esatti, ma i microservizi sono così. Questo deve essere tenuto a mente. Si scopre che al momento il sottosistema di raccolta dei log è il più caricato in Lazada.

Come risolvere il problema di elasticsearch? Se è necessario ottenere rapidamente i registri in un'unica posizione in modo da non eseguire su tutte le macchine e raccoglierli lì, utilizzare l'archiviazione file. Questo è garantito per funzionare. Viene eseguito da qualsiasi server. Hai solo bisogno di colpire i dischi lì e mettere syslog. Dopodiché, avrai la garanzia di avere tutti i log in un unico posto. Inoltre, sarà già possibile configurare lentamente elasticsearch, graylog e quant'altro. Ma avrai già tutti i registri e, inoltre, puoi archiviarli finché ci sono abbastanza array di dischi.

Al momento della mia presentazione, il diagramma sembrava così. Abbiamo praticamente smesso di scrivere sul file. Ora, molto probabilmente, taglieremo gli avanzi. Smetteremo di scrivere su file su macchine locali che eseguono l'API. Innanzitutto, c'è l'archiviazione dei file, che funziona davvero bene. In secondo luogo, queste macchine sono costantemente a corto di spazio, è necessario monitorarle costantemente.

Questa parte con Logstash e Graylog, è davvero sospesa. Pertanto, dobbiamo liberarcene. Devi scegliere una cosa.

Abbiamo deciso di abbandonare Logstash e Kibana. Perché abbiamo un dipartimento di sicurezza. Qual è la connessione? La connessione è che Kibana senza X-Pack e senza Shield non consente di differenziare i diritti di accesso ai log. Pertanto, abbiamo preso Graylog. Ha tutto. Non mi piace, ma funziona. Abbiamo acquistato nuovo hardware, installato lì un nuovo Graylog e spostato tutti i log formattati in modo rigoroso in un Graylog separato. Abbiamo risolto organizzativamente il problema con diverse tipologie degli stessi campi.

Cosa è esattamente incluso nel nuovo Graylog. Abbiamo appena scritto tutto a Docker. Abbiamo preso un sacco di server, lanciato tre istanze Kafka, 7 server Graylog versione 2.3 (perché volevo Elasticsearch versione 5). Tutto questo è stato raccolto dall'HDD durante i raid. Abbiamo visto un tasso di indicizzazione fino a 100 mila messaggi al secondo. Abbiamo visto la cifra che 140 terabyte di dati a settimana.

E ancora il rastrello! Abbiamo due vendite in arrivo. Abbiamo spostato oltre 6 milioni di post. Il nostro Graylog non ha tempo per masticare. In qualche modo devi sopravvivere di nuovo.

Siamo sopravvissuti così. Aggiunti altri server e SSD. Al momento viviamo in questo modo. Ora stiamo già masticando 160k messaggi al secondo. Non abbiamo ancora raggiunto il limite, quindi non è ancora chiaro quanto possiamo effettivamente tirare fuori da questo.

Questi sono i nostri progetti per il futuro. Di questi, in realtà, il più importante è probabilmente l'elevata disponibilità. Non l'abbiamo ancora. Diverse auto sono impostate allo stesso modo, ma finora tutto sta passando attraverso un'auto. Ci vuole tempo per impostare il failover nel mezzo.

Raccogli metriche da Graylog.

Stabilisci un limite di velocità in modo da avere un'API impazzita, che non uccida la nostra larghezza di banda e tutto il resto.

E infine, per firmare una sorta di SLA con gli sviluppatori in modo da poter servire così tanto. Se scrivi di più mi dispiace.

E scrivere documentazione.

In breve, i risultati di tutto ciò che abbiamo vissuto. In primo luogo, gli standard. In secondo luogo, syslog è una torta. Terzo, rsyslog funziona esattamente come è scritto sulla diapositiva. E veniamo alle domande.

Domande .

Domanda : Perché hai deciso di non prendere ... (filebeat?)

Risposta : devi scrivere su un file. Non volevo davvero. Quando la tua API scrive migliaia di messaggi al secondo, anche se ruoti una volta all'ora, questa non è ancora un'opzione. Puoi scrivere su pipe. Al che gli sviluppatori mi hanno chiesto: "Cosa succederà se cade il processo in cui stiamo scrivendo"? Semplicemente non ho trovato cosa rispondere loro e ho detto: "Beh, ok, non facciamolo".

Domanda : Perché non scrivi semplicemente i log su HDFS?

Risposta : questa è la fase successiva. Ci abbiamo pensato all'inizio, ma poiché al momento non ci sono risorse per farlo, abbiamo una soluzione a lungo termine.

Domanda : il formato della colonna sarebbe più appropriato.

Risposta : ho capito tutto. Siamo "per" con entrambe le mani.

Domanda : Stai scrivendo a rsyslog. Sia TCP che UDP sono consentiti lì. 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 li metterai da qualche parte per noi nel caso succeda qualcosa", rispondiamo loro "Eccellente! Iniziamo a bloccare la scrittura sul socket e a farlo nelle transazioni, in modo che tu sia sicuro di inserirlo nel socket e assicurarci di averlo ricevuto dall'altra parte. " E in questo momento, non tutti ne hanno bisogno in una volta. E se non è necessario, quali sono le domande per noi? Se non vuoi garantire le scritture socket, perché dovremmo garantire la consegna? Facciamo del nostro meglio. Cerchiamo davvero di fornire il più e il meglio possibile, ma non diamo una garanzia al 100%. Pertanto, non è necessario scrivere lì i dati finanziari. Per questo, ci sono database con transazioni.

Domanda : quando l'API genera un messaggio nel registro e trasferisce il controllo ai microservizi, hai mai riscontrato il problema che i messaggi provenienti da diversi microservizi arrivano nell'ordine sbagliato? Questo crea confusione.

Risposta : È normale che vengano in un ordine diverso. Devi essere pronto per questo. Perché qualsiasi consegna in rete non garantisce l'ordine o è necessario spendere risorse speciali su di esso. Se prendiamo archivi di file, ogni API salva i log nel proprio file. Piuttosto, rsyslog li scompone in directory. Ogni API ha i propri registri lì, dove puoi andare a guardare, e quindi puoi confrontarli usando il timestamp in questo registro. Se vanno a cercare in Graylog, verranno ordinati lì per timestamp. Andrà tutto bene lì.

Domanda : Il timestamp può differire di millisecondi.

Risposta : il timestamp è generato dall'API stessa. Questo, infatti, è l'intero trucco. Abbiamo NTP. L'API genera un timestamp già nel messaggio stesso. Non viene aggiunto da rsyslog.

Domanda : L'interazione tra i data center non è molto chiara. Nell'ambito del data center, è chiaro come sono stati raccolti ed elaborati i log. Come sta andando l'interazione tra i data center? Oppure ogni datacenter vive la propria vita?

Risposta : quasi. Nel nostro paese, ogni paese si trova in un datacenter. Al momento, non abbiamo diffamazioni, quindi un paese si trova in diversi data center. Pertanto, non è necessario combinarli. Ogni centro ha un Log Relay all'interno. Questo è un server Rsyslog. In effetti, ci sono due macchine di gestione. Sono ugualmente sintonizzati. Ma per ora, solo il traffico passa attraverso uno di essi. Registra tutti gli aggregati. Ha una coda del disco per ogni evenienza. Preme i registri e li invia al centro dati centrale (Singapore), dove vengono quindi inviati a Graylog. E ogni datacenter ha il proprio archivio di file. Nel caso in cui abbiamo perso la comunicazione, abbiamo tutti i log lì. Rimarranno lì. Saranno salvati lì.

Domanda : Ricevi i log da lì durante situazioni anomale?

Risposta : puoi andare lì (all'archiviazione dei file) e vedere.

Domanda : Come si controlla 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 dall'API Go dispone di metriche. Può contare quante volte non è riuscita a scrivere su socket. Al momento c'è un'euristica complicata. C'è un buffer lì dentro. Prova a scrivere un messaggio da esso al socket. Se il buffer trabocca, inizia a rilasciarli. E conta quanto li ha fatti cadere. Se i contatori iniziano a traboccare, lo scopriremo. Adesso arrivano anche a prometeo, e puoi vedere i grafici a Grafana. Puoi personalizzare gli avvisi. Ma non è ancora chiaro a chi inviarli.

Domanda : In elasticsearch, archivi i log con ridondanza. Quante righe hai?

Risposta : una replica.

Domanda : questa è solo una replica?

Risposta : Questo è un master e una replica. I dati vengono archiviati in due copie.

Domanda : Hai in qualche modo modificato la dimensione del buffer rsyslog?

Risposta : scriviamo datagrammi su un socket unix personalizzato. Questo ci impone immediatamente un limite di 128 kilobyte. Non possiamo scriverci di più. Lo abbiamo scritto nella norma. Chi vuole entrare nel negozio, scrive 128 kilobyte. Le librerie, inoltre, troncano e impostano il flag che il messaggio viene troncato. Abbiamo un campo speciale nello standard del messaggio stesso, che mostra se è stato tagliato o meno durante la registrazione. Quindi siamo in grado di tracciare anche questo momento.

D : Stai scrivendo JSON rotto?

Risposta : JSON interrotto verrà scartato durante l'inoltro, perché il pacchetto è troppo grande. Oppure Graylog verrà scartato perché non è in grado di analizzare il JSON. Ma qui ci sono delle sfumature che devono essere risolte e sono per lo più legate a rsyslog. Ho già compilato diversi problemi che devono ancora essere elaborati.

D : Perché Kafka? Hai provato RabbitMQ? Graylog non si accumula sotto tali carichi?

Risposta : Non stiamo andando bene con Graylog. E Graylog sta prendendo forma. È davvero problematico con lui. È una specie di cosa. E, in effetti, non è necessario. Preferirei scrivere da rsyslog direttamente a elasticsearch e poi guardare Kibana. Ma dobbiamo risolvere la questione con le guardie di sicurezza. Questa è una possibile variante del nostro sviluppo, quando abbandoniamo Graylog e usiamo Kibana. Logstash non avrà senso. Perché posso fare lo stesso con rsyslog. E ha un modulo per scrivere su elasticsearch. Con Graylog stiamo cercando di vivere in qualche modo. L'abbiamo anche regolato un po'. Ma ci sono ancora margini di miglioramento.

A proposito di Kafka. È successo così storicamente. Quando sono arrivato, era già lì e i registri erano già stati scritti su di esso. Abbiamo appena creato il nostro cluster e ci siamo spostati su di esso con i log. Lo gestiamo, sappiamo come si sente. Per quanto riguarda RabbitMQ... non ci rendiamo conto di RabbitMQ. E stiamo sviluppando RabbitMQ. Lo abbiamo in produzione e abbiamo avuto problemi con esso. Ora, prima della vendita, sarebbe stato sciamanizzato e avrebbe iniziato a lavorare normalmente. Ma prima, non ero pronto a rilasciarlo in produzione. C'è un'altra cosa. Graylog può leggere AMQP 0.9 e rsyslog può scrivere AMQP 1.0. E non c'è una sola soluzione che possa fare entrambe le cose nel mezzo. C'è o l'uno o l'altro. Quindi, al momento, solo Kafka. Ma ci sono anche alcune sfumature. Perché l'omkafka della versione di rsyslog che stiamo usando potrebbe perdere l'intero buffer dei messaggi che ha preso da rsyslog. Finché lo sopportiamo.

D : Stai usando Kafka perché ce l'hai? Non utilizzato per altri scopi?

Risposta : il Kafka utilizzato dal team di Data Sсience. Questo è un progetto completamente separato, sul quale, purtroppo, non posso dire nulla. Non lo so. È stato gestito dal team di Data Science. Quando i log sono stati avviati, abbiamo deciso di usarlo per non metterci i nostri. Ora abbiamo aggiornato Graylog e abbiamo perso la compatibilità perché esiste una vecchia versione di Kafka. Abbiamo dovuto iniziare da soli. Allo stesso tempo, ci siamo sbarazzati di questi quattro argomenti per ogni API. Abbiamo creato un argomento ampio per tutti i live, un argomento ampio per tutti gli allestimenti e abbiamo girato tutto lì. Graylog rimuove tutto questo in parallelo.

Domanda : Perché è necessario questo sciamanesimo con prese? Hai provato a utilizzare il driver di registro syslog per i contenitori.

Risposta : All'epoca in cui abbiamo posto questa domanda, avevamo un rapporto teso con il docker. Era la finestra mobile 1.0 o 0.9. La stessa Docker era strana. In secondo luogo, se ci metti anche i registri ... ho il sospetto non verificato che passi tutti i registri attraverso se stesso, attraverso il demone docker. Se abbiamo un'API che sta impazzendo, il resto delle API è bloccato nel fatto che non possono inviare stdout e stderr. Non so dove porterà questo. Ho il sospetto a livello di sensazione che non sia necessario utilizzare il driver syslog docker qui in questo luogo. Il nostro reparto di test funzionali dispone di un proprio cluster graylog con log. Usano i driver di registro della finestra mobile e sembrano funzionare bene lì. Ma loro GELF scrivono immediatamente a Graylog. In quel momento, quando tutti hanno iniziato a farlo, avevamo bisogno che funzionasse. Forse più tardi, quando verrà qualcuno e ci dirà che funziona normalmente da cento anni, ci proveremo.

Domanda : Effettui la consegna tra i data center su rsyslog. Perché non Kafka?

Risposta : Facciamo questo e così di fatto. Per due ragioni. Se il canale viene completamente ucciso, tutti i log, anche in forma compressa, non lo attraverseranno. E kafka ti consente semplicemente di perderli nel processo. Usiamo questo metodo per eliminare l'attaccamento di questi registri. Stiamo semplicemente usando Kafka in questo caso direttamente. Se abbiamo un buon canale e vogliamo liberarlo, allora usiamo il loro rsyslog. Ma in realtà, puoi impostarlo in modo che rilasci ciò che non si adatta. Al momento stiamo semplicemente usando la consegna rsyslog direttamente da qualche parte, Kafka da qualche parte.