Top 10 Docker logging gotchas ogni utente Docker dovrebbe sapere

Uno dei primi comandi che gli utenti Docker imparano dopo “docker run” è “docker logs — – ma lo sapevate che il comando “docker logs” non sempre funziona? Potrebbe sembrare incredibile, ma è vero. Impareremo di più sui motivi più tardi.

Docker ha modificato non solo il modo in cui le applicazioni vengono distribuite, ma anche il flusso di lavoro per la gestione dei log. Invece di scrivere i registri sui file, i contenitori scrivono i registri sulla console (stdout/stderr) e i driver di registrazione Docker inoltrano i registri alla loro destinazione. Un controllo contro i problemi di Github di Docker mostra rapidamente che gli utenti hanno vari problemi quando si tratta di registri Docker.

Panoramica dei driver di registrazione Docker

Gestire i log con Docker sembra essere complicato e richiede una conoscenza più approfondita delle implementazioni e delle alternative dei driver di registrazione Docker per superare i problemi segnalati dalle persone. Quindi quali sono i migliori 10 trucchi di registrazione Docker, ogni utente Docker dovrebbe sapere?

Iniziamo con una panoramica dei driver di registrazione Docker e delle opzioni per spedire i log a soluzioni di gestione dei log centralizzate come Elastic Stack (ex ELK Stack) o Sematext Cloud.

Nei primi giorni di Docker, i log dei container erano disponibili solo tramite Docker remote API, ovvero tramite il comando “docker logs” e alcuni caricatori di log avanzati. In seguito, Docker ha introdotto i driver di registrazione come plugin, per aprire Docker per integrazioni con vari strumenti di gestione dei registri. Questi driver di registrazione sono implementati come plugin binari nel demone docker. Recentemente, l’architettura dei plugin è stata estesa per eseguire plug-in di registrazione come processi esterni, che potrebbero registrarsi come plug-in e recuperare i log tramite file FIFO di Linux. Attualmente, i driver di registrazione forniti con i binari docker sono plugin binari, ma questo potrebbe cambiare nel prossimo futuro.

I driver di registrazione Docker ricevono i registri dei container e li inoltrano a destinazioni o file remoti. Il driver di registrazione predefinito è “json-file”. Memorizza i registri dei contenitori in formato JSON sul disco locale. Mobile ha una architettura a plugin per la registrazione di driver, quindi non ci sono plugin per strumenti open source e commerciali, strumenti a disposizione:

  • Journald – conservazione del contenitore registra nel diario di sistema
  • Syslog Driver di supporto UDP, TCP, TLS
  • Fluentd – supporto TCP o Unix socket a fluentd
  • Splunk – HTTP/HTTPS inoltro di Splunk server
  • Gelf – log UDP inoltro Graylog2

Per una completa soluzione di gestione dei log, strumenti aggiuntivi devono essere coinvolti:

  • Log parser per strutturare i log, tipicamente parte dei log shippers (fluentd, rsyslog, logstash, logagent, …)
  • Log indicizzazione, visualizzazione e avviso:
    • Elasticsearch e Kibana (Elastico Stack, noto anche come ALCI stack),
    • Splunk,
    • Logentries,
    • Loggly,
    • Sumologic,
    • Graylog OSS / Azienda
    • Sematext Cloud / Azienda
    • e molti altri …

Per spedire i log di uno dei backend potrebbe essere necessario selezionare una registrazione di driver o di registrazione strumento che supporta la vostra soluzione di Gestione dei Log di scelta. Se il tuo strumento ha bisogno di input Syslog, puoi scegliere il driver Syslog.

1.Il comando Docker logs funziona solo con il driver di registrazione json-file

Il driver di registrazione predefinito “json-file” scrive i log sul disco locale e il driver json-file è l’unico che funziona in parallelo al comando “docker logs”. Non appena si utilizzano driver di registrazione alternativi, come Syslog, Gelf o Splunk, le chiamate API Docker logs iniziano a fallire e il comando “docker logs” mostra un errore che segnala le limitazioni invece di visualizzare i log sulla console. Non solo il comando docker log fallisce, ma molti altri strumenti che utilizzano l’API Docker per i log, come le interfacce utente Docker come Portainer o i contenitori di raccolta dei log come Logspout non sono in grado di mostrare i log dei container in questa situazione.

Vedi questo problema.

Il driver Syslog Docker può bloccare la distribuzione dei container e perdere i log quando il server Syslog non è raggiungibile

L’utilizzo del driver Syslog Docker con TCP o TLS è un modo affidabile per distribuire i log. Tuttavia, il driver di registrazione Syslog richiede una connessione TCP stabilita al server Syslog all’avvio di un contenitore. Se questa connessione non può essere stabilita all’ora di inizio del contenitore, l’avvio del contenitore non riesce con un messaggio di errore come

docker: Risposta di errore da daemon: Impossibile inizializzare driver di registrazione: comporre tcp

Ciò significa che un problema di rete temporaneo o una latenza di rete elevata potrebbe bloccare la distribuzione dei contenitori. Inoltre, un riavvio del server Syslog potrebbe abbattere tutti i contenitori che registrano tramite TCP / TS a un server Syslog centrale, che è sicuramente la situazione da evitare.

Vedi questo problema.

3. Il driver syslog Docker perde i registri quando la destinazione è inattivo

Simile al problema precedente, causando una perdita di registri è la capacità mancante dei driver di registrazione Docker di memorizzare i registri sul disco quando non possono essere consegnati a destinazioni remote. Ecco un problema interessante da guardare.

4. I driver di registrazione Docker non supportano i log multilinea come error stack traces

Quando parliamo di log, la maggior parte delle persone pensa a semplici log a riga singola, ad esempio i log Nginx o Apache. Tuttavia, i registri possono anche estendersi su più righe. Ad esempio, le tracce di eccezione in genere si estendono su più righe, quindi per aiutare gli utenti di Logstash abbiamo condiviso come gestire le tracce di stack con Logstash.

Le cose non vanno meglio nel mondo dei contenitori, dove le cose diventano ancora più complicate perché i registri di tutte le app in esecuzione nei contenitori vengono emessi sullo stesso output – stdout. Non c’è da stupirsi vedendo problema #22920 chiuso con ” Chiuso. Non importa.”deluso così tante persone. Fortunatamente, ci sono strumenti come Sematext Docker Agent che possono analizzare i log multi-linea fuori dalla scatola, così come applicare modelli multi-linea personalizzati.

Il comando Docker service logs si blocca con driver di registrazione non json

Mentre il driver json-files sembra robusto, altri driver di log potrebbero purtroppo ancora causare problemi con la modalità Sciame Docker. Vedi questo problema GitHub.

Il demone Docker si blocca se il demone fluentd è scomparso e il buffer è pieno

Un altro scenario in cui un driver di registrazione causa problemi quando la destinazione remota non è raggiungibile — in questo caso particolare, i driver di registrazione generano eccezioni che causano il crash del demone Docker.

Il contenitore Docker si blocca nello stato creato in caso di errore del driver Splunk

Se il server Splunk restituisce un 504 all’avvio del contenitore, il contenitore viene effettivamente avviato, ma docker segnala che il contenitore non è stato avviato. Una volta in questo stato, il contenitore non appare più sotto docker ps e il processo del contenitore non può essere interrotto con docker kill. L’unico modo per fermare il processo è ucciderlo manualmente.

Vedi questo problema.

Registri Docker saltando/registri delle applicazioni mancanti (driver journald)

Si scopre che questo problema è causato dai limiti di velocità di journald, che devono essere aumentati in quanto Docker crea registri per tutte le applicazioni in esecuzione e journald potrebbe saltare alcuni registri a causa delle sue impostazioni di limitazione della velocità. Quindi, essere consapevoli delle impostazioni journald quando si collega Docker ad esso.

Problemi del driver Gelf

Il driver di registrazione Gelf manca di un’opzione TCP o TLS e supporta solo UDP, il che potrebbe essere rischioso perdere i messaggi di log quando i pacchetti UDP vengono eliminati. Alcuni problemi segnalano un problema di risoluzione DNS / caching con i driver GELF in modo che i log possano essere inviati a “Nirvana” quando l’IP del server Graylog cambia — e questo potrebbe accadere rapidamente utilizzando le distribuzioni di container.

Docker non supporta più driver di log

Sarebbe bello avere i log memorizzati localmente sul server e la possibilità di spedirli a server remoti. Attualmente, Docker non supporta più driver di log, quindi gli utenti sono costretti a scegliere un singolo driver di log. Non è una decisione facile conoscere i vari problemi elencati in questo post.

Questo è tutto! Questi sono i miei migliori 10 trucchi di registrazione Docker!

VEDI ANCHE: Continuous Delivery with Jenkins & Docker Security: I pro, i contro e un aggiornamento di stato

Alternative ai driver di log Docker

Con così tanti problemi relativi ai driver di log Docker, ci sono alternative? Si scopre che ci sono-caricatori di log basati su API Docker in soccorso!in soccorso.

Ecco alcuni buoni motivi per guardare a tali alternative:

  1. Il driver Json-file è predefinito e affidabile, una copia locale dei log è sempre disponibile e le chiamate ‘docker logs’ E Docker API per i log funzionano.
  2. Possibilità di filtrare i log in base a vari criteri dinamici come il nome dell’immagine o le etichette
  3. Metadati migliori, con accesso completo all’API Docker
  4. Nessun rischio di arresto anomalo del demone Docker perché tali caricatori di log potrebbero essere eseguiti in un contenitore con un utilizzo limitato di risorse e metti la directory buffer in un volume e imposta limiti utili)

Diamo un’occhiata a due strumenti di raccolta di log basati su API Docker consigliati: Logspout e Sematext Docker Agent. Entrambi sono open source.

Si prega di notare che un terzo strumento, che si adatta più o meno in questa categoria è Elastic Filebeat. Filebeat raccoglie i file di log da, generati dal driver di log json-file solo l’arricchimento per i metadati del contenitore viene effettuato tramite chiamate API Docker.

Logspout fornisce più uscite e può instradare i registri da contenitori diversi a destinazioni diverse senza modificare le impostazioni di registrazione del contenitore dell’applicazione. Gestisce sequenze di escape ANSI (come i codici colore nei log), che potrebbero essere problematici per la ricerca full-text in Elasticsearch.

Come Logspout, Sematext Docker Agent (SDA) è basato su API, supporta il routing dei log e gestisce le sequenze di escape ANSI per la ricerca full-text. Tuttavia, Sematext Docker Agent è in realtà più di un semplice spedizioniere di log.

SDA si occupa di molti problemi sollevati dagli utenti Docker come i log multi-linea, il rilevamento del formato di log e l’analisi dei log, contenitori completi di arricchimento dei metadati (etichette, metadati specifici geoip, Swarm e Kubernetes), il buffering del disco e la spedizione affidabile tramite TLS. È open source su Github, può essere utilizzato con Elastic Stack o Sematext Cloud e può raccogliere non solo i log del contenitore, ma anche gli eventi del contenitore, oltre alle metriche dell’host Docker e del contenitore.

Differenze tra le tre la registrazione di soluzioni che funzionano bene con il json-file di driver e Pannello Remoto API

Raccomandazione

La chiara raccomandazione per API basata logger potrebbe cambiare in futuro, come la finestra Mobile di registro driver migliorare nel corso del tempo e il nuovo plugin meccanismo tramite socket Unix consente la registrazione di driver implementazioni per l’esecuzione come processi separati. Questa funzione migliora davvero l’architettura dei plugin di registrazione dei Docker ed è un buon segno che Docker prende sul serio i problemi di registrazione.

Nel frattempo, considera i raccoglitori di log basati su API Docker come Sematext Docker Agent e Logspout per evitare di incorrere in problemi con i registri Docker, come i 10 trucchi descritti qui.

Lascia un commento

Il tuo indirizzo email non sarà pubblicato.