Pozrime sa na základy prihlasovania v Docker a Kubernetes a potom zvážime dva nástroje, ktoré možno bezpečne použiť vo výrobe: Grafana Loki a EFK stack (Elasticsearch + Fluent Bit + Kibana).
Materiál článku je stlačený z . Ak máte túžbu a ešte viac výrobnú potrebu, môžete absolvovať úplné školenie - prihláste sa na kurz .
Prihlásenie do Dockera
Na úrovni Kubernetes sa aplikácie spúšťajú v podoch, ale na nižšej úrovni stále zvyčajne bežia v Dockeri. Preto je potrebné nakonfigurovať protokolovanie takým spôsobom, aby sa protokoly zbierali z kontajnerov. Kontajnery spúšťa Docker, čo znamená, že musíte pochopiť, ako funguje protokolovanie na úrovni Docker.
Dúfam, že každý čitateľ vie: denníky aplikácií by sa mali zapisovať do stdout/stderr, a nie do kontajnera. Protokoly agreguje Docker Daemon a funguje presne s tými protokolmi, ktoré sa odosielajú na stdout/stderr. Okrem toho zapisovanie protokolov do kontajnera je plné problémov: kontajner sa zväčšuje z rastúceho protokolu (pretože v kontajneri s najväčšou pravdepodobnosťou nie je žiadny Logrotate) a Docker Daemon o tomto protokole nevie.
Docker má niekoľko ovládačov denníkov alebo doplnkov na zhromažďovanie denníkov kontajnerov. Bezplatná edícia Docker Community Edition (CE) má menej ovládačov protokolov ako komerčná edícia Docker Enterprise Edition (EE).
Docker EE som v praxi nikdy nepoužil: v Southbridge sa snažíme držať Open Source riešení a klienti väčšinu doplnkových funkcií Docker EE nepotrebujú.
Zaznamenať ovládače v Docker CE:
miestne — zapisovanie protokolov do interných súborov Docker Daemon;
json-súbor — vytvorenie json-log v priečinku každého kontajnera;
denník — odosielanie protokolov do journald.
Nastavenia protokolovania Docker sa nachádzajú v súbore daemon.json.
Pole „log-driver“ označuje doplnok a pole „log-opts“ označuje jeho nastavenia. Vo vyššie uvedenom príklade je špecifikovaný doplnok „json-file“, limit veľkosti protokolu je „max-size“: „10m“; obmedzenie počtu súborov (nastavenia rotácie) - „max-file“: „3“; ako aj hodnoty, ktoré budú pripojené k protokolom.
Niektoré nastavenia ovládača denníka je možné nastaviť pomocou príkazového nástroja. Je to výhodné, ak je potrebné spustiť samostatný kontajner s iným ovládačom denníka.
Takto vyzerá schéma protokolovania v Dockeri:
Ako schéma funguje: ovládač protokolu, ako napríklad json-file, vytvára súbory. Zberače denníkov (Rsyslog, Fluentd, Logagent a iné) zhromažďujú tieto súbory a prenášajú ich na uloženie do Elastic, Sematext alebo iných úložných zariadení.
Funkcie prihlasovania v Kubernetes
Zjednodušená schéma protokolovania v Kubernetes vyzerá takto: je tam pod, v ňom beží kontajner, kontajner posiela protokoly na stdout/stderr. Docker potom vytvorí súbor a zapíše protokoly, ktoré potom môže otáčať.
Pozrime sa na funkcie prihlasovania v Kubernetes.
Uložte protokoly medzi nasadeniami. Toto je predpoklad pre správne nastavenie protokolovania. Ak medzi nasadeniami neuložíte protokoly, po vydaní novej verzie aplikácie sa protokoly predchádzajúcej aplikácie prepíšu a reštart kontajnera bude tiež spojený so stratou protokolov. Kubernetes má —predchádzajúci kľúč, ktorý vám umožňuje prezerať denníky aplikácií až do posledného reštartu modulu, ale nie hlbšie.
Súhrnné protokoly zo všetkých inštancií. Ak sú mikroslužby hosťované v cloude, za monitorovanie systému je zodpovedný poskytovateľ cloudu. Ak sú mikroslužby na vašom vlastnom hardvéri, musíte okrem protokolov z kontajnerov zbierať aj systémové protokoly.
Predtým neexistovali žiadne pohodlné nástroje na zhromažďovanie protokolov zo systému aj mikroslužieb. Jeden nástroj zvyčajne zbiera systémové protokoly (napríklad Rsyslog), druhý protokoly z Dockera (napríklad journal-bit s ovládačom protokolu Docker nakonfigurovaným na journald). Skúsili sme použiť journal-bit na zhromažďovanie protokolov z kontajnerov (v ovládači protokolu Docker špecifikujte, že musíte zapisovať protokoly do journald) aj zo systému (CentOS 7 už má systemd a journald). Riešenie funguje, ale nie ideálne. Ak existuje veľa protokolov, žurnálový bit začne meškať a správy sa stratia.
Experimenty pokračovali – a našiel sa iný spôsob. V CentOS 7 sú hlavné systémové protokoly (správy, audit, zabezpečenie) duplikované v protokole var vo forme súborov. V Dockeri môžete tiež nakonfigurovať ukladanie protokolov do súborov json. V súlade s tým je možné tieto súbory z CentOS 7 a Docker zhromažďovať spolu.
Postupom času sa riešenie ELK Stack stalo populárnym. Ide o kombináciu niekoľkých nástrojov: Elasticsearch, Logstash a Kibana.
Elasticsearch ukladá protokoly z kontajnerov, Logstash zbiera protokoly z inštancií, Kibana vám umožňuje spracovávať prijaté protokoly a vytvárať na nich grafy. ELK Stack sa už nejaký čas vo veľkej miere používa, ale podľa mňa jeho čas plynie. Neskôr ti poviem prečo.
Pridajte metadáta. Pody, aplikácie, kontajnery je možné spustiť kdekoľvek. Jedna aplikácia môže mať navyše niekoľko inštancií. Protokoly sú napísané v rovnakom formáte, ale musíme pochopiť, o akú repliku ide, ktorý Pod ju zapisuje a v ktorom mennom priestore sa nachádza. Preto je potrebné do denníkov pridať metadáta.
Analyzujte denníky. Je to smiešne, ale náklady na údržbu logovacieho a monitorovacieho systému môžu prevýšiť náklady na hlavnú aplikáciu. Keď vám lietajú desiatky a stovky tisíc kmeňov za sekundu, zdá sa to prirodzené, ale stále potrebujete poznať čiaru. Jedným zo spôsobov, ako nájsť tento riadok, je analýza protokolov.
Spravidla nie je potrebné zhromažďovať a ukladať všetky protokoly, na uloženie by sa mala odoslať iba časť - napríklad protokoly so stavom „varovanie“ alebo „chyba“. Ak hovoríme o protokoloch nginx alebo ingress controllers, potom môžete poslať do úložiska iba tie, ktorých stav sa líši od 200. Toto však nie je univerzálna rada: ak nejakým spôsobom vytvoríte analytiku na protokoloch Nginx, potom sa samozrejme oplatí ich zbierať. .
Neodporúča sa bezhlavo filtrovať protokoly, pretože filtrované údaje nemusia stačiť na bežnú analýzu. Na druhej strane, analytika by sa možno mala vykonávať nie na úrovni protokolovania, ale na úrovni zberu metrík. Potom nebudete musieť ukladať státisíce riadkov s kódom 200. Jedným z prístupov je získať informácie o prevádzke a chybách z metrík kontroléra vstupu.
Vo všeobecnosti si tu musíte dobre premyslieť: čo chcete skladovať a ako dlho, pretože inak nastane situácia, keď logovací systém zaberie viac zdrojov ako hlavný projekt.
Zatiaľ neexistuje štandardné riešenie pre ťažbu dreva. Na rozdiel od monitorovania, kde existuje jedno najbežnejšie riešenie Prometheus, neexistuje žiadny štandard v protokolovaní.
V tejto prednáške sa pozrieme na dva nástroje: jeden populárny a druhý, ktorý si získava na popularite. Okrem nich existujú aj ďalšie, ale tých sa v tomto článku nebudeme dotýkať.
Berúc do úvahy všetky funkcie diskutované vyššie, prihlasovanie do Kubernetes môže byť teraz znázornené v nasledujúcom diagrame:
Protokol kontajnera a rotácia zostanú, ale objaví sa agent zberu, ktorý vyberie protokoly a odošle ich na uloženie (v diagrame - do Logging Backend). Agent beží na každom uzle a zvyčajne sa spúšťa na Kubernetes.
Teraz sa pozrime na protokolovacie nástroje.
Grafana Loki
sa objavil nedávno, ale už sa stal celkom známym. Jeho výhody: jednoduchá inštalácia, spotrebováva málo zdrojov, nevyžaduje inštaláciu Elasticsearch, pretože ukladá dáta do TSDB (databáza časových radov). V predchádzajúcom článku som písal, že Prometheus ukladá dáta do takejto databázy a je to jedna z mnohých podobností medzi týmito dvoma produktmi. Vývojári dokonca tvrdia, že Loki je „Prometheus pre svet ťažby dreva“.
Krátka odbočka o TSDB pre tých, ktorí ju nečítali : TSDB je skvelý na ukladanie veľkého množstva údajov časových radov, ale nie je určený na dlhodobé ukladanie. Ak z nejakého dôvodu potrebujete uchovávať protokoly dlhšie ako dva týždne, je lepšie nakonfigurovať ich prenos do inej databázy.
Ďalšou výhodou Loki je, že Grafana sa používa na vizualizáciu dát. Je to veľmi pohodlné: v Grafane sa pozeráme na monitorovacie údaje a po pripojení Lokiho sa pozeráme na protokoly. Pomocou protokolov môžete vytvárať grafy.
Architektúra Loki vyzerá asi takto:
Pomocou DaemonSet je agent – Promtail alebo Fluent Bit – nasadený na všetky servery v klastri. Agent zbiera protokoly. Loki ich vezme a uloží do svojej TSDB. Metadáta sa okamžite pridajú do protokolov, čo je praktické: môžete filtrovať podľa modulov, menných priestorov, názvov kontajnerov a dokonca aj štítkov.
Loki beží na známom rozhraní Grafana. Loki má dokonca svoj vlastný dopytovací jazyk, volá sa LogQL – podobný názvom a syntaxou ako PromQL v Prometheus. Lokiho rozhranie má výzvy na otázky, takže ich nemusíte poznať naspamäť.
Loki v rozhraní Grafana
Pomocou filtrov môžete nájsť kódy v Loki („400“, „404“ a akékoľvek iné); zobraziť protokoly z celého uzla; filtrovať všetky protokoly, ktoré obsahujú slovo „chyba“. Ak kliknete na denník, otvorí sa karta so všetkými informáciami o udalosti.
Loki má dostatok nástrojov, ktoré vám umožnia vytiahnuť potrebné polená, aj keď úprimne povedané, technicky by ich mohlo byť viac. Teraz sa Loki aktívne rozvíja a získava na popularite.
Elastické + Fluent Bit + Kibana (EFK Stack)
EFK stack je klasickejší, ale nemenej populárny nástroj na zaznamenávanie.
Na začiatku článku bol spomenutý ELK (Elasticsearch + Logstash + Kibana), tento stack je však zastaraný kvôli málo produktívnemu a zároveň na zdroje náročnému Logstash. Namiesto toho začali používať ľahší a produktívnejší Fluentd a po nejakom čase mu prišli na pomoc — ešte ľahší a ešte produktívnejší zberný prostriedok.
Podľa vývojárov je Fluent Bit vo výkone viac ako 100-krát lepší ako Fluentd: „kde Fluentd spotrebuje 20 MB RAM, Fluent Bit spotrebuje 150 KB“ – priama citácia z dokumentácie. Pri pohľade na to sa Fluent Bit začal používať častejšie.
Fluent Bit má menej funkcií ako Fluentd, ale pokrýva základné potreby, takže väčšinou používame Fluent Bit.
Schéma fungovania EFK stacku: agent zbiera logy zo všetkých podov (spravidla ide o DaemonSet bežiaci na všetkých serveroch v klastri) a posiela ich do úložiska (Elasticsearch, PostgreSQL alebo Kafka). Kibana sa pripojí k úložisku a získa odtiaľ všetky potrebné informácie.
poskytuje informácie vo vhodnom webovom rozhraní. K dispozícii sú grafy, filtre a mnoho ďalšieho.
Pomocou denníkov môžete vytvárať celé informačné panely.
Plynulé vlastnosti bitov
Keďže o Fluent Bit je vo všeobecnosti menej počuť ako o Logstash, pozrime sa naň bližšie. Fluent Bit je možné logicky rozdeliť na 6 modulov, pričom niektoré moduly môžu obsahovať pluginy, ktoré rozširujú možnosti Fluent Bit.
Vstupný modul zhromažďuje protokoly zo súborov, služieb systemd a dokonca aj z tcp-socket (stačí zadať koncový bod a Fluent Bit tam začne chodiť). Tieto možnosti sú dostatočné na zhromažďovanie protokolov zo systému aj kontajnerov.
Pri výrobe najčastejšie používame pluginy (dá sa nastaviť proti priečinku s protokolmi) a (môžete mu povedať, z ktorých služieb má zbierať protokoly).
Modul analyzátora prináša protokoly do všeobecnej podoby. V predvolenom nastavení sú protokoly Nginx reťazce. Pomocou doplnku je možné tento reťazec previesť na JSON: nastavte polia a ich hodnoty. S JSON sa pracuje oveľa jednoduchšie ako s protokolom reťazcov, pretože existujú flexibilnejšie možnosti triedenia.
Modul filtra. Na tejto úrovni sa odfiltrujú nepotrebné protokoly. Napríklad protokoly iba s hodnotou „varovanie“ alebo s určitými štítkami sa odosielajú na uloženie. Vybrané protokoly idú do vyrovnávacej pamäte.
Modul vyrovnávacej pamäte. Fluent Bit má dva typy vyrovnávacej pamäte: vyrovnávaciu pamäť a vyrovnávaciu pamäť disku. Buffer je dočasné úložisko protokolov, ktoré je potrebné v prípade chýb alebo zlyhaní. Každý chce šetriť na RAM, preto si väčšinou vyberie diskovú vyrovnávaciu pamäť. Musíte však vziať do úvahy, že pred prechodom na disk sa protokoly stále sťahujú do pamäte.
Smerovací/Výstupný modul obsahuje pravidlá a adresy na odosielanie protokolov. Ako už bolo spomenuté, logy je možné posielať do Elasticsearch, PostgreSQL alebo napríklad Kafka.
Zaujímavé je, že protokoly z Fluent Bit možno posielať do Fluentd. Keďže prvý z nich je ľahší a menej funkčný, môžete prostredníctvom neho zbierať protokoly a posielať ich do Fluentd a tam ich pomocou ďalších doplnkov možno ďalej spracovávať a odosielať do repozitárov.
Ak plánujete použiť Elasticsearch...
Na záver dva tipy pre tých, ktorí plánujú používať Elasticsearch ako úložisko guľatiny vo výrobe.
- Nastavte upozornenia pomocou . Tento program izoluje dôležité správy od všeobecného toku protokolov a upozorňuje na ne prostredníctvom pošty alebo iného kanála. Pravda, vyšlo to nie tak dávno .
- Otočte protokoly pomocou aplikácie alebo volania rozhrania Elasticsearch API. Samotný Elastic v zásade teraz podniká významné kroky na riadenie životnosti indexov bez použitia nástrojov tretích strán. Vo všeobecnosti nemá zmysel uchovávať protokoly na dlhú dobu: je nepravdepodobné, že po dvoch týždňoch bude potrebný akýkoľvek protokol – ak je skutočne kritický, určite bude spracovaný do dvoch týždňov. V krajnom prípade je možné staré protokoly archivovať a poslať niekam na dlhodobé uskladnenie. Počul som o špeciálnych protokoloch, ktoré sú zo zákona povinné skladovať až 5 rokov. Osobne som sa s tým nestretol, ale takéto informácie by som nestotožňoval s bežnými protokolmi a možno ich ukladal aj samostatne.
Ak sa chcete pokračovať ...
Autor: Marcel Ibraev, certifikovaný správca Kubernetes, praktický inžinier v spoločnosti , rečník a vývojár kurzov .
Zdroj: hab.com
