Lokiren erregistroak biltzen

Lokiren erregistroak biltzen

Badoo-n teknologia berrien jarraipena egiten ari gara etengabe eta gure sisteman erabili edo ez ebaluatzen ari gara. Ikerketa horietako bat komunitatearekin partekatu nahi dugu. Loki-ri eskainia dago, log-ak agregatzeko sistema bat.

Loki erregistroak gordetzeko eta ikusteko irtenbide bat da, eta pila honek sistema malgu bat ere eskaintzen du horiek aztertzeko eta Prometheusi datuak bidaltzeko. Maiatzean, beste eguneratze bat kaleratu zen, sortzaileek aktiboki sustatzen dutena. Loki-k zer egin dezakeen, zer gaitasun eskaintzen dituen eta zein neurritaraino joka dezakeen ELK-ren alternatiba gisa, orain erabiltzen dugun pila, interesatzen zitzaigun.

Zer da Loki

Grafana Loki erregistro-sistema oso baterako osagaien multzoa da. Antzeko beste sistema batzuek ez bezala, Loki log metadatuak soilik indexatzeko ideian oinarritzen da - etiketak (Prometheus-en berdinak) eta erregistroak zati bereizietan konprimitzea.

Hasiera orria, GitHub

Lokirekin zer egin dezakezun sartu aurretik, "metadatuak soilik indexatzeko ideia" esan nahi duena argitu nahi dut. Konpara ditzagun Loki ikuspegia eta indexatzeko ikuspegia soluzio tradizionaletan, hala nola Elasticsearch, nginx log-eko lerro baten adibidea erabiliz:

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

Sistema tradizionalek errenkada osoa analizatzen dute, user_id eta item_id balio esklusibo ugari dituzten eremuak barne, eta dena indize handietan gordetzen dute. Ikuspegi honen abantaila da kontsulta konplexuak azkar exekutatu ditzakezula, datu ia guztiak indizean baitaude. Baina horrek kostua du indizea handitzen baita, eta horrek memoria eskakizunetan bihurtzen du. Ondorioz, erregistroen testu osoko indizea erregistroen berdina da. Azkar bilatu ahal izateko, indizea memorian kargatu behar da. Eta zenbat eta erregistro gehiago, orduan eta azkarrago hazten da indizea eta zenbat eta memoria gehiago kontsumitzen du.

Loki ikuspegiak kate batetik beharrezko datuak bakarrik ateratzea eskatzen du, zeinen balio kopurua txikia baita. Horrela indize txiki bat lortuko dugu eta datuak denboraren arabera eta indexatutako eremuen arabera iragaziz bilatu ditzakegu, eta, ondoren, gainerakoak adierazpen erregular edo azpikateen bilaketarekin aztertuz. Prozesua ez dirudi azkarrena denik, baina Lokik eskaera hainbat zatitan banatzen du eta paraleloan exekutatzen ditu, denbora gutxian datu kopuru handia prozesatzen du. Haietako zatien eta eskaera paraleloen kopurua konfiguragarria da; horrela, denbora-unitate bakoitzeko prozesatu daitekeen datu kopurua eskaintzen den baliabide kopuruaren araberakoa da linealki.

Indize azkar handi baten eta indar brute-indize paralelo txiki baten arteko truke-off honek Loki sistemaren kostua kontrolatzeko aukera ematen dio. Malgutasunez konfiguratu eta zabaldu daiteke zure beharren arabera.

Loki pila hiru osagai ditu: Promtail, Loki, Grafana. Promtail-ek erregistroak biltzen ditu, prozesatzen ditu eta Loki-ra bidaltzen ditu. Lokik mantentzen ditu. Eta Grafanak Lokiri datuak eska diezazkioke eta erakutsi. Oro har, Loki erregistroak gordetzeko eta haietan bilatzeko ez ezik erabil daiteke. Pila osoak aukera handiak eskaintzen ditu sarrerako datuak Prometheus modua erabiliz prozesatzeko eta aztertzeko.
Instalazio-prozesuaren deskribapena aurki daiteke Hemen.

Erregistro bilaketa

Erregistroak Grafana interfaze berezi batean bilatu ditzakezu - Explorer. Kontsultek LogQL hizkuntza erabiltzen dute, Prometheus-ek erabiltzen duen PromQL-aren oso antzekoa dena. Printzipioz, banatutako grep gisa pentsa daiteke.

Bilaketa-interfazea honelakoa da:

Lokiren erregistroak biltzen

Kontsultak berak bi zati ditu: hautatzailea eta iragazkia. Hautatzailea erregistroei esleitzen zaizkien metadatuak (etiketak) indexatutako bilaketa bat da, eta iragazkia hautatzaileak definitutako erregistroak iragazten dituen bilaketa-katea edo adierazpen erregularra da. Goiko adibidean: kortxete artean - hautatzailea, ondoren dena - iragazkia.

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

Loki-k funtzionatzen duen modua dela eta, ezin dituzu eskaerarik egin hautatzailerik gabe, baina etiketak modu arbitrarioan generikoak izan daitezke.

Hautatzailea giltza kizkurdun balioaren gako-balioa da. Hautatzaileak konbinatu eta bilaketa-baldintza desberdinak zehaztu ditzakezu =, != eragileak edo adierazpen erregularrak erabiliz:

{instance=~"kafka-[23]",name!="kafka-dev"} 
// Найдёт Π»ΠΎΠ³ΠΈ с Π»Π΅ΠΉΠ±Π»ΠΎΠΌ instance, ΠΈΠΌΠ΅ΡŽΡ‰ΠΈΠ΅ Π·Π½Π°Ρ‡Π΅Π½ΠΈΠ΅ kafka-2, kafka-3, ΠΈ ΠΈΡΠΊΠ»ΡŽΡ‡ΠΈΡ‚ dev 

Iragazkia hautatzaileak jasotako datu guztiak iragaziko dituen testu edo adierazpen erregularra da.

Jasotako datuetan oinarritutako grafikoak lor daitezke metrika moduan. Adibidez, nginx erregistroetan kate-indizea duen sarrera bat zenbat aldiz agertzen den jakin dezakezu:

Lokiren erregistroak biltzen

Ezaugarrien deskribapen osoa dokumentazioan aurki daiteke LogQL.

Erregistroen analisia

Erregistroak biltzeko hainbat modu daude:

  • Promtail-en laguntzaz, erregistroak biltzeko pilaren osagai estandarra.
  • Docker edukiontzitik zuzenean erabiliz Loki Docker Logging Driver.
  • Erabili Fluentd edo Fluent Bit eta horrek datuak bidal ditzake Loki-ra. Promtail-ek ez bezala, ia edozein motatako erregistroetarako prest egindako analizatzaileak dituzte eta lerro anitzeko erregistroak ere kudea ditzakete.

Normalean Promtail erabiltzen da analizatzeko. Hiru gauza egiten ditu:

  • Datu-iturriak aurkitzen ditu.
  • Erantsi etiketak.
  • Loki-ri datuak bidaltzen dizkio.

Gaur egun Promtail-ek fitxategi lokaletako eta systemd aldizkariko erregistroak irakur ditzake. Erregistroak biltzen diren makina guztietan instalatu behar da.

Kubernetes-ekin integrazioa dago: Promtail-ek automatikoki ezagutzen du klusterraren egoera Kubernetes REST APIaren bidez eta nodo, zerbitzu edo pod batetik erregistroak biltzen ditu, berehala Kubernetesen metadatuetan oinarritutako etiketak argitaratuz (pod-en izena, fitxategi-izena, etab.).

Erregistroko datuetan oinarritutako etiketak ere zintzilikatu ditzakezu Pipeline erabiliz. Pipeline Promtail lau etapa mota izan daitezke. Xehetasun gehiago - in dokumentazio ofiziala, berehala ohartuko naiz Γ±abardura batzuk.

  1. Analisiaren faseak. Hau RegEx eta JSON-en etapa da. Fase honetan, erregistroetatik datuak ateratzen ditugu ateratako mapa deritzonera. JSONtik atera dezakezu ateratako mapan behar ditugun eremuak kopiatuz edo adierazpen erregularren bidez (RegEx), non izendatutako taldeak ateratako mapan "mapatzen" diren. Erauzitako mapa gako-balioen biltegiratze bat da, non gakoa eremuaren izena den eta balioa erregistroetako balioa den.
  2. Etapak eraldatu. Etapa honek bi aukera ditu: transformatu, non eraldatze-arauak ezartzen ditugun, eta iturria - ateratako mapatik eraldatzeko datu-iturria. Erauzitako mapan halako eremurik ez badago, orduan sortuko da. Horrela, ateratako mapan oinarritzen ez diren etiketak sortzea posible da. Fase honetan, ateratako mapako datuak manipula ditzakegu nahiko indartsua erabiliz golang txantiloia. Horrez gain, gogoratu behar dugu ateratako mapa guztiz kargatuta dagoela analisian, eta horri esker, adibidez, bertan dagoen balioa egiaztatzea posible da: β€œ{{if .tag}tag value exists{end}}”. Txantiloiak baldintzak, begiztak eta kate-funtzio batzuk onartzen ditu, hala nola Ordeztu eta Moztu.
  3. Ekintza-etapak. Fase honetan, ateratakoarekin zerbait egin dezakezu:
    • Sortu ateratako datuetatik etiketa bat, Lokik indexatuko duena.
    • Aldatu edo ezarri gertaeren ordua erregistrotik.
    • Aldatu Loki-ra joango diren datuak (erregistroko testua).
    • Sortu neurketak.
  4. Iragazte-etapak. Bat-etortze fasea, non /dev/null behar ez ditugun erregistroak bidal ditzakegu edo prozesatzeko gehiago bidal ditzakegun.

Nginx erregistro arruntak prozesatzeko adibidea erabiliz, Promtail erabiliz erregistroak nola analiza ditzakezun erakutsiko dut.

Proba egiteko, har dezagun aldatutako nginx irudi bat jwilder/nginx-proxy:alpine nginx-proxy gisa eta HTTP bidez bere burua kontsulta dezakeen deabru txiki bat. Daemonak hainbat amaiera-puntu ditu, eta horiei tamaina ezberdinetako erantzunak eman ditzake, HTTP egoera ezberdinekin eta atzerapen ezberdinekin.

Docker edukiontzietatik erregistroak bilduko ditugu, /var/lib/docker/containers/ bidetik aurki daitezkeenak / -json.log

Docker-compose.yml-en Promtail konfiguratu dugu eta konfiguraziorako bidea zehaztu dugu:

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'
 // ...

Gehitu promtail.yml-ra erregistroen bidea (konfigurazioan "docker" aukera bat dago, lerro batean gauza bera egiten duena, baina ez litzateke hain agerikoa izango):

scrape_configs:
 - job_name: containers

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

Konfigurazio hau gaituta dagoenean, Loki-k edukiontzi guztietako erregistroak jasoko ditu. Hori ekiditeko, test nginx-en ezarpenak aldatzen ditugu docker-compose.yml-n - gehitu erregistro-etilaren eremua:

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

Editatu promtail.yml eta konfiguratu Pipeline. Erregistroak hauek dira:

{"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"}

kanalizazioaren faseak:

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

Korrontea, attrs, attrs.tag eremuak (halakorik badago) sarrerako JSONtik ateratzen ditugu eta ateratako mapan jartzen ditugu.

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

Erauzitako mapan etiketa-eremua jartzea lortu badugu, orduan, adierazpen erregularra erabiliz, irudiaren eta edukiontziaren izenak ateratzen ditugu.

 - labels:
     image_name:
     container_name:

Etiketak esleitzen ditugu. Erauzitako datuetan irudi_izena eta edukiontzi_izena gakoak aurkitzen badira, haien balioak etiketa egokiei esleituko zaizkie.

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

Irudi_izena eta edukiontzi_izena ezarrita ez duten erregistro guztiak baztertzen ditugu.

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

Irudi_izena nginx.promtail.test duten erregistro guztietan, atera erregistro-eremua iturburuko erregistrotik eta jarri ateratako mapan errenkada-gakoarekin.

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

Sarrera-katea adierazpen erregularrekin garbitzen dugu eta nginx ostalari birtuala eta nginx log-lerroa ateratzen ditugu.

     - 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.]+)")?

Analizatu nginx erregistroa adierazpen erregularrak erabiliz.

    - 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>[^/?.]+).*$

Analizatu eskaera_url. Esperimentu erregularra erabiliz eskaeraren helburua zehazten dugu: datu estatikoak, argazkiak, APIa eta ateratako mapan dagokion gakoa ezarri.

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

Txantiloian baldintzapeko operadoreak erabiliz, ateratako mapan instalatutako eremuak egiaztatzen ditugu eta eskaera_mota eremurako beharrezko balioak ezartzen ditugu: argazkia, estatikoa, APIa. Esleitu beste bat huts egiten badu. request_type orain eskaera mota dauka.

       - labels:
           api_request:
           virtual_host:
           request_type:
           status:

Ateratako mapan jartzea lortu dugunaren arabera api_request, virtual_host, request_type eta status (HTTP egoera) etiketak ezarri ditugu.

       - output:
           source: nginx_log_row

Aldatu irteera. Orain ateratako mapatik garbitutako nginx erregistroa Lokira doa.

Lokiren erregistroak biltzen

Goiko konfigurazioa exekutatu ondoren, sarrera bakoitza erregistroko datuen arabera etiketatuta dagoela ikus dezakezu.

Kontuan izan beharreko gauza bat da balio kopuru handia duten etiketak (kardinalitatea) berreskuratzeak Loki nabarmen moteldu dezakeela. Hau da, ez zenuke indizean jarri behar, adibidez, user_id. Irakurri honi buruz gehiago artikuluanLoki-n etiketak nola egin ditzakeen erregistro-kontsultak azkarrago eta errazagoak". Baina horrek ez du esan nahi erabiltzaile_id-aren bidez bilatu ezin denik indizerik gabe. Bilatzerakoan iragazkiak erabiltzea beharrezkoa da ("grabatu" datuen arabera), eta hemen indizeak korronte-identifikatzaile gisa jokatzen du.

Erregistroen bistaratzea

Lokiren erregistroak biltzen

Loki-k Grafana diagramen datu-iturri gisa jardun dezake LogQL erabiliz. Ezaugarri hauek onartzen dira:

  • rate β€” segundoko erregistro kopurua;
  • zenbatu denboran zehar - emandako tartean erregistro kopurua.

Batera, Batez besteko eta beste funtzio batzuk ere badaude. Nahiko grafiko konplexuak eraiki ditzakezu, adibidez, HTTP erroreen kopuruaren grafikoa:

Lokiren erregistroak biltzen

Loki datu-iturburu estandarra zertxobait murrizten da Prometheus datu-iturburuarekin alderatuta (adibidez, ezin duzu kondaira aldatu), baina Loki iturri gisa konekta daiteke Prometheus motarekin. Ez nago ziur portaera hori dokumentatua den, baina garatzaileen erantzuna ikusita "Nola konfiguratu Loki Prometheus datu-iturburu gisa? Β· 1222. alea Β· grafana/loki”, adibidez, guztiz legezkoa da, eta Loki guztiz bateragarria da PromQLrekin.

Gehitu Loki datu-iturburu gisa Prometheus motarekin eta erantsi URL /loki:

Lokiren erregistroak biltzen

Eta grafikoak egin ditzakezu, Prometheus-en metrikekin lan egingo bagenu bezala:

Lokiren erregistroak biltzen

Funtzionalitatearen desadostasuna behin-behinekoa dela eta garatzaileek etorkizunean konponduko dutela uste dut.

Lokiren erregistroak biltzen

Metrikak

Loki-k erregistroetatik zenbakizko metrikak ateratzeko eta Prometheus-era bidaltzeko gaitasuna eskaintzen du. Esate baterako, nginx erregistroak erantzun bakoitzeko byte-kopurua jasotzen du, eta, gainera, erregistro-formatu estandarraren aldaketa jakin batekin, erantzuteko behar izan duen denbora segundotan. Datu hauek atera eta Prometheus-era bidal daitezke.

Gehitu beste atal bat promtail.yml-ra:

- 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

Aukera horri esker, ateratako mapako datuetan oinarritutako metrikoak definitu eta egunera ditzakezu. Neurri hauek ez dira Loki-ra bidaltzen; Promtail /metrics amaierako puntuan agertzen dira. Prometheus etapa honetako datuak jasotzeko konfiguratu behar da. Goiko adibidean, request_type="api"-rako histograma metrika bat biltzen dugu. Neurri mota honekin pertzentilak lortzea komeni da. Estatikarako eta argazkietarako, byteen batura eta byteak jaso ditugun errenkaden batura biltzen dugu batez bestekoa kalkulatzeko.

Irakurri gehiago neurketari buruz Hemen.

Ireki ataka Promtail-en:

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

Promtail_custom aurrizkia duten neurketak agertu direla ziurtatzen dugu:

Lokiren erregistroak biltzen

Prometheus konfiguratzea. Gehitu lanaren iragarkia:

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

Eta marraztu grafiko bat:

Lokiren erregistroak biltzen

Hala, aurki ditzakezu, adibidez, lau eskaera motelenak. Neurri hauetarako monitorizazioa ere konfigura dezakezu.

Eskalatzea

Loki modu bitar bakarrean eta zatituta egon daiteke (modu horizontalean eskalagarria). Bigarren kasuan, datuak hodeian gorde ditzake, eta zatiak eta indizeak bereizita gordetzen dira. 1.5 bertsioan, leku batean gordetzeko gaitasuna inplementatzen da, baina oraindik ez da gomendagarria ekoizpenean erabiltzea.

Lokiren erregistroak biltzen

Chunk-ak S3-rekin bateragarria den biltegian gorde daitezke, eta horizontalki eskalagarriak diren datu-baseak erabil daitezke indizeak gordetzeko: Cassandra, BigTable edo DynamoDB. Loki-ren beste zati batzuk - Banatzaileak (idazteko) eta Querier (kontsultetarako) - estaturik gabekoak dira eta horizontalki ere eskalatzen dira.

DevOpsDays Vancouver 2019 konferentzian, parte-hartzaileetako batek Callum Styanek iragarri zuen Lokirekin bere proiektuak tamaina osoaren % 1 baino indize txikiagoa duten erregistro petabyte dituela: "Loki-k nola erlazionatzen dituen metrikak eta erregistroak, eta nola aurrezten dizun".

Loki eta ELK konparaketa

Indizearen tamaina

Emaitza den indizearen tamaina probatzeko, goiko Pipeline konfiguratuta zegoen nginx edukiontziko erregistroak hartu ditut. Erregistro-fitxategiak 406 lerro zituen, guztira 624 MB-ko bolumenarekin. Erregistroak ordubeteko epean sortu ziren, segundoko 109 erregistro gutxi gorabehera.

Erregistroko bi lerroren adibidea:

Lokiren erregistroak biltzen

ELK-k indexatu zuenean, honek 30,3 MB-ko indizearen tamaina eman zuen:

Lokiren erregistroak biltzen

Loki-ren kasuan, honek 128 KB inguru indizea eta 3,8 MB inguru datu zatika eman zituen. Aipatzekoa da erregistroa artifizialki sortu zela eta ez zuela datu askotarikorik. Datuekin jatorrizko Docker JSON erregistroan gzip soil batek % 95,4ko konpresioa eman zuen, eta garbitutako nginx erregistroa Loki berari bakarrik bidali zitzaiola ikusita, 4 MBko konpresioa ulergarria da. Loki etiketen balio esklusiboen kopuru osoa 35 izan zen, eta horrek indizearen tamaina txikia azaltzen du. ELKrentzat ere erregistroa garbitu zen. Horrela, Lokik jatorrizko datuak % 96 konprimitu zituen, eta ELK-k % 70ean.

Memoria-kontsumoa

Lokiren erregistroak biltzen

Prometheus eta ELK-en pila osoa konparatzen badugu, orduan Lokik hainbat aldiz gutxiago "jaten du". Argi dago Go zerbitzuak Java zerbitzuak baino gutxiago kontsumitzen duela, eta Heap Elasticsearch JVM-ren tamaina eta Loki-ri esleitutako memoria alderatzea okerra dela, baina, hala ere, aipatzekoa da Loki-k askoz memoria gutxiago erabiltzen duela. Bere CPU abantaila ez da hain agerikoa, baina presente ere badago.

Abiadura

Lokik azkarrago "irensten" ditu erregistroak. Abiadura faktore askoren araberakoa da - nolako erregistroak, nola analizatzen ditugun sofistikatuak, sarea, diskoa, etab. - baina zalantzarik gabe ELKrena baino handiagoa da (nire proban - bi aldiz inguru). Lokik indizean askoz datu gutxiago jartzen dituelako eta, horrenbestez, denbora gutxiago ematen duelako indexatzen. Kasu honetan, egoera iraultzen da bilaketa-abiadurarekin: Loki-k nabarmen moteltzen du gigabyte batzuk baino handiagoak diren datuetan, ELK-ren kasuan, berriz, bilaketa-abiadura ez da datuen tamainaren araberakoa.

Erregistro bilaketa

Loki ELK baino nabarmen txikiagoa da log bilaketa-gaitasunei dagokienez. Adierazpen erregularrak dituen Grep indartsua da, baina datu-base heldu baten azpikoa da. Barruti-kontsulten ezak, etiketen bidez soilik batzea, etiketarik gabe bilatzeko ezintasuna - honek guztiak mugatzen gaitu Lokiren intereseko informazioa bilatzea. Horrek ez du esan nahi Loki erabiliz ezer aurkitu ezin denik, baina Prometheus zerrendetan arazoren bat aurkitzen duzunean erregistroekin lan egiteko fluxua definitzen du, eta gero etiketa hauek erabili erregistroetan gertatutakoa bilatzeko.

interface

Lehenik eta behin, ederra da (barkatu, ezin izan dut eutsi). Grafanak itxura polita dauka interfazea, baina Kibana askoz funtzionalagoa da.

Loki alde onak eta txarrak

Abantailetatik, Loki Prometheus-ekin integratzen dela esan daiteke, hurrenez hurren, neurketak eta alertak ateratzen ditugula kutxatik. Erregistroak biltzeko eta Kubernetes Pods-ekin gordetzeko komenigarria da, Prometheus-en heredatutako zerbitzu-aurkikuntza bat baitu eta etiketak automatikoki eransten baititu.

Minusetatik - dokumentazio eskasa. Gauza batzuk, hala nola, Promtail-en ezaugarriak eta gaitasunak, kodea aztertzeko prozesuan bakarrik aurkitu nuen kode irekiaren onura. Beste desabantaila bat analizatzeko gaitasun ahulak dira. Adibidez, Lokik ezin du lerro anitzeko erregistroak analizatu. Era berean, desabantailen artean dago Loki teknologia nahiko gaztea dela (1.0 bertsioa 2019ko azaroan izan zen).

Ondorioa

Loki % 100eko teknologia interesgarria da, proiektu txiki eta ertainetarako egokia dena, erregistroen agregazio, log bilaketa, jarraipena eta erregistroen azterketa arazo asko konpontzeko aukera ematen duena.

Badoo-n ez dugu Loki erabiltzen, guri egokitzen zaigun ELK pila bat dugulako eta urte hauetan zehar hainbat soluzio pertsonalizatuz hazi dena. Guretzat, oztopoa erregistroetan bilatzea da. Egunean ia 100 GB-ko erregistroekin, garrantzitsua da guretzat dena eta apur bat gehiago aurkitzea eta azkar egitea. Grafikoak eta jarraipena egiteko, gure beharretara egokitutako eta elkarren artean integratutako beste irtenbide batzuk erabiltzen ditugu. Loki pilak onura nabariak ditu, baina ez digu guk daukaguna baino gehiago emango, eta bere onurak ez du migrazioaren kostua zehazki gainditzen.

Eta ikerketaren ondoren Loki ezin dugula erabili argi geratu bada ere, mezu honek aukeratzen lagunduko dizula espero dugu.

Artikuluan erabilitako kodea duen biltegia dago Hemen.

Iturria: www.habr.com

Gehitu iruzkin berria