Top 10 Docker protokolování gotchas každý uživatel Docker by měl vědět

jeden z prvních příkazů Uživatelé Docker učit po „docker run“ je „Docker logs“ – ale věděli jste, že příkaz „Docker logs“ nefunguje vždy? To může znít úžasně, ale je to pravda. O důvodech se dozvíme později.

Docker změnil nejen způsob nasazení aplikací, ale také pracovní postup pro správu protokolů. Místo zápisu protokolů do souborů, kontejnery zapisují protokoly do konzoly (stdout/stderr) a ovladače protokolování Docker předávají protokoly na místo určení. Kontrola problémů s Docker Github rychle ukazuje, že uživatelé mají při práci s protokoly Docker různé problémy.

Docker protokolování ovladače přehled

Správa protokolů s Docker se zdá být složité a potřebuje hlubší znalosti o Docker protokolování implementace ovladačů a alternativy k překonání problémů, které lidé hlásí. Takže jaké jsou top 10 Docker protokolování gotchas, každý uživatel Docker by měl vědět?

začněme s přehledem ovladačů protokolování Docker a možností odeslání protokolů do centralizovaných řešení správy protokolů, jako je Elastic Stack (bývalý Elk Stack) nebo Sematext Cloud.

v prvních dnech Docker, protokoly kontejnerů byly k dispozici pouze přes Docker remote API, tj. pomocí příkazu „Docker logs“ a několika pokročilých přepravců protokolu. Později Docker představil ovladače protokolování jako pluginy, otevřít Docker pro integraci s různými nástroji pro správu protokolu. Tyto logovací ovladače jsou implementovány jako binární Pluginy v démonu docker. V poslední době byla architektura pluginů rozšířena tak, aby spouštěla logovací pluginy jako externí procesy, které by se mohly registrovat jako pluginy a načítat protokoly prostřednictvím souborů Linux FIFO. V současné době jsou ovladače protokolování dodávané s binárními soubory docker binárními pluginy, ale to se může v blízké budoucnosti změnit.

ovladače protokolování Docker přijímají protokoly kontejnerů a předávají je vzdáleným cílům nebo souborům. Výchozí ovladač protokolování je „json-file“. Ukládá protokoly kontejnerů ve formátu JSON na místním disku. Docker má architekturu pluginů pro protokolování ovladačů, takže jsou k dispozici pluginy pro nástroje s otevřeným zdrojovým kódem a komerční nástroje:

  • Journald-ukládání protokolů kontejnerů v systémovém deníku
  • Syslog Driver – podpora UDP, TCP, TLS
  • Fluentd-podpora TCP nebo Unix socket připojení k fluentd
  • Splunk-HTTP / HTTPS forwarding na Splunk server
  • Gelf-UDP log forwarding na Graylog2

pro kompletní řešení správy protokolu je třeba zapojit další nástroje:

  • analyzátor logu na logy struktury, typicky součást přepravců logu (fluentd, rsyslog, logstash, logagent, …)
  • indexování, vizualizace a upozornění logu:
    • Elasticsearch a Kibana (Elastic Stack, také známý jako Elk stack),
    • Splunk,
    • Logentries,
    • Loggly,
    • Sumologic,
    • Graylog OSS / Enterprise
    • Sematext Cloud / Enterprise
    • a mnoho dalších …

Chcete-li odeslat protokoly do jednoho z backendů, možná budete muset vybrat ovladač protokolování nebo nástroj pro protokolování, který podporuje vaše řešení správy protokolů. Pokud váš nástroj potřebuje vstup Syslog, můžete zvolit ovladač Syslog.

1.Příkaz Docker logs funguje pouze s ovladačem protokolování souborů json

výchozí ovladač protokolování „json-file“ zapisuje protokoly na místní disk a ovladač json-file je jediný, který pracuje paralelně s příkazem“ Docker logs“. Jakmile jeden používá alternativní ovladače protokolování, jako je Syslog, Gelf nebo Splunk, volání API Docker logs začnou selhat a příkaz „Docker logs“ zobrazí chybu oznamující omezení místo zobrazení protokolů na konzole. Nejen, že příkaz Docker log nezdaří, ale mnoho dalších nástrojů používajících Docker API pro protokoly, jako jsou uživatelská rozhraní Docker, jako je Portainer nebo kontejnery pro sběr protokolů, jako je Logspout, nejsou schopny v této situaci zobrazit protokoly kontejnerů.

viz tento problém.

ovladač Docker Syslog může blokovat nasazení kontejneru a ztratit protokoly, když server Syslog není dosažitelný

použití ovladače Docker Syslog s protokolem TCP nebo TLS je spolehlivým způsobem doručování protokolů. Při spuštění kontejneru však ovladač protokolování Syslog vyžaduje navázané připojení TCP k serveru Syslog. Pokud toto spojení nelze navázat v době zahájení kontejneru, spuštění kontejneru selže s chybovou zprávou jako

docker: Error response from daemon: Failed to initialize logging driver: dial tcp

to znamená, že dočasný problém se sítí nebo vysoká latence sítě může blokovat nasazení kontejnerů. Kromě toho by restart serveru Syslog mohl strhnout všechny kontejnery protokolující přes TCP / TS na centrální server Syslog, což je určitě situace, které je třeba se vyhnout.

viz tento problém.

3. Ovladač Docker syslog ztratí protokoly, když je cíl dole

podobně jako výše uvedený problém způsobuje ztrátu protokolů chybějící schopnost ovladačů protokolování Docker ukládat protokoly na disk, když nemohou být doručeny do vzdálených destinací. Zde je zajímavý problém sledovat.

4. Ovladače protokolování Docker nepodporují víceřádkové protokoly, jako jsou stopy chybového zásobníku

když mluvíme o protokolech, většina lidí si myslí o jednoduchých jednořádkových protokolech, například o protokolech Nginx nebo Apache. Protokoly však mohou také zahrnovat více řádků. Například stopy výjimek obvykle pokrývají více řádků, takže pro pomoc uživatelům Logstash jsme sdíleli, jak zacházet se stopami zásobníku pomocí Logstash.

věci nejsou o nic lepší ve světě kontejnerů, kde se věci ještě komplikují, protože protokoly ze všech aplikací běžících v kontejnerech se vysílají na stejný výstup-stdout. Není divu, že problém # 22920 uzavřen “ zavřeno. Je mi to jedno.“zklamalo tolik lidí. Naštěstí existují nástroje, jako je Sematext Docker Agent, který dokáže analyzovat víceřádkové protokoly z krabice a také použít vlastní víceřádkové vzory.

Docker service logs příkaz visí s non-json logování řidiče

zatímco ovladač json-files se zdá robustní, ostatní ovladače protokolu by bohužel stále způsobit potíže s Docker roje režimu. Podívejte se na tento problém GitHub.

Docker daemon havaruje, pokud je démon fluentd pryč a vyrovnávací paměť je plná

další scénář, kdy ovladač protokolování způsobuje potíže, když vzdálený cíl není dosažitelný — v tomto konkrétním případě ovladače protokolování vyvolávají výjimky, které způsobují selhání démona Dockeru.

kontejner Docker uvízne ve vytvořeném stavu při selhání ovladače Splunk

pokud server Splunk vrátí 504 při spuštění kontejneru, kontejner je skutečně spuštěn, ale docker hlásí kontejner jako neúspěšný. Jakmile je v tomto stavu, kontejner se již nezobrazuje pod docker ps a proces kontejneru nelze zastavit pomocí Docker kill. Jediný způsob, jak zastavit proces, je ručně zabít.

viz tento problém.

protokoly Docker přeskakování / chybějící protokoly aplikací (ovladač žurnáld)

ukazuje se, že tento problém je způsoben limity rychlosti žurnáld, které je třeba zvýšit, protože Docker vytváří protokoly pro všechny spuštěné aplikace a žurnáld může některé protokoly přeskočit kvůli nastavení omezení rychlosti. Takže buďte si vědomi svého nastavení journald při připojení Docker k němu.

problémy s ovladačem Gelf

ovladač logování Gelf chybí volba TCP nebo TLS a podporuje pouze UDP, což by mohlo být riskantní ztratit zprávy protokolu, Když se pakety UDP dostanou. Některé problémy hlásí problém s rozlišením DNS / ukládání do mezipaměti s ovladači GELF, takže protokoly mohou být odeslány do „Nirvana“, když se změní IP adresa serveru Graylog-a to by se mohlo stát rychle pomocí nasazení kontejnerů.

Docker nepodporuje více ovladačů protokolu

bylo by hezké mít protokoly uložené lokálně na serveru a možnost je odeslat na vzdálené servery. V současné době Docker nepodporuje více ovladačů protokolu, takže uživatelé jsou nuceni vybrat jeden ovladač protokolu. Není to snadné rozhodnutí znát různé problémy uvedené v tomto příspěvku.

to je ono! To jsou moje top 10 Docker protokolování Gotchas!

viz také: nepřetržité doručování s Jenkins & Docker bezpečnost: klady, zápory a aktualizace stavu

alternativy k ovladačům protokolu Docker

s tolika problémy kolem ovladačů protokolu Docker existují alternativy? Ukazuje se, že existují-Docker API založené log odesílatelé na záchranu!na záchranu.

zde je několik dobrých důvodů, proč se podívat na tyto alternativy:

  1. Json-file driver je výchozí a spolehlivý, lokální kopie protokolů je vždy k dispozici, a ‚Docker logs‘ a Docker API volání pro protokoly prostě práce.
  2. Schopnost filtrovat protokoly podle různých dynamických kritérií, jako je název obrázku nebo štítky
  3. lepší metadata, mít plný přístup k rozhraní Docker API
  4. žádné riziko zhroucení démona Dockeru, protože tito odesílatelé protokolů by mohli běžet v kontejneru s omezeným využitím zdrojů a spotřebou místa na disku (např. vložte adresář vyrovnávací paměti do svazku a nastavte užitečné limity)

podívejme se na dva doporučené nástroje pro sběr protokolů založené na rozhraní Docker API: Logspout a Sematext Docker Agent. Oba jsou open source.

Vezměte prosím na vědomí, že třetí nástroj, který se více či méně hodí do této kategorie, je Elastic Filebeat. Filebeat shromažďuje soubory protokolu z, generované ovladačem protokolu json-file pouze obohacení pro metadata kontejneru se provádí pomocí volání Docker API.

Logspout poskytuje více výstupů a může směrovat protokoly z různých kontejnerů do různých destinací bez změny nastavení protokolování aplikačních kontejnerů. Zpracovává únikové sekvence ANSI (jako barevné kódy v protokolech), což by mohlo být problematické pro fulltextové vyhledávání v Elasticsearch.

stejně jako Logspout je Sematext Docker Agent (SDA) založen na API, podporuje směrování protokolů a zpracovává únikové sekvence ANSI pro fulltextové vyhledávání. Sematext Docker Agent je však ve skutečnosti více než jen jednoduchý odesílatel protokolu.

SDA se stará o mnoho problémů vznesených uživateli Docker, jako jsou víceřádkové protokoly, Detekce formátu protokolu a analýza protokolu, kompletní kontejnery pro obohacení metadat (štítky, geoip, Swarm a Kubernetes specifická metadata), ukládání do vyrovnávací paměti disku a spolehlivá přeprava přes TLS. Je to open source na Githubu, může být použit s Elastic Stack nebo Sematext Cloud a může shromažďovat nejen protokoly kontejnerů,ale také události kontejnerů, plus metriky Docker host a container.

rozdíly mezi třemi řešeními protokolování, která dobře fungují s ovladačem json-file a Docker Remote API

doporučení

jasné doporučení pro loggery založené na API se může v budoucnu změnit, protože ovladače protokolu Docker se časem zlepšují a nový mechanismus pluginu přes unix socket umožňuje, aby nové implementace ovladačů protokolování fungovaly jako samostatné procesy. Tato funkce opravdu zlepšuje Dockers protokolování plugin architekturu a je dobrým znamením, že Docker bere problémy protokolování vážně.

mezitím zvažte kolektory protokolů založené na rozhraní Docker API, jako je Sematext Docker Agent a Logspout, abyste se vyhnuli problémům s protokoly Docker, jako je 10 gotchů popsaných zde.

Napsat komentář

Vaše e-mailová adresa nebude zveřejněna.