Top 10 Docker logging gotchas hver Docker — bruger skal vide

en af de første kommandoer Docker-brugere lærer efter “docker run” er “docker logs” – men vidste du, at kommandoen “docker logs” ikke altid fungerer? Det lyder måske fantastisk, men det er sandt. Vi vil lære mere om årsagerne senere.

Docker ændrede ikke kun den måde, applikationer implementeres på, men også arbejdsgangen til logstyring. I stedet for at skrive logfiler til filer, skriver containere logfiler til konsollen (stdout/stderr) og Docker Logging drivere videresender logfiler til deres destination. En kontrol mod Docker Github-problemer viser hurtigt, at brugerne har forskellige problemer, når de beskæftiger sig med Docker-logfiler.

Docker Logging Drivers oversigt

håndtering af logfiler med Docker synes at være vanskelig og har brug for dybere viden om Docker Logging Driver implementeringer og alternativer til at overvinde problemer, som folk rapporterer. Så hvad er toppen 10 Docker logging gotchas, hver Docker bruger bør vide?

lad os starte med en oversigt over Docker Logging drivere og muligheder for at sende logfiler til centraliserede Log Management løsninger såsom Elastic Stack (tidligere ELK Stack) eller Sematekst Cloud.

i de tidlige dage af Docker var containerlogfiler kun tilgængelige via Docker remote API, dvs. via kommandoen” docker logs ” og et par avancerede logafsendere. Senere introducerede Docker logdrivere som plugins for at åbne Docker for integrationer med forskellige logstyringsværktøjer. Disse logging drivere er implementeret som binære plugins i docker dæmonen. For nylig blev plugin-arkitekturen udvidet til at køre logging plugins som eksterne processer, som kunne registrere som plugins og hente logfiler via FIFO-filer. I øjeblikket er logdrivere, der leveres med docker-binære filer, binære plugins, men dette kan ændre sig i den nærmeste fremtid.

Docker Logging drivere modtager container logs og videresender dem til fjerntliggende destinationer eller filer. Standard logging driver er “json-file”. Det gemmer container logfiler i JSON format på lokal disk. Docker har en plugin-arkitektur til logning af drivere, så der er plugins til open source-værktøjer og kommercielle værktøjer til rådighed:

  • Journald – lagring af containerlogfiler i systemjournalen
  • Syslog Driver – understøttelse af UDP, TCP, TLS
  • Fluentd – understøttelse af TCP – eller unikke stikforbindelser til fluentd
  • Splunk – HTTP/HTTPS videresendelse til Splunk-server
  • gelf-UDP log videresendelse til Graylog2

for en komplet logstyringsløsning skal der inddrages yderligere værktøjer:

  • Log parser til struktur logs, typisk en del af log afsendere (fluentd, rsyslog, logstash, logagent, …)
  • log indeksering, visualisering og alarmering:
    • Elasticsearch and Kibana (elastisk stak, også kendt som ELK stack),
    • Splunk,
    • Logentries,
    • Loggly,
    • Sumologic,
    • Graylog OSS / Enterprise
    • sematekst cloud / enterprise
    • og mange flere …

for at sende logfiler til en af backends skal du muligvis vælge en logdriver eller et logværktøj, der understøtter din valgte Logadministrationsløsning. Hvis dit værktøj har brug for Syslog-input, kan du vælge Syslog-driveren.

1.Docker logs command fungerer kun med JSON-file Logging driver

standard Logging driver “json-file” skriver logfiler til den lokale disk, og json-file driveren er den eneste, der fungerer parallelt med kommandoen “docker logs”. Så snart man bruger alternative logdrivere, såsom Syslog, Gelf eller Splunk, begynder Docker logs API-opkald at mislykkes, og kommandoen “docker logs” viser en fejl, der rapporterer begrænsningerne i stedet for at vise logfilerne på konsollen. Docker-logkommandoen mislykkes ikke kun, men mange andre værktøjer, der bruger Docker API til logfiler, såsom Docker-brugergrænseflader som Portainer eller logopsamlingsbeholdere som Logspout, er ikke i stand til at vise containerlogfilerne i denne situation.

se dette nummer.

Docker Syslog driver kan blokere containerudrulning og miste logfiler, når Syslog server ikke kan nås

brug af Docker Syslog driver med TCP eller TLS er en pålidelig måde at levere logfiler på. Syslog-logdriveren kræver dog en etableret TCP-forbindelse til Syslog-serveren, når en container starter. Hvis denne forbindelse ikke kan oprettes ved containerstarttidspunktet, mislykkes containerstart med en fejlmeddelelse som

docker: Fejlrespons fra daemon: kunne ikke initialisere logdriver: dial tcp

dette betyder, at et midlertidigt netværksproblem eller høj netværksforsinkelse kan blokere implementeringen af containere. Derudover kan en genstart af Syslog-serveren rive alle containere, der logger via TCP/TS, ned til en central Syslog-server, hvilket bestemt er situationen at undgå.

se dette nummer.

3. Docker syslog driver mister logfiler, når destinationen er nede

svarende til problemet ovenfor, forårsager et tab af logfiler er den manglende evne til Docker logging drivere til buffer logfiler på disken, når de ikke kan leveres til fjerntliggende destinationer. Her er et interessant emne at se.

4. Docker logging drivere understøtter ikke multi-line logs som error stack traces

når vi taler om logs, tænker de fleste på simple single-line logs, f.eks. Logfiler kan dog også spænde over flere linjer. For eksempel spænder undtagelsesspor typisk over flere linjer, så for at hjælpe Logstash-brugere har vi delt, hvordan man håndterer stakspor med Logstash.

ting er ikke bedre i containerverdenen, hvor tingene bliver endnu mere komplicerede, fordi logfiler fra alle apps, der kører i containere, udsendes til den samme output – stdout. Ikke underligt at se nummer #22920 lukket med “lukket. Jeg er ligeglad.”jeg har skuffet så mange mennesker. Heldigvis er der værktøjer som Sematekst Docker Agent, der kan analysere multi-line logs ud af kassen, samt anvende brugerdefinerede multi-line mønstre.

Docker service logs command hænger med ikke-json logging driver

mens JSON-files driveren virker robust, kan andre logdrivere desværre stadig forårsage problemer med Docker sværm mode. Se dette GitHub-problem.

Docker — dæmonen går ned, hvis fluentd-dæmonen er væk, og bufferen er fuld

et andet scenario, hvor en logdriver skaber problemer, når fjerndestinationen ikke kan nås-i dette særlige tilfælde kaster logdriverne undtagelser, der får Docker-dæmonen til at gå ned.

Docker container sidder fast i Oprettet tilstand ved Splunk-driverfejl

hvis Splunk-serveren returnerer en 504 ved containerstart, startes containeren faktisk, men docker rapporterer, at containeren ikke kunne starte. En gang i denne tilstand vises beholderen ikke længere under docker ps, og containerprocessen kan ikke stoppes med docker kill. Den eneste måde at stoppe processen på er at dræbe den manuelt.

se dette nummer.

Docker logs skipping/missing application logs (journald driver)

det viser sig, at dette problem skyldes journald rate limits, som skal øges, da Docker opretter logfiler for alle kørende applikationer, og journald kan springe over nogle logfiler på grund af dens hastighedsbegrænsningsindstillinger. Så vær opmærksom på dine journald indstillinger, når du tilslutter Docker til det.

gelf-driverproblemer

Gelf-logdriveren mangler en TCP-eller TLS-indstilling og understøtter kun UDP, hvilket kan være risikabelt at miste logmeddelelser, når UDP-pakker bliver droppet. Nogle problemer rapporterer et problem med DNS-opløsning / caching med GELF — drivere, så du logger muligvis til “Nirvana”, når din Graylog server IP ændres-og dette kan ske hurtigt ved hjælp af containerinstallationer.

Docker understøtter ikke flere logdrivere

det ville være rart at have logfiler gemt lokalt på serveren og muligheden for at sende dem til eksterne servere. I øjeblikket understøtter Docker ikke flere logdrivere, så brugerne er tvunget til at vælge en enkelt logdriver. Ikke en let beslutning at kende forskellige problemer, der er anført i dette indlæg.

det er det! Disse er min top 10 Docker Logging Gotchas!

se også: kontinuerlig levering med Jenkins & Docker-Sikkerhed: fordele, ulemper og en statusopdatering

alternativer til Docker-Logdrivere

med så mange problemer omkring Docker-Logdrivere, er der alternativer? Det viser sig, at der er — Docker API baserede log afsendere til undsætning!til undsætning.

her er et par gode grunde til at se på sådanne alternativer:

  1. Json-file driver er standard og pålidelig, en lokal kopi af logfiler er altid tilgængelig, og ‘docker logs’ og Docker API opfordrer til logfiler bare arbejde.
  2. mulighed for at filtrere logfiler efter forskellige dynamiske kriterier som billednavn eller etiketter
  3. bedre metadata, der har fuld adgang til Docker API
  4. ingen risiko for at gå ned i Docker-dæmonen, fordi sådanne logafskibere kunne køre i en container med begrænset ressourceforbrug og diskpladsforbrug (f. eks. put buffer mappe i en volumen og sætte nyttige grænser)

lad os se på to anbefalede Docker API-baserede logindsamlingsværktøjer: Logspout og Sematekst Docker Agent. Begge dele er open source.

bemærk, at et tredje værktøj, der passer mere eller mindre i denne kategori, er Elastic Filebeat. Filebeat indsamler logfiler fra, genereret af json-file log driver kun berigelse for container metadata sker via Docker API opkald.

Logspout giver flere udgange og kan dirigere logfiler fra forskellige containere til forskellige destinationer uden at ændre indstillingerne for logning af applikationsbeholdere. Det håndterer ANSI Escape-sekvenser (som farvekoder i logfiler), hvilket kan være problematisk for fuldtekstsøgning i Elasticsearch.

ligesom Logspout er Sematekst Docker Agent (SDA) API-baseret, understøtter log routing og håndterer ANSI Escape-sekvenser til fuldtekstsøgning. Imidlertid, Sematekst Docker Agent er faktisk mere end blot en simpel log afsender.

SDA tager sig af mange problemer rejst af Docker-brugere, såsom logfiler med flere linjer, registrering af logformat og logparsing, komplette metadataberigelsesbeholdere (etiketter, geoip, sværm og Kubernetes specifikke metadata), diskbuffer og pålidelig forsendelse via TLS. Det er open source på Github, kan bruges med elastisk stak eller Sematekst Sky og kan indsamle ikke bare container logs, men også container begivenheder, plus Docker vært og container målinger.

forskelle mellem tre logning løsninger, der fungerer godt med json-file driver og Docker Remote API

anbefaling

den klare anbefaling til API-baserede loggere kan ændre sig i fremtiden, da Docker-logdrivere forbedres over tid, og den nye plugin-mekanisme via stikdåse gør det muligt for nye logdriverimplementeringer at køre som separate processer. Denne funktion forbedrer virkelig Dockers logging plugin arkitektur og er et godt tegn på, at Docker tager logging problemer alvorligt.

i mellemtiden skal du overveje Docker API-baserede logsamlere som Sematekst Docker Agent og Logspout for at undgå at løbe ind i problemer med Docker-logfiler, som de 10 gotchas, der er beskrevet her.

Skriv et svar

Din e-mailadresse vil ikke blive publiceret.