Nglumpukake log saka Loki

Kita ing Badoo terus-terusan ngawasi teknologi anyar lan ngevaluasi manawa bakal digunakake ing sistem kita utawa ora. Kita pengin nuduhake salah sawijining studi kasebut karo masyarakat. Iki khusus kanggo Loki, sistem agregasi log.

Loki minangka solusi kanggo nyimpen lan ndeleng log, lan tumpukan iki uga nyedhiyakake sistem sing fleksibel kanggo nganalisa lan ngirim data menyang Prometheus. Ing wulan Mei, nganyari liyane dirilis, sing dipromosekake kanthi aktif dening para pangripta. Kita kasengsem karo apa sing bisa ditindakake Loki, fitur apa sing disedhiyakake, lan sepira bisa dadi alternatif kanggo ELK, tumpukan sing digunakake saiki.

Apa Loki

Grafana Loki minangka kumpulan komponen kanggo sistem logging lengkap. Ora kaya sistem liyane sing padha, Loki adhedhasar ide mung ngindeks metadata log - label (kaya ing Prometheus), lan ngompres log dhewe-dhewe dadi potongan sing kapisah.

Kaca Ngarep, GitHub

Sadurunge aku ngerti apa sing bisa sampeyan lakoni karo Loki, aku pengin njlentrehake apa tegese "gagasan ngindeks mung metadata". Ayo mbandhingake pendekatan Loki lan pendekatan indeksasi ing solusi tradisional, kayata Elasticsearch, nggunakake conto baris saka 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 ngurai kabeh baris, kalebu kolom kanthi akeh nilai user_id lan item_id unik, lan nyimpen kabeh ing indeks gedhe. Kauntungan saka pendekatan iki yaiku sampeyan bisa mbukak pitakon kompleks kanthi cepet, amarga meh kabeh data ana ing indeks. Nanging sampeyan kudu mbayar iki ing indeks dadi gedhe, kang nerjemahake menyang syarat memori. Akibaté, indeks teks lengkap saka log bisa dibandhingake karo ukuran log kasebut. Kanggo nggoleki kanthi cepet, indeks kasebut kudu dimuat ing memori. Lan luwih akeh log, luwih cepet indeks mundhak lan memori luwih akeh.

Pendekatan Loki mbutuhake mung data sing dibutuhake sing diekstrak saka senar, jumlah nilai sing cilik. Kanthi cara iki, kita entuk indeks cilik lan bisa nggoleki data kanthi nyaring miturut wektu lan kolom sing diindeks, banjur mindhai liyane nganggo ekspresi reguler utawa telusuran substring. Proses kasebut ora katon paling cepet, nanging Loki mbagi panjaluk kasebut dadi pirang-pirang bagean lan nglakokake paralel, ngolah data sing akeh ing wektu sing cendhak. Jumlah shards lan panjalukan paralel ing wong-wong mau bisa dikonfigurasi; mangkono, jumlah data sing bisa diproses saben unit wektu gumantung linearly ing jumlah sumber kasedhiya.

Iki trade-off antarane indeks cepet gedhe lan indeks brute-force paralel cilik ngidini Loki ngontrol biaya sistem. Bisa dikonfigurasi kanthi fleksibel lan ditambahi miturut kabutuhan sampeyan.

Tumpukan Loki kasusun saka telung komponen: Promtail, Loki, Grafana. Promtail nglumpukake log, ngolah lan dikirim menyang Loki. Loki njaga dheweke. Lan Grafana bisa njaluk data saka Loki lan nuduhake. Umumé, Loki bisa digunakake ora mung kanggo nyimpen log lan nggoleki. Tumpukan kabeh menehi kesempatan gedhe kanggo ngolah lan nganalisa data sing mlebu nggunakake cara Prometheus.
Katrangan babagan proses instalasi bisa ditemokake kene.

Panelusuran Log

Sampeyan bisa nelusuri log ing antarmuka khusus Grafana - Explorer. Pitakonan nggunakake basa LogQL, sing meh padha karo PromQL sing digunakake dening Prometheus. Ing asas, bisa dianggep minangka grep sing disebarake.

Antarmuka telusuran katon kaya iki:

Pitakon kasebut dhewe dumadi saka rong bagean: pamilih lan saringan. Selector minangka telusuran kanthi indeks metadata (label) sing ditugasake menyang log, lan filter minangka string telusuran utawa regexp sing nyaring cathetan sing ditetepake dening pamilih. Ing conto sing diwenehake: Ing kurung kriting - pamilih, kabeh sawise - saringan.

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

Amarga cara kerjane Loki, sampeyan ora bisa njaluk panjaluk tanpa pamilih, nanging label bisa digawe kanthi sewenang-wenang.

Pamilih minangka nilai kunci saka nilai ing kurung kriting. Sampeyan bisa nggabungake pamilih lan nemtokake kahanan panelusuran sing beda nggunakake operator =, != utawa ekspresi reguler:

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

Filter minangka teks utawa regexp sing bakal nyaring kabeh data sing ditampa dening pamilih.

Sampeyan bisa entuk grafik ad-hoc adhedhasar data sing ditampa ing mode metrik. Contone, sampeyan bisa ngerteni frekuensi kedadeyan ing log nginx saka entri sing ngemot string indeks:

Katrangan lengkap babagan fitur bisa ditemokake ing dokumentasi LogQL.

Parsing log

Ana sawetara cara kanggo ngumpulake log:

• Kanthi bantuan saka Promtail, komponen standar tumpukan kanggo ngumpulake log.
• Langsung saka wadhah docker nggunakake Loki Docker Logging Driver.
• Gunakake Fluentd utawa Fluent Bit sing bisa ngirim data menyang Loki. Ora kaya Promtail, dheweke duwe parser sing wis siap kanggo meh kabeh jinis log lan uga bisa nangani log multiline.

Biasane Promtail digunakake kanggo parsing. Iku nindakake telung perkara:

• Nemokake sumber data.
• Pasang label kanggo wong-wong mau.
• Ngirim data menyang Loki.

Saiki Promtail bisa maca log saka file lokal lan saka jurnal systemd. Iku kudu diinstal ing saben mesin saka kang log diklumpukake.

Ana integrasi karo Kubernetes: Promtail kanthi otomatis ngerteni kahanan kluster liwat Kubernetes REST API lan ngumpulake log saka simpul, layanan utawa pod, langsung ngirim label adhedhasar metadata saka Kubernetes (jeneng pod, jeneng berkas, lsp.).

Sampeyan uga bisa nyumerepi label adhedhasar data saka log nggunakake Pipeline. Pipeline Promtail bisa kalebu patang jinis tahapan. Rincian liyane - ing dokumentasi resmi, Aku bakal langsung nyathet sawetara nuansa.

1. Tahap parsing. Iki minangka tataran RegEx lan JSON. Ing tahap iki, kita ngekstrak data saka log menyang peta sing diekstrak. Sampeyan bisa ngekstrak saka JSON kanthi mung nyalin lapangan sing kita butuhake menyang peta sing diekstrak, utawa liwat ekspresi reguler (RegEx), ing ngendi klompok sing dijenengi "dipetakan" menyang peta sing diekstrak. Peta sing diekstrak minangka panyimpenan nilai kunci, ing ngendi kunci minangka jeneng lapangan, lan nilai kasebut minangka nilai saka log.
2. Transformasi tahapan. Tahap iki nduweni rong pilihan: transformasi, ing ngendi kita nyetel aturan transformasi, lan sumber - sumber data kanggo transformasi saka peta sing diekstrak. Yen ora ana lapangan kasebut ing peta sing diekstrak, mula bakal digawe. Mangkono, bisa nggawe label sing ora adhedhasar peta sing diekstrak. Ing tataran iki, kita bisa ngapusi data ing peta dijupuk nggunakake cukup kuat cithakan golang. Kajaba iku, kita kudu ngelingi yen peta sing diekstrak wis dimuat kanthi lengkap sajrone parsing, sing ndadekake, contone, kanggo mriksa nilai kasebut: "{{yen .tag}nilai tag ana{end}}". Cithakan ndhukung kahanan, puteran, lan sawetara fungsi senar kayata Ganti lan Trim.
3. Tahap tumindak. Ing tahap iki, sampeyan bisa nindakake apa wae kanthi ekstrak:
   • Nggawe label saka data sing diekstrak, sing bakal diindeks dening Loki.
   • Ngganti utawa nyetel wektu acara saka log.
   • Ngganti data (teks log) sing bakal pindhah menyang Loki.
   • Nggawe metrik.
4. Tahap nyaring. Tahap pertandhingan, ing ngendi kita bisa ngirim rekaman sing ora perlu kanggo / dev / null, utawa ngirim kanggo proses luwih.

Nggunakake conto ngolah log nginx biasa, aku bakal nuduhake carane sampeyan bisa ngurai log nggunakake Promtail.

Kanggo tes, ayo njupuk gambar nginx jwilder/nginx-proxy:alpine lan daemon cilik sing bisa takon dhewe liwat HTTP minangka nginx-proxy. Daemon nduweni sawetara titik pungkasan, sing bisa menehi respon kanthi ukuran sing beda-beda, kanthi status HTTP sing beda lan wektu tundha sing beda.

Kita bakal ngumpulake log saka wadhah docker, sing bisa ditemokake ing dalan /var/lib/docker/containers/ / -json.log

Ing docker-compose.yml kita nyiyapake Promtail lan nemtokake dalan menyang 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'
 // ...

Tambah path menyang log menyang promtail.yml (ana "docker" pilihan ing config sing padha ing siji baris, nanging ora bakal dadi ketok):

scrape_configs:
 - job_name: containers

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

Nalika konfigurasi iki diaktifake, Loki bakal nampa log saka kabeh wadhah. Kanggo ngindhari iki, kita ngganti setelan nginx test ing docker-compose.yml - nambah log menyang kolom tag:

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

Owahi promtail.yml lan atur Pipeline. Log kasebut kaya ing ngisor iki:

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

tahapan pipa:

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

We extract kolom stream, attrs, attrs.tag (yen ana) saka JSON mlebu lan sijine menyang peta sing diekstrak.

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

Yen sampeyan bisa nyelehake kolom tag ing peta sing diekstrak, banjur nggunakake regexp kita extract jeneng gambar lan wadhah.

 - labels:
     image_name:
     container_name:

Kita nemtokake label. Yen tombol image_name lan container_name ditemokake ing data sing diekstrak, nilai kasebut bakal ditugasake menyang label sing cocog.

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

Kita mbuang kabeh log sing ora duwe label image_name lan container_name set.

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

Kanggo kabeh log sing image_name padha karo nginx.promtail.test, kita extract kolom log saka log sumber lan sijine ing peta sing dijupuk nganggo tombol baris.

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

Kita mbusak string input kanthi ekspresi biasa lan narik host virtual nginx lan 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 log nginx kanthi ekspresi reguler.

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

Parse request_url. Kanthi bantuan regexp, kita nemtokake tujuan panyuwunan: statis, foto, API lan nyetel kunci sing cocog ing peta sing diekstrak.

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

Nggunakake operator kondisional ing Cithakan, kita mriksa kothak sing diinstal ing peta sing diekstrak lan nyetel nilai sing dibutuhake kanggo kolom request_type: foto, statis, API. Nemtokake liyane yen gagal. Saiki request_type ngemot jinis request.

       - labels:
           api_request:
           virtual_host:
           request_type:
           status:

Kita nyetel label api_request, virtual_host, request_type lan status (status HTTP) adhedhasar apa sing bisa dilebokake ing peta sing diekstrak.

       - output:
           source: nginx_log_row

Ngganti output. Saiki log nginx sing wis diresiki saka peta sing diekstrak menyang Loki.

Sawise mbukak konfigurasi ing ndhuwur, sampeyan bisa ndeleng manawa saben entri diwenehi label adhedhasar data saka log.

Elinga yen ngekstrak label kanthi nomer akeh nilai (kardinalitas) bisa nyuda Loki kanthi signifikan. Sing, sampeyan ora kudu sijine ing indeks, contone, user_id. Waca liyane babagan iki ing artikelKepiye label ing Loki bisa nggawe pitakon log luwih cepet lan luwih gampang". Nanging iki ora ateges sampeyan ora bisa nggoleki kanthi user_id tanpa indeks. Sampeyan perlu nggunakake saringan nalika nggoleki ("nyekel" miturut data), lan indeks ing kene tumindak minangka pengenal stream.

Visualisasi log

Loki bisa dadi sumber data kanggo grafik Grafana nggunakake LogQL. Fitur ing ngisor iki didhukung:

• rate - nomer cathetan per detik;
• count liwat wektu - jumlah cathetan ing sawetara tartamtu.

Ana uga fungsi aggregating Sum, Avg lan liya-liyane. Sampeyan bisa nggawe grafik sing cukup rumit, contone, grafik jumlah kesalahan HTTP:

sumber data standar Loki punika dicokot kurang fungsi saka sumber data Prometheus (Contone, sampeyan ora bisa ngganti legenda), nanging Loki bisa disambungake minangka sumber jinis Prometheus. Aku ora yakin manawa iki minangka prilaku sing didokumentasikake, nanging kanthi menehi tanggapan saka pangembang "Kepiye cara ngatur Loki minangka sumber data Prometheus? · Jeksa Agung bisa ngetokake # 1222 · grafana/loki”, contone, iku sampurna legal lan Loki kebak kompatibel karo PromQL.

Tambah Loki minangka sumber data kanthi jinis Prometheus lan nambah URL /loki:

Lan sampeyan bisa nggawe grafik, kaya-kaya kita nggarap metrik saka Prometheus:

Aku mikir sing bedo ing fungsi sak wentoro lan gawe bakal ndandani iku ing mangsa.

Metrik

Loki nyedhiyakake kemampuan kanggo ngekstrak metrik numerik saka log lan dikirim menyang Prometheus. Contone, log nginx ngemot jumlah bita saben respon, lan uga, kanthi modifikasi tartamtu saka format log standar, wektu ing sawetara detik kanggo nanggapi. Data iki bisa diekstrak lan dikirim menyang Prometheus.

Tambah bagean liyane menyang 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

Opsi kasebut ngidini sampeyan nemtokake lan nganyari metrik adhedhasar data saka peta sing diekstrak. Metrik iki ora dikirim menyang Loki - katon ing titik pungkasan Promtail /metrics. Prometheus kudu dikonfigurasi kanggo nampa data saka tahap iki. Ing conto ing ndhuwur, kanggo request_type = "api" kita ngumpulake metrik histogram. Kanthi jinis metrik iki trep kanggo entuk persentil. Kanggo statis lan foto, kita ngumpulake jumlah bita lan jumlah baris sing ditampa bita kanggo ngetung rata-rata.

Waca liyane babagan metrik kene.

Bukak port ing Promtail:

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

Kita priksa manawa metrik kanthi awalan promtail_custom wis katon:

Nggawe Prometheus. Tambah lowongan kerja:

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

Lan nggambar grafik:

Kanthi cara iki sampeyan bisa ngerteni, contone, papat panjaluk sing paling alon. Sampeyan uga bisa ngatur pemantauan kanggo metrik kasebut.

Scaling

Loki bisa ing mode binar tunggal lan sharded (mode skala horisontal). Ing kasus kapindho, bisa nyimpen data menyang awan, lan potongan lan indeks disimpen kanthi kapisah. Ing versi 1.5, kemampuan kanggo nyimpen ing sak panggonan wis dileksanakake, nanging durung dianjurake kanggo nggunakake ing produksi.

Potongan bisa disimpen ing panyimpenan sing kompatibel karo S3, kanggo nyimpen indeks, gunakake database sing bisa diukur kanthi horisontal: Cassandra, BigTable utawa DynamoDB. Bagean liyane Loki - Distributor (kanggo nulis) lan Querier (kanggo pitakon) - ora ana negara lan uga skala horisontal.

Ing konferensi DevOpsDays Vancouver 2019, salah sawijining peserta Callum Styan ngumumake manawa karo Loki proyeke duwe petabyte log kanthi indeks kurang saka 1% saka ukuran total: "Kepiye Loki Korelasi Metrik lan Log - Lan Ngirit Dhuwit Sampeyan".

Perbandingan Loki lan ELK

Ukuran indeks

Kanggo nguji ukuran indeks sing diasilake, aku njupuk log saka wadhah nginx sing Pipeline ing ndhuwur dikonfigurasi. Berkas log ngemot 406 baris kanthi volume total 624 MB. Log digawe sajrone jam, kira-kira 109 rekaman per detik.

Conto rong baris saka log:

Nalika diindeks dening ELK, iki menehi ukuran indeks 30,3 MB:

Ing kasus Loki, iki menehi sekitar 128 KB indeks lan udakara 3,8 MB data ing potongan. Wigati dicathet yen log digawe kanthi artifisial lan ora ngemot macem-macem data. A gzip prasaja ing log Docker JSON asli karo data menehi komprèsi 95,4%, lan diwenehi sing mung di resiki log nginx dikirim menyang Loki dhewe, komprèsi kanggo 4 MB bisa dingerteni. Jumlah total nilai unik kanggo label Loki yaiku 35, sing nerangake ukuran indeks sing cilik. Kanggo ELK, log kasebut uga dibusak. Mangkono, Loki ngompres data asli kanthi 96%, lan ELK kanthi 70%.

Konsumsi memori

Yen kita mbandhingake kabeh tumpukan Prometheus lan ELK, banjur Loki "mangan" kaping pirang-pirang kurang. Cetha yen layanan Go nganggo kurang saka layanan Java, lan mbandhingake ukuran Heap Elasticsearch JVM lan memori sing diparengake kanggo Loki ora bener, nanging kudu dicathet yen Loki nggunakake memori sing luwih sithik. Kaluwihan CPU ora dadi ketok, nanging uga ana.

Kacepetan

Loki "devours" log luwih cepet. Kacepetan gumantung ing akeh faktor - apa jenis log, carane canggih kita parse wong, jaringan, disk, lan sapiturute - nanging mesthi luwih dhuwur tinimbang ELK (ing test - bab kaping pindho). Iki diterangake kanthi kasunyatan manawa Loki nglebokake data sing luwih sithik menyang indeks lan, kanthi mangkono, mbuwang wektu luwih sithik kanggo indeksasi. Ing kasus iki, kahanan dibalikake kanthi kacepetan telusuran: Loki nyepetake data sing luwih gedhe tinimbang sawetara gigabyte, dene kanggo ELK, kacepetan telusuran ora gumantung saka ukuran data.

Panelusuran Log

Loki sacara signifikan luwih cendhek tinimbang ELK babagan kemampuan telusuran log. Grep kanthi ekspresi reguler minangka perkara sing kuwat, nanging luwih murah tinimbang database diwasa. Kurang pitakon sawetara, panggabungan mung kanthi label, ora bisa nelusuri tanpa label - kabeh iki mbatesi kita nggoleki informasi babagan Loki. Iki ora ateges ora ana sing bisa ditemokake nggunakake Loki, nanging nemtokake aliran kerja karo log, nalika sampeyan nemokake masalah ing grafik Prometheus, banjur goleki apa sing kedadeyan ing log nggunakake label kasebut.

antarmuka

Kaping pisanan, iku ayu (maaf, ora bisa nolak). Grafana nduweni antarmuka sing apik, nanging Kibana luwih fungsional.

Loki pros lan cons

Saka plus, bisa dicathet yen Loki nggabungake Prometheus, masing-masing, kita entuk metrik lan menehi tandha metu saka kothak. Iku trep kanggo ngumpulake log lan nyimpen karo Kubernetes Pods, amarga nduweni panemuan layanan sing diwarisake saka Prometheus lan kanthi otomatis nempelake label.

Saka minuses - dokumentasi miskin. Sawetara perkara, kayata fitur lan kemampuan Promtail, aku nemokake mung ing proses sinau kode, entuk manfaat saka open-source. Kerugian liyane yaiku kemampuan parsing sing lemah. Contone, Loki ora bisa ngurai log multiline. Kajaba iku, kekurangane kalebu kasunyatan manawa Loki minangka teknologi sing isih enom (rilis 1.0 ing November 2019).

kesimpulan

Loki minangka teknologi menarik 100% sing cocog kanggo proyek cilik lan medium, ngidini sampeyan ngatasi akeh masalah agregasi log, telusuran log, ngawasi lan nganalisa log.

Kita ora nggunakake Loki ing Badoo, amarga kita duwe tumpukan ELK sing cocog karo kita lan wis akeh banget karo macem-macem solusi khusus sajrone pirang-pirang taun. Kanggo kita, sandhungan yaiku panelusuran ing log. Kanthi meh 100 GB log saben dina, iku penting kanggo kita bisa nemokake kabeh lan sethitik liyane lan nindakaken cepet. Kanggo nggawe grafik lan ngawasi, kita nggunakake solusi liyane sing cocog karo kabutuhan lan digabungake karo siji liyane. Tumpukan Loki nduweni keuntungan nyata, nanging ora bakal menehi luwih saka apa sing kita duwe, lan keuntungan kasebut ora bakal ngluwihi biaya migrasi.

Lan sanajan sawise riset dadi jelas yen kita ora bisa nggunakake Loki, muga-muga kiriman iki bisa mbantu sampeyan milih.

Repositori kanthi kode sing digunakake ing artikel kasebut ana kene.

Source: www.habr.com