Le të shqyrtojmë bazat e regjistrimit në Docker dhe Kubernetes, dhe pastaj të shqyrtojmë dy mjete që mund t'i përdorim me besim në prodhim: Grafana Loki dhe staku EFK (Elasticsearch + Fluent Bit + Kibana).
Materiali i kĂ«tij artikulli Ă«shtĂ« njĂ« pĂ«rmbledhje nga . NĂ«se ka dĂ«shirĂ«, dhe pĂ«r mĂ« tepĂ«r, njĂ« nevojĂ« prodhuese, mund tĂ« ndiqni njĂ« trajnim tĂ« plotĂ« â regjistrohuni nĂ« kursin pĂ«r .
Regjistrimi në Docker
NĂ« nivelin e Kubernetes, aplikacionet janĂ« tĂ« nisura nĂ« pod-et, por nĂ« nivelin mĂ« tĂ« ulĂ«t, ato funksionojnĂ« zakonisht nĂ« Docker. Prandaj, duhet tĂ« konfigurojmĂ« regjistrimin nĂ« mĂ«nyrĂ« qĂ« tĂ« mbledhim log-e nga kontejnerĂ«t. KontejnerĂ«t nisen nga Docker â kĂ«shtu qĂ« duhet tĂ« kuptojmĂ« si Ă«shtĂ« e organizuar regjistrimi nĂ« nivelin e Docker.
Shpresoj se çdo lexues e di: log-et e aplikacionit duhet të shkruhen në stdout/stderr, dhe jo brenda kontejnerit. Log-et agregohen nga Docker Daemon, dhe ai punon me ato log-e që dërgohen në stdout/stderr. Po ashtu, regjistrimi i log-eve brenda kontejnerit sjell probleme: kontejneri fryhet nga rritja e log-ut (pasi ndoshta nuk ka Logrotate brenda tij), dhe Docker Daemon nuk është i vetëdijshëm për këtë log.
Docker ka disa shoferë log-u ose plugins për mbledhjen e log-eve të kontejnerëve. Në versionin falas të Docker Community Edition (CE) ka më pak shoferë log-u se në Docker Enterprise Edition (EE) komercial.
Nuk e kam përdorur kurrë Docker EE në praktikë: në Southbridge përpiqemi të qëndrojmë te zgjidhjet Open Source, dhe shumica e mundësive shtesë të Docker EE nuk janë të nevojshme për klientët.
Shoferët e log-ut në Docker CE:
local â regjistrimi i log-eve nĂ« skedarĂ«t e brendshĂ«m tĂ« Docker Daemon;
json-file â krijimi i log-eve json nĂ« dosjen e çdo konteneri;
journald â dĂ«rgimi i log-eve nĂ« journald.
Caktimet e logimit në Docker ndodhen në skedarin daemon.json.
NĂ« fushĂ«n âlog-driverâ tregohet plugin-i, dhe nĂ« fushĂ«n âlog-optsâ kjo janĂ« caktimet e tij. NĂ« shembullin e mĂ«sipĂ«rm tregohet plugin-i âjson-fileâ, kufizimi nĂ« madhĂ«sinĂ« e log-ut â âmax-sizeâ: â10mâ; kufizimi nĂ« numrin e skedarĂ«ve (caktimet pĂ«r rotacion) â âmax-fileâ: â3â; si dhe vlerat qĂ« do tĂ« lidhen me log-et.
Disa caktime të shoferit të log-ut mund të caktohen përmes utilitarit komandor. Kjo është e përshtatshme nëse një kontener i veçantë duhet të startohet me një shofer log-u tjetër.
Kështu duket skema e logimit në Docker:
Si sihemi funksionon: drejtpërdrejtësi log, për shembull json-file, krijon skedarë. Mbledhësit e logut (Rsyslog, Fluentd, Logagent dhe të tjerë) i mbledhin këta skedarë dhe i dërgojnë për ruajtje në Elastic, Sematext ose depo të tjera.
Veçoritë e regjistrimit të logeve në Kubernetes
Në mënyrë të thjeshtë, skema e regjistrimit të logeve në Kubernetes duket kështu: ka një pod, në të cilin ekzekutohet një kontejner, kontejneri dërgon loget në stdout/stderr. Më pas, Docker krijon një skedar dhe shkruan loget, të cilat mund të rrotullohen.
Le të shqyrtojmë veçoritë e regjistrimit të logeve në Kubernetes.
TĂ« ruani loget midis publikimeve. Kjo Ă«shtĂ« njĂ« kusht i domosdoshĂ«m pĂ«r konfigurimin e saktĂ« tĂ« regjistrimit tĂ« logeve. NĂ«se loget nuk ruhen midis publikimeve, atĂ«herĂ« gjatĂ« daljes sĂ« njĂ« versioni tĂ« ri tĂ« aplikacionit, loget e mĂ«parshme do tĂ« fshihen, dhe rinovimi i kontejnerit gjithashtu do tĂ« rrezikojĂ« humbjen e logeve. Kubernetes ka njĂ« çelĂ«s âprevious, i cili lejon tĂ« shihni loget e aplikacionit para rinovimit tĂ« fundit tĂ« Pod, por jo mĂ« thellĂ«.
Të agregoni loget nga të gjitha instancat. Nëse mikroshërbimet hostohen në re, atëherë kontrolli i sistemit i nënshtrohet ofruesit të shërbimit të cloud. Nëse mikroshërbimet janë në pajisje të veta, atëherë përveç logeve nga kontejnerët, duhet të mblidhen edhe loget e sistemit.
Më parë nuk kishte mjete të përshtatshme për mbledhjen e log-eve si nga sistemi ashtu edhe nga mikroshërbimet. Zakonisht një mjet mbledh log-et sistemore (p.sh., Rsyslog), kurse një tjetër log-et nga Docker (p.sh., journal-bit me konfigurimin e log-drajverit të Dockerit mbi journald). Provova të përdor journal-bit për të mbledhur log-et edhe nga kontejnerët (në log-drajverin e Dockerit të tregohet që duhet të shkruhen log-e në journald), dhe nga sistemi (në CentOS 7 tashmë ka systemd dhe journald). Zgjidhja funksionon, por nuk është ideale. Nëse ka shumë log-e, journal-bit fillon të vonojë, mesazhet humbasin.
Eksperimentet vazhduan â dhe u gjet njĂ« mĂ«nyrĂ« tjetĂ«r. NĂ« CentOS 7 log-et kryesore sistemore (messages, audit, secure) duplohen nĂ« var-log si skedarĂ«. Edhe nĂ« Docker mund tĂ« konfigurohet ruajtja e log-eve 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 mjeteve: Elasticsearch, Logstash dhe Kibana.
Elasticsearch ruan log-et nga kontejnerët, Logstash mbledh log-et nga instancat, Kibana lejon përpunimin e log-eve të marra, ndërtimin e grafikëve mbi to. Për disa kohë, ELK Stack u përdor aktivisht, por, sipas mendimit tim, koha e tij po kalon. Më vonë do të tregoj pse.
Shto metadata. Pods, aplikacionet, kontejnerët mund të ekzekutohen kudo. Për më tepër, një aplikacion mund të ketë disa instanca. Log-et regjistrohen në një format të caktuar, dhe ne duhet të kuptojmë se cila është saktësisht kjo kopje, cili Pod po e shkruan, në cilin namespace ndodhet. Pikërisht për këtë arsye, log-et duhet të kenë metadata të shtuar.
TĂ« analizosh log-et. ĂshtĂ« e çuditshme, por shpenzimet pĂ«r mbĂ«shtetje tĂ« sistemit tĂ« regjistrimit dhe monitorimit mund tĂ« tejkalojnĂ« kostot pĂ«r aplikacionin kryesor. Kur keni dhjetĂ«ra dhe qindra mijĂ«ra log-e nĂ« sekondĂ«, kjo duket e natyrshme, por megjithatĂ« duhet tĂ« dini kufirin. NjĂ« nga mĂ«nyrat pĂ«r ta gjetur kĂ«tĂ« kufi Ă«shtĂ« analiza e log-eve.
Si zakonisht, nuk Ă«shtĂ« e nevojshme tĂ« mbani dhe ruani tĂ« gjithĂ« log-et, duhet tĂ« dĂ«rgoni pĂ«r ruajtje vetĂ«m njĂ« pjesĂ« â pĂ«r shembull, log-et me statusin 'warning' ose 'error'. NĂ«se flasim pĂ«r log-et e nginx ose kontrollorĂ«ve tĂ« ingress-it, atĂ«herĂ« mund tĂ« dĂ«rgoni pĂ«r ruajtje vetĂ«m ato, statusi i tĂ« cilave Ă«shtĂ« ndryshe nga 200. Por kjo nuk Ă«shtĂ« njĂ« kĂ«shillĂ« universale: nĂ«se jeni duke ndĂ«rtuar ndonjĂ« mĂ«nyrĂ« analitikĂ« mbi log-et e Nginx, atĂ«herĂ« Ă«shtĂ« e qartĂ« se ato duhet tĂ« mblidhen.
Grumbullisht nuk rekomandohet filtrimi i logeve, sepse të dhënat e filtruar mund të mos jenë të mjaftueshme për një analizë normale. Nga ana tjetër, ndoshta analitika duhet të bëhet jo në nivelin e regjistrimit, por në nivelin e mbledhjes së metrikeve. Kështu nuk do të duhet të ruajmë qindram mijëra rreshta me kod 200. Një nga qasjet është të marrim informacion rreth trafikëve dhe gabimeve nga metrikat e kontrollorëve të ingress.
Në përgjithësi, këtu duhet të mendoni mirë: çfarë dëshironi të ruani dhe për sa kohë, sepse ndryshe do të krijohet një situatë kur sistemi i regjistrimit do të marrë më shumë burime se projekti kryesor.
Aktualisht nuk ka një zgjidhje standarde për regjistrimin. Ndryshe nga monitorimi, ku ka një zgjidhje të vetme më të njohur si Prometheus, në regjistrim nuk ka një standard.
NĂ« kuadĂ«r tĂ« kĂ«saj leksioni ne do tĂ« shqyrtojmĂ« dy mjete: njĂ« tĂ« njohur dhe njĂ« tjetĂ«r qĂ« po merr popullaritet. PĂ«rveç kĂ«tyre, ka edhe tĂ« tjera, por nĂ« kĂ«tĂ« artikull nuk do tâi prekim.
Duke marrë parasysh gjithë karakteristikat e përmendura më sipër, regjistrimi në Kubernetes tani mund të paraqitet në këtë skemë:
Mbajtja e log-ut tĂ« kontejnerit, rrotullimi vazhdon, por shfaqet njĂ« agjent-mbledhĂ«s qĂ« merr loget dhe i dĂ«rgon pĂ«r ruajtje (nĂ« skemĂ« â nĂ« Logging Backend). Agjenti punon nĂ« çdo nod dhe, zakonisht, aktivizohet nĂ« Kubernetes.
Tani le të shqyrtojmë mjetet për regjistrimin e logeve.
Grafana Loki
u shfaq kohët e fundit, por tashmë ka fituar njohje të konsiderueshme. Avantazhet e tij janë: instalohet lehtësisht, konsumon pak burime, nuk kërkon instalimin e Elasticsearch, pasi ruan të dhënat në TSDB (baza e të dhënave të serive të kohës). Në artikullin e kaluar kam shkruar se një bazë e tillë ruan të dhënat e Prometheus, dhe kjo është një nga shumë ngjashmëritë mes dy produkteve. Zhvilluesit madje deklarojnë se Loki është "Prometheus-i për botën e logeve."
Një përjashtim i vogël për TSDB për ata që nuk e kanë lexuar : TSDB e menaxhon shkëlqyer ruajtjen e shumicës së të dhënave, të serive të kohës, por nuk është e dizajnuar për ruajtje afatgjatë. Nëse për ndonjë arsye ju nevojitet të ruani loget më gjatë se dy javë, është më mirë të konfiguroni dërgimin e tyre në një DB tjetër.
Një përfitim tjetër i Loki është se për vizualizimin e të dhënave përdoret Grafana. Mjaft e përshtatshme: në Grafana shohim të dhënat për monitorimin dhe gjithashtu, duke lidhur Loki, shohim logët. Nga logët mund të ndërtojmë grafika.
Arkitektura e Loki duket kështu:
Me anĂ« tĂ« DaemonSet nĂ« tĂ« gjithĂ« serverĂ«t e klasterit, zhvillohet njĂ« agjent â Promtail ose Fluent Bit. Agjenti mbledh logĂ«t. Loki i merr dhe i ruan nĂ« TSDB. I gjithĂ« logĂ«ve u shtohen metadatat menjĂ«herĂ«, gjĂ« qĂ« Ă«shtĂ« e pĂ«rshtatshme: mund tĂ« filtrosh sipas Pods, namespaces, emrave tĂ« kontejnerĂ«ve dhe madje edhe etiketave.
Loki funksionon nĂ« njĂ« ndĂ«rfaqe tĂ« njohur Grafana. Loki ka madje njĂ« gjuhĂ« tĂ« vet, e cila quhet LogQL â duke u frymĂ«zuar nga emri dhe sintaksa qĂ« i ngjan PromQL nĂ« Prometheus. NĂ« ndĂ«rfaqen e Loki ka sugjerime me kĂ«rkesa, kĂ«shtu qĂ« nuk Ă«shtĂ« e nevojshme t'i dish pĂ«rmendsh.
Loki në ndërfaqen Grafana
Duke pĂ«rdorur filtrat, nĂ« Loki mund tĂ« gjesh kode (â400â, â404â dhe çdo tjetĂ«r); tĂ« shikosh logĂ«t nga e gjithĂ« noda; tĂ« filtroni tĂ« gjithĂ« logĂ«t qĂ« pĂ«rmbajnĂ« fjalĂ«n âerrorâ. NĂ«se klikoni mbi logun, do tĂ« hapet njĂ« kartelĂ« me tĂ« gjithĂ« informacionin pĂ«r ngjarjen.
Në Loki ka mjaft mjete të cilat lejojnë nxjerrjen e log-eve të nevojshme, megjithëse sinqerisht, mund të kishin qenë edhe më shumë teknikisht. Tani Loki po zhvillohet aktivisht dhe po fiton popullaritet.
Elastic + Fluent Bit + Kibana (EFK Stack)
Staku EFK është një mjet më klasik dhe gjithashtu mjaft popullor për regjistrimin e log-eve.
NĂ« fillim tĂ« artikullit u pĂ«rmend ELK (Elasticsearch + Logstash + Kibana), por ky stak Ă«shtĂ« bĂ«rĂ« i vjetruar pĂ«r shkak tĂ« Logstash-it, i cili nuk Ă«shtĂ« shumĂ« efektiv dhe Ă«shtĂ« gjithashtu kĂ«rkesor pĂ«r burime. NĂ« vend tĂ« tij, filluan tĂ« pĂ«rdorin njĂ« zgjidhje mĂ« tĂ« lehtĂ« dhe mĂ« efikase si Fluentd, dhe pas pak kohe iu shtua â njĂ« agjent mbledhĂ«s edhe mĂ« i lehtĂ« dhe edhe mĂ« efikas.
NĂ«se i besohet zhvilluesve, allora Fluent Bit Ă«shtĂ« mĂ« shumĂ« se 100 herĂ« mĂ« efikas se Fluentd: «aty ku Fluentd konsumon 20 MB RAM, Fluent Bit do tĂ« konsumojĂ« 150 KB» â njĂ« citat direkt nga dokumentacioni. Duke e parĂ« kĂ«tĂ«, Fluent Bit Ă«shtĂ« pĂ«rdorur mĂ« shpesh.
Fluent Bit ka më pak mundësi sesa Fluentd, por përmbush nevojat thelbësore, prandaj ne kryesisht përdorim Fluent Bit.
Skema e funksionimit të stack-ut EFK: agjenti mbledh log-et nga të gjithë pod-ët (zakonisht, kjo është një DaemonSet që është e aktivizuar në të gjitha serverët e klasterit) dhe i dërgon në ruajtje (Elasticsearch, PostgreSQL ose Kafka). Kibana lidhet me ruajtjen dhe nxjerr të gjithë informacionin e nevojshëm nga aty.
paraqet informacionin në një ndërfaqe web të përshtatshme. Ka grafikë, filtra dhe shumë më tepër.
Nga log-et mund të krijohen të tëra dashboard-e.
Aftësitë e Fluent Bit
Duke qenë se për Fluent Bit, zakonisht, është dëgjuar më pak se për Logstash, le të shqyrtojmë atë pak më në thellësi. Fluent Bit mund të ndahet në mënyrë logjike në 6 module, disa nga të cilat mund të kenë shtesa që zgjasin kapacitetet e Fluent Bit.
Moduli Input mbledh log-et nga skedarët, shërbimet systemd dhe madje edhe nga tcp-socket (thjesht duhet të specifikoni endpoint-in dhe Fluent Bit do të fillojë ta kontrollojë atë). Këto mundësi janë të mjaftueshme për të mbledhur log-et si nga sistemi ashtu edhe nga kontejnerët.
Në prodhim zakonisht përdorim shtesat (mund ta drejtoni atë drejt dosjes me log-e) dhe (mund t'i thoni asaj se nga cilat shërbime të mbledhë log-et).
Moduli Parser shndërron logët në një format të përbashkët. Sipas parazgjedhjes, logët e Nginx-it janë një varg. Me ndihmën e këtij plugini, ky varg mund të konvertohet në JSON: të caktohen fushat dhe vlerat e tyre. Me JSON është më e lehtë të punosh sesa me logun në format vargu, sepse ofron mundësi më fleksibël për renditje.
Moduli Filter. NĂ« kĂ«tĂ« nivel filtrohen logĂ«t e padĂ«shiruar. PĂ«r shembull, vetĂ«m logĂ«t me vlerĂ«n âwarningâ apo me etiketa tĂ« caktuara dĂ«rgohen pĂ«r ruajtje. LogĂ«t e pĂ«rzgjedhur kalojnĂ« nĂ« bufer.
Moduli Buffer. Fluent Bit ka dy lloje buferash: bufer memorie dhe bufer në disk. Buferi është një ruajtje temporale e logëve, e nevojshme për rastet e gabimeve ose prishjeve. Të gjithë duan të kursejnë në RAM, prandaj zakonisht zgjidhet buferi në disk. Por duhet të mbani parasysh se logët ende shkarkohen në memory para se të shkojnë në disk.
Moduli Routing/Output përmban rregulla dhe adresa për dërgimin e logëve. Siç u tha më parë, logët mund të dërgohen në Elasticsearch, PostgreSQL ose, për shembull, Kafka.
është interesante se si log-et nga Fluent Bit mund të dërgohen në Fluentd. Duke qenë se e para është më e lehtë dhe më pak funksionale, mund të grumbullohen log-et dhe të dërgohen në Fluentd, ku mund të përpunohen më tej me ndihmën e plugins shtesë dhe të dërgohen në depo.
Nëse planifikoni të përdorni Elasticsearch...
Në fund, dy këshilla për ata që planifikojnë të përdorin Elasticsearch në prodhim si një depo log-esh.
- Konfiguroni njoftimet me anë të . Ky program nxjerr nga fluksi i përgjithshëm i log-eve mesazhet e rëndësishme dhe krijon alerte për to në email ose kanale të tjera. Megjithatë, jo shumë kohë më parë dolën .
- Rrotulloni log-et me ndihmĂ«n e aplikacionit ose dhe thirrjeve ndaj API Elasticsearch. Elastic aktualisht po bĂ«n hapa tĂ« rĂ«ndĂ«sishĂ«m nĂ« menaxhimin e jetĂ«s sĂ« indekseve pa pĂ«rdorimin e mjeteve tĂ« tjera. NĂ« pĂ«rgjithĂ«si, nuk ka ndonjĂ« kuptim tĂ« ruash logĂ«t pĂ«r njĂ« kohĂ« tĂ« gjatĂ«: Ă«shtĂ« e pamundur qĂ« njĂ« log tĂ« nevojitet pas dy javĂ«sh â nĂ«se Ă«shtĂ« me tĂ« vĂ«rtetĂ« kritik, brenda dy javĂ«sh do tĂ« jetĂ« trajtuar patjetĂ«r. NĂ« rastin mĂ« tĂ« keq, logĂ«t e vjetra mund tĂ« arkivohen dhe dĂ«rgohen diku pĂ«r ruajtje afatgjatĂ«. Kam dĂ«gjuar pĂ«r logĂ« tĂ« veçantĂ« qĂ« ligji kĂ«rkon tĂ« ruhet deri nĂ« 5 vjet. Personalish nuk kam hasur nĂ« kĂ«tĂ«, por nuk do ta barazoja kĂ«tĂ« informacion me logĂ« tĂ« zakonshĂ«m, dhe ndoshta do tâi ruaja ato veçmas.
VazhdonâŠ
Autori: Marsel Ibraev, administrator i çertifikuar i Kubernetes, inxhinier praktik në kompaninë , folës dhe zhvillues kurse .
Burimi: habr.com
