{"id":93294,"date":"2020-09-05T07:42:58","date_gmt":"2020-09-05T05:42:58","guid":{"rendered":"https:\/\/prohoster.info\/blog\/administrirovanie\/logirovanie-v-kubernetes-kak-sobirat-hranit-parsit-i-obrabatyvat-logi"},"modified":"2020-09-05T07:42:58","modified_gmt":"2020-09-05T05:42:58","slug":"logirovanie-v-kubernetes-kak-sobirat-hranit-parsit-i-obrabatyvat-logi","status":"publish","type":"post","link":"https:\/\/prohoster.info\/ro\/blog\/administrirovanie\/logirovanie-v-kubernetes-kak-sobirat-hranit-parsit-i-obrabatyvat-logi","title":{"rendered":"Logarea \u00een Kubernetes: cum s\u0103 colectezi, s\u0103 stochezi, s\u0103 parsezi \u0219i s\u0103 procesezi jurnalele","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

S\u0103 analiz\u0103m conceptele de baz\u0103 ale log\u0103rii \u00een Docker \u0219i Kubernetes, dup\u0103 care vom explora dou\u0103 instrumente care pot fi utilizate cu \u00eencredere \u00een produc\u021bie: Grafana Loki \u0219i stiva EFK (Elasticsearch + Fluent Bit + Kibana).<\/p>\n

<\/p>\n

Materialul articolului este o sintez\u0103 din lectura deschis\u0103 a \u0219colii \u201eSlurm\u201d<\/a><\/noindex>. Dac\u0103 exist\u0103 dorin\u021ba \u0219i mai ales necesitatea de produc\u021bie, se poate urma o instruire complet\u0103 \u2014 \u00eenscrie\u021bi-v\u0103 la cursul despre Monitorizarea \u0219i logarea infrastructurii \u00een Kubernetes<\/a><\/noindex>.<\/em><\/p>\n

<\/p>\n

\"Logarea<\/p>\n

<\/a><\/noindex><\/p>\n

Logarea \u00een Docker<\/h2>\n

<\/p>\n

La nivel de Kubernetes, aplica\u021biile sunt pornite \u00een pod-uri, dar la nivelul inferior ele func\u021bioneaz\u0103 de obicei \u00een Docker. De aceea, trebuie s\u0103 configur\u0103m logarea astfel \u00eenc\u00e2t s\u0103 colect\u0103m jurnalele din containere. Containerele sunt lansate de Docker \u2014 deci trebuie s\u0103 \u00een\u021belegem cum func\u021bioneaz\u0103 logarea la nivelul Docker.<\/p>\n

<\/p>\n

Sper c\u0103 fiecare cititor \u0219tie: jurnalele aplica\u021biei trebuie s\u0103 fie scrise \u00een stdout\/stderr, nu \u00een interiorul containerului. Jurnalele sunt agregate de Docker Daemon, care lucreaz\u0103 doar cu acele jurnale care sunt trimise la stdout\/stderr. \u00cen plus, scrierea jurnalelor \u00een interiorul containerului duce la probleme: containerul se umfl\u0103 din cauza cre\u0219terii jurnalului (deoarece cel mai probabil nu exist\u0103 Logrotate \u00een container), iar Docker Daemon nu are informa\u021bii despre acest jurnal.<\/p>\n

<\/p>\n

Docker are mai mul\u021bi drivere de log sau plugin-uri pentru colectarea jurnalelor din containere. \u00cen versiunea gratuit\u0103 Docker Community Edition (CE), driverele de log sunt mai pu\u021bine dec\u00e2t \u00een versiunea comercial\u0103 Docker Enterprise Edition (EE).<\/p>\n

<\/p>\n

\"Logarea<\/p>\n

<\/p>\n

Nu am folosit niciodat\u0103 Docker EE \u00een practic\u0103: \u00een Southbridge ne str\u0103duim s\u0103 respect\u0103m solu\u021biile Open Source, iar majoritatea clien\u021bilor nu au nevoie de func\u021bionalit\u0103\u021bile suplimentare ale Docker EE. <\/p>\n

<\/p>\n

Driverele de log \u00een Docker CE:<\/p>\n

<\/p>\n

local<\/strong> \u2014 scrierea jurnalelor \u00een fi\u0219iere interne ale Docker Daemon;
\njson-file<\/strong> \u2014 crearea de json-log \u00een folderul fiec\u0103rui container;
\njournald<\/strong> \u2014 trimiterea jurnalelor c\u0103tre journald.<\/p>\n

<\/p>\n

Set\u0103rile de logare \u00een Docker se afl\u0103 \u00een fi\u0219ierul daemon.json. <\/p>\n

<\/p>\n

\u00cen c\u00e2mpul \u201clog-driver\u201d se indic\u0103 plugin-ul, iar \u00een c\u00e2mpul \u201clog-opts\u201d \u2014 set\u0103rile acestuia. \u00cen exemplul de mai sus este men\u021bionat plugin-ul \u201cjson-file\u201d, limita de dimensiune a jurnalului \u2014 \u201cmax-size\u201d: \u201c10m\u201d; limita num\u0103rului de fi\u0219iere (set\u0103rile rota\u021biei) \u2014 \u201cmax-file\u201d: \u201c3\u201d; \u0219i valorile care vor fi ad\u0103ugate la jurnale.<\/p>\n

<\/p>\n

\"Logarea<\/p>\n

<\/p>\n

Unele set\u0103ri ale driverului de log pot fi specificate prin interfa\u021ba de linie de comand\u0103. Este convenabil dac\u0103 un anumit container trebuie s\u0103 fie lansat cu un alt driver de log. <\/p>\n

<\/p>\n

Iat\u0103 cum arat\u0103 schema de logare \u00een Docker:<\/p>\n

<\/p>\n

\"Logarea<\/p>\n

<\/p>\n

Cum func\u021bioneaz\u0103 schema: un driver de log-uri, cum ar fi json-file, creeaz\u0103 fi\u0219iere. Colectoarele de log-uri (Rsyslog, Fluentd, Logagent \u0219i altele) adun\u0103 aceste fi\u0219iere \u0219i le transmit pentru stocare \u00een Elastic, Sematext sau alte depozite.<\/p>\n

<\/p>\n

Caracteristici ale log\u0103rii \u00een Kubernetes<\/h2>\n

<\/p>\n

Simplificat, schema de logare \u00een Kubernetes arat\u0103 astfel: exist\u0103 un pod, \u00een care se ruleaz\u0103 un container, iar containerul trimite log-urile \u00een stdout\/stderr. Apoi, Docker creeaz\u0103 un fi\u0219ier \u0219i \u00eenregistreaz\u0103 log-urile, care pot fi apoi rotite.<\/p>\n

<\/p>\n

\"Logarea<\/p>\n

<\/p>\n

S\u0103 analiz\u0103m caracteristicile log\u0103rii \u00een Kubernetes.<\/p>\n

<\/p>\n

A p\u0103stra log-urile \u00eentre deployment-uri<\/strong>. Aceasta este o condi\u021bie obligatorie pentru configurarea corect\u0103 a \u00eenregistr\u0103rii. Dac\u0103 nu se p\u0103streaz\u0103 jurnalele \u00eentre desf\u0103\u0219ur\u0103ri, atunci, la lansarea unei noi versiuni a aplica\u021biei, jurnalele anterioare vor fi suprascrise, iar repornirea containerului va duce, de asemenea, la pierderea jurnalele. Kubernetes are o op\u021biune \u2014previous, care permite vizualizarea jurnalele aplica\u021biei p\u00e2n\u0103 la ultima repornire a Pod-ului, dar nu mai ad\u00e2nc.<\/p>\n

<\/p>\n

A agrega log-urile de pe toate instan\u021bele<\/strong>. Dac\u0103 microserviciile sunt g\u0103zduite \u00een cloud, atunci controlul sistemului este responsabilitatea furnizorului de cloud. Dac\u0103 microserviciile sunt pe echipamentele proprii, atunci pe l\u00e2ng\u0103 log-urile din containere, trebuie s\u0103 se adune \u0219i log-urile sistemului.<\/p>\n

<\/p>\n

Anterior, nu existau instrumente convenabile pentru colectarea log-urilor at\u00e2t din sistem, c\u00e2t \u0219i din microservicii. De obicei, un instrument aduna log-urile sistemului (de exemplu, Rsyslog), iar un altul \u2014 log-urile din Docker (de exemplu, journal-bit cu configurarea driver-ului de log Docker pe journald). S-a \u00eencercat utilizarea journal-bit \u2014 pentru a aduna log-urile \u0219i din containere (\u00een driver-ul de log Docker specific\u00e2nd c\u0103 trebuie s\u0103 se scrie log-urile \u00een journald), \u0219i din sistem (\u00een CentOS 7 deja exist\u0103 systemd \u0219i journald). Solu\u021bia este func\u021bional\u0103, dar nu ideal\u0103. Dac\u0103 sunt multe log-uri, journal-bit \u00eencepe s\u0103 \u00eent\u00e2rzie, iar mesajele se pierd.<\/p>\n

<\/p>\n

Experimentele au continuat \u2014 \u0219i am g\u0103sit o alt\u0103 abordare. \u00cen CentOS 7, principalele log-uri de sistem (messages, audit, secure) sunt duplicate \u00een var-log sub form\u0103 de fi\u0219iere. \u00cen Docker, de asemenea, se poate configura salvarea log-urilor \u00een fi\u0219iere json. Prin urmare, aceste fi\u0219iere din CentOS 7 \u0219i Docker pot fi adunate \u00eempreun\u0103.<\/p>\n

<\/p>\n

\u00centre timp, solu\u021bia ELK Stack a devenit popular\u0103. Aceasta este o combina\u021bie de mai multe instrumente: Elasticsearch, Logstash \u0219i Kibana.<\/p>\n

<\/p>\n

Elasticsearch stocheaz\u0103 log-urile din containere, Logstash adun\u0103 log-urile din instan\u021be, Kibana permite procesarea log-urilor ob\u021binute, cre\u00e2nd grafice pe baza acestora. O perioad\u0103, ELK Stack a fost utilizat activ, dar, din punctul meu de vedere, timpul s\u0103u a trecut. Voi explica ulterior de ce.<\/p>\n

<\/p>\n

Ad\u0103ugarea de metadate<\/strong>. Poduri, aplica\u021biile \u0219i containerele pot fi pornite de oriunde. Mai mult, o aplica\u021bie poate avea mai multe instan\u021be. Jurnalele sunt scrise \u00eentr-un format uniform, iar noi trebuie s\u0103 \u00een\u021belegem care este replica specific\u0103, ce Pod scrie \u0219i \u00een ce spa\u021biu de nume se afl\u0103. De aceea, este necesar s\u0103 ad\u0103ug\u0103m metadate \u00een jurnale.<\/p>\n

<\/p>\n

Parsat jurnalele<\/strong>. Este amuzant, dar costurile de suport pentru sistemul de jurnalizare \u0219i monitorizare pot dep\u0103\u0219i cheltuielile pentru aplica\u021bia principal\u0103. Atunci c\u00e2nd ai zeci \u0219i sute de mii de jurnale pe secund\u0103, acest lucru pare logic, dar totu\u0219i trebuie s\u0103 cunoa\u0219tem limita. Una dintre metodele de a g\u0103si aceast\u0103 limit\u0103 este parsarea jurnalele. <\/p>\n

<\/p>\n

\u00cen general, nu trebuie s\u0103 colectezi \u0219i s\u0103 stochezi toate jurnalele, ci s\u0103 trimi\u021bi la stocare doar o parte - de exemplu, jurnalele cu statut \u00abwarning\u00bb sau \u00aberror\u00bb. Dac\u0103 vorbim despre jurnalele nginx sau ale controlerelor de ingress, atunci se pot trimite la stocare doar cele care au un statut diferit de 200. Dar acest lucru nu este un sfat universal: dac\u0103 construie\u0219ti cumva analize pe jurnalele Nginx, atunci evident c\u0103 ar trebui s\u0103 le colectezi. <\/p>\n

<\/p>\n

Nu este recomandat s\u0103 filtrezi jurnalele f\u0103r\u0103 discern\u0103m\u00e2nt, deoarece datele filtrate ar putea s\u0103 nu fie suficiente pentru o analiz\u0103 normal\u0103. Pe de alt\u0103 parte, poate analizele ar trebui s\u0103 se fac\u0103 nu la nivel de jurnalizare, ci la nivel de colectare a metricilor. Atunci nu va fi necesar s\u0103 stochezi sute de mii de r\u00e2nduri cu cod 200. Una dintre abord\u0103ri este s\u0103 ob\u021bii informa\u021bii despre trafic \u0219i erori din metricile controlerelor de ingress. <\/p>\n

<\/p>\n

\u00cen general, trebuie s\u0103 te g\u00e2nde\u0219ti bine: ce vrei s\u0103 stochezi \u0219i c\u00e2t timp, deoarece altfel va ap\u0103rea o situa\u021bie \u00een care sistemul de jurnalizare va consuma mai multe resurse dec\u00e2t proiectul principal.<\/p>\n

<\/p>\n

Momentan nu exist\u0103 o solu\u021bie standard pentru jurnalizare<\/strong>. Spre deosebire de monitorizare, unde exist\u0103 o solu\u021bie preponderent\u0103, Prometheus, \u00een jurnalizare nu exist\u0103 un standard. <\/p>\n

<\/p>\n

\u00cen cadrul acestei lec\u021bii, vom examina dou\u0103 instrumente: unul popular \u0219i cel\u0103lalt - \u00een cre\u0219tere. Pe l\u00e2ng\u0103 acestea, exist\u0103 \u0219i altele, dar \u00een acest articol nu le vom aborda.<\/p>\n

<\/p>\n

Av\u00e2nd \u00een vedere toate caracteristicile discutate anterior, jurnalizarea \u00een Kubernetes poate fi acum reprezentat\u0103 \u00een acest mod:<\/p>\n

<\/p>\n

\"Logarea<\/p>\n

<\/p>\n

R\u0103m\u00e2ne jurnalul containerului, rotirea, dar apare un agent colector, care adun\u0103 jurnalele \u0219i le trimite la stocare (\u00een diagram\u0103 - \u00een Logging Backend). Agentul func\u021bioneaz\u0103 pe fiecare nod \u0219i, \u00een general, este pornit \u00een Kubernetes.<\/p>\n

<\/p>\n

Acum s\u0103 discut\u0103m despre instrumentele de logging.<\/p>\n

<\/p>\n

\u2014 noul nostru sistem de agregare a log-urilor, \u2014 care a ajutat s\u0103 ne asigur\u0103m c\u0103 toate Ingester-urile s-au comportat corect \u00een timpul \u0219i dup\u0103 e\u0219ec.<\/h2>\n

<\/p>\n

\u2014 noul nostru sistem de agregare a log-urilor, \u2014 care a ajutat s\u0103 ne asigur\u0103m c\u0103 toate Ingester-urile s-au comportat corect \u00een timpul \u0219i dup\u0103 e\u0219ec.<\/a><\/noindex> a ap\u0103rut recent, dar a devenit deja destul de cunoscut. Avantajele sale sunt: se instaleaz\u0103 u\u0219or, consum\u0103 pu\u021bine resurse \u0219i nu necesit\u0103 instalarea Elasticsearch, deoarece stocheaz\u0103 datele \u00een TSDB (baze de date pentru serii temporale). \u00cen articolul trecut, am men\u021bionat c\u0103 Prometheus stocheaz\u0103 date \u00een astfel de baze, \u0219i aceasta este una dintre numeroasele asem\u0103n\u0103ri \u00eentre cele dou\u0103 produse. Dezvoltatorii afirm\u0103 chiar c\u0103 Loki este 'Prometheus pentru lumea logging-ului'.<\/p>\n

<\/p>\n

O mic\u0103 digresiune despre TSDB pentru cei care nu au citit. articolul anterior<\/a><\/noindex>: TSDB se descurc\u0103 excelent cu sarcina de a stoca cantit\u0103\u021bi mari de date \u0219i serii temporale, dar nu este destinat pentru stocarea pe termen lung. Dac\u0103 din vreun motiv trebuie s\u0103 p\u0103stra\u021bi logurile mai mult de dou\u0103 s\u0103pt\u0103m\u00e2ni, ar fi mai bine s\u0103 le configura\u021bi pentru a fi transferate \u00een alt\u0103 baz\u0103 de date.<\/p>\n

<\/p>\n

Un alt avantaj al lui Loki este c\u0103 pentru vizualizarea datelor se folose\u0219te Grafana. Este foarte convenabil: \u00een Grafana vizualiz\u0103m datele de monitorizare \u0219i tot acolo, conect\u00e2nd Loki, putem vedea logurile. Din loguri se pot construi grafice.<\/p>\n

<\/p>\n

Arhitectura lui Loki arat\u0103 cam a\u0219a: <\/p>\n

<\/p>\n

\"Logarea<\/p>\n

<\/p>\n

Prin intermediul DaemonSet, pe toate serverele din cluster se desf\u0103\u0219oar\u0103 un agent \u2014 Promtail sau Fluent Bit. Agentul colecteaz\u0103 logurile. Loki le preia \u0219i le stocheaz\u0103 \u00een TSDB. Logurile sunt imediat ad\u0103ugate cu metadate, ceea ce este convenabil: se poate filtra dup\u0103 Pods, namespaces, numele containerelor \u0219i chiar dup\u0103 etichete.<\/p>\n

<\/p>\n

Instruc\u021biuni pentru instalarea lui Loki<\/a><\/noindex><\/p>\n

<\/p>\n

Loki func\u021bioneaz\u0103 \u00eentr-un mediu familiar Grafana. Loki are chiar \u0219i un propriul limbaj de interogare, numit LogQL \u2014 care, dup\u0103 denumire \u0219i sintax\u0103, seam\u0103n\u0103 cu PromQL din Prometheus. \u00cen interfa\u021ba lui Loki exist\u0103 sugestii pentru interog\u0103ri, a\u0219a c\u0103 nu trebuie s\u0103 le \u021bii minte pe de rost.<\/p>\n

<\/p>\n

Documenta\u021bia pentru limbajul LogQL<\/a><\/noindex><\/p>\n

<\/p>\n

\"Logarea
\nLoki \u00een interfa\u021ba Grafana<\/em><\/p>\n

<\/p>\n

Folosind filtre, \u00een Loki po\u021bi g\u0103si coduri ('400', '404' \u0219i orice altul); po\u021bi vizualiza logurile de pe \u00eentreaga nod; po\u021bi filtra toate logurile care con\u021bin cuv\u00e2ntul 'eroare'. Dac\u0103 dai clic pe un log, se va deschide un card cu toate informa\u021biile despre eveniment.<\/p>\n

<\/p>\n

\u00cen Loki exist\u0103 suficiente instrumente care permit extragerea logurilor dorite, de\u0219i, onest vorbind, tehnic ar putea fi mai multe. Acum Loki este \u00een dezvoltare activ\u0103 \u0219i c\u00e2\u0219tig\u0103 popularitate. <\/p>\n

<\/p>\n

Elastic + Fluent Bit + Kibana (Stiva EFK)<\/h2>\n

<\/p>\n

Stiva EFK este un instrument de logging mai clasic \u0219i, \u00een acela\u0219i timp, la fel de popular. <\/p>\n

<\/p>\n

La \u00eenceputul articolului s-a men\u021bionat ELK (Elasticsearch + Logstash + Kibana), dar aceast\u0103 stiv\u0103 a devenit \u00eenvechit\u0103 din cauza lui Logstash, care nu este prea performant \u0219i consum\u0103 multe resurse. \u00cen locul s\u0103u, a \u00eenceput s\u0103 fie utilizat agentul mai u\u0219or \u0219i mai performant Fluentd, iar dup\u0103 un timp acesta a fost ajutat de Fluent Bit<\/a><\/noindex> \u2014 un agent de colectare \u0219i mai u\u0219or \u0219i \u0219i mai performant. <\/p>\n

<\/p>\n

Dac\u0103 este s\u0103 credem dezvoltatorii, Fluent Bit este de peste 100 de ori mai performant dec\u00e2t Fluentd: \u201eacolo unde Fluentd consum\u0103 20 MB de RAM, Fluent Bit va consuma 150 KB\u201d \u2014 citat direct din documenta\u021bie. Av\u00e2nd \u00een vedere acest lucru, Fluent Bit este utilizat mai frecvent.<\/p>\n

<\/p>\n

Fluent Bit are mai pu\u021bine func\u021bionalit\u0103\u021bi dec\u00e2t Fluentd, dar acoper\u0103 cerin\u021bele de baz\u0103, a\u0219a c\u0103 noi folosim de obicei Fluent Bit.<\/p>\n

<\/p>\n

Schema de lucru a stivei EFK: agentul colecteaz\u0103 jurnalele din toate podurile (de obicei, un DaemonSet care ruleaz\u0103 pe toate serverele clusterului) \u0219i le trimite \u00een stocare (Elasticsearch, PostgreSQL sau Kafka). Kibana se conecteaz\u0103 la stocare \u0219i extrage toate informa\u021biile necesare.<\/p>\n

<\/p>\n

\"Logarea<\/p>\n

<\/p>\n

Kibana<\/a><\/noindex> ofer\u0103 informa\u021biile \u00eentr-o interfa\u021b\u0103 web convenabil\u0103. Exist\u0103 grafice, filtre \u0219i multe altele.<\/p>\n

<\/p>\n

\"Logarea<\/p>\n

<\/p>\n

Din jurnale se pot crea tablouri de bord complete.<\/p>\n

<\/p>\n

\"Logarea<\/p>\n

<\/p>\n

Func\u021bionalit\u0103\u021bile Fluent Bit<\/h2>\n

<\/p>\n

Deoarece despre Fluent Bit, \u00een general, s-a auzit mai pu\u021bin dec\u00e2t despre Logstash, s\u0103-l examin\u0103m un pic mai \u00een detaliu. Fluent Bit poate fi logic \u00eemp\u0103r\u021bit \u00een 6 module, unele dintre module pot avea pluginuri care extind func\u021bionalit\u0103\u021bile Fluent Bit.<\/p>\n

<\/p>\n

\"Logarea<\/p>\n

<\/p>\n

Modul Input<\/strong> colecteaz\u0103 jurnale din fi\u0219iere, servicii systemd \u0219i chiar din tcp-socket (trebuie doar s\u0103 specifici endpoint-ul, iar Fluent Bit va \u00eencepe s\u0103 acceseze acea adres\u0103). Aceste func\u021bionalit\u0103\u021bi sunt suficiente pentru a colecta jurnale at\u00e2t din sistem, c\u00e2t \u0219i din containere.<\/p>\n

<\/p>\n

\u00cen produc\u021bie, de obicei, folosim pluginuri tail<\/a><\/noindex> (poate fi direc\u021bionat c\u0103tre un folder cu jurnale) \u0219i systemd<\/a><\/noindex> (\u00eei po\u021bi spune din ce servicii s\u0103 adune jurnale).<\/p>\n

<\/p>\n

Modul Parser<\/strong> transform\u0103 jurnalele \u00eentr-un format comun. \u00cen mod implicit, jurnalele Nginx sunt reprezentate ca un \u0219ir de caractere. Cu ajutorul pluginului, acest \u0219ir poate fi transformat \u00een JSON: se pot specifica c\u00e2mpuri \u0219i valorile acestora. Lucrul cu JSON este mult mai simplu dec\u00e2t cu un jurnal \u00een format de \u0219ir de caractere, deoarece exist\u0103 op\u021biuni mai flexibile de sortare.<\/p>\n

<\/p>\n

Modul Filter<\/strong>. La acest nivel sunt eliminat jurnalele nedorite. De exemplu, pentru stocare sunt trimise doar jurnalele cu valoarea \u201ewarning\u201d sau cu anumite etichete. Jurnalele selectate ajung \u00een buffer.<\/p>\n

<\/p>\n

Modul Buffer<\/strong>. Fluent Bit are dou\u0103 tipuri de buffer: buffer \u00een memorie \u0219i buffer pe disc. Buffer-ul este un spa\u021biu de stocare temporar pentru jurnalele de logare, necesar \u00een caz de erori sau defec\u021biuni. Toat\u0103 lumea vrea s\u0103 economiseasc\u0103 pe RAM, a\u0219a c\u0103 de obicei se aleg buffer-ele pe disc. Dar trebuie avut \u00een vedere c\u0103 jurnalele sunt totu\u0219i desc\u0103rcate \u00een memorie \u00eenainte de a fi scrise pe disc.<\/p>\n

<\/p>\n

Modulul Routing\/Output<\/strong> con\u021bine reguli \u0219i adrese pentru trimiterea jurnalelor. A\u0219a cum am men\u021bionat, jurnalele pot fi trimise \u00een Elasticsearch, PostgreSQL sau, de exemplu, Kafka. <\/p>\n

<\/p>\n

Interesant este c\u0103 din Fluent Bit jurnalele pot fi trimise \u00een Fluentd. Fiindc\u0103 primul este mai u\u0219or \u0219i mai pu\u021bin func\u021bional, prin el se pot colecta jurnalele \u0219i trimite \u00een Fluentd, iar acolo, folosind pluginuri suplimentare, ele pot fi procesate \u0219i trimise \u00een stoc\u0103ri.<\/p>\n

<\/p>\n

Dac\u0103 pl\u0103nui\u021bi s\u0103 folosi\u021bi Elasticsearch\u2026<\/p>\n

\u00cen final, dou\u0103 sfaturi pentru cei care pl\u0103nuiesc s\u0103 foloseasc\u0103 Elasticsearch ca stocare de jurnale \u00een produc\u021bie. <\/p>\n

    \n
  1. Configura\u021bi alerte folosind ElastAlert<\/a><\/noindex>. Acest program extrage din fluxul general de jurnale mesajele importante \u0219i face alerte pe mail sau \u00een alt canal. Totu\u0219i, nu cu mult timp \u00een urm\u0103 a ap\u0103rut o veste trist\u0103 c\u0103 proiectul ar putea \u00eenceta cur\u00e2nd s\u0103 existe.<\/a><\/noindex><\/em>.<\/li>\n
  2. Rotunji\u021bi jurnalele folosind aplica\u021bia Curator<\/a><\/noindex> sau apel\u00e2nd API-ul Elasticsearch. Elastic, \u00een principiu, face acum pa\u0219i semnificativi \u00een gestionarea vie\u021bii indexurilor f\u0103r\u0103 a folosi instrumente externe. \u00cen general, nu are nici un sens s\u0103 p\u0103stra\u021bi jurnalele mult timp: este pu\u021bin probabil ca un jurnal s\u0103 fie necesar dup\u0103 dou\u0103 s\u0103pt\u0103m\u00e2ni \u2014 dac\u0103 este cu adev\u0103rat critic, \u00een dou\u0103 s\u0103pt\u0103m\u00e2ni cu siguran\u021b\u0103 va fi procesat. \u00cen caz extrem, jurnalele vechi pot fi arhivate \u0219i trimise undeva pentru stocare pe termen lung. Am auzit despre jurnale speciale care trebuie p\u0103strate prin lege timp de 5 ani. Personal, nu m-am \u00eent\u00e2lnit cu a\u0219a ceva, dar a\u0219 trata astfel de informa\u021bii diferit de jurnalele obi\u0219nuite, \u0219i poate chiar le-a\u0219 p\u0103stra separat.<\/li>\n<\/ol>\n

    \n<\/p><\/blockquote>\n

    Continuarea urmeaz\u0103\u2026<\/p>\n

    <\/p>\n

    Autor: Marcel Ibraev, administrator certificat Kubernetes, inginer practicant la compania Southbridge<\/a><\/noindex>, speaker \u0219i dezvoltator de cursuri Slurm<\/a><\/noindex>.<\/em><\/p>\n

    Sursa: habr.com<\/a> <\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"

    \u0420\u0430\u0437\u0431\u0435\u0440\u0451\u043c \u043e\u0441\u043d\u043e\u0432\u044b \u043b\u043e\u0433\u0438\u0440\u043e\u0432\u0430\u043d\u0438\u044f \u0432 Docker \u0438 Kubernetes, \u0430 \u0437\u0430\u0442\u0435\u043c \u0440\u0430\u0441\u0441\u043c\u043e\u0442\u0440\u0438\u043c \u0434\u0432\u0430 \u0438\u043d\u0441\u0442\u0440\u0443\u043c\u0435\u043d\u0442\u0430, \u043a\u043e\u0442\u043e\u0440\u044b\u0435 \u043c\u043e\u0436\u043d\u043e \u0441\u043c\u0435\u043b\u043e \u0438\u0441\u043f\u043e\u043b\u044c\u0437\u043e\u0432\u0430\u0442\u044c \u043d\u0430 \u043f\u0440\u043e\u0434\u0430\u043a\u0448\u0435\u043d\u0435: Grafana Loki \u0438 \u0441\u0442\u0435\u043a EFK (Elasticsearch + Fluent Bit + Kibana). \u041c\u0430\u0442\u0435\u0440\u0438\u0430\u043b \u0441\u0442\u0430\u0442\u044c\u0438 \u2014 \u0432\u044b\u0436\u0438\u043c\u043a\u0430 \u0438\u0437 \u043e\u0442\u043a\u0440\u044b\u0442\u043e\u0439 \u043b\u0435\u043a\u0446\u0438\u0438 \u0448\u043a\u043e\u043b\u044b \u00ab\u0421\u043b\u0451\u0440\u043c\u00bb. \u0415\u0441\u043b\u0438 \u0435\u0441\u0442\u044c \u0436\u0435\u043b\u0430\u043d\u0438\u0435 \u0438 \u0442\u0435\u043c \u0431\u043e\u043b\u0435\u0435 \u043f\u0440\u043e\u0438\u0437\u0432\u043e\u0434\u0441\u0442\u0432\u0435\u043d\u043d\u0430\u044f \u043d\u0435\u043e\u0431\u0445\u043e\u0434\u0438\u043c\u043e\u0441\u0442\u044c \u043c\u043e\u0436\u043d\u043e \u043f\u0440\u043e\u0439\u0442\u0438 \u043f\u043e\u043b\u043d\u043e\u0435 \u043e\u0431\u0443\u0447\u0435\u043d\u0438\u0435 \u2014 \u0437\u0430\u043f\u0438\u0441\u044b\u0432\u0430\u0439\u0442\u0435\u0441\u044c \u043d\u0430 \u043a\u0443\u0440\u0441 \u043f\u043e […]<\/p>\n","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"author":1,"featured_media":93295,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[688],"tags":[],"class_list":["post-93294","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-administrirovanie"],"aioseo_notices":[],"aioseo_head":"\n\t\t\n\t\n\t\n\t\n\t\n\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\n","aioseo_head_json":{"title":"\ud83e\udd47\u00cenregistrarea jurnalelor \u00een Kubernetes: cum s\u0103 colectezi, s\u0103 stochezi, s\u0103 parsezi \u0219i s\u0103 procesezi jurnalele | ProHoster","description":"Vom analiza principiile de baz\u0103 ale \u00eenregistr\u0103rii jurnalelor \u00een Docker \u0219i Kubernetes, apoi vom examina dou\u0103 instrumente care pot fi utilizate \u00een produc\u021bie: Grafana Loki \u0219i stiva EFK (Elasticsearch + Fluent Bit + Kibana).","canonical_url":"https:\/\/prohoster.info\/ro\/blog\/administrirovanie\/logirovanie-v-kubernetes-kak-sobirat-hranit-parsit-i-obrabatyvat-logi","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"ro_RO","og:site_name":"ProHoster | \u041a\u0443\u043f\u0438\u0442\u044c \u043d\u0430\u0434\u0435\u0436\u043d\u044b\u0439 \u0445\u043e\u0441\u0442\u0438\u043d\u0433 \u0434\u043b\u044f \u0441\u0430\u0439\u0442\u043e\u0432 \u0441 \u0437\u0430\u0449\u0438\u0442\u043e\u0439 \u043e\u0442 DDoS, VPS VDS \u0441\u0435\u0440\u0432\u0435\u0440\u044b","og:type":"article","og:title":"\ud83e\udd47\u041b\u043e\u0433\u0438\u0440\u043e\u0432\u0430\u043d\u0438\u0435 \u0432 Kubernetes: \u043a\u0430\u043a \u0441\u043e\u0431\u0438\u0440\u0430\u0442\u044c, \u0445\u0440\u0430\u043d\u0438\u0442\u044c, \u043f\u0430\u0440\u0441\u0438\u0442\u044c \u0438 \u043e\u0431\u0440\u0430\u0431\u0430\u0442\u044b\u0432\u0430\u0442\u044c \u043b\u043e\u0433\u0438 | ProHoster","og:description":"\u0420\u0430\u0437\u0431\u0435\u0440\u0451\u043c \u043e\u0441\u043d\u043e\u0432\u044b \u043b\u043e\u0433\u0438\u0440\u043e\u0432\u0430\u043d\u0438\u044f \u0432 Docker \u0438 Kubernetes, \u0430 \u0437\u0430\u0442\u0435\u043c \u0440\u0430\u0441\u0441\u043c\u043e\u0442\u0440\u0438\u043c \u0434\u0432\u0430 \u0438\u043d\u0441\u0442\u0440\u0443\u043c\u0435\u043d\u0442\u0430, \u043a\u043e\u0442\u043e\u0440\u044b\u0435 \u043c\u043e\u0436\u043d\u043e \u0441\u043c\u0435\u043b\u043e \u0438\u0441\u043f\u043e\u043b\u044c\u0437\u043e\u0432\u0430\u0442\u044c \u043d\u0430 \u043f\u0440\u043e\u0434\u0430\u043a\u0448\u0435\u043d\u0435: Grafana Loki \u0438 \u0441\u0442\u0435\u043a EFK (Elasticsearch + Fluent Bit + Kibana)..","og:url":"https:\/\/prohoster.info\/ro\/blog\/administrirovanie\/logirovanie-v-kubernetes-kak-sobirat-hranit-parsit-i-obrabatyvat-logi","og:image":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:secure_url":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:width":350,"og:image:height":350,"article:published_time":"2020-09-05T05:42:58+00:00","article:modified_time":"2020-09-05T05:42:58+00:00","article:publisher":"https:\/\/www.facebook.com\/prohoster","article:author":"https:\/\/www.facebook.com\/prohoster"},"aioseo_meta_data":{"post_id":"93294","title":null,"description":null,"keywords":null,"keyphrases":null,"primary_term":null,"canonical_url":null,"og_title":null,"og_description":null,"og_object_type":"default","og_image_type":"default","og_image_url":null,"og_image_width":null,"og_image_height":null,"og_image_custom_url":null,"og_image_custom_fields":null,"og_video":null,"og_custom_url":null,"og_article_section":null,"og_article_tags":null,"twitter_use_og":false,"twitter_card":"default","twitter_image_type":"default","twitter_image_url":null,"twitter_image_custom_url":null,"twitter_image_custom_fields":null,"twitter_title":null,"twitter_description":null,"schema":{"blockGraphs":[],"customGraphs":[],"default":{"data":{"Article":[],"Course":[],"Dataset":[],"FAQPage":[],"Movie":[],"Person":[],"Product":[],"ProductReview":[],"Car":[],"Recipe":[],"Service":[],"SoftwareApplication":[],"WebPage":[]},"graphName":"","isEnabled":true},"graphs":[]},"schema_type":null,"schema_type_options":null,"pillar_content":false,"robots_default":true,"robots_noindex":false,"robots_noarchive":false,"robots_nosnippet":false,"robots_nofollow":false,"robots_noimageindex":false,"robots_noodp":false,"robots_notranslate":false,"robots_max_snippet":null,"robots_max_videopreview":null,"robots_max_imagepreview":"large","priority":null,"frequency":null,"local_seo":null,"seo_analyzer_scan_date":null,"breadcrumb_settings":null,"limit_modified_date":false,"reviewed_by":null,"ai":null,"created":"2021-02-28 11:50:29","updated":"2022-09-27 18:43:48","focus_keyword":null,"additional_keywords":null,"truseo_locale":null},"gt_translate_keys":[{"key":"link","format":"url"}],"_links":{"self":[{"href":"https:\/\/prohoster.info\/ro\/wp-json\/wp\/v2\/posts\/93294","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/ro\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/ro\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/ro\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/ro\/wp-json\/wp\/v2\/comments?post=93294"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/ro\/wp-json\/wp\/v2\/posts\/93294\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/prohoster.info\/ro\/wp-json\/wp\/v2\/media\/93295"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/ro\/wp-json\/wp\/v2\/media?parent=93294"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/ro\/wp-json\/wp\/v2\/categories?post=93294"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/ro\/wp-json\/wp\/v2\/tags?post=93294"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}