Logimine Kubernetes: kuidas koguda, salvestada, analüüsida ja töödelda logisid

Vaatame üle logimise alused Dockeris ja Kuberneteses, seejärel käsitleme kahte tööriista, mida saab julgelt kasutada tootmises: Grafana Loki ja EFK (Elasticsearch + Fluent Bit + Kibana) komplekti.

Artikli sisu — väljaanne avatud loengust koolis "Slerm". Kui on soov ja eriti kui see on tootmisvajadus, on võimalik läbida täiendav koolitus — registreeruge kursusele Kuberneteses infrastruktuuri jälgimise ja logimise kohta.

Logimine Dockeris

Kuberneteses töötavad rakendused podides, kuid madalamal tasemel töötavad nad siiski tavaliselt Dockeris. Seetõttu tuleb logimine seadistada nii, et koguda logisid konteineritest. Kuna konteinerid käivitab Docker, tuleb aru saada, kuidas logimine Dockeris toimib.

Loodan, et iga lugeja teab: rakenduse logid tuleb kirjutada stdout/stderr, mitte konteineri sisse. Logid kogub Docker Daemon, ning see töötab just nende logidega, mis saadetakse stdout/stderr. Lisaks toob logide salvestamine konteineri sisse endaga kaasa probleeme: konteiner paisub kasvava logi tõttu (kuna konteineris pole tõenäoliselt Logrotate'i), ja Docker Daemon ei ole sellest logist teadlik.

Dockeril on mitmeid logide kogumise draivereid või pluginaid. Tasuta versioonis Docker Community Edition (CE) on logidraivereid vähem kui kommertsversioonis Docker Enterprise Edition (EE).

Docker EE-d pole ma praktikas kunagi kasutanud: Southbridge'is püüame kinni pidada avatud lähtekoodiga lahendustest ning enamikku Docker EE täiendavaid funktsioone klientidele ei ole vajalik.

Docker CE logidraiverid:

local — logide salvestamine Docker Daemoni sisemisse faili;
json-file — iga konteineri katalooge luuakse json-log;
journald — logide saatmine journald-ile.

Dockeris asuvad logimise seaded failis daemon.json.

Väljas "log-driver" määratakse plugin ja väljas "log-opts" — selle seadistused. Ülaltoodud näites on määratud plugin "json-file", logi suuruse piirang — "max-size": "10m"; failide arvu piirang (ringluse seaded) — "max-file": "3"; samuti väärtused, mis logidele lisanduvad.

Mõningaid logidraiveri seadistusi saab määrata käsurea utiliidi kaudu. See on mugav, kui ühte konteinerit tuleb käivitada teise logidraiveriga.

Nii näeb logimise skeem Dockeris välja:

Kuidas skeem töötab: logi draiver, näiteks json-file, loob faile. Logikogujad (Rsyslog, Fluentd, Logagent ja teised) koguvad need failid ja edastavad need salvestamiseks Elasticu, Sematexti või muudele salvestuskohtadele.

Kubernetes'e logimise omadused

Lihtsustatult näeb logimise skeem Kubernetes'es välja järgmine: on pod, milles töötab konteiner, ja konteiner saadab logid stdout'i/stderr'i. Seejärel loob Docker faili ja salvestab logid, mida saab hiljem roteerida.

Vaatame Kubernetes'e logimise omadusi.

Salvesta logid deployments'ide vahel. See on oluline tingimus logimise õige seadistamise jaoks. Kui logisid ei salvestata deployments'ide vahel, siis uue rakenduse versiooni väljalaskmisel kustutatakse eelnevad logid, samuti põhjustab konteineri taaskäivitamine logide kaotust. Kubernetes'il on võtme sõna —previous, mis võimaldab vaadata rakenduse logisid enne viimast pod'i taaskäivitamist, kuid mitte kaugemale.

Koguda logisid kõigilt instantsidelt. Kui mikroteenuseid majutatakse pilves, vastutab süsteemi üle Cloud Provider. Kui mikroteenused on enda riistvaral, siis peavad lisaks konteinerite logidele olema kogutud ka süsteemi logid.

Varem ei olnud mugavaid tööriistu logide kogumiseks nii süsteemist kui mikroteenustest. Tavaliselt kogus üks tööriist süsteemi logisid (näiteks Rsyslog), teine - logisid Dockerist (näiteks journal-bit koos Docker'i logi draiveri seadistusega journald'ile). Prooviti kasutada journal-bit’i, et koguda logisid nii konteineritest (Docker'i logi draiveris märkida, et logid peavad minema journald'isse) kui ka süsteemist (CentOS 7-l on juba systemd ja journald). Lahendus on toimiv, kuid mitte ideaalne. Kui logisid on palju, hakkab journal-bit lagima ja sõnumid kaovad.

Katsetamine jätkus - ja leiti teine ​​meetod. CentOS 7-s dubleeritakse peamised süsteemi logid (messages, audit, secure) var-log'ide kaudu failidena. Dockeris saab samuti seadistada logide salvestamise faile json. Seega saab CentOS 7 ja Docker'i faile koos koguda.

Aja jooksul muutus ELK Stack lahendus populaarseks. See on kombinatsioon mitmest tööriistast: Elasticsearch, Logstash ja Kibana.

Elasticsearch salvestab konteinerite logid, Logstash kogub logisid instantsidelt, Kibana võimaldab kokku saada logisid ja koostada nende põhjal graafikuid. Mõnda aega kasutati ELK Stack'i aktiivselt, kuid minu arvates jõuab selle aeg lõpule. Räägin hiljem, miks.

Lisa metaandmeid. Podid, rakendused, konteinerid võivad olla käivitatud igal pool. Veelgi enam, ühel rakendusel võib olla mitu instantsi. Logid on salvestatud ühes formaadis, kuid me peame aru saama, milline replika on tegu, milline Pod seda kirjutab ja millises namespace'is see asub. Seetõttu peab logidele lisama metainformatsiooni.

Parsi logisid. Lõbus on see, et logimis- ja järelevalvesüsteemi hoolduskulud võivad ületada peamise rakenduse kulud. Kui teid voolab kümneid ja sadu tuhandeid logisid sekundis, tundub see loogiline, kuid siiski tuleb teada piir. Üks viis selle piiri leidmiseks on logide parsimine.

Reeglina ei ole vajalik koguda ja salvestada kõiki logisid, tuleks salvestada ainult osa — näiteks logid, mille staatus on 'warning' või 'error'. Kui rääkida nginx'i või ingress-kontrollerite logidest, siis tuleks salvestada ainult need, mille staatus erineb 200-st. Kuid see pole universaalne soovitus: kui te ehitate mingil viisil analüüsi nginx'i logide põhjal, siis on ilmselgelt mõistlik neid koguda.

Mõtlematult logide filtreerimist ei soovitata, sest filtreeritud andmed võivad mitte piisata normaalseks analüüsiks. Teiselt poolt, võib olla, et analüütika tuleks viia läbi mitte logimise tasemel, vaid mõõtmete kogumise tasemel. Siis ei pea salvestama sadu tuhandeid ridu koodiga 200. Üks lähenemisviis on saada teavet liiklusest ja vigadest ingress-kontrollerite mõõtmetest.

Kokkuvõttes tuleb siin hoolikalt mõelda: mida te soovite salvestada ja kui kaua, sest muidu tekib olukord, kus logimis-süsteem röövib ressursse rohkem kui peamine projekt.

Praegu ei ole standardset lahendust logimise jaoks. Erinevalt järelevalvest, kus on üks enimlevinud lahendus Prometheus, ei ole logimisel standardit.

Käesolevas loengus vaatame kahte tööriista: üks populaarne ja teine — üha populaarsem. Lisaks neile on ka teisi, kuid sellest artiklist me neid ei puuduta.

Arvestades kõiki eelnevalt käsitletud omadusi, võib logimist Kuberneteses nüüd kujutada sellise skeemina:

Jääb konteineri logi, pööramine, kuid ilmub kogumise agent, mis kogub logid ja saadab need säilitamiseks (skeemil — Logging Backend). Agent töötab igas sõlmes ja tavaliselt on see käivitatud Kuberneteses.

Nüüd vaatame logimise tööriistu.

Grafana Loki

Grafana Loki on hiljuti ilmunud, kuid on juba saanud üsna tuntuks. Selle eelised: lihtne installatsioon, vähenenud ressursikasutus, ei vaja Elasticsearchi installimist, kuna salvestab andmeid TSDB-sse (aegade seeria andmebaas). Eelmisel artiklil kirjutasin, et sellises andmebaasis salvestab andmeid Prometheus, ja see on üks paljusid sarnaseid jooni kahe toote vahel. Arendajad isegi väidavad, et Loki on "Prometheus logimise maailmas."

Väike kõrvalepõige TSDB-st neile, kes ei ole lugenud eelmist artiklit: TSDB täidab suurepäraselt suurte andmemahtude, ajaseeriate salvestamise ülesande, kuid ei ole mõeldud pikaajaliseks salvestamiseks. Kui mingil põhjusel peate logisid hoidma rohkem kui kaks nädalat, on parem neid edastada teise andmebaasi.

Veel üks Loki eelis on see, et andmete visualiseerimiseks kasutatakse Grafanat. Väga mugav: Grafanas vaatame monitoorimise andmeid ja seal samas, ühendades Loki, vaatame logisid. Logide põhjal saab luua grafiike.

Loki arhitektuur näeb välja umbes nii:

Kasutades DaemonSet-i, paigaldatakse kõikidesse klastri serveritesse agent - Promtail või Fluent Bit. Agent kogub logisid. Loki võtab need ja salvestab oma TSDB-sse. Logidele lisatakse kohe metainvormatsioon, mis on mugav: saab filtreerida Pods'ide, nimede, konteinerite ja isegi silte järgi.

Loki installimise juhend

Loki töötab tuttavas Grafana liideses. Lokil on isegi oma päringute keel, nimega LogQL - selle nimi ja süntaks meenutavad PromQL-i Prometheuses. Loki liideses on päringute nõuanded, seega ei pea neid meeles pidama.

Dokumentatsioon LogQL keele jaoks

Loki Grafana liideses

Filtreid kasutades on Lokis võimalik leida koodid ("400", "404" ja muud); vaadata logisid kogu nodest; filtreerida välja kõik logid, kus on sõna "error". Kui logile vajutada, avaneb kaardike kogu sündmuse teabega.

Lokis on piisavalt tööriistu, mis võimaldavad vajalikud logid välja võtta, kuigi ausalt öeldes võiks neid tehniliselt olla rohkem. Praegu areneb Loki aktiivselt ja võtab populaarsust.

Elastic + Fluent Bit + Kibana (EFK stack)

EFK stack on klassikalisem ja siiski mitte vähem populaarne logimise tööriist.

Artiklis mainitud ELK (Elasticsearch + Logstash + Kibana) on vananenud, kuna Logstash on ebaefektiivne ja ressursimahukas. Selle asemel on levinud kergem ja efektiivsem Fluentd, millele on hiljem lisandunud Fluent Bit — veel kergem ja veel efektiivsem logikogumise agent.

Arendajate väitel on Fluent Bit üle 100 korra efektiivsem kui Fluentd: "seal, kus Fluentd tarbib 20 MB RAM-i, tarbib Fluent Bit 150 KB" — otsekohene tsitaat dokumentatsioonist. Selle tõttu on Fluent Bit'i kasutamine sagenenud.

Fluent Bit'il on vähem võimalusi kui Fluentd'l, kuid ta katab peamised vajadused, seetõttu kasutame peamiselt Fluent Bit'i.

EFK stack töörežiim: agent kogub logisid kõigist podidest (tavaliselt on see DaemonSet, mis töötab kõikidel klastriserveritel) ja saadab need salvestusse (Elasticsearch, PostgreSQL või Kafka). Kibana ühendub salvestusega ja tõmbab sealt kogu vajaliku teabe.

Kibana esitab teabe mugavas veebirakenduses. Seal on diagrammid, filtrid ja palju muud.

Logide põhjal saab luua terveid juhtpaneele.

Fluent Bit'i võimalused

Kuna Fluent Bit'ist on tavaliselt vähem kuulda kui Logstash'ist, vaatame seda veidi lähemalt. Fluent Bit'it saab loogiliselt jagada 6 mooduliks, millele saab lisada pluginaid, mis laiendavad Fluent Bit'i funktsioone.

Input moodul kogub logisid failidest, systemd teenustest ja isegi tcp-socket'ist (peab vaid määrama lõpp-punkti, ja Fluent Bit hakkab sinna liikuma). Neid võimalusi on piisavalt, et logisid koguda nii süsteemist kui ka konteineritest.

Tootmis keskkonnas kasutame kõige sagedamini pluginaid tail (seda saab suunata logifailide kausta) ja systemd (seda saab käskida, millistest teenustest logisid koguda).

Parser moodul viib logid ühise vormingusse. Vaikimisi on Nginx'i logid rida. Plugina abil saab seda rida muuta JSON'iks: määrata väljad ja nende väärtused. JSON'iga on palju lihtsam töötada kui teksti logiga, kuna on olemas paindlikumad sorteerimisvõimalused.

Filter moodul. Sellel tasemel jäetakse välja ebaolulised logid. Näiteks saadetakse säilitamiseks logid, millel on väärtus "warning" või kindlate siltidega. Valitud logid suunatakse puhvri.

Buffer moodul. Fluent Bit'il on kaks tüüpi puhvrit: mälu puhver ja ketaspuhver. Puhver on ajutine logide hoidla, mis on vajalik vigade või tõrgete korral. Kõik tahavad RAM-i pealt kokku hoida, seetõttu valitakse tavaliselt ketaspuhver. Kuid tuleb arvestada, et enne ketaspuhvri kasutamist laaditakse logid ikkagi esmalt mälu.

Routing/Output moodul sisaldab logide saatmise reegleid ja aadresse. Nagu juba mainitud, on logid võimalik saata Elasticsearchi, PostgreSQLi või näiteks Kafka'sse.

Huvitav on see, et logisid on võimalik saata Fluent Bit'ist Fluentd'sse. Kuna esimene on kergema kaaluga ja vähem funktsionaalne, saab läbi selle koguda logisid ja saata need Fluentd'sse, kus neid saab tänu täiendavatele pluginatele edasi töödelda ja saata salvestitesse.

Kui plaanite kasutada Elasticsearchi…

Lõpetuseks kaks nõuannet neile, kes plaanivad kasutada Elasticsearchi logide salvestamiseks tootmisrežiimis.

1. Seadistage teavitused kasutades ElastAlert. See programm eristab logide üldvoost olulisi sõnumeid ja saadab neist teateid e-postile või muudele kanalitele. Kahjuks on hiljuti toimunud kurvade uudiste avaldamine, et projekt võib peagi lõpetada oma tegevuse..
2. Logide pööramine kasutades rakendust Curator või pöördudes Elasticsearchi API poole. Elastic teeb praegu tegelikult olulisi samme indeksite elutsükli haldamiseks ilma kolmandate osapoolte tööriistade kasutamiseta. Üldiselt ei ole mõistlik logisid pikka aega hoida: tõenäoliselt ei ole mingit logi vajalik kahe nädala pärast — kui see tõeliselt kriitiline on, siis saab see kahe nädala jooksul kindlasti töödeldud. Äärmisel juhul saab vanad logid arhiveerida ja saata pikaajalisse säilitamisse. Olen kuulnud erilogidest, mida seadus kohustab hoidma kuni 5 aastat. Isiklikult pole ma sellekohasega kokku puutunud, kuid ei seostaks ma sellist info tavaliste logidega, ning võib-olla säilitaksin neid isegi eraldi.

Jätkub…

Autor: Marsel Ibraev, sertifitseeritud Kubernetes administraator, praktiseeriv insener ettevõttes Southbridge, esineja ja kursuste arendaja Slürm.

Allikas: habr.com