🥇Mbledhja e shkrimeve nga Loki

Në Badoo, ne monitorojmë vazhdimisht teknologjitë e reja dhe vlerësojmë nëse ato ia vlen të përdoren në sistemin tonë. Ne dëshirojmë të ndajmë një nga këto studime me komunitetin. Ai i kushtohet Loki, një sistem grumbullimi i regjistrave.

Loki është një zgjidhje për ruajtjen dhe shikimin e regjistrave, dhe kjo pirg gjithashtu ofron një sistem fleksibël për analizimin e tyre dhe dërgimin e të dhënave te Prometheus. Në maj, u lëshua një azhurnim tjetër, i cili promovohet në mënyrë aktive nga krijuesit. Ne ishim të interesuar se çfarë mund të bëjë Loki, çfarë aftësish ofron dhe në çfarë mase mund të veprojë si një alternativë ndaj ELK-së, grupit që ne përdorim tani.

Çfarë është Loki

Grafana Loki është një grup komponentësh për një sistem të plotë për të punuar me shkrimet. Ndryshe nga sistemet e tjera të ngjashme, Loki bazohet në idenë e indeksimit të vetëm të meta të dhënave të regjistrave - etiketave (njëlloj si në Prometheus), dhe ngjeshjes së vetë regjistrave në copa të veçanta.

Домашняя страница, GitHub

Para se të futemi në atë që mund të bëni me Loki, dua të sqaroj se çfarë nënkuptojmë me "idenë e indeksimit vetëm të meta të dhënave". Le të krahasojmë qasjen Loki dhe qasjen ndaj indeksimit në zgjidhjet tradicionale si Elasticsearch, duke përdorur shembullin e një rreshti nga regjistri nginx:

172.19.0.4 - - [01/Jun/2020:12:05:03 +0000] "GET /purchase?user_id=75146478&amp;item_id=34234 HTTP/1.1" 500 8102 "-" "Stub_Bot/3.0" "0.001"

Sistemet tradicionale analizojnë të gjithë rreshtin, duke përfshirë fushat me një numër të madh vlerash unike user_id dhe item_id, dhe ruajnë gjithçka në indekse të mëdha. Avantazhi i kësaj qasjeje është se ju mund të ekzekutoni shpejt pyetje komplekse, pasi pothuajse të gjitha të dhënat janë në indeks. Por kjo ka një kosto në atë që indeksi bëhet i madh, gjë që përkthehet në kërkesa për memorie. Si rezultat, indeksi i regjistrit të tekstit të plotë është i krahasueshëm në madhësi me vetë regjistrat. Për të kërkuar shpejt nëpër të, indeksi duhet të ngarkohet në memorie. Dhe sa më shumë regjistra, aq më shpejt rritet indeksi dhe aq më shumë memorie konsumon.

Qasja Loki kërkon që vetëm të dhënat e nevojshme të nxirren nga një varg, numri i vlerave të të cilit është i vogël. Në këtë mënyrë marrim një indeks të vogël dhe mund t'i kërkojmë të dhënat duke i filtruar sipas kohës dhe sipas fushave të indeksuara, dhe më pas duke skanuar pjesën tjetër me shprehje të rregullta ose kërkim të nënvargut. Procesi nuk duket si më i shpejti, por Loki e ndan kërkesën në disa pjesë dhe i ekzekuton ato paralelisht, duke përpunuar një sasi të madhe të dhënash në një kohë të shkurtër. Numri i copëzave dhe kërkesave paralele në to është i konfigurueshëm; Kështu, sasia e të dhënave që mund të përpunohen për njësi të kohës varet në mënyrë lineare nga sasia e burimeve të ofruara.

Ky shkëmbim ndërmjet një indeksi të madh, të shpejtë dhe një indeksi të vogël, paralel të forcës brutale, lejon Loki të kontrollojë koston e sistemit. Mund të konfigurohet dhe zgjerohet në mënyrë fleksibël sipas nevojave.

Stacki Loki përbëhet nga tre komponentë: Promtail, Loki, Grafana. Promtail mbledh regjistrat, i përpunon dhe i dërgon te Loki. Loki i mban ato. Dhe Grafana mund të kërkojë të dhëna nga Loki dhe t'i shfaqë ato. Në përgjithësi, Loki mund të përdoret jo vetëm për ruajtjen e shkrimeve dhe kërkimin nëpër to. I gjithë pirgu ofron mundësi të mëdha për përpunimin dhe analizimin e të dhënave hyrëse duke përdorur mënyrën Prometheus.
Mund të gjendet një përshkrim i procesit të instalimit këtu.

Kërko sipas regjistrave

Ju mund të kërkoni regjistrat në një ndërfaqe të veçantë Grafana - Explorer. Pyetjet përdorin gjuhën LogQL, e cila është shumë e ngjashme me PromQL të përdorur në Prometheus. Në parim, mund të mendohet si një grep i shpërndarë.

Ndërfaqja e kërkimit duket si kjo:

Vetë kërkesa përbëhet nga dy pjesë: përzgjedhësi dhe filtri. Selektori është një kërkim duke përdorur meta të dhëna të indeksuar (etiketa) që u janë caktuar regjistrave dhe filtri është një varg kërkimi ose regexp që filtron të dhënat e përcaktuara nga përzgjedhësi. Në shembullin e dhënë: Në mbajtëset kaçurrelë ka një përzgjedhës, çdo gjë pas është një filtër.

{image_name="nginx.promtail.test"} |= "index"

Për shkak të mënyrës se si funksionon Loki, nuk mund të bësh pyetje pa një përzgjedhës, por etiketat mund të bëhen aq të përgjithshme sa të duash.

Një përzgjedhës është një vlerë me vlerë kyçe në mbajtëset kaçurrelë. Ju mund të kombinoni përzgjedhës dhe të specifikoni kushte të ndryshme kërkimi duke përdorur operatorët =, != ose shprehjet e rregullta:

{instance=~"kafka-[23]",name!="kafka-dev"} 
// Найдёт логи с лейблом instance, имеющие значение kafka-2, kafka-3, и исключит dev

Një filtër është tekst ose regexp që do të filtrojë të gjitha të dhënat e marra nga përzgjedhësi.

Është e mundur të merren grafikë ad-hoc bazuar në të dhënat e marra në modalitetin metrikë. Për shembull, mund të zbuloni se sa shpesh shfaqet një hyrje që përmban indeksin e vargut në regjistrat e nginx:

Një përshkrim i plotë i aftësive mund të gjendet në dokumentacion LogQL.

Analiza e regjistrave

Ka disa mënyra për të mbledhur shkrimet:

Duke përdorur Promtail, një komponent standard i pirgut për mbledhjen e shkrimeve.
Direkt nga kontejneri docker duke përdorur Shofer Loki Docker Logging.
Përdorni Fluentd ose Fluent Bit, të cilat mund të dërgojnë të dhëna te Loki. Ndryshe nga Promtail, ata kanë analizues të gatshëm për pothuajse çdo lloj regjistri dhe gjithashtu mund të trajtojnë regjistrat me shumë linja.

Zakonisht Promtail përdoret për analizë. Ai bën tre gjëra:

Gjen burimet e të dhënave.
U bashkangjit atyre etiketa.
Dërgon të dhëna te Loki.

Aktualisht Promtail mund të lexojë regjistrat nga skedarët lokalë dhe nga ditari systemd. Duhet të instalohet në secilën makinë nga e cila mblidhen shkrimet.

Ka integrim me Kubernetes: Promtail automatikisht, përmes Kubernetes REST API, njeh gjendjen e grupit dhe mbledh regjistrat nga një nyje, shërbim ose pod, duke postuar menjëherë etiketat bazuar në meta të dhënat nga Kubernetes (emri i pod, emri i skedarit, etj.) .

Ju gjithashtu mund të varni etiketat bazuar në të dhënat nga regjistri duke përdorur Pipeline. Pipeline Promtail mund të përbëhet nga katër lloje fazash. Më shumë detaje në dokumentacion zyrtar, do të vërej menjëherë disa nuanca.

Fazat e analizimit. Kjo është faza RegEx dhe JSON. Në këtë fazë, ne nxjerrim të dhëna nga regjistrat në të ashtuquajturën harta e nxjerrë. Ne mund të nxjerrim nga JSON thjesht duke kopjuar fushat që na nevojiten në hartën e nxjerrë, ose përmes shprehjeve të rregullta (RegEx), ku grupet e emërtuara janë "hartë" në hartën e nxjerrë. Harta e Ekstraktuar është një depo me vlerë kyçe, ku çelësi është emri i fushës dhe vlera është vlera e saj nga regjistrat.
Transformoni fazat. Kjo fazë ka dy opsione: transformimin, ku vendosim rregullat e transformimit, dhe burimin - burimin e të dhënave për transformimin nga harta e nxjerrë. Nëse nuk ka një fushë të tillë në hartën e nxjerrë, ajo do të krijohet. Në këtë mënyrë është e mundur të krijohen etiketa që nuk bazohen në hartën e nxjerrë. Në këtë fazë ne mund të manipulojmë të dhënat në hartën e nxjerrë duke përdorur një model mjaft të fuqishëm Modeli Golang. Përveç kësaj, duhet të kujtojmë se harta e nxjerrë ngarkohet tërësisht gjatë analizimit, gjë që bën të mundur, për shembull, kontrollimin e vlerës në të: “{{nëse .tag}vlera e etiketës ekziston{end}}”. Modeli mbështet kushte, sythe dhe disa funksione të vargut si Replace dhe Trim.
Fazat e veprimit. Në këtë pikë mund të bëni diçka me përmbajtjen e nxjerrë:
- Krijo një etiketë nga të dhënat e nxjerra, e cila do të indeksohet nga Loki.
- Ndryshoni ose vendosni kohën e ngjarjes nga regjistri.
- Ndryshoni të dhënat (teksti i regjistrit) që do të shkojnë te Loki.
- Krijo metrikë.
Fazat e filtrimit. Faza e ndeshjes, ku ne mund t'i dërgojmë hyrjet që nuk na duhen /dev/null ose t'i përcjellim për përpunim të mëtejshëm.

Duke përdorur një shembull të përpunimit të regjistrave të rregullt të nginx, unë do të tregoj se si mund të analizoni regjistrat duke përdorur Promtail.

Për provën, le të marrim si nginx-proxy një imazh të modifikuar nginx jwilder/nginx-proxy:alpine dhe një daemon të vogël që mund të pyesë veten nëpërmjet HTTP. Daemon ka disa pika fundore, për të cilat mund të japë përgjigje të madhësive të ndryshme, me statuse të ndryshme HTTP dhe me vonesa të ndryshme.

Ne do të mbledhim shkrime nga kontejnerët docker, të cilët mund të gjenden përgjatë shtegut /var/lib/docker/containers/ / -json.log

Në docker-compose.yml ne konfigurojmë Promtail dhe specifikojmë rrugën drejt konfigurimit:

promtail:
  image: grafana/promtail:1.4.1
 // ...
 volumes:
   - /var/lib/docker/containers:/var/lib/docker/containers:ro
   - promtail-data:/var/lib/promtail/positions
   - ${PWD}/promtail/docker.yml:/etc/promtail/promtail.yml
 command:
   - '-config.file=/etc/promtail/promtail.yml'
 // ...

Shtoni shtegun e regjistrave te promtail.yml (ekziston një opsion "docker" në konfigurim, i cili bën të njëjtën gjë në një rresht, por nuk do të ishte aq e qartë):

scrape_configs:
 - job_name: containers

   static_configs:
       labels:
         job: containerlogs
         __path__: /var/lib/docker/containers/*/*log  # for linux only

Kur aktivizohet ky konfigurim, regjistrat nga të gjithë kontejnerët do të dërgohen te Loki. Për të shmangur këtë, ne ndryshojmë cilësimet e testit nginx në docker-compose.yml - shtoni një fushë të etiketës së regjistrimit:

proxy:
 image: nginx.test.v3
//…
 logging:
   driver: "json-file"
   options:
     tag: "{{.ImageName}}|{{.Name}}"

Redaktimi i promtail.yml dhe konfigurimi i Pipeline. Hyrja përfshin regjistrat e llojit të mëposhtëm:

{"log":"u001b[0;33;1mnginx.1    | u001b[0mnginx.test 172.28.0.3 - - [13/Jun/2020:23:25:50 +0000] "GET /api/index HTTP/1.1" 200 0 "-" "Stub_Bot/0.1" "0.096"n","stream":"stdout","attrs":{"tag":"nginx.promtail.test|proxy.prober"},"time":"2020-06-13T23:25:50.66740443Z"}
{"log":"u001b[0;33;1mnginx.1    | u001b[0mnginx.test 172.28.0.3 - - [13/Jun/2020:23:25:50 +0000] "GET /200 HTTP/1.1" 200 0 "-" "Stub_Bot/0.1" "0.000"n","stream":"stdout","attrs":{"tag":"nginx.promtail.test|proxy.prober"},"time":"2020-06-13T23:25:50.702925272Z"}

Faza e tubacionit:

 - json:
     expressions:
       stream: stream
       attrs: attrs
       tag: attrs.tag

Ne nxjerrim fushat stream, attrs, attrs.tag (nëse ekzistojnë) nga JSON-i në hyrje dhe i vendosim në hartën e nxjerrë.

 - regex:
     expression: ^(?P<image_name>([^|]+))|(?P<container_name>([^|]+))$
     source: "tag"

Nëse kemi arritur të vendosim fushën e etiketës në hartën e nxjerrë, atëherë duke përdorur regexp nxjerrim emrat e imazhit dhe kontejnerit.

 - labels:
     image_name:
     container_name:

Ne caktojmë etiketa. Nëse në të dhënat e nxjerra gjenden çelësat image_name dhe container_name, atëherë vlerat e tyre do t'u caktohen etiketave përkatëse.

 - match:
     selector: '{job="docker",container_name="",image_name=""}'
     action: drop

Ne i hedhim poshtë të gjithë regjistrat që nuk kanë të instaluar etiketat image_name dhe container_name.

  - match:
     selector: '{image_name="nginx.promtail.test"}'
     stages:
       - json:
           expressions:
             row: log

Për të gjithë regjistrat emri i imazhit të të cilëve është nginx.promtail.test, nxirrni fushën e regjistrit nga regjistri i burimit dhe vendoseni në hartën e nxjerrë me tastin e rreshtit.

  - regex:
         # suppress forego colors
         expression: .+nginx.+|.+[0m(?P<virtual_host>[a-z_.-]+) +(?P<nginxlog>.+)
         source: logrow

Ne pastrojmë linjën e hyrjes me shprehje të rregullta dhe nxjerrim hostin virtual nginx dhe linjën log nginx.

     - regex:
         source: nginxlog
         expression: ^(?P<ip>[w.]+) - (?P<user>[^ ]*) [(?P<timestamp>[^ ]+).*] "(?P<method>[^ ]*) (?P<request_url>[^ ]*) (?P<request_http_protocol>[^ ]*)" (?P<status>[d]+) (?P<bytes_out>[d]+) "(?P<http_referer>[^"]*)" "(?P<user_agent>[^"]*)"( "(?P<response_time>[d.]+)")?

Analizoni regjistrin e nginx duke përdorur shprehje të rregullta.

    - regex:
           source: request_url
           expression: ^.+.(?P<static_type>jpg|jpeg|gif|png|ico|css|zip|tgz|gz|rar|bz2|pdf|txt|tar|wav|bmp|rtf|js|flv|swf|html|htm)$
     - regex:
           source: request_url
           expression: ^/photo/(?P<photo>[^/?.]+).*$
       - regex:
           source: request_url
           expression: ^/api/(?P<api_request>[^/?.]+).*$

Le të analizojmë request_url. Duke përdorur regexp ne përcaktojmë qëllimin e kërkesës: në të dhëna statike, në foto, në API dhe vendosim çelësin përkatës në hartën e nxjerrë.

       - template:
           source: request_type
           template: "{{if .photo}}photo{{else if .static_type}}static{{else if .api_request}}api{{else}}other{{end}}"

Duke përdorur operatorët e kushtëzuar në Template, ne kontrollojmë fushat e instaluara në hartën e nxjerrë dhe vendosim vlerat e kërkuara për fushën e llojit të kërkesës: foto, statike, API. Cakto të tjera nëse dështon. request_type tani përmban llojin e kërkesës.

       - labels:
           api_request:
           virtual_host:
           request_type:
           status:

Ne vendosëm etiketat api_request, virtual_host, request_type dhe status (statusi HTTP) bazuar në atë që arritëm të vendosnim në hartën e nxjerrë.

       - output:
           source: nginx_log_row

Ndrysho prodhimin. Tani regjistri i pastruar i nginx nga harta e nxjerrë shkon te Loki.

Pas ekzekutimit të konfigurimit të mësipërm, mund të shihni se çdo hyrje i janë caktuar etiketat bazuar në të dhënat nga regjistri.

Një gjë që duhet mbajtur parasysh është se marrja e etiketave me një numër të madh vlerash (kardinaliteti) mund të ngadalësojë ndjeshëm Loki-n. Kjo do të thotë, nuk duhet të vendosni, për shembull, user_id në indeks. Lexoni më shumë rreth kësaj në artikullin "Si etiketat në Loki mund t'i bëjnë pyetjet e regjistrave më të shpejtë dhe më të lehtë" Por kjo nuk do të thotë që nuk mund të kërkoni sipas user_id pa indekse. Ju duhet të përdorni filtra kur kërkoni ("rrëmbeni" të dhënat), dhe indeksi këtu vepron si një identifikues i transmetimit.

Vizualizimi i shkrimeve

Loki mund të veprojë si një burim të dhënash për grafikët Grafana duke përdorur LogQL. Karakteristikat e mëposhtme mbështeten:

norma - numri i regjistrimeve për sekondë;
numërimi me kalimin e kohës - numri i regjistrimeve në intervalin e specifikuar.

Ekzistojnë gjithashtu funksione grumbullimi Sum, Avg dhe të tjera. Ju mund të ndërtoni grafikë mjaft komplekse, për shembull një grafik të numrit të gabimeve HTTP:

Burimi standard i të dhënave Loki është disi i reduktuar në funksionalitet në krahasim me burimin e të dhënave Prometheus (për shembull, nuk mund ta ndryshoni legjendën), por Loki mund të lidhet si burim me llojin Prometheus. Nuk jam i sigurt nëse kjo është sjellje e dokumentuar, por duke gjykuar nga përgjigja e zhvilluesve "Si të konfiguroni Loki si burim të dhënash Prometheus? · Numri #1222 · grafana/loki”, për shembull, është plotësisht i ligjshëm dhe Loki është plotësisht i pajtueshëm me PromQL.

Shtoni Loki si një burim të dhënash me llojin Prometheus dhe shtoni URL /loki:

Dhe ne mund të bëjmë grafikë, sikur të ishim duke punuar me metrikë nga Prometheus:

Unë mendoj se mospërputhja në funksionalitet është e përkohshme dhe zhvilluesit do ta korrigjojnë këtë në të ardhmen.

Metrikë

Loki ofron mundësinë për të nxjerrë metrikë numerike nga regjistrat dhe për t'i dërguar ato te Prometheus. Për shembull, regjistri nginx përmban numrin e bajteve për përgjigje, si dhe, me një modifikim të caktuar të formatit standard të regjistrit, kohën në sekonda që iu desh për t'u përgjigjur. Këto të dhëna mund të nxirren dhe dërgohen te Prometeu.

Shto një seksion tjetër te promtail.yml:

- match:
   selector: '{request_type="api"}'
   stages:
     - metrics:
         http_nginx_response_time:
           type: Histogram
           description: "response time ms"
           source: response_time
           config:
             buckets: [0.010,0.050,0.100,0.200,0.500,1.0]
- match:
   selector: '{request_type=~"static|photo"}'
   stages:
     - metrics:
         http_nginx_response_bytes_sum:
           type: Counter
           description: "response bytes sum"
           source: bytes_out
           config:
             action: add
         http_nginx_response_bytes_count:
           type: Counter
           description: "response bytes count"
           source: bytes_out
           config:
             action: inc

Opsioni ju lejon të përcaktoni dhe përditësoni metrikat bazuar në të dhënat nga harta e nxjerrë. Këto metrikë nuk dërgohen te Loki - ato shfaqen në pikën përfundimtare të Promtail /metrics. Prometeu duhet të konfigurohet për të marrë të dhënat e marra në këtë fazë. Në shembullin e mësipërm, për request_type=“api” ne mbledhim një metrikë histogrami. Me këtë lloj metrike është e përshtatshme të merren përqindjet. Për statike dhe foto, ne mbledhim shumën e bajteve dhe numrin e rreshtave në të cilat kemi marrë bajt për të llogaritur mesataren.

Lexoni më shumë rreth metrikës këtu.

Hapni portën në Promtail:

promtail:
     image: grafana/promtail:1.4.1
     container_name: monitoring.promtail
     expose:
       - 9080
     ports:
       - "9080:9080"

Sigurohuni që të shfaqen metrikat me prefiksin promtail_custom:

Ngritja e Prometeut. Shto promtail të punës:

- job_name: 'promtail'
 scrape_interval: 10s
 static_configs:
   - targets: ['promtail:9080']

Dhe ne vizatojmë një grafik:

Në këtë mënyrë mund të zbuloni, për shembull, katër pyetjet më të ngadalta. Ju gjithashtu mund të konfiguroni monitorimin për këto metrika.

Shkallëzimi

Loki mund të jetë ose në modalitetin binar të vetëm ose në modalitetin e copëtuar (modaliteti i shkallëzuar horizontalisht). Në rastin e dytë, ai mund të ruajë të dhëna në cloud, dhe pjesët dhe indeksi ruhen veçmas. Versioni 1.5 prezanton mundësinë e ruajtjes në një vend, por ende nuk rekomandohet përdorimi i tij në prodhim.

Copat mund të ruhen në ruajtje të përputhshme me S3 dhe bazat e të dhënave horizontale të shkallëzueshme mund të përdoren për të ruajtur indekset: Cassandra, BigTable ose DynamoDB. Pjesë të tjera të Loki - Distributors (për shkrim) dhe Querier (për pyetje) - janë pa shtetësi dhe gjithashtu shkallëzohen horizontalisht.

Në konferencën DevOpsDays Vancouver 2019, një nga pjesëmarrësit Callum Styan njoftoi se me Loki projekti i tij ka petabajt shkrime me një indeks më të vogël se 1% të madhësisë totale: "Si lidh Loki metrikat dhe regjistrat - dhe ju kursen para".

Krahasimi i Loki dhe ELK

Madhësia e indeksit

Për të testuar madhësinë e indeksit që rezulton, mora regjistrat nga kontejneri nginx për të cilin ishte konfiguruar tubacioni i mësipërm. Skedari i regjistrit përmbante 406 rreshta me një vëllim total prej 624 MB. Regjistrat u krijuan brenda një ore, afërsisht 109 hyrje në sekondë.

Shembull i dy rreshtave nga regjistri:

Kur u indeksua nga ELK, kjo dha një madhësi indeksi prej 30,3 MB:

Në rastin e Loki, kjo rezultoi në rreth 128 KB indeks dhe afërsisht 3,8 MB të dhëna në copa. Vlen të përmendet se regjistri ishte krijuar artificialisht dhe nuk kishte një larmi të madhe të dhënash. Një gzip i thjeshtë në regjistrin origjinal të Docker JSON me të dhëna dha një ngjeshje prej 95,4%, dhe duke marrë parasysh faktin se vetëm regjistri i pastruar i nginx iu dërgua vetë Loki, kompresimi deri në 4 MB është i kuptueshëm. Numri i përgjithshëm i vlerave unike për etiketat Loki ishte 35, gjë që shpjegon madhësinë e vogël të indeksit. Për ELK u fshi edhe regjistri. Kështu, Loki kompresoi të dhënat origjinale me 96%, dhe ELK me 70%.

Konsumi i memories

Nëse krahasojmë të gjithë pirgun e Prometheus dhe ELK, atëherë Loki "ha" disa herë më pak. Është e qartë se një shërbim Go konsumon më pak se një shërbim Java, dhe krahasimi i madhësisë së JVM Heap Elasticsearch dhe memorjes së caktuar për Loki është i pasaktë, por megjithatë vlen të përmendet se Loki përdor shumë më pak memorie. Avantazhi i tij i CPU-së nuk është aq i dukshëm, por është gjithashtu i pranishëm.

Shpejtësi

Loki "përpin" regjistrat më shpejt. Shpejtësia varet nga shumë faktorë - çfarë lloj regjistrash janë, sa të sofistikuar jemi në analizimin e tyre, rrjeti, disku, etj. - por është padyshim më i lartë se ELK (në testin tim - rreth dy herë më shumë). Kjo shpjegohet me faktin se Loki vendos shumë më pak të dhëna në indeks dhe, në përputhje me rrethanat, shpenzon më pak kohë për indeksimin. Me shpejtësinë e kërkimit, situata është e kundërta: Loki ngadalësohet dukshëm në të dhëna më të mëdha se disa gigabajt, ndërsa shpejtësia e kërkimit të ELK nuk varet nga madhësia e të dhënave.

Kërko sipas regjistrave

Loki është dukshëm inferior ndaj ELK për sa i përket aftësive të kërkimit të regjistrave. Grep me shprehje të rregullta është i fuqishëm, por është inferior ndaj një baze të dhënash të pjekur. Mungesa e pyetjeve të gamës, grumbullimi vetëm sipas etiketave, pamundësia për të kërkuar pa etiketa - e gjithë kjo na kufizon në kërkimin e informacionit me interes në Loki. Kjo nuk do të thotë që asgjë nuk mund të gjendet duke përdorur Loki, por përcakton rrjedhën e punës me regjistrat kur së pari gjeni një problem në grafikët e Prometheus dhe më pas përdorni këto etiketa për të kërkuar atë që ndodhi në regjistra.

ndërfaqe

Para së gjithash, është e bukur (më falni, nuk mund të rezistoja). Grafana ka një ndërfaqe të këndshme, por Kibana është shumë më e pasur me karakteristika.

Të mirat dhe të këqijat e Loki

Një nga avantazhet është se Loki integrohet me Prometheus, kështu që ne marrim metrikë dhe sinjalizime jashtë kutisë. Është i përshtatshëm për mbledhjen e regjistrave dhe ruajtjen e tyre nga Kubernetes Pods, pasi ka zbulimin e shërbimit të trashëguar nga Prometheus dhe vendos automatikisht etiketat.

Ana negative është dokumentacioni i dobët. Disa gjëra, për shembull, veçoritë dhe aftësitë e Promtail, i zbulova vetëm në procesin e studimit të kodit, për fat të mirë është me burim të hapur. Një tjetër disavantazh është aftësia e dobët e analizës. Për shembull, Loki nuk mund të analizojë regjistrat me shumë rreshta. Një tjetër disavantazh është se Loki është një teknologji relativisht e re (lëshimi 1.0 ishte në nëntor 2019).

Përfundim

Loki është një teknologji 100% interesante që është e përshtatshme për projekte të vogla dhe të mesme, duke ju lejuar të zgjidhni shumë probleme të grumbullimit të regjistrave, kërkimit të regjistrave, monitorimit dhe analizës së regjistrave.

Ne nuk e përdorim Loki në Badoo sepse kemi një stack ELK që na përshtatet dhe që është tejmbushur me zgjidhje të ndryshme me porosi gjatë viteve. Për ne, pengesa është kërkimi nëpër shkrime. Me pothuajse 100 GB regjistra në ditë, është e rëndësishme që ne të jemi në gjendje të gjejmë gjithçka dhe pak më shumë dhe ta bëjmë atë shpejt. Për hartimin dhe monitorimin, ne përdorim zgjidhje të tjera që janë të përshtatura për nevojat tona dhe të integruara me njëra-tjetrën. Stacki Loki ka përfitime të prekshme, por nuk do të na japë më shumë sesa kemi tashmë dhe përfitimet e tij sigurisht që nuk do të tejkalojnë koston e migrimit.

Dhe megjithëse pas hulumtimit u bë e qartë se ne nuk mund të përdorim Loki, shpresojmë që ky postim t'ju ndihmojë në zgjedhjen tuaj.

Depoja me kodin e përdorur në artikull ndodhet këtu.

Burimi: www.habr.com

Mbledhja e trungjeve nga Loki