Topp 10 Docker logging gotchas varje Docker — användare borde veta

en av de första kommandona Docker-användare lär sig efter ”docker run” är ”docker logs” – men visste du att kommandot ”docker logs” inte alltid fungerar? Det kanske låter fantastiskt men det är sant. Vi kommer att lära oss mer om orsakerna senare.

Docker ändrade inte bara hur applikationer distribueras utan också arbetsflödet för logghantering. Istället för att skriva loggar till filer skriver Behållare loggar till konsolen (stdout/stderr) och Docker-Loggningsdrivrutiner vidarebefordrar loggar till deras destination. En kontroll mot Docker Github-problem visar snabbt att användare har olika problem när de hanterar Docker-loggar.

Docker loggning drivrutiner översikt

hantera loggar med Docker verkar vara svårt och behöver djupare kunskaper om Docker loggning förare implementeringar och alternativ för att övervinna problem som människor rapporterar. Så vad är topp 10 Docker logging gotchas, varje Docker-användare borde veta?

Låt oss börja med en översikt över Docker-Loggningsdrivrutiner och alternativ för att skicka loggar till centraliserade Logghanteringslösningar som Elastic Stack (tidigare ELK Stack) eller Sematext Cloud.

i början av Docker var containerloggar endast tillgängliga via Docker remote API, dvs via kommandot ”docker logs” och några avancerade loggavsändare. Senare introducerade Docker loggningsdrivrutiner som plugins för att öppna Docker för integrationer med olika logghanteringsverktyg. Dessa loggningsdrivrutiner implementeras som binära plugins i docker-demonen. Nyligen, plugin arkitektur fick utvidgas till att köra loggning plugins som externa processer, som kan registrera sig som plugins och hämta loggar via Linux FIFO-filer. För närvarande är loggningsdrivrutiner som levereras med docker-binärer binära plugins, men det kan förändras inom en snar framtid.

Docker-Loggningsdrivrutiner tar emot containerloggar och vidarebefordrar dem till avlägsna destinationer eller filer. Standardloggningsdrivrutinen är ”json-file”. Den lagrar containerloggar i JSON-format på lokal disk. Docker har en plugin-arkitektur för att logga drivrutiner, så det finns plugins för open source-verktyg och kommersiella verktyg tillgängliga:

  • Journald – lagra containerloggar i systemet journal
  • Syslog Driver – stödja UDP, TCP, TLS
  • Fluentd – stödja TCP eller Unix socket anslutningar till fluentd
  • Splunk – HTTP/HTTPS vidarebefordran till Splunk server
  • Gelf – UDP logga vidarebefordran till Graylog2

för en komplett logghanteringslösning måste ytterligare verktyg involveras:

  • Loggparser för att strukturera loggar, vanligtvis en del av loggavsändare (fluentd, rsyslog, logstash, logagent, …)
  • Loggindexering, visualisering och varning:
    • Elasticsearch och Kibana (elastisk Stack, även känd som ELK stack),
    • Splunk,
    • Logentries,
    • Loggly,
    • Sumologic,
    • Graylog OSS / Enterprise
    • Sematext Cloud / enterprise
    • och många fler …

för att skicka loggar till en av backends kan du behöva välja en loggningsdrivrutin eller loggningsverktyg som stöder din Logghanteringslösning. Om ditt verktyg behöver Syslog-inmatning kan du välja Syslog-drivrutinen.

1.Docker loggar kommandot fungerar bara med JSON-fil loggning drivrutin

standard loggning drivrutinen ”json-fil” skriver loggar till den lokala disken, och JSON-fil drivrutin är den enda som fungerar parallellt med ”Docker loggar” kommando. Så snart man använder alternativa loggningsdrivrutiner, som Syslog, Gelf eller Splunk, börjar Docker logs API-samtal misslyckas och kommandot ”docker logs” visar ett fel som rapporterar begränsningarna istället för att visa loggarna på konsolen. Docker log-kommandot misslyckas inte bara, men många andra verktyg som använder Docker API för loggar, till exempel Docker-användargränssnitt som Portainer eller logguppsamlingsbehållare som Logspout kan inte visa behållarloggarna i den här situationen.

se det här problemet.

Docker Syslog driver kan blockera containerdistribution och förlora loggar när Syslog server inte kan nås

använda Docker Syslog driver med TCP eller TLS är ett pålitligt sätt att leverera loggar. Syslog-loggningsdrivrutinen kräver dock en etablerad TCP-anslutning till Syslog-servern när en behållare startar. Om den här anslutningen inte kan upprättas vid starttiden för behållaren misslyckas behållarens start med ett felmeddelande som

docker: felsvar från demonen: misslyckades med att initiera loggningsdrivrutin: Ring tcp

detta innebär att ett tillfälligt nätverksproblem eller hög nätverksfördröjning kan blockera utplaceringen av behållare. Dessutom kan en omstart av Syslog-servern riva ner alla containrar som loggar via TCP/TS till en central Syslog-server, vilket definitivt är situationen att undvika.

se det här problemet.

3. Docker syslog-drivrutinen förlorar loggar när destinationen är nere

i likhet med problemet ovan, orsakar förlust av loggar den saknade förmågan hos Docker-loggningsdrivrutiner att buffra loggar på disken när de inte kan levereras till avlägsna destinationer. Här är en intressant fråga att titta på.

4. Docker loggning drivrutiner stöder inte multi-line loggar som fel stack spår

när vi talar om loggar, de flesta människor tänker på enkla single-line loggar, säger som Nginx eller Apache loggar. Loggar kan dock också sträcka sig över flera rader. Till exempel spänner undantagsspår vanligtvis över flera rader, så för att hjälpa Logstash-användare har vi delat hur man hanterar stackspår med Logstash.

saker är inte bättre i containervärlden, där saker blir ännu mer komplicerade eftersom loggar från alla appar som körs i containrar släpps ut till samma utgång – stdout. Inte konstigt att se problem # 22920 stängt med ”stängt. Strunta i det.”besviken så många människor. Lyckligtvis finns det verktyg som Sematext Docker Agent som kan tolka flera linjers loggar ur lådan, samt tillämpa anpassade flerlinjemönster.

Docker service logs-kommandot hänger med icke-json-loggningsdrivrutin

medan JSON-files-drivrutinen verkar robust, kan andra loggdrivrutiner tyvärr fortfarande orsaka problem med Docker Swarm-läge. Se den här GitHub-frågan.

Docker daemon kraschar om fluentd daemon är borta och bufferten är full

ett annat scenario där en loggningsdrivrutin orsakar problem när fjärrdestinationen inte kan nås — i det här fallet kastar loggningsdrivrutinerna undantag som får Docker daemon att krascha.

Docker container fastnar i skapat tillstånd vid Splunk-drivrutinsfel

om Splunk-servern returnerar en 504 vid containerstart startas behållaren faktiskt, men docker rapporterar behållaren som misslyckades med att starta. En gång i detta tillstånd visas behållaren inte längre under docker ps, och behållarprocessen kan inte stoppas med docker kill. Det enda sättet att stoppa processen är att manuellt döda den.

se det här problemet.

Docker loggar hoppa över/saknas programloggar (journald driver)

det visar sig att det här problemet orsakas av journald rate gränser, som måste ökas som Docker skapar loggar för alla program som körs och journald kan hoppa över vissa loggar på grund av dess hastighetsbegränsningsinställningar. Så var medveten om dina journaldinställningar när du ansluter Docker till den.

Gelf-drivrutinsproblem

Gelf-loggningsdrivrutinen saknar ett TCP-eller TLS-alternativ och stöder endast UDP, vilket kan vara riskabelt att förlora loggmeddelanden när UDP-paket släpps. Vissa problem rapporterar ett problem med DNS-upplösning / caching med GELF — drivrutiner så att du loggar kan skickas till ”Nirvana” när din Graylog server IP ändras-och det kan hända snabbt med hjälp av containerdistributioner.

Docker stöder inte flera loggdrivrutiner

det skulle vara trevligt att ha loggar lagrade lokalt på servern och möjligheten att skicka dem till fjärrservrar. För närvarande stöder Docker inte flera loggdrivrutiner, så användare tvingas välja en enda loggdrivrutin. Inte ett lätt beslut att veta olika frågor som anges i det här inlägget.

det är det! Dessa är mina topp 10 Docker Logging Gotchas!

se även: kontinuerlig leverans med Jenkins & Docker Security: fördelarna, nackdelarna och en statusuppdatering

alternativ till Docker Log-drivrutiner

med så många problem kring Docker Log-drivrutiner, finns det alternativ? Det visar sig att det finns — Docker API-baserade loggavsändare till undsättning!till undsättning.

här är några bra skäl att titta på sådana alternativ:

  1. Json-file driver är standard och pålitlig, en lokal kopia av loggar är alltid tillgänglig, och ’docker logs’ och Docker API kräver loggar bara arbete.
  2. möjlighet att filtrera loggar med olika dynamiska kriterier som bildnamn eller etiketter
  3. bättre metadata, med full tillgång till Docker API
  4. ingen risk att krascha Docker Daemon eftersom sådana logg avlastare kan köras i en behållare med begränsad resursanvändning och diskutrymme konsumtion (t. ex. sätt buffertkatalogen i en volym och sätt användbara gränser)

Låt oss titta på två rekommenderade Docker API-baserade logginsamlingsverktyg: Logspout och Sematext Docker Agent. Båda är open source.

Observera att ett tredje verktyg, som passar mer eller mindre i denna kategori är Elastic Filebeat. Filebeat samlar loggfiler från, genereras av JSON-file log driver endast anrikning för containermetadata sker via Docker API-anrop.

Logspout ger flera utgångar och kan dirigera loggar från olika behållare till olika destinationer utan att ändra inställningarna för applikationsbehållarloggning. Den hanterar ANSI Escape-sekvenser (som färgkoder i loggar), vilket kan vara problematiskt för fulltextsökning i Elasticsearch.

liksom Logspout är Sematext Docker Agent (SDA) API-baserat, stöder loggrutning och hanterar ANSI-Flyktsekvenser för fulltextsökning. Sematext Docker Agent är dock faktiskt mer än bara en enkel loggavsändare.

SDA tar hand om många frågor som tas upp av Docker användare som multi-line loggar, log Format upptäckt och log Tolkning, kompletta metadata anrikning Behållare (etiketter, geoip, Swarm och Kubernetes specifika metadata), disk buffring och pålitlig frakt via TLS. Det är öppen källkod på Github, kan användas med Elastic Stack eller Sematext Cloud och kan samla inte bara containerloggar, men också containerhändelser, plus Docker host och container metrics.

skillnader mellan tre loggningslösningar som fungerar bra med JSON-file driver och Docker Remote API

rekommendation

den tydliga rekommendationen för API – baserade loggers kan förändras i framtiden när Docker-loggdrivrutiner förbättras över tiden och den nya plugin-mekanismen via Unix-uttaget gör att nya loggdrivrutinsimplementeringar kan köras som separata processer. Denna funktion förbättrar verkligen Dockers loggning plugin arkitektur och är ett gott tecken på att Docker tar loggning frågor på allvar.

under tiden, överväga Docker API-baserade loggsamlare som Sematext Docker Agent och Logspout för att undvika att stöta på problem med Docker-loggar, som de 10 gotchas som beskrivs här.

Lämna ett svar

Din e-postadress kommer inte publiceras.