Do tĂ« shqyrtojmĂ« bazat e logimit nĂ« Docker dhe Kubernetes, dhe pastaj do tĂ« shqyrtojmĂ« dy instrumente qĂ« mund tâi pĂ«rdorim me besim nĂ« prodhim: Grafana Loki dhe staku EFK (Elasticsearch + Fluent Bit + Kibana).
Materiali i artikullit Ă«shtĂ« njĂ« pĂ«rmbledhje nga . NĂ«se keni dĂ«shirĂ« dhe veçanĂ«risht nevojĂ« prodhuese, mund tĂ« kaloni njĂ« trajnim tĂ« plotĂ« â regjistrohuni pĂ«r kursin mbi .
Logimi në Docker
NĂ« nivelin Kubernetes, aplikacionet kryhen nĂ« kontejnerĂ«, por nĂ« nivelin mĂ« tĂ« ulĂ«t ato zakonisht funksionojnĂ« nĂ« Docker. Prandaj, duhet tĂ« konfigurojmĂ« logimin nĂ« mĂ«nyrĂ« qĂ« tĂ« mbledhim loget nga kontejnerĂ«t. KontejnerĂ«t nisen nga Docker â kĂ«shtu qĂ« duhet tĂ« kuptojmĂ« se si funksionon logimi nĂ« nivelin Docker.
Shpresoj që çdo lexues ta dijë: loget e aplikacioneve duhet të shkruhen në stdout/stderr, dhe jo brenda kontejnerit. Loget mblidhen nga Docker Daemon, dhe ai punon saktësisht me ato loge që dërgohen në stdout/stderr. Për më tepër, regjistrimi i logeve brenda kontejnerit sjell probleme: kontejneri fryhet nga rritja e logut (sepse zakonisht nuk ka Logrotate në kontejner), dhe Docker Daemon nuk është në dijeni për këtë log.
Docker ka disa shoferë logu ose plugin për mbledhjen e logeve nga kontejnerët. Në versionin falas Docker Community Edition (CE), ka më pak shoferë logu se në Docker Enterprise Edition (EE) komercial.
Nuk kam përdorur kurrë Docker EE në praktikë: në Southbridge përpiqemi të respektojmë zgjidhjet Open Source, dhe për klientët shumica e mundësive shtesë të Docker EE nuk janë të nevojshme.
Shoferët e logeve në Docker CE:
local â regjistrimi i logeve nĂ« skedarĂ«t e brendshĂ«m tĂ« Docker Daemon;
json-file â krijimi i json-log nĂ« dosjen e çdo kontejneri;
journald â dĂ«rgimi i logeve nĂ« journald.
Caktimet e logimit në Docker ndodhen në skedarin daemon.json.
NĂ« fushĂ«n âlog-driverâ tregohet plugin, dhe nĂ« fushĂ«n âlog-optsâ janĂ« parametrat e tij. NĂ« shembullin mĂ« sipĂ«r, Ă«shtĂ« tregohet plugin âjson-fileâ, kufizimi i madhĂ«sisĂ« sĂ« logut Ă«shtĂ« âmax-sizeâ: â10mâ; kufizimi i numrit tĂ« skedarĂ«ve (caktimet e rotacionit) Ă«shtĂ« âmax-fileâ: â3â; si dhe vlerat qĂ« do tĂ« lidhen me loget.
Disa caktime të shoferit të logut mund të përcaktohen përmes utilitarit komandor. Kjo është e përshtatshme, nëse një kontejner i veçantë duhet të fillohet me një shofer logu tjetër.
Ja si duket skema e logimit në Docker:
Si për funksionon skema: një log-driver, si p.sh. json-file, krijon skedarë. Mblodhësit e logve (Rsyslog, Fluentd, Logagent dhe të tjerë) mbledhin këta skedarë dhe i dërgojnë për ruajtje në Elastic, Sematext ose depove të tjera.
Veçoritë e regjistrimit në Kubernetes
Thjeshtësisht, skema e regjistrimit në Kubernetes duket kështu: ka një pod, brenda të cilit është një kontejner, ky kontejner dërgon loget në stdout/stderr. Pastaj Docker krijon një skedar dhe regjistron loget, të cilat mund të rrotullohen më pas.
Le të shqyrtojmë veçoritë e regjistrimit në Kubernetes.
TĂ« ruash loget mes pĂ«rditĂ«simeve. Kjo Ă«shtĂ« njĂ« kusht i domosdoshĂ«m pĂ«r njĂ« konfigurim tĂ« saktĂ« tĂ« regjistrimit. NĂ«se nuk ruhen loget mes pĂ«rditĂ«simeve, atĂ«herĂ« kur del njĂ« version i ri i aplikacionit, loget e mĂ«parshme do tĂ« shuhen, gjithashtu rihapja e kontejnerit do tĂ« sjellĂ« humbjen e logeve. Kubernetes ka njĂ« çelĂ«s âprevious, i cili lejon tĂ« shikosh loget e aplikacionit para rivendosjes sĂ« fundit tĂ« Pod-it, por jo mĂ« thellĂ«.
Të agregosh loget nga të gjitha instancat. Nëse mikroshërbimet strehohen në mjete cloud, atëherë për mbikëqyrjen e sistemit përgjigjet ofruesi i cloud. Nëse mikroshërbimet janë në pajisjet e veta, atëherë përveç logeve nga kontenierët duhet të mblidhen edhe loget e sistemit.
Deri më parë nuk kishte mjete të përshtatshme për mbledhjen e logeve si nga sistemi, ashtu edhe nga mikroshërbimet. Zakonisht një mjet mbante loget e sistemit (p.sh. Rsyslog), dhe një tjetër - loget nga Docker (p.sh. journal-bit me konfigurimin e log-driver-it të Docker për journald). U përpoqëm të përdornim journal-bit - për të mbledhur loget edhe nga kontenierët (në log-driver-in e Docker duhet të spesifikosh se duhet të shkruhen loget në journald), dhe nga sistemi (në CentOS 7 tashmë ka systemd dhe journald). Zgjidhja funksionuese, por jo ideale. Nëse ka shumë loge, journal-bit fillon të ngadalësohet, mesazhet humbasin.
Eksperimentet vazhduan - dhe u gjet një mënyrë tjetër. Në CentOS 7 loget kryesore sistemore (messages, audit, secure) përsëriten në var-log si skedarë. Edhe në Docker mund të konfigurohet ruajtja e logeve në skedarë json. Përkatësisht, këta skedarë nga CentOS 7 dhe Docker mund të mblidhen së bashku.
Me kalimin e kohës zgjidhja ELK Stack u bë e njohur. Kjo është një kombinim i disa veglave: Elasticsearch, Logstash dhe Kibana.
Elasticsearch ruan loget nga kontenierët, Logstash mbledh loget nga instancat, Kibana lejon përpunimin e logeve të marra dhe ndihmon në ndërtimin e grafimeve për to. Për një kohë, ELK Stack u përdor aktivisht, por, sipas mendimit tim, koha e tij po kalon. Më vonë do t'ju tregoj pse.
Shto metadatat. Podet, aplikacionet, kontejnerët mund të ekzekutohen kudo. Më shumë se kaq, një aplikacion mund të ketë disa instanca. Loget e regjistruara janë në një format të vetëm, dhe ne duhet të kuptojmë se cila saktësisht është replicimi, cili Pod e shkruan atë, në cilin namespace ndodhet. Kjo është arsyeja pse logeve u nevojiten metadatë.
Parsing loget. është interesant, por shpenzimet për mbështetje të sistemit të regjistrimit dhe monitorimit mund të tejkalojnë kostot e aplikacionit kryesor. Kur qarkullojnë dhjetëra dhe qindra mijëra loge në sekondë, kjo duket e arsyeshme, por prapëseprapë duhet ta dini kufirin. Një nga mënyrat për ta gjetur këtë kufi është parsing logeve.
Si zakonisht, nuk Ă«shtĂ« e nevojshme tĂ« mblidhni dhe ruani tĂ« gjitha loget, duhet tĂ« dĂ«rgoni pĂ«r ruajtje vetĂ«m njĂ« pjesĂ« â pĂ«r shembull, loget me status 'warning' ose 'error'. NĂ«se flasim pĂ«r loget nginx ose ingress-controller, atĂ«herĂ« mund tĂ« dĂ«rgoni pĂ«r ruajtje vetĂ«m ata qĂ« kanĂ« njĂ« status tĂ« ndryshĂ«m nga 200. Por kjo nuk Ă«shtĂ« njĂ« kĂ«shillĂ« universale: nĂ«se po ndĂ«rtoni ndonjĂ« lloj analize tĂ« logeve tĂ« Nginx, atĂ«herĂ« Ă«shtĂ« e qartĂ« se duhet t'i mbani ato.
Për të filtruar loget pa menduar nuk rekomandohet, sepse të dhënat e filtruar mund të mos mjaftojnë për një analizë të duhur. Nga ana tjetër, ndoshta analitika duhet të kryhet jo në nivelin e regjistrimit, por në nivelin e mbledhjes së metrikave. Atëherë nuk do të duhet të ruani qindra mijëra rreshta me kod 200. Një nga qasjet është të merrni informacion për trafikun dhe gabimet nga metrikat e ingress-controllerëve.
Në përgjithësi, këtu duhet të mendoni mirë: çfarë dëshironi të ruani dhe për sa kohë, sepse në të kundërt do të ketë një situatë ku sistemi i regjistrimit do t'ju marrë më shumë burime se projekti kryesor.
Për momentin nuk ka një zgjidhje standarde për regjistrimin. Ndryshe nga monitorimi, ku ka një zgjidhje më të përhapur si Prometheus, në regjistrim nuk ka standard.
Në kuadër të kësaj leksione ne do të shqyrtojmë dy instrumente: një të njohur dhe një tjetër në rritje popullariteti. Përveç këtyre ka edhe të tjera, por në këtë artikull ne nuk do t'i trajtojmë.
Duke marrë parasysh të gjitha këto karakteristika të diskutuar më lart, regjistrimi në Kubernetes tani mund të paraqitet me këtë skemë:
Mbete logu i kontejnerit, rotacioni, por shfaqet njĂ« agjent-mbledhĂ«s, i cili grumbullon loget dhe i dĂ«rgon pĂ«r ruajtje (nĂ« skemĂ« â nĂ« Logging Backend). Agjenti punon nĂ« çdo nod dhe, si zakonisht, Ă«shtĂ« nisur nĂ« Kubernetes.
Tani të shqyrtojmë mjetet për regjistrimin e logeve.
Grafana Loki
ka dalë së fundmi, por tashmë ka fituar popullaritet. Avantazhet e tij: instalohet lehtë, konsumon pak burime, nuk kërkon instalimin e Elasticsearch, pasi mban të dhënat në TSDB (baza e të dhënave me seri kohore). Në artikullin e kaluar kam shkruar se në një bazë të tillë mban të dhënat Prometheus, dhe kjo është një nga shumë ngjashmëritë midis dy produkteve. Zhvilluesit madje deklarojnë se Loki është "Prometheus për botën e logeve".
Një shpjegim i vogël në lidhje me TSDB për ata që nuk lexuan : TSDB përshtatet shumë mirë me detyrën për të ruajtur një sasi të madhe të dhënash me seri kohore, por nuk është e destinuar për ruajtje të gjatë. Nëse për ndonjë arsye keni nevojë të ruani loget më shumë se dy javë, është më mirë të konfiguroni transmetimin e tyre në një tjetër DB.
Një tjetër avantazh i Loki është se për vizualizimin e të dhënave përdoret Grafana. Shumë e përshtatshme: në Grafana shikojmë të dhënat për monitorimin dhe po aty, duke e lidhur Loki, shohim loget. Nga loget mund të ndërtojmë grafikë.
Arkitektura e Loki duket përafërsisht kështu:
Me ndihmĂ«n e DaemonSet, nĂ« tĂ« gjitha serverat e klasterit shpĂ«rndahet agjenti â Promtail ose Fluent Bit. Agjenti mbledh loget. Loki i merr dhe i ruan nĂ« TSDB. Logeve i shtohen menjĂ«herĂ« tĂ« dhĂ«na shtesĂ«, qĂ« Ă«shtĂ« e pĂ«rshtatshme: mund tĂ« filtrohet sipas Pods, namespaces, emrave tĂ« kontejnerĂ«ve dhe madje edhe etiketave.
Loki punon nĂ« njĂ« ndĂ«rfaqe tĂ« njohur Grafana. Loki ka edhe njĂ« gjuhĂ« tĂ« vet tĂ« pyetjeve, e cila quhet LogQL â emri dhe sintaksa e saj i ngjajnĂ« PromQL nĂ« Prometheus. NĂ« ndĂ«rfaqen e Loki ka sugjerime pĂ«r pyetjet, prandaj nuk Ă«shtĂ« e nevojshme t'i dini ato pĂ«rmendsh.
Loki në ndërfaqen Grafana
Duke përdorur filtre, në Loki mund të gjeni kodet ("400", "404" dhe çdo tjetër); shikoni loget nga i gjithë nodi; filtrojini të gjitha loget që kanë fjalën "error". Nëse klikoni mbi logun, do të shfaqet një kartë me të gjitha informacionet për ngjarjen.
Në Loki ka mjaft mjete që lejojnë nxjerrjen e logeve të nevojshme, megjithatë sinqerisht, teknikisht mund të ishin edhe më shumë. Tani Loki është duke u zhvilluar aktivisht dhe po fiton popullaritet.
Elastic + Fluent Bit + Kibana (EFK Stack)
Staku EFK është një mjet më klasik dhe gjithashtu po aq popullor për regjistrimin e logeve.
NĂ« fillim tĂ« artikullit u pĂ«rmend ELK (Elasticsearch + Logstash + Kibana), por ky stak Ă«shtĂ« vjetruar pĂ«r shkak tĂ« Logstash-it tĂ« pandjeshĂ«m dhe tĂ« pĂ«rdorur shumĂ« burime. NĂ« vend tĂ« tij Ă«shtĂ« pĂ«rdorur njĂ« agent mĂ« i lehtĂ« dhe mĂ« efikas, Fluentd, dhe pas njĂ« kohe i Ă«shtĂ« bashkuar â njĂ« agjent mbledhĂ«s edhe mĂ« i lehtĂ« dhe edhe mĂ« efikas.
NĂ«se i besojmĂ« zhvilluesve, atĂ«herĂ« Fluent Bit Ă«shtĂ« mĂ« shumĂ« se 100 herĂ« mĂ« i shpejtĂ« se Fluentd: «aty ku Fluentd konsumon 20 MB RAM, Fluent Bit do tĂ« konsumojĂ« 150 KB» â njĂ« citim direkt nga dokumentacioni. Duke e marrĂ« parasysh kĂ«tĂ«, Fluent Bit Ă«shtĂ« pĂ«rdorur mĂ« shpesh.
Fluent Bit ka më pak mundësi se Fluentd, por plotëson nevojat kryesore, prandaj ne kryesisht përdorim Fluent Bit.
Skema e funksionimit të stakut EFK: agjenti mbledh log-et nga të gjitha pod-et (zakonisht, ky është një DaemonSet i aktivizuar në të gjitha serverët e klustrit) dhe i dërgon në depo (Elasticsearch, PostgreSQL ose Kafka). Kibana lidhet me depotin dhe nxjerr të gjitha informacionet e nevojshme nga aty.
paraqet informacionin në një ndërfaqe të rehatshme në web. Ka grafikë, filtra dhe shumë gjëra të tjera.
Nga log-et mund të krijohen dashboard-e të plota.
Mundësitë e Fluent Bit
Duke qenë se për Fluent Bit, zakonisht, është dëgjuar më pak se për Logstash, le të e shqyrtojmë atë pak më në detaje. Fluent Bit mund të ndahet logjikisht në 6 module, disa nga të cilat mund të kenë plugin-e që zgjasin mundësitë e Fluent Bit.
Moduli Input mbledh log-et nga skedarët, shërbimet systemd dhe madje edhe nga tcp-socket (duhet vetëm të tregoni endpoint-in, dhe Fluent Bit do të fillojë të shkojë atje). Këto mundësi janë të mjaftueshme për të mbledhur log-et si nga sistemi ashtu edhe nga konteinerët.
NĂ« prodhim, ne zakonisht pĂ«rdorim plugin-et (mund ta drejtoni mbi njĂ« dosje me log-e) dhe (mund tâi thoni se nga cilat shĂ«rbime tĂ« mbledh log-et).
Moduli Parser e bën log-un në një formë të njëjtë. Në mënyrë që log-et Nginx, sipas të dhënave të paracaktuara, përbëjnë një varg. Me ndihmën e plugin-it, ky varg mund të konvertohet në JSON: mund të përcaktoni fushat dhe vlerat e tyre. Duke punuar me JSON është shumë më e lehtë se me log-un me varg, sepse ka mundësi më fleksibile për renditjen.
Moduli Filter. NĂ« kĂ«tĂ« nivel, filtrohen log-et e panevojshme. PĂ«r shembull, pĂ«r tĂ« ruajtur, dĂ«rgohen vetĂ«m log-et qĂ« kanĂ« vlerĂ«n âwarningâ ose me etiketa tĂ« caktuara. Log-et e zgjedhura kalojnĂ« nĂ« buffer.
Moduli Buffer. Fluent Bit ka dy tipo buffer: buferri i memories dhe buferri në disk. Bufferi është një ruajtës temporar i logeve, e nevojshme në rast gabimesh ose defekteve. Të gjithë duan të kursejnë në RAM, prandaj zakonisht zgjidhet bufferi në disk. Mirëpo, duhet të merret parasysh se para se të transferohen në disk, loget sërish shkarkohen në memories.
Moduli Routing/Output përmban rregullat dhe adresat për dërgimin e logeve. Siç u tha më parë, loget mund të dërgohen në Elasticsearch, PostgreSQL ose, për shembull, Kafka.
E interesant është se nga Fluent Bit loget mund të dërgohen në Fluentd. Duke qenë se i pari është më i lehtë dhe më pak funksional, përmes tij mund të mblidhen loget dhe të dërgohen në Fluentd, dhe atje, me ndihmën e plugins shtesë, të përpunohen dhe dërgohen në ruajtje.
NĂ«se planifikoni tĂ« pĂ«rdorni ElasticsearchâŠ
Në fund, dy këshilla për ata që planifikojnë të përdorin Elasticsearch në prodhim si ruajtje logesh.
- Konfiguroni njoftimet me anë të . Ky program nxjerr nga rrjedha e përgjithshme e logeve mesazhe të rëndësishme dhe bën alarme për to në email ose në një kanal tjetër. Megjithatë, jo shumë kohë më parë doli .
- Rrotulloni loget me ndihmën e aplikacionit apo duke iu drejtuar API-t të Elasticsearch. Vetë Elastic, në fakt, tani po bën hapa të rëndësishëm në menaxhimin e jetës së indekseve pa përdorimin e mjeteve të jashtme. Në përgjithësi, nuk ka asnjë kuptim të ruhet loget për një kohë të gjatë: është e vështirë që ndonjë log të nevojitet pas dy javësh - nëse realmente është kritik, brenda dy javësh do të jetë sigurisht përpunuar. Në rastet më të skajshme, loget e vjetra mund të arkivohen dhe dërgohen diku për ruajtje afatgjatë. Kam dëgjuar për loge të veçanta, që sipas ligjit duhet të ruhen deri në 5 vjet. Personalish, nuk kam hasur në këtë, por nuk do ta barazoja këtë informacion me loget e zakonshme, dhe ndoshta do t'i ruaja ato veçmas.
To be continued...
Autor: Marsel Ibraev, administrator i certifikuar Kubernetes, inxhinier praktik në kompaninë , folës dhe zhvillues kursesh .
Burimi: habr.com
