Kubernetesi logimine: kuidas koguda, salvestada, analüüsida ja töödelda logisid

Alustame logimise põhitõdedest Dockeris ja Kubernetesis ning seejärel vaatame kahte tööriista, mida saab usaldusväärselt kasutada tootmisosas: Grafana Loki ja EFK (Elasticsearch + Fluent Bit + Kibana) virna.

Artikli materjal on väljavõte avatoru loengust „Slyrm“. Kui on soov ja eriti tootmisvajadus, on võimalik läbida põhjalik koolitus — registreeruge kursusele Kubernetes'e infrastruktuuri jälgimise ja logimise kohta.

Logimine Dockeris

Kubernetesi tasandil käivitatakse rakendused podides, kuid madalamal tasandil töötavad nad siiski tavaliselt Dockeris. Seetõttu peab logimise seadistama nii, et koguda logisid konteineritest. Kuna konteinerid käivitab Docker, tuleb mõista, kuidas logimine toimub Dockeris.

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

Dockeril on mitmeid logi draivereid või pistikprogramme konteinerite logide kogumiseks. Tasuta versioonis Docker Community Edition (CE) on logi draivereid vähem kui kaubanduslikus Docker Enterprise Editionis (EE).

Ma ei ole kunagi praktikas kasutanud Docker EE-d: Southbridge'is püüame kinni pidada avatud lähtekoodiga lahendustest ning enamikule klientidest ei ole Docker EE lisafunktsioonid vajalikud.

Logi draiverid Docker CE-s:

local — logide salvestamine Docker Daemoni sisemistesse failidesse;
json-file — json-logi loomine iga konteineri kausta;
journald — logide saatmine journald'ile.

Dockeris logimise seaded asuvad failis daemon.json.

Väljas "log-driver" määratakse pistikprogramm ja väljas "log-opts" — selle seaded. Ülaltoodud näites on määratud pistikprogramm "json-file", logi suuruse piirang - "max-size": "10m"; failide arvu piirang (pöörlemise seaded) - "max-file": "3"; ning väärtused, mis lisatakse logidele.

Mõningaid logi draiveri seadeid saab määrata käsurea utiliidi kaudu. See on mugav, kui eraldi konteiner tuleb käivitada teise logi draiveriga.

Nii näeb logimise skeem Dockeris välja:

Kuidas süsteem töötab: logidraiver, näiteks json-file, loob faile. Logikogujaid (Rsyslog, Fluentd, Logagent ja teised) koguvad need failid ja edastavad need salvestamiseks Elasticusse, Sematexti või teistele salvestuskohtadele.

Logimise eritiused Kuberneteses

Lihtsustatud kujul näeb logimine Kuberneteses välja nii: 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 keerata.

Vaadake lähemalt, millised on logimise eripärad Kuberneteses.

Säilitada logid deploide vahel. See on hädavajalik tingimus logimise õigeks seadistamiseks. Kui logisid deploide vahel ei säilitata, siis uue rakenduse versiooni väljatöötamisel kustutatakse varasemate logid, konteineri taaskäivitamine toob samuti kaasa logide kadumise. Kubernetesel on lipp —previous, mis võimaldab näha rakenduse logisid enne viimast Pod'i taaskäivitamist, kuid mitte sügavamale.

Agregeerida logid kõikidest instantsidest. Kui mikroteenuseid majutatakse pilves, siis vastutab süsteemi järelevalve eest pilveteenuse pakkuja. Kui mikroteenuseid töötab oma riistvara peal, tuleb konteinerite logide kõrval koguda ka süsteemi logisid.

Varem ei olnud mugavaid tööriistu logide kogumiseks nii süsteemist kui ka mikroteenustest. Üks tööriist kogus tavaliselt süsteemi logisid (näiteks Rsyslog), teine logisid Dockerilt (näiteks journal-bit koos Docker logi draiveri seadistamisega journaldile). Proovisime kasutada journal-bit'it, et koguda logisid konteineritest (Docker logi draiveri seadistamine, et logid kirjutataks journaldile) ja süsteemist (CentOS 7-l on juba systemd ja journald). Lahendus töötab, aga ei ole ideaalne. Kui logisid on palju, hakkab journal-bit lagima ja teated kaovad.

Eksperimendid kestsid ja leiti teine lahendus. CentOS 7-s dubleeritakse põhised süsteemi logid (messages, audit, secure) var-logis failidena. Dockeris saab samuti seadistada logide salvestamist json failidesse. Seega saab neid faile CentOS 7-st ja Dockerist koos koguda.

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

Elasticsearch salvestab konteineritest logisid, Logstash kogub instantsidelt logisid, Kibana võimaldab saadud logisid töödelda ja nende põhjal graafikuid koostada. Mõnda aega kasutati ELK Stack'i aktiivselt, aga minu arvates on selle aeg möödas. Hiljem räägin, miks.

Lisage metaandmed. Podid, rakendused ja konteinerid võivad töötada igal pool. Veelgi enam, ühel rakendusel võib olla mitu instantsi. Logid on salvestatud ühte vormingusse, kuid me peame mõistma, milline täpselt see replika on, milline Pod seda kirjutab ja millisest nimede ruumist see pärineb. Seepärast on logidele vaja lisada metaandmed.

Parsi logid. Naljakas, kuid logimise ja jälgimise süsteemi toetamise kulud võivad ületada põhirakenduse kulud. Kui teil voolab kümneid ja sadu tuhandeid logisid sekundis, tundub see loomulik, kuid siiski tuleb tunda piiri. Üks viis selle piiri leidmiseks on logide parsimine.

Üldiselt ei ole vaja koguda ja salvestada kõiki logisid, vaid saadetakse salvestamiseks ainult osa — näiteks logid staatusega „warning” või „error”. Kui rääkida nginx-i või ingress-kontrollerite logidest, siis võib salvestada vaid need, mille staatus erineb 200-st. Kuid see ei ole universaalne nõuanne: kui te võtate logidest mingil moel analüüse, siis on loogiline neid koguda.

Mõtlematult logide filtreerimist ei soovitata, kuna filtreeritud andmed ei pruugi olla piisavad normaalseks analüüsiks. Teisest küljest, võib-olla peaks analüüsi läbi viima mitte logimistaseme, vaid metrite kogumise tasemel. Siis ei ole vaja säilitada sadu tuhandeid 200 koodiga ridu. Üks lähenemisviis on saada teavet liiklusest ja vigadest ingress-kontrollerite mõõtmistest.

Üldiselt tuleb siin korralikult mõelda: mida soovite säilitada ja kui kaua, sest vastasel juhul tekib olukord, kus logimissüsteem võtab rohkem ressursse kui peamine projekt.

Praegu ei ole standardset lahendust logimiseks.Erinevalt jälgimisest, kus on üks kõige levinum lahendus Prometheus, puudub logimisel standard.

Selles loengus vaatleme kahte tööriista: ühte populaarsest ja teist — järjest populaarsemat. Peale nende on olemas ka teisi, kuid selles artiklis me neid ei käsitle.

Kuna arvesse on võetud kõik ülaltoodud omadused, saab logimist Kuberneteses nüüd kujutada sellise skeemi kaudu:

Konteinerilogide jääb alles, rotatsioon on olemas, kuid ilmub kogumise agent, mis valib logid ja saadab need salvestamiseks (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 ilmus hiljuti, kuid on juba üsna tuntud. Selle eelised: kergesti paigaldatav, tarbib vähe ressursse, ei vaja Elasticsearchi paigaldamist, kuna salvestab andmed TSDB-sse (ajareäkitud andmebaas). Eelmisel artiklis kirjutasin, et sellises andmebaasis hoiab andmeid Prometheus, ja see on üks paljusid sarnasusi kahe toote vahel. Arendajad isegi väidavad, et Loki on "Prometheus logimise maailmas".

Päevakorda TSDB kohta neile, kes ei ole lugenud eelmist artiklit: TSDB täidab suure hulga ajareadade andmete säilitamise ülesande suurepäraselt, kuid ei ole mõeldud pikaajaliseks säilitamiseks. Kui mingil põhjusel peate logisid säilitama kauem kui kaks nädalat, siis on parem seadistada nende edastamine teise andmebaasi.

Veel üks Loki eelis on see, et andmete visualiseerimiseks kasutatakse Grafanat. See on väga mugav: Grafanas vaatame jälgimisandmeid ja seal samas, ühendades Loki, vaatame logisid. Logide põhjal saab ehitada diagramme.

Loki arhitektuur näeb välja umbes selline:

DaemonSet'i abil käitatakse klastris kõigil serveritel agendi — Promtail või Fluent Bit. Agent kogub logisid. Loki võtab need ja salvestab oma TSDB-sse. Logidele lisatakse kohe metainformatsioon, mis on mugav: saab filtreerida Pods'i, namespace'ide, konteinerite nimede ja isegi siltide järgi.

Loki installimise juhend

Loki töötab tuttavas Grafana liideses. Loki'l on isegi oma päringute keel, mida nimetatakse LogQL-iks — nime ja süntaksi poolest meenutab see PromQL-i Prometheuses. Loki liideses on päringute vihjed, seega ei pea neid südameiselt teadma.

Dokumentatsioon LogQL keele kohta

Loki liidese Grafanas

Filtreid kasutades saab Lokis leida koode ("400", "404" ja igasuguseid muid); vaadata logisid kogu sõlmel; filtreerida välja kõik logid, kus esineb sõna "error". Kui logile vajutada, avaneb kaart, kus on kogu teave sündmuse kohta.

Loki pakub mitmeid tööriistu, mis võimaldavad vajalikest logidest andmeid välja tõmmata, kuigi ausalt öeldes võiks neid tehniliselt rohkem olla. Praegu arendatakse Lokit aktiivselt ja see kogub populaarsust.

Elastic + Fluent Bit + Kibana (EFK virn)

EFK virn on klassikalisem ja samas mitte vähem populaarne logimisvahend.

Artikli alguses mainiti ELK-d (Elasticsearch + Logstash + Kibana), kuid see virn on vananenud, kuna Logstash ei ole kuigi efektiivne ja nõuab palju ressursse. Selle asemel on hakanud kasutama kergekaalulisemat ja efektiivsemat Fluentd-d, ning pärast seda tuli sellele appi Fluent Bit — veelgi kergekaalulisem ja veelgi efektiivsem logikoguja agent.

Arendajate väitel on Fluent Bit rohkem kui 100 korda efektiivsem kui Fluentd: «Seal, kus Fluentd tarbib 20 MB RAM-i, tarbib Fluent Bit 150 KB» — otse tsitaat dokumentatsioonist. Selle põhjal on Fluent Bit-d hakanud sagedamini kasutama.

Fluent Bit-l on vähem võimalusi kui Fluentd-l, kuid see katab peamised vajadused, mistõttu kasutame peamiselt Fluent Bit-i.

EFK steki tööpõhimõte: agent kogub logisid kõigilt podidelt (tavaliselt on see DaemonSet, mis on käivitatud kõigil klastriserveritel) ja saadab need salvestusse (Elasticsearch, PostgreSQL või Kafka). Kibana ühendub salvestusega ja toob sealt välja kogu vajaliku teabe.

Kibana esitleb teavet kasutajasõbralikus veebiliideses. Seal on graafikud, filtrid ja palju muud.

Logide põhjal saab luua terveid infosüsteeme.

Fluent Biti võimalused

Kuna Fluent Bitist on tavaliselt räägitud vähem kui Logstashist, vaatame seda veidi lähemalt. Fluent Biti võib loogiliselt jagada kuue mooduli peale, millele saab lisada pistikprogramme, mis laiendavad Fluent Biti võimalusi.

Sisendi moodul kogub logisid failidest, systemd teenustest ja isegi tcp-socketist (piisab, kui näidata endpoint'i, ja Fluent Bit hakkab sinna ühenduma). Need võimalused on piisavad, et koguda logisid nii süsteemist kui konteineritest.

Tootmisperioodil kasutame kõige sagedamini pistikprogramme tail (seda saab suunata logifailidega kausta) ja systemd (sellele saab öelda, millistest teenustest logisid koguda).

Parsimise moodul toob logid ühtsesse vormi. Vaikimisi on Nginx'i logid stringid. Plugina abil saab selle stringi teisendada JSON-ks: määrata välja ja nende väärtused. JSON-iga on palju lihtsam töötada kui tekstilogi puhul, kuna see pakub paindlikumaid sorteerimisvõimalusi.

Filtri moodul. Sel tasemel eraldatakse soovimatud logid. Näiteks saadetakse salvestamiseks ainult logid, mille väärtus on "warning" või kindlatele märgistele vastavad logid. Valitud logid jõuavad puhvrisse.

Puhvri moodul. Fluent Bit'il on kaks tüüpi puhvrit: mälupuhver ja kettapuhver. Puhver on ajutine logide salvestus, mis on vajalik vigade või rikke korral. Kõik tahavad RAM-i pealt kokku hoida, seetõttu valitakse tavaliselt kettapuhver. Kuid tuleb arvestada, et enne kettale minekut laaditakse logid ikkagi mällu.

Suunamise/Väljundi moodul sisaldab reegleid ja logide saatmise aadresse. Nagu juba mainitud, saab logisid saata Elasticsearch'i, PostgreSQL'i või näiteks Kafka'sse.

Huvitav on see, et Fluent Bit logisid saab saata Fluentd-sse. Kuna esimene on kergem ja vähem funktsionaalne, saab selle kaudu logisid koguda ja edastada Fluentd-sse, kus neid täiendavate plugin'ite abil töötelda ja salvestustesse saata.

Kui plaanite kasutada Elasticsearchi…

Lõpetuseks kaks näpunäidet neile, kes plaanivad kasutada Elasticsearchi tootmisandmetena logide salvestamiseks.

1. Seadistage teavitused kasutades ElastAlert. See rakendus eraldab üldisest logivoolust olulisi sõnumeid ja saadab nende kohta teavitusi e-postile või teistele kanalitele. Kahjuks tuli hiljuti kurb uudis, et projekt võib peagi lõpetada oma eksisteerimise. kurbavalt uudis, et projekt võib peagi lõpetada oma olemasolu.
2. Rottige logisid rakenduse Curator või Elasticsearchi API kõnesid. Elastic teeb sisuliselt praegu olulisi samme indeksite elutsükli haldamiseks ilma kolmandate osapoolte tööriistadeta. Üldiselt pole mõtet logisid pikalt hoida: tõenäoliselt pole mingit logi vajalik kaks nädalat hiljem – kui see on tõeliselt kriitiline, on see kindlasti juba kahe nädala jooksul käsitletud. Äärmisel juhul saab vanad logid arhiveerida ja saata pikaajalisse säilitamisse. Olen kuulnud erilistest logidest, mida seaduse kohaselt peab säilitama kuni 5 aastat. Isiklikult ma sellise olukorraga kokku ei ole puutunud, kuid ma ei seondaks sellist teavet tavalogidega ning tõenäoliselt hoiaksin neid isegi eraldi.

Jätkub…

Autor: Marcell Ibraev, sertifitseeritud Kubernetes administraator, praktikainsener Southbridge, esineja ja koolituste arendaja Slöärm.

Allikas: habr.com