Top 10 Docker naplózás gotchas minden Docker felhasználónak tudnia kell

az egyik első parancs, amelyet a Docker felhasználók a “docker run” után megtanulnak, a “docker logs” — de tudta, hogy a “docker logs” parancs nem mindig működik? Lehet, hogy csodálatosan hangzik, de igaz. Az okokról később többet megtudunk.

a Docker nem csak az alkalmazások telepítésének módját változtatta meg, hanem a naplózási munkafolyamatot is. Ahelyett, hogy naplókat írnának fájlokba, a tárolók naplókat írnak a konzolra (stdout/stderr), a Docker naplózó illesztőprogramjai pedig a naplókat továbbítják a rendeltetési helyükre. A Docker Github-problémák elleni ellenőrzés gyorsan megmutatja, hogy a felhasználóknak különféle problémái vannak a Docker-naplók kezelésekor.

Docker naplózási illesztőprogramok áttekintése

a naplók kezelése a Dockerrel bonyolultnak tűnik, és mélyebb ismereteket igényel a Docker naplózási illesztőprogramok megvalósításáról és alternatíváiról az emberek által jelentett problémák leküzdéséhez. Tehát mi a top 10 Docker naplózó gotchas, minden Docker felhasználónak tudnia kell?

kezdjük a Docker naplózási illesztőprogramjainak áttekintésével, valamint a naplók központi naplózási megoldásokba történő szállításának lehetőségeivel, mint például az Elastic Stack (korábbi ELK Stack) vagy a Sematext Cloud.

a Docker kezdeti napjaiban a konténernaplók csak a Docker remote API-n keresztül voltak elérhetők, azaz a “docker logs” paranccsal és néhány fejlett naplófájlt feladóval. Később a Docker bevezette a naplózási illesztőprogramokat pluginként, hogy megnyissa a Dockert a különféle naplókezelő eszközökkel történő integrációkhoz. Ezek a naplózási illesztőprogramok bináris bővítményekként vannak megvalósítva a docker démonban. A közelmúltban a plugin architektúrát kiterjesztették a naplózási bővítmények külső folyamatokként történő futtatására, amelyek pluginként regisztrálhatnak és naplókat tölthetnek le Linux FIFO fájlokon keresztül. Jelenleg a Docker bináris fájlokkal szállított naplózási illesztőprogramok bináris bővítmények, de ez a közeljövőben megváltozhat.

a Docker naplózási illesztőprogramjai konténernaplókat fogadnak és távoli célállomásokra vagy fájlokba továbbítják azokat. Az alapértelmezett naplózási illesztőprogram a “json-file”. A tároló naplókat JSON formátumban tárolja a helyi lemezen. A Docker plugin architektúrával rendelkezik az illesztőprogramok naplózásához, így vannak pluginok a nyílt forráskódú eszközökhöz és a kereskedelmi eszközökhöz:

  • Journald – tároló naplók tárolása a rendszernaplóban
  • Syslog illesztőprogram – UDP, TCP, TLS támogatása
  • Fluentd – TCP vagy Unix socket kapcsolatok támogatása fluentd
  • Splunk – HTTP/HTTPS továbbítás Splunk szerverre
  • Gelf – UDP napló továbbítás Graylog2

a teljes naplózási megoldáshoz további eszközöket kell bevonni:

  • Log elemző a struktúra naplók, jellemzően része log feladók (fluentd, rsyslog, logstash, logagent, …)
  • Log indexelés, megjelenítés és riasztás:
    • Elasticsearch és Kibana (rugalmas verem, más néven ELK verem),
    • Splunk,
    • Logentries,
    • Loggly,
    • Sumologic,
    • Graylog OSS / Enterprise
    • sematext Cloud / Enterprise
    • és még sok más …

a hajó naplók egyik backends szükség lehet, hogy válasszon egy naplózási illesztőprogramot vagy naplózási eszköz, amely támogatja a Log Management megoldás a választás. Ha az eszköznek Syslog bemenetre van szüksége, választhatja a Syslog illesztőprogramot.

1.A Docker logs parancs csak a JSON-fájl naplózási illesztőprogrammal működik

az alapértelmezett naplózási illesztőprogram “json-file” naplókat ír a helyi lemezre, és a json-fájl illesztőprogram az egyetlen, amely párhuzamosan működik a “docker logs” paranccsal. Amint alternatív naplózási illesztőprogramokat használ, mint például a Syslog, a Gelf vagy a Splunk, a Docker logs API-hívások meghibásodnak, a “docker logs” parancs pedig hibát jelenít meg a korlátozásokról, ahelyett, hogy a naplókat megjelenítené a konzolon. Nem csak a docker log parancs sikertelen, de sok más eszköz, amely a Docker API-t használja a naplókhoz, például a Docker felhasználói felületei, például a Portainer vagy a naplógyűjtő tárolók, például a Logspout, nem képesek megjeleníteni a konténernaplókat ebben a helyzetben.

lásd ezt a számot.

a Docker Syslog illesztőprogram képes blokkolni a konténerek telepítését és naplókat veszíteni, ha a Syslog szerver nem érhető el

a Docker Syslog illesztőprogram használata TCP-vel vagy TLS-sel megbízható módja a naplók kézbesítésének. A Syslog naplózási illesztőprogramnak azonban létre kell hoznia egy TCP kapcsolatot a Syslog kiszolgálóval, amikor egy tároló elindul. Ha ez a kapcsolat nem hozható létre a tároló indításakor, a tároló indítása sikertelen hibaüzenettel, például

docker: Error response from daemon: Failed to inicialize logging driver: dial TCP

ez azt jelenti, hogy egy ideiglenes hálózati probléma vagy a magas hálózati késleltetés blokkolhatja a tárolók telepítését. Ezenkívül a Syslog szerver újraindítása lebonthatja az összes TCP/TS-en keresztül naplózó tárolót egy központi Syslog szerverre, amelyet mindenképpen el kell kerülni.

lásd ezt a számot.

3. A Docker syslog illesztőprogram elveszíti a naplókat, ha a cél nem működik

a fenti problémához hasonlóan a naplók elvesztését okozza a Docker naplózó illesztőprogramok hiányzó képessége a naplók pufferelésére a lemezen, amikor azokat nem lehet távoli célállomásokra szállítani. Itt van egy érdekes kérdés, amelyet meg kell nézni.

4. A Docker naplózási illesztőprogramjai nem támogatják a többsoros naplókat, mint például a error stack traces

amikor naplókról beszélünk, a legtöbb ember egyszerű egysoros naplókra gondol, mondjuk nginx vagy Apache naplók. A naplók azonban több sorra is kiterjedhetnek. Például a kivételnyomok általában több sort ölelnek fel, így a Logstash felhasználók segítése érdekében megosztottuk, hogyan kell kezelni a veremnyomokat a Logstash segítségével.

a dolgok nem jobbak a konténerek világában, ahol a dolgok még bonyolultabbá válnak, mert a konténerekben futó összes alkalmazás naplóit ugyanarra a kimenetre bocsátják ki – stdout. Nem csoda, hogy a 22920-as számot a ” zárva. Nem érdekel.”csalódott olyan sok ember. Szerencsére vannak olyan eszközök, mint a Sematext Docker Agent, amelyek elemezhetik a többsoros naplókat a dobozból, valamint alkalmazhatnak egyedi többsoros mintákat.

a Docker service logs parancs nem json naplózási illesztőprogrammal lóg

míg a json-files illesztőprogram robusztusnak tűnik, más naplózási illesztőprogramok sajnos továbbra is problémákat okozhatnak a Docker Swarm módban. Lásd ezt a GitHub kérdést.

a Docker démon összeomlik, ha a fluentd démon eltűnt, és a puffer megtelt

egy másik eset, amikor a naplózási illesztőprogram problémát okoz, ha a távoli cél nem érhető el — ebben az esetben a naplózási illesztőprogramok kivételeket dobnak, amelyek a Docker démon összeomlását okozzák.

Docker konténer elakad létrehozott állapotban Splunk driver failure

ha a Splunk kiszolgáló 504-es értéket ad vissza a konténer indításakor, akkor a konténer valóban elindul, de a docker jelentése szerint a konténer nem indult el. Ebben az állapotban a tároló már nem jelenik meg a docker ps alatt, és a tároló folyamatát nem lehet leállítani a docker kill segítségével. A folyamat leállításának egyetlen módja az, ha manuálisan megöli.

lásd ezt a számot.

Docker naplók alkalmazásnaplók kihagyása/hiánya (journald illesztőprogram)

kiderült, hogy a problémát a journald sebességkorlátozások okozzák, amelyeket növelni kell, mivel a Docker naplókat hoz létre az összes futó alkalmazáshoz, és a journald a sebességkorlátozási beállítások miatt kihagyhat néhány naplót. Tehát legyen tisztában a naplóbeállításokkal, amikor csatlakoztatja a Dockert hozzá.

gelf driver issues

a gelf naplózási illesztőprogramjából hiányzik egy TCP vagy TLS opció, és csak az UDP-t támogatja, ami kockázatos lehet a naplózási üzenetek elvesztéséhez, amikor az UDP-csomagokat eldobják. Néhány probléma a DNS-felbontás/gyorsítótár problémájáról számol be a GELF illesztőprogramokkal, így a naplók elküldhetők a “Nirvana” — ba, amikor a Graylog szerver IP-címe megváltozik-és ez gyorsan megtörténhet a konténer telepítések használatával.

a Docker nem támogat több log illesztőprogramot

jó lenne, ha a naplókat helyben tárolnák a szerveren, és lehetőség lenne távoli szerverekre szállítani. Jelenleg a Docker nem támogat több naplómeghajtót, így a felhasználók kénytelenek egyetlen naplómeghajtót választani. Nem könnyű döntés az ebben a bejegyzésben felsorolt különféle kérdések ismeretében.

ez az! Ezek az én top 10 Dokkoló naplózó Gotchas!

Lásd még: folyamatos szállítás Jenkins-szel & Docker biztonság: előnyök, hátrányok és Állapotfrissítés

a Docker Log illesztőprogramok alternatívái

a Docker Log illesztőprogramok körüli sok probléma miatt vannak alternatívák? Kiderült, hogy vannak-Docker API alapú naplószállítók a mentéshez!a megmentésre.

Íme néhány jó ok, hogy nézd meg az ilyen alternatívák:

  1. a Json-fájlmeghajtó az alapértelmezett és megbízható, a naplók helyi példánya mindig elérhető, és a ‘docker naplók’ és a Docker API naplók csak működnek.
  2. képes szűrni naplók különböző dinamikus kritériumok, mint a kép neve vagy címkék
  3. jobb metaadatok, miután teljes hozzáférést Docker API
  4. nincs veszélye összeomlik Docker démon, mert az ilyen napló feladók futhatnak egy konténer korlátozott erőforrás-felhasználás és lemezterület-fogyasztás (pl. a buffer könyvtár egy kötetbe helyezése és hasznos korlátok beállítása)

nézzünk meg két ajánlott Docker API alapú naplógyűjtő eszközt: Logspout és Sematext Docker Agent. Mindkettő nyílt forráskódú.

kérjük, vegye figyelembe, hogy egy harmadik eszköz, amely többé-kevésbé illeszkedik ebbe a kategóriába, az Elastic Filebeat. Filebeat gyűjt log fájlokat, által generált json-file log driver csak a dúsítás konténer metaadatok keresztül történik Docker API hívásokat.

a Logspout több kimenetet biztosít, és az alkalmazástároló naplózási beállításainak módosítása nélkül képes a naplókat különböző tárolókból különböző célállomásokra irányítani. Kezeli az ANSI menekülési szekvenciákat (például a naplók színkódjait), ami problémás lehet az Elasticsearch teljes szöveges keresésekor.

a Logspouthoz hasonlóan a Sematext Docker Agent (SDA) API alapú, támogatja a naplózást és kezeli az ANSI Escape szekvenciákat a teljes szöveges kereséshez. Azonban Sematext Docker Agent valójában több, mint egy egyszerű napló feladó.

az SDA gondoskodik a Docker felhasználók által felvetett számos kérdésről, mint például a többsoros naplók, a naplóformátum-felismerés és a naplóelemzés, a teljes metaadat-gazdagító tárolók (címkék, geoip, Swarm és Kubernetes specifikus metaadatok), a lemezpufferelés és a megbízható szállítás a TLS-en keresztül. Nyílt forráskódú a Githubon, használható az Elastic Stack vagy a Sematext felhővel, és nemcsak konténernaplókat, hanem konténer eseményeket, valamint Docker host és konténer metrikákat is gyűjthet.

a JSON-file driverrel és a Docker Remote API-val jól működő három naplózási megoldás közötti különbségek

ajánlás

az API – alapú naplózókra vonatkozó egyértelmű ajánlás a jövőben megváltozhat, mivel a Docker log illesztőprogramok idővel javulnak, és az Unix socket-en keresztüli új plugin mechanizmus lehetővé teszi az új naplózási illesztőprogram-implementációk külön folyamatként történő futtatását. Ez a funkció valóban javítja a Dockers naplózási plugin architektúráját, és jó jele annak, hogy a Docker komolyan veszi a naplózási problémákat.

addig is fontolja meg a Docker API alapú naplógyűjtőket, mint például a Sematext Docker Agent és a Logspout, hogy elkerülje a Docker naplókkal kapcsolatos problémákat, mint például az itt leírt 10 Gotcha.

Vélemény, hozzászólás?

Az e-mail-címet nem tesszük közzé.