Ngumpulkeun log ti Loki

Di Badoo, kami terus-terusan ngawaskeun téknologi anyar sareng ngaevaluasi naha éta patut dianggo dina sistem kami. Kami hoyong bagikeun salah sahiji studi ieu sareng masarakat. Ieu dedicated ka Loki, sistem aggregation log.

Loki mangrupikeun solusi pikeun nyimpen sareng ningali log, sareng tumpukan ieu ogé nyayogikeun sistem anu fleksibel pikeun nganalisis sareng ngirim data ka Prometheus. Dina Méi, update sejen dileupaskeun, nu aktip diwanohkeun ku panyipta. Kami kabetot dina naon anu tiasa dilakukeun ku Loki, kamampuan naon anu disayogikeun, sareng sajauh mana éta tiasa janten alternatif pikeun ELK, tumpukan anu kami anggo ayeuna.

Naon Loki

Grafana Loki mangrupikeun sakumpulan komponén pikeun sistem lengkep pikeun damel sareng log. Beda sareng sistem anu sanés, Loki didasarkeun kana ideu ngan ukur ngindeks log metadata - labél (sarua sareng dina Prometheus), sareng ngakomprés log sorangan kana sakumpulan anu misah.

homepage, GitHub

Sateuacan urang lebet kana naon anu anjeun tiasa laksanakeun sareng Loki, abdi hoyong netelakeun naon anu kami maksud ku "gagasan ngindeks ukur metadata." Hayu urang ngabandingkeun pendekatan Loki sareng pendekatan kana indéks dina solusi tradisional sapertos Elasticsearch, nganggo conto garis tina log nginx:

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"

Sistem tradisional parse sakabéh baris, kaasup widang kalawan angka nu gede ngarupakeun user_id unik sarta nilai item_id, tur nyimpen sagalana dina indéks badag. Kauntungannana pendekatan ieu nu bisa ngajalankeun queries kompléks gancang, saprak ampir sakabéh data aya dina indéks dina. Tapi ieu asalna di ongkos nu indéks jadi badag, nu ditarjamahkeun kana sarat memori. Hasilna, indéks log téks lengkep tiasa dibandingkeun sareng ukuran log sorangan. Pikeun gancang milarian éta, indéks kedah dimuat kana mémori. Sareng langkung seueur log, langkung gancang indéksna tumbuh sareng langkung seueur memori anu dikonsumsi.

Pendekatan Loki meryogikeun yén ngan ukur data anu diperyogikeun tina senar, jumlah nilaina leutik. Ku cara kieu urang meunang indéks leutik tur bisa neangan data ku nyaring eta ku waktu jeung widang indéks, lajeng scanning sésana kalawan éksprési biasa atawa pilarian substring. Prosésna henteu sigana anu paling gancang, tapi Loki ngabagi pamundut kana sababaraha bagian sareng ngalaksanakeunana paralel, ngolah data anu ageung dina waktos anu singget. Jumlah shards na requests paralel di antarana anu configurable; sahingga, jumlah data nu bisa diolah per unit waktu gumantung linier dina jumlah sumberdaya disadiakeun.

Ieu trade-off antara badag, indéks gancang sarta leutik, indéks BRUTE-gaya paralel ngamungkinkeun Loki ngadalikeun biaya sistem. Ieu bisa flexibly ngonpigurasi tur dimekarkeun nurutkeun pangabutuh.

Tumpukan Loki diwangun ku tilu komponén: Promtail, Loki, Grafana. Promtail ngumpulkeun log, ngolah sareng ngirim ka Loki. Loki ngajaga aranjeunna. Sareng Grafana tiasa nyuhunkeun data ti Loki sareng nampilkeunana. Sacara umum, Loki tiasa dianggo henteu ngan ukur pikeun nyimpen log sareng milarianana. Sakabéh tumpukan nyadiakeun kasempetan gede pikeun ngolah jeung nganalisis data asup ngagunakeun cara Prometheus.
Katerangan ngeunaan prosés pamasangan tiasa dipendakan di dieu.

Pilarian ku log

Anjeun tiasa milarian log dina antarmuka Grafana khusus - Explorer. Patarosan ngagunakeun basa LogQL, nu sarupa pisan jeung PromQL dipaké dina Prometheus. Sacara prinsip, éta tiasa dianggap salaku grep anu disebarkeun.

Antarbeungeut milarian sapertos kieu:

Paménta sorangan diwangun ku dua bagian: pamilih sareng saringan. Selector mangrupakeun pilarian maké indéks metadata (labél) nu ditugaskeun ka log, sarta filter nyaéta string pilarian atanapi regexp nu nyaring kaluar rékaman ditetepkeun ku pamilih nu. Dina conto dibikeun: Dina braces Curly aya pamilih a, sagalana sanggeus éta filter a.

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

Kusabab cara Loki jalan, anjeun moal bisa nyieun queries tanpa pamilih a, tapi labél bisa dijieun salaku umum sakumaha anjeun resep.

Pamilih mangrupikeun nilai konci dina kurung keriting. Anjeun tiasa ngagabungkeun pamilih sareng nangtukeun kaayaan pamilarian anu béda-béda nganggo operator =, != atanapi ekspresi biasa:

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

Saringan nyaéta téks atanapi regexp anu bakal nyaring sadaya data anu ditampi ku pamilih.

Ieu mungkin pikeun ménta grafik ad-hoc dumasar kana data narima dina modeu métrik. Salaku conto, anjeun tiasa terang sabaraha sering éntri anu ngandung indéks string muncul dina log nginx:

Katerangan lengkep ngeunaan kamampuan tiasa dipendakan dina dokuméntasi LogQL.

Parsing log

Aya sababaraha cara pikeun ngumpulkeun log:

• Ngagunakeun Promtail, komponén baku tumpukan pikeun ngumpulkeun log.
• Langsung tina wadah docker ngagunakeun Loki Docker Logging Supir.
• Anggo Fluentd atanapi Fluent Bit, anu tiasa ngirim data ka Loki. Beda sareng Promtail, aranjeunna gaduh parser anu siap-siap pikeun ampir sadaya jinis log sareng ogé tiasa ngadamel log multiline.

Biasana Promtail dianggo pikeun parsing. Éta ngalakukeun tilu hal:

• Manggihan sumber data.
• Ngagantelkeun labél ka aranjeunna.
• Ngirim data ka Loki.

Ayeuna Promtail tiasa maca log tina file lokal sareng tina jurnal systemd. Ieu kudu dipasang dina unggal mesin ti mana log dikumpulkeun.

Aya integrasi sareng Kubernetes: Promtail otomatis, ngaliwatan Kubernetes REST API, ngakuan kaayaan klaster sareng ngumpulkeun log tina node, jasa atanapi pod, langsung ngeposkeun labél dumasar kana metadata ti Kubernetes (ngaran pod, nami file, jsb.) .

Anjeun ogé tiasa ngagantung labél dumasar kana data tina log nganggo Pipeline. Pipeline Promtail tiasa diwangun ku opat jinis tahapan. Langkung rinci dina dokuméntasi resmi, Kuring gé geuwat catetan sababaraha nuances.

1. Tahap parsing. Ieu mangrupikeun tahap RegEx sareng JSON. Dina tahap ieu, urang nimba data tina log kana anu disebut peta ékstraksi. Urang tiasa nimba ti JSON ku saukur nyalin widang urang butuh kana peta sasari, atawa ngaliwatan ungkapan biasa (RegEx), dimana grup ngaranna "dipetakeun" kana peta sasari. Peta Extracted mangrupikeun toko nilai konci, dimana konci mangrupikeun nami lapangan, sareng nilai mangrupikeun nilai tina log.
2. Transformasi tahapan. Tahap ieu ngagaduhan dua pilihan: transformasi, dimana urang nyetél aturan transformasi, sareng sumber - sumber data pikeun transformasi tina peta anu sasari. Upami teu aya widang sapertos kitu dina peta anu sasari, éta bakal didamel. Ku cara kieu kasebut nyaéta dimungkinkeun pikeun nyieun labél nu teu dumasar kana peta sasari. Dina tahap ieu urang bisa ngamanipulasi data dina peta sasari ngagunakeun cukup kuat Golang Citakan. Sajaba ti éta, urang kudu inget yén peta sasari dimuat sagemblengna salila parsing, nu ngamungkinkeun, contona, mariksa nilai di dinya: "{{lamun .tag} nilai tag aya {tungtung}}". Citakan ngadukung kaayaan, puteran, sareng sababaraha fungsi senar sapertos Ganti sareng Potong.
3. Tahapan tindakan. Dina titik ieu anjeun tiasa ngalakukeun hiji hal kalayan eusi sasari:
   • Jieun labél tina data sasari, nu bakal saestuna ku Loki.
   • Robah atanapi setel waktos acara tina log.
   • Robah data (téks log) anu bakal ka Loki.
   • Jieun metrics.
4. Tahap nyaring. Tahap pertandingan, dimana urang tiasa ngirim éntri anu urang henteu kedah / dev / null atanapi neraskeunana pikeun ngolah salajengna.

Nganggo conto ngolah log nginx biasa, kuring bakal nunjukkeun kumaha anjeun tiasa nga-parse log nganggo Promtail.

Pikeun tés, hayu urang nyandak salaku nginx-proxy gambar nginx dirobah jwilder/nginx-proxy:alpine sarta daemon leutik nu bisa nanya sorangan via HTTP. Daemon boga sababaraha titik tungtung, nu bisa nyadiakeun respon ukuran béda, kalawan status HTTP béda jeung reureuh béda.

Kami bakal ngumpulkeun log tina peti docker, anu tiasa dipendakan sapanjang jalur /var/lib/docker/containers/ / -json.log

Dina docker-compose.yml kami ngonpigurasikeun Promtail sareng netepkeun jalur pikeun konfigurasi:

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

Nambahkeun jalur ka log ka promtail.yml (aya pilihan "docker" dina config, nu ngalakukeun hal anu sarua dina hiji garis, tapi teu bakal jadi jelas):

scrape_configs:
 - job_name: containers

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

Nalika konfigurasi ieu diaktipkeun, log ti sadaya wadahna bakal dikirim ka Loki. Pikeun ngahindarkeun ieu, urang ngarobih setélan tés nginx dina docker-compose.yml - tambahkeun médan tag logging:

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

Ngédit promtail.yml sareng nyetél Pipeline. Input kalebet log tina jinis ieu:

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

Tahap Pipa:

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

Urang nimba aliran widang, attrs, attrs.tag (upami aya) ti JSON asup tur nempatkeun eta dina peta sasari.

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

Upami urang junun nempatkeun médan tag dina peta anu sasari, teras nganggo regexp urang nimba nami gambar sareng wadahna.

 - labels:
     image_name:
     container_name:

Urang napelkeun labél. Upami konci image_name sareng container_name dipendakan dina data anu sasari, maka nilaina bakal ditugaskeun kana labél anu saluyu.

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

Urang piceun kabeh log nu teu boga labél dipasang image_name na container_name.

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

Pikeun sakabéh log anu image_name nyaeta nginx.promtail.test, nimba widang log tina sumber log sarta nempatkeun eta dina peta sasari jeung konci baris.

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

Urang mupus garis input kalayan ekspresi biasa sareng tarik kaluar host virtual nginx sareng garis 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.]+)")?

Parse nginx log nganggo ekspresi biasa.

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

Hayu urang parse request_url. Ngagunakeun regexp kami nangtukeun tujuan pamundut: mun data statik, mun poto, mun API tur nyetel konci pakait dina peta sasari.

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

Ngagunakeun operator kondisional dina Citakan, urang pariksa widang dipasang dina peta sasari tur nyetel nilai diperlukeun pikeun request_type widang: poto, statik, API. Napelkeun séjén lamun gagal. request_type ayeuna ngandung tipe pamundut.

       - labels:
           api_request:
           virtual_host:
           request_type:
           status:

Kami nyetél labél api_request, virtual_host, request_type sareng status (status HTTP) dumasar kana naon anu urang junun nempatkeun dina peta anu sasari.

       - output:
           source: nginx_log_row

Robah kaluaran. Ayeuna log nginx anu dibersihkeun tina peta anu diekstrak angkat ka Loki.

Saatos ngajalankeun konfigurasi di luhur, anjeun tiasa ningali yén unggal éntri ditugaskeun labél dumasar kana data tina log.

Hiji hal anu kedah diperhatoskeun nyaéta nyandak labél kalayan sajumlah ageung nilai (kardinalitas) tiasa ngalambatkeun Loki sacara signifikan. Nyaéta, anjeun teu kedah nempatkeun, contona, user_id dina indéks. Baca langkung seueur ngeunaan ieu dina tulisan "Kumaha labél di Loki tiasa ngajantenkeun pamundut log langkung gancang sareng langkung gampang" Tapi ieu lain hartosna yén anjeun teu bisa neangan ku user_id tanpa indexes. Anjeun kedah nganggo saringan nalika milarian ("cekel" data), sareng indéks di dieu bertindak salaku identifier aliran.

Visualisasi log

Loki tiasa janten sumber data pikeun grafik Grafana nganggo LogQL. Fitur di handap ieu dirojong:

• laju - jumlah rékaman per detik;
• count leuwih waktos - jumlah rékaman dina rentang dieusian.

Aya ogé fungsi aggregation Sum, Avg jeung sajabana. Anjeun tiasa ngawangun grafik anu cukup rumit, contona grafik jumlah kasalahan HTTP:

Sumber data baku Loki rada ngurangan di pungsionalitasna dibandingkeun sumber data Prometheus (Contona, anjeun teu bisa ngarobah legenda), tapi Loki bisa disambungkeun salaku sumber jeung tipe Prometheus. Abdi henteu yakin upami ieu mangrupikeun kabiasaan anu didokumentasikeun, tapi ditilik ku réspon pamekar "Kumaha ngonpigurasikeun Loki salaku sumber data Prometheus? · Ngaluarkeun #1222 · grafana/loki", contona, sagemblengna légal, sarta Loki sapinuhna cocog sareng PromQL.

Tambihkeun Loki salaku sumber data kalayan jinis Prometheus sareng tambahkeun URL /loki:

Sareng urang tiasa ngadamel grafik, saolah-olah urang damel sareng métrik ti Prometheus:

Kuring nyangka yén bédana fungsionalitas samentawis sareng pamekar bakal ngabenerkeun ieu ka hareup.

Métrik

Loki nyadiakeun kamampuhan pikeun nimba metrics numerik tina log sarta ngirimkeunana ka Prometheus. Contona, log nginx ngandung jumlah bait per respon, kitu ogé, ku modifikasi tangtu format log baku, waktu dina detik nu diperlukeun pikeun ngabales. Data ieu tiasa diékstrak sareng dikirim ka Prometheus.

Tambahkeun bagian sejen kana 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

Pilihan éta ngamungkinkeun anjeun pikeun nangtukeun sareng ngapdet métrik dumasar kana data tina peta anu sasari. Métrik ieu henteu dikirim ka Loki - aranjeunna muncul dina titik tungtung Promtail /metrics. Prometheus kedah dikonpigurasikeun pikeun nampi data anu ditampi dina tahap ieu. Dina conto di luhur, pikeun request_type = "api" kami ngumpulkeun métrik histogram. Kalawan tipe ieu metrics éta merenah pikeun ménta persentil. Pikeun statik sareng poto, kami ngumpulkeun jumlah bait sareng jumlah barisan dimana kami nampi bait pikeun ngitung rata-rata.

Baca langkung seueur ngeunaan métrik di dieu.

Buka port dina Promtail:

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

Pastikeun yén métrik kalayan awalan promtail_custom muncul:

Nyetél Prometheus. Tambahkeun Promtail Proyék:

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

Sareng urang ngagambar grafik:

Ku cara ieu anjeun tiasa mendakan, contona, opat patarosan anu paling laun. Anjeun ogé tiasa nyetél ngawaskeun métrik ieu.

Skala

Loki tiasa boh dina modeu binér tunggal atanapi dina modeu sharded (mode skala-horizontal). Dina kasus kadua, éta tiasa nyimpen data kana awan, sareng sakumpulan sareng indéks disimpen nyalira. Vérsi 1.5 ngenalkeun kamampuan pikeun nyimpen di hiji tempat, tapi henteu disarankeun pikeun dianggo dina produksi.

Sakumpulan bisa disimpen dina gudang S3-cocog, sarta database horisontal scalable bisa dipaké pikeun nyimpen indexes: Cassandra, BigTable atanapi DynamoDB. Bagian séjén Loki - Distributor (pikeun nulis) jeung Querier (pikeun queries) - nu stateless sarta ogé skala horisontal.

Dina konperénsi DevOpsDays Vancouver 2019, salah sahiji pamilon Callum Styan ngumumkeun yén sareng Loki proyékna ngagaduhan petabytes log kalayan indéks kirang ti 1% tina total ukuran: "Kumaha Loki Ngahubungkeun Métrik sareng Log - Sareng Ngahémat Duit Anjeun".

Babandingan Loki jeung ELK

Ukuran indéks

Pikeun nguji ukuran indéks anu dihasilkeun, kuring nyandak log tina wadah nginx dimana Pipeline di luhur dikonpigurasi. Berkas log ngandung 406 garis kalayan volume total 624 MB. Log dihasilkeun dina sajam, kira-kira 109 éntri per detik.

Conto dua garis tina log:

Nalika diindéks ku ELK, ieu masihan ukuran indéks 30,3 MB:

Dina kasus Loki, ieu nyababkeun kira-kira 128 KB indéks sareng sakitar 3,8 MB data dina sakumpulan. Eta sia noting yén log ieu dihasilkeun sacara artifisial jeung teu boga rupa badag data. A gzip basajan dina log Docker JSON aslina kalawan data masihan komprési 95,4%, sarta nyokot kana akun kanyataan yén ngan log nginx cleaned dikirim ka Loki sorangan, komprési nepi ka 4 MB bisa kaharti. Jumlah total nilai unik pikeun labél Loki éta 35, anu ngajelaskeun ukuran leutik indéks. Pikeun ELK log ogé diberesihan. Ku kituna, Loki dikomprés data aslina ku 96%, sarta ELK ku 70%.

Konsumsi mémori

Lamun urang ngabandingkeun sakabéh tumpukan Prometheus na ELK, Loki "dahar" sababaraha kali kirang. Ieu jelas yén layanan Go meakeun kirang ti layanan Java, sarta ngabandingkeun ukuran JVM numpuk Elasticsearch jeung memori dialokasikeun pikeun Loki teu bener, tapi eta sia noting yén Loki ngagunakeun memori teuing kirang. Kauntungannana CPU na teu jadi atra, tapi ogé hadir.

kagancangan

Loki "devours" log leuwih gancang. Laju gumantung kana sababaraha faktor - jenis log naon, kumaha canggih kami dina parsing aranjeunna, jaringan, disk, jeung sajabana - tapi pasti leuwih luhur ti ELK (dina test kuring - ngeunaan dua kali loba). Ieu dijelaskeun ku kanyataan yén Loki nempatkeun langkung seueur data kana indéks sareng, sasuai, nyéépkeun waktos langkung seueur pikeun indéks. Kalawan speed pilarian, kaayaan téh sabalikna: Loki noticeably slows turun dina data leuwih badag batan sababaraha gigabytes, bari speed pilarian ELK urang henteu gumantung kana ukuran data.

Pilarian ku log

Loki sacara signifikan inferior mun ELK dina watesan kamampuhan pilarian log. Grep kalawan ekspresi biasa kuat, tapi inferior mun database dewasa. Kurangna queries rentang, aggregation ukur ku labél, henteu mampuh neangan tanpa labél - kabeh ieu ngawatesan urang dina neangan informasi dipikaresep ku Loki. Ieu henteu hartosna yén nanaon bisa kapanggih maké Loki, tapi ngahartikeun aliran gawé bareng log sawaktos Anjeun pertama manggihan masalah dina grafik Prometheus, lajeng nganggo labél ieu pikeun néangan naon anu lumangsung dina log.

interface

Mimitina, geulis (punten, teu tiasa nolak). Grafana ngagaduhan antarmuka anu saé, tapi Kibana langkung seueur fitur.

Pro jeung kontra ngeunaan Loki

Salah sahiji kaunggulan nyaéta Loki ngahijikeun sareng Prometheus, janten kami nampi métrik sareng waspada tina kotak. Éta merenah pikeun ngumpulkeun log sareng nyimpenna tina Kubernetes Pods, sabab gaduh penemuan jasa anu diwariskeun ti Prometheus sareng otomatis ngalampirkeun labél.

The downside nyaeta dokuméntasi lemah. Sawatara hal, contona, fitur sareng kamampuan Promtail, kuring ngan ukur mendakan dina prosés diajar kodeu, untungna éta open-source. Karugian sanésna nyaéta kamampuan parsing anu lemah. Contona, Loki teu bisa parse log multiline. Karugian sanésna nyaéta Loki mangrupikeun téknologi anu kawilang ngora (ngarilis 1.0 dina bulan Nopémber 2019).

kacindekan

Loki mangrupikeun téknologi anu pikaresepeun 100% anu cocog pikeun proyék-proyék leutik sareng sedeng, ngamungkinkeun anjeun pikeun ngabéréskeun seueur masalah agrégasi log, milarian log, ngawaskeun sareng analisa log.

Kami henteu nganggo Loki di Badoo sabab kami gaduh tumpukan ELK anu cocog sareng kami sareng anu parantos ditumbuh ku sababaraha solusi khusus salami mangtaun-taun. Pikeun urang, halangan nyaéta milarian log. Kalayan ampir 100 GB log per dinten, hal anu penting pikeun urang tiasa mendakan sadayana sareng sakedik deui sareng ngalakukeunana gancang. Pikeun charting jeung ngawaskeun, urang ngagunakeun solusi séjén nu tailored ka kabutuhan urang jeung terpadu saling. Tumpukan Loki ngagaduhan kauntungan anu nyata, tapi éta moal masihan urang langkung seueur tibatan anu urang parantos gaduh, sareng kauntunganna pasti moal ngaleuwihan biaya migrasi.

Sareng sanaos saatos panilitian janten jelas yén kami henteu tiasa nganggo Loki, kami ngarepkeun tulisan ieu bakal ngabantosan anjeun dina pilihan anjeun.

Repository sareng kode anu dianggo dina tulisan aya di dieu.

sumber: www.habr.com