Top 10 logare Docker gotchas fiecare utilizator Docker ar trebui să știe

una dintre primele comenzi pe care utilizatorii Docker le învață după „Docker run” este „Docker logs” — dar știați că comanda „docker logs” nu funcționează întotdeauna? Ar putea suna uimitor, dar este adevărat. Vom afla mai multe despre motive mai târziu.

Docker a schimbat nu numai modul în care sunt implementate aplicațiile, ci și fluxul de lucru pentru gestionarea jurnalului. În loc să scrie jurnale în fișiere, containerele scriu jurnale în consolă (stdout/stderr) și driverele de logare Docker redirecționează jurnalele către destinație. O verificare împotriva problemelor Docker Github arată rapid că utilizatorii au diverse probleme atunci când se ocupă de jurnalele Docker.

Docker logging drivers overview

gestionarea jurnalelor cu Docker pare a fi dificilă și are nevoie de cunoștințe mai profunde despre implementările driverului de logare Docker și alternative pentru a depăși problemele pe care oamenii le raportează. Deci, care sunt TOP 10 Docker logging gotchas, fiecare utilizator Docker ar trebui să știe?

să începem cu o prezentare generală a driverelor de logare Docker și a opțiunilor de expediere a jurnalelor către soluții centralizate de gestionare a jurnalelor, cum ar fi Elastic Stack (fostul Elk Stack) sau Sematext Cloud.

în primele zile ale Docker, jurnalele de containere erau disponibile numai prin Docker remote API, adică prin comanda „docker logs” și câțiva expeditori avansați de jurnale. Mai târziu, Docker a introdus driverele de logare ca pluginuri, pentru a deschide Docker pentru integrări cu diverse instrumente de gestionare a jurnalului. Aceste drivere de logare sunt implementate ca pluginuri binare în demonul docker. Recent, arhitectura pluginului a fost extinsă pentru a rula pluginuri de logare ca procese externe, care ar putea înregistra ca pluginuri și prelua jurnalele prin fișiere Linux FIFO. În prezent, driverele de logare livrate cu binare docker sunt pluginuri binare, dar acest lucru s-ar putea schimba în viitorul apropiat.

driverele de logare Docker primesc jurnale de containere și le redirecționează către destinații sau fișiere la distanță. Driverul de logare implicit este”JSON-file”. Stochează jurnalele de containere în format JSON pe discul local. Docker are o arhitectură de plugin pentru logarea driverelor, deci există pluginuri pentru instrumente open source și instrumente comerciale disponibile:

  • Journald – stocarea jurnalelor de containere în Jurnalul de sistem
  • Driver Syslog – suport pentru UDP, TCP, TLS
  • Fluentd – suport pentru conexiuni TCP sau UNIX socket la fluentd
  • Splunk – HTTP/HTTPS redirecționare către serverul Splunk
  • Gelf – UDP log forwarding la Graylog2

pentru o soluție completă de gestionare a jurnalului, trebuie implicate instrumente suplimentare:

  • Log parser pentru a structura jurnalele, de obicei parte a expeditorilor de jurnale (fluentd, rsyslog, logstash, logagent, …)
  • indexarea, vizualizarea și alertarea jurnalelor:
    • Elasticsearch și Kibana (stivă elastică, cunoscută și sub numele de stivă ELK),
    • Splunk,
    • Logentries,
    • Loggly,
    • Sumologic,
    • Graylog OSS / Enterprise
    • sematext cloud / enterprise
    • și multe altele …

pentru a livra jurnalele la unul dintre backend-uri, poate fi necesar să selectați un driver de înregistrare sau un instrument de înregistrare care acceptă soluția de gestionare a Jurnalului la alegere. Dacă instrumentul dvs. are nevoie de intrare Syslog, puteți alege driverul syslog.

1.Docker logs command funcționează numai cu JSON-file Logging driver

driverul de logare implicit „JSON-file” scrie jurnalele pe discul local, iar driverul JSON-file este singurul care funcționează în paralel cu comanda „Docker logs”. De îndată ce se utilizează drivere alternative de logare, cum ar fi Syslog, Gelf sau Splunk, apelurile API Docker logs încep să eșueze, iar comanda „Docker logs” arată o eroare care raportează limitările în loc să afișeze jurnalele pe consolă. Nu numai că comanda docker log eșuează, dar multe alte instrumente care utilizează API-ul Docker pentru jurnale, cum ar fi interfețele de utilizator Docker, cum ar fi portainer sau containerele de colectare a jurnalelor, cum ar fi Logspout, nu sunt capabile să afișeze jurnalele de containere în această situație.

vedeți această problemă.

driverul Docker syslog poate bloca implementarea containerului și pierde jurnalele atunci când serverul Syslog nu este accesibil

utilizarea driverului Docker syslog cu TCP sau TLS este o modalitate fiabilă de a livra jurnalele. Cu toate acestea, driverul de logare Syslog necesită o conexiune TCP stabilită la serverul Syslog atunci când un container pornește. Dacă această conexiune nu poate fi stabilită la ora de pornire a containerului, pornirea containerului eșuează cu un mesaj de eroare precum

docker: răspuns de eroare de la daemon: nu s-a reușit inițializarea înregistrării driver: dial tcp

aceasta înseamnă că o problemă temporară de rețea sau o latență ridicată a rețelei ar putea bloca implementarea containerelor. În plus, o repornire a serverului Syslog ar putea rupe toate containerele care se înregistrează prin TCP/TS pe un server central syslog, ceea ce este cu siguranță situația de evitat.

vedeți această problemă.

3. Driverul Docker syslog pierde jurnalele atunci când destinația este în jos

Similar cu problema de mai sus, provocând o pierdere de jurnale este capacitatea lipsă a driverelor de logare Docker de a tampona jurnalele de pe disc atunci când nu pot fi livrate către destinații la distanță. Iată o problemă interesantă de urmărit.

4. Driverele de logare Docker nu acceptă jurnalele cu mai multe linii, cum ar fi urmele stivei de erori

când vorbim despre jurnale, majoritatea oamenilor se gândesc la jurnalele simple cu o singură linie, să zicem ca jurnalele Nginx sau Apache. Cu toate acestea, jurnalele se pot întinde și pe mai multe linii. De exemplu, urmele de excepție se întind de obicei pe mai multe linii, astfel încât pentru a ajuta utilizatorii Logstash am împărtășit cum să gestionăm urmele de stivă cu Logstash.

lucrurile nu sunt mai bune în lumea containerelor, unde lucrurile devin și mai complicate, deoarece jurnalele din toate aplicațiile care rulează în containere sunt emise la aceeași ieșire – stdout. Nu e de mirare văzând problema #22920 închis cu „închis. Nu-mi pasă.”dezamăgit atât de mulți oameni. Din fericire, există instrumente precum Sematext Docker Agent care poate analiza jurnalele multi-line din cutie, precum și aplica modele personalizate multi-line.

Docker service logs comanda se blochează cu non-JSON logging driver

în timp ce driverul JSON-files pare robust, alte drivere jurnal ar putea, Din păcate, încă cauza probleme cu modul Docker Swarm. A se vedea această problemă GitHub.

Docker daemon se blochează dacă fluentd daemon este plecat și tampon este plin

un alt scenariu în cazul în care un driver de logare provoacă probleme atunci când destinația de la distanță nu este accesibil — în acest caz particular, driverele de logare aruncă excepții care cauzează Docker daemon să se prăbușească.

docker container se blochează în stare creată pe Splunk driver failure

dacă serverul Splunk returnează un 504 pe container start, containerul este de fapt pornit, dar docker raportează containerul ca nu a reușit să înceapă. Odată ajuns în această stare, containerul nu mai apare sub docker ps, iar procesul containerului nu poate fi oprit cu docker kill. Singura modalitate de a opri procesul este să-l ucizi manual.

vedeți această problemă.

jurnalele Docker sărind peste/lipsesc jurnalele de aplicații (driver journald)

se pare că această problemă este cauzată de limitele ratei journald, care trebuie mărită pe măsură ce Docker creează jurnale pentru toate aplicațiile care rulează și journald ar putea sări peste unele jurnale datorită setărilor sale de limitare a ratei. Deci, să fie conștienți de setările journald atunci când vă conectați Docker la ea.

Gelf driver issues

driverul de logare Gelf lipsește o opțiune TCP sau TLS și acceptă numai UDP, ceea ce ar putea fi riscant să pierdeți mesajele de jurnal Atunci când pachetele UDP sunt abandonate. Unele probleme raportează o problemă de rezoluție DNS / cache cu driverele GELF, astfel încât jurnalele să poată fi trimise la „nirvana” atunci când IP — ul serverului Graylog se schimbă-și acest lucru se poate întâmpla rapid folosind implementări de containere.

Docker nu acceptă mai multe drivere de jurnal

ar fi frumos să aveți jurnale stocate local pe server și posibilitatea de a le expedia pe servere la distanță. În prezent, Docker nu acceptă mai multe drivere de jurnal, astfel încât utilizatorii sunt obligați să aleagă un singur driver de jurnal. Nu este o decizie ușoară cunoașterea diferitelor probleme enumerate în acest post.

asta e! Acestea sunt Top 10 Docker Logging Gotchas!

vezi și: livrare continuă cu Jenkins & Docker Security: avantajele, dezavantajele și o actualizare de stare

alternative la driverele de jurnal Docker

cu atât de multe probleme legate de driverele de jurnal Docker, există alternative? Se pare că există-Docker API pe bază de expeditori jurnal la salvare!pentru salvare.

iată câteva motive bune pentru a analiza astfel de alternative:

  1. driverul Json-file este implicit și fiabil, o copie locală a jurnalelor este întotdeauna disponibilă, iar API-ul docker logs și Docker solicită jurnalele doar să funcționeze.
  2. abilitatea de a filtra jurnalele după diverse criterii dinamice, cum ar fi numele imaginii sau etichetele
  3. metadate mai bune, având acces complet la Docker API
  4. nici un risc de crashing Docker Daemon, deoarece astfel de expeditori jurnal ar putea rula într-un container cu utilizarea resurselor limitate și consumul de spațiu pe disc (de ex. puneți directorul tampon într-un volum și setați limite utile)

să ne uităm la două instrumente recomandate de colectare a jurnalelor bazate pe API Docker: Logspout și Sematext Docker Agent. Ambele sunt open source.

vă rugăm să rețineți că un al treilea instrument, care se potrivește mai mult sau mai puțin în această categorie este Elastic Filebeat. Filebeat colectează fișierele jurnal de la, generate de driverul jurnal json-fișier numai îmbogățirea pentru metadate container se face prin intermediul apelurilor Docker API.

Logspout oferă mai multe ieșiri și poate ruta jurnalele de la containere diferite la destinații diferite, fără a modifica setările de logare container cerere. Se ocupă de secvențe de evacuare ANSI (cum ar fi codurile de culoare în jurnalele), care ar putea fi problematică pentru căutare full-text în Elasticsearch.

la fel ca Logspout, Sematext Docker Agent (SDA) este bazat pe API, acceptă rutarea jurnalului și gestionează secvențele ANSI Escape pentru căutarea cu text complet. Cu toate acestea, Sematext Docker Agent este de fapt mai mult decât un simplu expeditor de jurnal.

SDA are grijă de multe probleme ridicate de utilizatorii Docker, cum ar fi jurnalele multi-line, detectarea formatului jurnalului și analiza jurnalului, containerele complete de îmbogățire a metadatelor (etichete, geoip, Swarm și Kubernetes metadate specifice), tamponarea discului și transportul fiabil prin TLS. Este open source pe Github, poate fi utilizat cu stiva elastică sau norul Sematext și poate colecta nu doar jurnalele de containere, ci și evenimentele de containere, plus valorile Docker host și container.

diferențele dintre trei soluții de logare care funcționează bine cu driverul JSON-file și Docker Remote API

recomandare

recomandarea clară pentru loggerele bazate pe API s-ar putea schimba în viitor, pe măsură ce driverele de jurnal Docker se îmbunătățesc în timp, iar noul mecanism de plugin prin socket Unix permite implementarea noilor drivere de logare să ruleze ca procese separate. Această caracteristică îmbunătățește cu adevărat arhitectura pluginului de logare Dockers și este un semn bun că Docker ia în serios problemele de logare.

între timp, luați în considerare colecționarii de jurnale bazate pe API Docker, cum ar fi Sematext Docker Agent și Logspout, pentru a evita problemele cu jurnalele Docker, cum ar fi cele 10 gotchas descrise aici.

Lasă un răspuns

Adresa ta de email nu va fi publicată.