Come avere più flussi di registro nella finestra mobile

Abbiamo un'applicazione che scrive tre tipi di log in tre file separati: log di accesso, log di applicazioni generiche e log di sistema. Il formato (e lo scopo) di questi registri sono molto diversi. E abbiamo logforwarder separati che li inviano separatamente al nostro sistema di registrazione centralizzato.

Sulla base dei registri tratta come principio dei flussi di eventi , stiamo pensando di passare dall'uso dei file allo stdout. Sebbene conosciamo alcuni dei vantaggi di questo approccio, ciò significherebbe anche che otterremmo un flusso unito di registri con formattazione diversa, che dovremmo suddividere nuovamente prima di poterli inviare al nostro sistema centrale (Kibana / Splunk / ecc.) o al suo interno.

Ci chiediamo se ci siano strumenti o raccomandazioni su come dovremmo affrontare questa situazione.

docker logging

— SztupY
fonte

Non credo ne valga la pena. Perché lavorare di più per unire e quindi dividere i flussi di log, proprio per via di un "principio"? I file sono buoni. I file funzionano. Sembra troppo ingegnoso. Direi che forse reindirizzare tutti i log in syslog, con tag diversi, ecc. Ma devo dire che se qualcuno nel mio team lo avesse suggerito ... sarei .. deluso.

— Assaf Lavie

Perché l'uso dei file ha altri tipi di incubi di gestione, specialmente se generati dall'interno di un contenitore docker. Per ora sembra che gli svantaggi del passaggio allo stdout siano superiori ai vantaggi del nostro caso d'uso, ma stiamo già

— riscontrando

Non so di "incubi". So che è così che è stato fatto per un po 'di tempo, e ci sono molti software là fuori che ti aiutano a farlo. I file di registro vengono ruotati, letti con checkpoint - un file è una grande astrazione per questo. Non comprerei un principio che mi vende nuovi incubi a causa della paura di vecchi schemi familiari. I record del registro vengono scritti in un file o gestiti in memoria (almeno finché vengono spostati nel contenitore). Buona fortuna nel raggiungere l'affidabilità dei file di registro con splitter e fusioni di flussi in memoria.

— Assaf Lavie

@AssafLavie Dovresti scriverlo in una risposta che può essere votata. IMHO è un punto di vista perfettamente valido.

— Dan Cornilescu,

Sono venuto qui con la stessa domanda. Il semplice fatto è che la funzionalità di registrazione integrata della docker dipende da tutto ciò che sta per stdout / stderr, quindi anche il driver di registrazione e l'ecosistema di strumenti di terze parti che si sviluppano attorno ad esso. Sono tentato di scaricare anche tutti i miei log in un volume host, ma so che dovrò tornare indietro e gestirli quando i miei contenitori si sposteranno su k8s o openshift o gke o altro, mentre se seguo la finestra mobile approccio stdout sarà molto più agevole. Nel frattempo continuerò a cercare una risposta a questa domanda legittima

— Rabarbaro,

Risposte:

Sto ancora cercando un approccio di fusione / scissione me stesso, ma nel frattempo questo approccio raccomandato dalla documentazione di Kubernetes sembra una soluzione valida: utilizzare un contenitore sidecar per ciascuno dei registri separati .

Un "sidecar" è qualsiasi contenitore docker che si utilizza insieme a un altro contenitore docker per funzionare in qualche modo con esso. In questo caso, per ciascuno dei tre registri, avresti un contenitore separato che scansiona o codifica i registri e gli output su stdout.

In questo modo ogni container log-sidecar ha il proprio log docker dal proprio stdout. Essendo separati in questo modo, puoi usare le pratiche docker standard (e kubernetes, ecc.) Per separare o aggregare. Ecco cosa dice la pagina di Kubernetes:

Questo approccio consente di separare diversi flussi di registro da diverse parti dell'applicazione, alcuni dei quali possono non avere supporto per la scrittura su stdout o stderr. La logica alla base del reindirizzamento dei registri è minima, quindi non è certo un sovraccarico significativo. Inoltre, poiché stdout e stderr sono gestiti da kubelet, puoi usare strumenti integrati come i log di kubectl.

I "flussi di registro separati" derivano dalla codifica integrata che la finestra mobile applica ai registri di contenitori diversi, descritta nella documentazione della finestra mobile qui:

L'opzione di registro tag specifica come formattare un tag che identifica i messaggi di registro del contenitore. Per impostazione predefinita, il sistema utilizza i primi 12 caratteri dell'ID contenitore. Per ignorare questo comportamento, specificare un'opzione tag

— rabarbaro
fonte

Vale la pena menzionare il rovescio della medaglia di questo approccio log-sidecar-containers, citando: "Si noti che, nonostante il basso utilizzo di CPU e memoria, scrivere registri su un file e poi trasmetterli in streaming su stdout può raddoppiare l'utilizzo del disco". Mi chiedo se qualcuno prova questo approccio in pratica.

— venerdì

L'idea di fonderli in un flusso solo per dividerli in seguito sembra dolorosa. Non ho avuto motivo di farlo da solo, ma ecco da dove iniziare:

Quando si esegue il contenitore della finestra mobile, creare un volume in modo che sia facile visualizzare / spedire i registri dall'host.
Usa qualcosa come remote_syslog2 per spedire i log al tuo raccoglitore di log

È un po 'meno che elegante dover fare anche qualche configurazione sull'host, ma se usi qualcosa come ansible dove puoi eseguire un playbook e configurarlo durante la tua distribuzione nella scatola, non dovrebbe essere troppo cattivo.

— bradym
fonte

Questa soluzione può essere combinata con named pipe, l'unico problema con le named pipe è che non funzionano su tutti i sistemi in questo momento. Non funzionano su Mac

— Jens