Mengumpul log daripada Loki

Di Badoo, kami sentiasa memantau teknologi baharu dan menilai sama ada ia berbaloi untuk digunakan dalam sistem kami. Kami ingin berkongsi salah satu kajian ini dengan masyarakat. Ia didedikasikan untuk Loki, sistem pengagregatan log.

Loki ialah penyelesaian untuk menyimpan dan melihat log, dan timbunan ini juga menyediakan sistem yang fleksibel untuk menganalisisnya dan menghantar data kepada Prometheus. Pada bulan Mei, kemas kini lain telah dikeluarkan, yang dipromosikan secara aktif oleh pencipta. Kami berminat dengan perkara yang boleh dilakukan oleh Loki, keupayaan yang disediakannya, dan sejauh mana ia boleh bertindak sebagai alternatif kepada ELK, susunan yang kami gunakan sekarang.

Apa itu Loki

Grafana Loki ialah satu set komponen untuk sistem lengkap untuk bekerja dengan log. Tidak seperti sistem lain yang serupa, Loki berdasarkan idea untuk mengindeks hanya metadata log - label (sama seperti dalam Prometheus), dan memampatkan log itu sendiri ke dalam ketulan yang berasingan.

Halaman rumah, GitHub

Sebelum kita mengetahui perkara yang boleh anda lakukan dengan Loki, saya ingin menjelaskan apa yang kami maksudkan dengan "idea mengindeks hanya metadata." Mari kita bandingkan pendekatan Loki dan pendekatan untuk mengindeks dalam penyelesaian tradisional seperti Elasticsearch, menggunakan contoh baris dari 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 menghuraikan keseluruhan baris, termasuk medan dengan sejumlah besar nilai user_id dan item_id yang unik, dan menyimpan segala-galanya dalam indeks yang besar. Kelebihan pendekatan ini ialah anda boleh menjalankan pertanyaan kompleks dengan cepat, kerana hampir semua data berada dalam indeks. Tetapi ini memerlukan kos kerana indeks menjadi besar, yang diterjemahkan ke dalam keperluan memori. Akibatnya, indeks log teks penuh adalah setanding saiz dengan log itu sendiri. Untuk mencarinya dengan cepat, indeks mesti dimuatkan ke dalam memori. Dan lebih banyak log, lebih cepat indeks berkembang dan lebih banyak memori yang digunakan.

Pendekatan Loki memerlukan hanya data yang diperlukan diekstrak daripada rentetan, yang bilangan nilainya kecil. Dengan cara ini kita mendapat indeks kecil dan boleh mencari data dengan menapisnya mengikut masa dan mengikut medan diindeks, dan kemudian mengimbas selebihnya dengan ungkapan biasa atau carian subrentetan. Proses itu nampaknya bukan yang paling pantas, tetapi Loki membahagikan permintaan kepada beberapa bahagian dan melaksanakannya secara selari, memproses sejumlah besar data dalam masa yang singkat. Bilangan serpihan dan permintaan selari di dalamnya boleh dikonfigurasikan; oleh itu, jumlah data yang boleh diproses setiap unit masa bergantung secara linear pada jumlah sumber yang disediakan.

Pertukaran antara indeks yang besar dan pantas dan indeks kekerasan yang kecil selari membolehkan Loki mengawal kos sistem. Ia boleh dikonfigurasikan secara fleksibel dan dikembangkan mengikut keperluan.

Timbunan Loki terdiri daripada tiga komponen: Promtail, Loki, Grafana. Promtail mengumpul log, memprosesnya dan menghantarnya ke Loki. Loki menyimpan mereka. Dan Grafana boleh meminta data daripada Loki dan memaparkannya. Secara umum, Loki boleh digunakan bukan sahaja untuk menyimpan log dan mencari melaluinya. Keseluruhan timbunan menyediakan peluang hebat untuk memproses dan menganalisis data masuk menggunakan cara Prometheus.
Penerangan mengenai proses pemasangan boleh didapati di sini.

Carian Log

Anda boleh mencari log dalam antara muka khas Grafana - Explorer. Pertanyaan menggunakan bahasa LogQL, yang hampir sama dengan PromQL yang digunakan dalam Prometheus. Pada dasarnya, ia boleh dianggap sebagai grep yang diedarkan.

Antara muka carian kelihatan seperti ini:

Permintaan itu sendiri terdiri daripada dua bahagian: pemilih dan penapis. Pemilih ialah carian menggunakan metadata (label) terindeks yang diperuntukkan kepada log, dan penapis ialah rentetan carian atau ekspres yang menapis rekod yang ditakrifkan oleh pemilih. Dalam contoh yang diberikan: Dalam pendakap kerinting terdapat pemilih, semuanya selepas adalah penapis.

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

Oleh kerana cara Loki berfungsi, anda tidak boleh membuat pertanyaan tanpa pemilih, tetapi label boleh dibuat seumum yang anda suka.

Pemilih ialah nilai nilai kunci dalam pendakap kerinting. Anda boleh menggabungkan pemilih dan menentukan keadaan carian yang berbeza menggunakan operator =, != atau ungkapan biasa:

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

Penapis ialah teks atau regexp yang akan menapis semua data yang diterima oleh pemilih.

Anda boleh mendapatkan graf ad-hoc berdasarkan data yang diterima dalam mod metrik. Sebagai contoh, anda boleh mengetahui kekerapan kemasukan yang mengandungi indeks rentetan muncul dalam log nginx:

Penerangan penuh tentang keupayaan boleh didapati dalam dokumentasi LogQL.

Penghuraian log

Terdapat beberapa cara untuk mengumpul log:

• Menggunakan Promtail, komponen standard timbunan untuk mengumpul log.
• Terus dari bekas docker menggunakan Pemacu Loki Docker Logging.
• Gunakan Fluentd atau Fluent Bit, yang boleh menghantar data ke Loki. Tidak seperti Promtail, mereka mempunyai penghurai siap sedia untuk hampir semua jenis log dan juga boleh mengendalikan log berbilang talian.

Biasanya Promtail digunakan untuk menghurai. Ia melakukan tiga perkara:

• Mencari sumber data.
• Lampirkan label pada mereka.
• Menghantar data kepada Loki.

Pada masa ini Promtail boleh membaca log daripada fail tempatan dan dari jurnal systemd. Ia mesti dipasang pada setiap mesin dari mana log dikumpulkan.

Terdapat penyepaduan dengan Kubernetes: Promtail secara automatik, melalui API REST Kubernetes, mengenali keadaan kluster dan mengumpul log daripada nod, perkhidmatan atau pod, serta-merta menyiarkan label berdasarkan metadata daripada Kubernetes (nama pod, nama fail, dll.) .

Anda juga boleh menggantung label berdasarkan data daripada log menggunakan Pipeline. Pipeline Promtail boleh terdiri daripada empat jenis peringkat. Butiran lanjut dalam dokumentasi rasmi, saya akan segera perhatikan beberapa nuansa.

1. Peringkat penghuraian. Ini ialah peringkat RegEx dan JSON. Pada peringkat ini, kami mengekstrak data daripada log ke dalam apa yang dipanggil peta yang diekstrak. Kami boleh mengekstrak daripada JSON dengan hanya menyalin medan yang kami perlukan ke dalam peta yang diekstrak, atau melalui ungkapan biasa (RegEx), di mana kumpulan bernama "dipetakan" ke dalam peta yang diekstrak. Peta yang diekstrak ialah stor nilai kunci, dengan kunci ialah nama medan dan nilai ialah nilainya daripada log.
2. Mengubah peringkat. Peringkat ini mempunyai dua pilihan: transformasi, di mana kami menetapkan peraturan transformasi, dan sumber - sumber data untuk transformasi daripada peta yang diekstrak. Jika tiada medan sedemikian dalam peta yang diekstrak, ia akan dibuat. Dengan cara ini adalah mungkin untuk membuat label yang tidak berdasarkan peta yang diekstrak. Pada peringkat ini kita boleh memanipulasi data dalam peta yang diekstrak menggunakan yang agak berkuasa Templat Golang. Di samping itu, kita mesti ingat bahawa peta yang diekstrak dimuatkan sepenuhnya semasa penghuraian, yang membolehkan, sebagai contoh, untuk menyemak nilai di dalamnya: "{{jika .tag}nilai teg wujud{end}}". Templat menyokong keadaan, gelung dan beberapa fungsi rentetan seperti Ganti dan Pangkas.
3. Peringkat tindakan. Pada ketika ini anda boleh melakukan sesuatu dengan kandungan yang diekstrak:
   • Buat label daripada data yang diekstrak, yang akan diindeks oleh Loki.
   • Tukar atau tetapkan masa acara daripada log.
   • Tukar data (teks log) yang akan pergi ke Loki.
   • Buat metrik.
4. Peringkat penapisan. Peringkat perlawanan, di mana kita boleh sama ada menghantar entri yang kita tidak perlu /dev/null atau memajukannya untuk pemprosesan selanjutnya.

Menggunakan contoh pemprosesan log nginx biasa, saya akan menunjukkan bagaimana anda boleh menghuraikan log menggunakan Promtail.

Untuk ujian, mari kita ambil sebagai nginx-proxy imej nginx yang diubah suai jwilder/nginx-proxy:alpine dan daemon kecil yang boleh bertanya sendiri melalui HTTP. Daemon mempunyai beberapa titik akhir, yang mana ia boleh memberikan respons dengan saiz yang berbeza, dengan status HTTP yang berbeza dan dengan kelewatan yang berbeza.

Kami akan mengumpul log daripada bekas docker, yang boleh didapati di sepanjang laluan /var/lib/docker/containers/ / -json.log

Dalam docker-compose.yml kami mengkonfigurasi Promtail dan menentukan laluan ke 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'
 // ...

Tambahkan laluan ke log ke promtail.yml (terdapat pilihan "docker" dalam konfigurasi, yang melakukan perkara yang sama dalam satu baris, tetapi ia tidak begitu jelas):

scrape_configs:
 - job_name: containers

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

Apabila konfigurasi ini didayakan, log daripada semua bekas akan dihantar ke Loki. Untuk mengelakkan ini, kami menukar tetapan ujian nginx dalam docker-compose.yml - tambah medan tag pengelogan:

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

Mengedit promtail.yml dan menyediakan Pipeline. Input termasuk log jenis berikut:

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

Peringkat saluran paip:

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

Kami mengekstrak strim medan, attrs, attrs.tag (jika wujud) daripada JSON masuk dan meletakkannya dalam peta yang diekstrak.

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

Jika kami berjaya meletakkan medan teg dalam peta yang diekstrak, kemudian menggunakan regexp kami mengekstrak nama imej dan bekas.

 - labels:
     image_name:
     container_name:

Kami menetapkan label. Jika kekunci image_name dan container_name ditemui dalam data yang diekstrak, maka nilainya akan diberikan kepada label yang sepadan.

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

Kami membuang semua log yang tidak mempunyai label terpasang image_name dan container_name.

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

Untuk semua log yang imej_namenya ialah nginx.promtail.test, ekstrak medan log daripada log sumber dan letakkannya dalam peta yang diekstrak dengan kekunci baris.

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

Kami mengosongkan baris input dengan ungkapan biasa dan mengeluarkan hos maya nginx dan baris 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 menggunakan ungkapan 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>[^/?.]+).*$

Mari kita menghuraikan request_url. Menggunakan regexp kami menentukan tujuan permintaan: kepada data statik, kepada foto, kepada API dan menetapkan kunci yang sepadan dalam peta yang diekstrak.

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

Menggunakan operator bersyarat dalam Templat, kami menyemak medan yang dipasang dalam peta yang diekstrak dan menetapkan nilai yang diperlukan untuk medan request_type: photo, static, API. Tetapkan yang lain jika gagal. request_type kini mengandungi jenis permintaan.

       - labels:
           api_request:
           virtual_host:
           request_type:
           status:

Kami menetapkan label api_request, virtual_host, request_type dan status (status HTTP) berdasarkan apa yang kami berjaya letakkan dalam peta yang diekstrak.

       - output:
           source: nginx_log_row

Tukar output. Sekarang log nginx yang dibersihkan daripada peta yang diekstrak pergi ke Loki.

Selepas menjalankan konfigurasi di atas, anda boleh melihat bahawa setiap entri diberikan label berdasarkan data daripada log.

Satu perkara yang perlu diingat ialah mendapatkan semula label dengan sejumlah besar nilai (kardinaliti) boleh melambatkan Loki dengan ketara. Iaitu, anda tidak sepatutnya meletakkan, sebagai contoh, user_id dalam indeks. Baca lebih lanjut mengenai ini dalam artikel "Bagaimana label dalam Loki boleh membuat pertanyaan log lebih cepat dan lebih mudah" Tetapi ini tidak bermakna anda tidak boleh mencari mengikut user_id tanpa indeks. Anda perlu menggunakan penapis semasa mencari ("rebut" data), dan indeks di sini bertindak sebagai pengecam strim.

Visualisasi log

Loki boleh bertindak sebagai sumber data untuk graf Grafana menggunakan LogQL. Ciri-ciri berikut disokong:

• kadar — bilangan rekod sesaat;
• kiraan dari semasa ke semasa — bilangan rekod dalam julat yang ditentukan.

Terdapat juga fungsi pengagregatan Sum, Purata dan lain-lain. Anda boleh membina graf yang agak kompleks, contohnya graf bilangan ralat HTTP:

Sumber data standard Loki agak berkurangan dalam fungsi berbanding dengan sumber data Prometheus (contohnya, anda tidak boleh menukar legenda), tetapi Loki boleh disambungkan sebagai sumber dengan jenis Prometheus. Saya tidak pasti sama ada ini adalah tingkah laku yang didokumenkan, tetapi berdasarkan respons pembangun “Bagaimana untuk mengkonfigurasi Loki sebagai sumber data Prometheus? · Isu #1222 · grafana/loki”, sebagai contoh, adalah sah sepenuhnya, dan Loki serasi sepenuhnya dengan PromQL.

Tambahkan Loki sebagai sumber data dengan jenis Prometheus dan tambah URL /loki:

Dan kita boleh membuat graf, seolah-olah kita bekerja dengan metrik daripada Prometheus:

Saya berpendapat bahawa percanggahan dalam fungsi adalah sementara dan pembangun akan membetulkannya pada masa hadapan.

Metrik

Loki menyediakan keupayaan untuk mengekstrak metrik berangka daripada log dan menghantarnya ke Prometheus. Sebagai contoh, log nginx mengandungi bilangan bait setiap respons, serta, dengan pengubahsuaian tertentu format log standard, masa dalam saat yang diambil untuk bertindak balas. Data ini boleh diekstrak dan dihantar ke Prometheus.

Tambahkan bahagian lain pada 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 ini membolehkan anda menentukan dan mengemas kini metrik berdasarkan data daripada peta yang diekstrak. Metrik ini tidak dihantar ke Loki - ia muncul dalam titik akhir Promtail /metrics. Prometheus mesti dikonfigurasikan untuk menerima data yang diterima pada peringkat ini. Dalam contoh di atas, untuk request_type=“api” kami mengumpulkan metrik histogram. Dengan jenis metrik ini adalah mudah untuk mendapatkan persentil. Untuk statik dan foto, kami mengumpulkan jumlah bait dan bilangan baris yang kami terima bait untuk mengira purata.

Baca lebih lanjut mengenai metrik di sini.

Buka port pada Promtail:

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

Pastikan metrik dengan awalan promtail_custom muncul:

Menyediakan Prometheus. Tambah promtail kerja:

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

Dan kami melukis graf:

Dengan cara ini anda boleh mengetahui, sebagai contoh, empat pertanyaan paling perlahan. Anda juga boleh menyediakan pemantauan untuk metrik ini.

Penskalaan

Loki boleh sama ada dalam mod binari tunggal atau dalam mod sharded (mod boleh skala mendatar). Dalam kes kedua, ia boleh menyimpan data ke awan, dan ketulan dan indeks disimpan secara berasingan. Versi 1.5 memperkenalkan keupayaan untuk menyimpan di satu tempat, tetapi masih belum disyorkan untuk menggunakannya dalam pengeluaran.

Potongan boleh disimpan dalam storan serasi S3 dan pangkalan data boleh skala mendatar boleh digunakan untuk menyimpan indeks: Cassandra, BigTable atau DynamoDB. Bahagian lain Loki - Pengedar (untuk menulis) dan Querier (untuk pertanyaan) - adalah tanpa kewarganegaraan dan juga skala mendatar.

Pada persidangan DevOpsDays Vancouver 2019, salah seorang peserta Callum Styan mengumumkan bahawa dengan Loki projeknya mempunyai petabait log dengan indeks kurang daripada 1% daripada jumlah saiz: “Cara Loki Menghubungkaitkan Metrik dan Log — Dan Menjimatkan Wang Anda".

Perbandingan Loki dan ELK

Saiz indeks

Untuk menguji saiz indeks yang terhasil, saya mengambil log dari bekas nginx yang mana Pipeline di atas telah dikonfigurasikan. Fail log mengandungi 406 baris dengan jumlah volum 624 MB. Log dijana dalam masa sejam, kira-kira 109 entri sesaat.

Contoh dua baris daripada log:

Apabila diindeks oleh ELK, ini memberikan saiz indeks 30,3 MB:

Dalam kes Loki, ini menghasilkan kira-kira 128 KB indeks dan kira-kira 3,8 MB data dalam ketulan. Perlu diingat bahawa log itu dijana secara buatan dan tidak mempunyai pelbagai jenis data. Gzip ringkas pada log Docker JSON asal dengan data memberikan pemampatan sebanyak 95,4%, dan mengambil kira fakta bahawa hanya log nginx yang dibersihkan dihantar ke Loki sendiri, pemampatan sehingga 4 MB boleh difahami. Jumlah nilai unik untuk label Loki ialah 35, yang menerangkan saiz kecil indeks. Untuk ELK log itu juga telah dikosongkan. Oleh itu, Loki memampatkan data asal sebanyak 96%, dan ELK sebanyak 70%.

Penggunaan ingatan

Jika kita membandingkan keseluruhan timbunan Prometheus dan ELK, maka Loki "makan" beberapa kali lebih sedikit. Adalah jelas bahawa perkhidmatan Go menggunakan kurang daripada perkhidmatan Java, dan membandingkan saiz JVM Heap Elasticsearch dan memori yang diperuntukkan untuk Loki adalah tidak betul, tetapi perlu diingat bahawa Loki menggunakan lebih sedikit memori. Kelebihan CPUnya tidak begitu jelas, tetapi ia juga ada.

Kelajuan

Loki "memakan" log lebih cepat. Kelajuan bergantung pada banyak faktor - jenis log, betapa canggihnya kita dalam menghuraikannya, rangkaian, cakera, dll. - tetapi ia pasti lebih tinggi daripada ELK (dalam ujian saya - kira-kira dua kali lebih banyak). Ini dijelaskan oleh fakta bahawa Loki meletakkan lebih sedikit data ke dalam indeks dan, dengan itu, menghabiskan lebih sedikit masa untuk pengindeksan. Dengan kelajuan carian, keadaan adalah sebaliknya: Loki ketara memperlahankan data yang lebih besar daripada beberapa gigabait, manakala kelajuan carian ELK tidak bergantung pada saiz data.

Carian Log

Loki jauh lebih rendah daripada ELK dari segi keupayaan carian log. Grep dengan ungkapan biasa berkuasa, tetapi ia lebih rendah daripada pangkalan data matang. Kekurangan pertanyaan julat, pengagregatan hanya mengikut label, ketidakupayaan untuk mencari tanpa label - semua ini mengehadkan kami dalam mencari maklumat yang menarik di Loki. Ini tidak bermakna tiada apa yang boleh ditemui menggunakan Loki, tetapi ia mentakrifkan aliran bekerja dengan log apabila anda mula-mula menemui masalah dalam carta Prometheus, dan kemudian gunakan label ini untuk mencari perkara yang berlaku dalam log.

antara muka

Pertama sekali, ia cantik (maaf, tidak dapat menahan). Grafana mempunyai antara muka yang kelihatan bagus, tetapi Kibana lebih kaya dengan ciri.

Kebaikan dan keburukan Loki

Salah satu kelebihannya ialah Loki berintegrasi dengan Prometheus, jadi kami mendapat metrik dan makluman di luar kotak. Ia mudah untuk mengumpul log dan menyimpannya daripada Kubernetes Pods, kerana ia mempunyai penemuan perkhidmatan yang diwarisi daripada Prometheus dan melampirkan label secara automatik.

Kelemahannya ialah dokumentasi yang lemah. Beberapa perkara, sebagai contoh, ciri dan keupayaan Promtail, saya dapati hanya dalam proses mengkaji kod itu, mujurlah ia adalah sumber terbuka. Kelemahan lain ialah keupayaan penghuraian yang lemah. Sebagai contoh, Loki tidak boleh menghuraikan log berbilang baris. Satu lagi kelemahan ialah Loki adalah teknologi yang agak muda (keluaran 1.0 pada November 2019).

Kesimpulan

Loki ialah teknologi 100% menarik yang sesuai untuk projek kecil dan sederhana, membolehkan anda menyelesaikan banyak masalah pengagregatan log, carian log, pemantauan dan analisis log.

Kami tidak menggunakan Loki dalam Badoo kerana kami mempunyai timbunan ELK yang sesuai dengan kami dan yang telah ditumbuhi dengan pelbagai penyelesaian tersuai selama ini. Bagi kami, batu penghalang adalah mencari melalui log. Dengan hampir 100 GB log setiap hari, adalah penting bagi kami untuk dapat mencari segala-galanya dan lebih sedikit dan melakukannya dengan cepat. Untuk carta dan pemantauan, kami menggunakan penyelesaian lain yang disesuaikan dengan keperluan kami dan disepadukan antara satu sama lain. Timbunan Loki mempunyai faedah yang ketara, tetapi ia tidak akan memberi kita lebih daripada yang kita sedia ada, dan faedahnya pastinya tidak akan melebihi kos penghijrahan.

Dan walaupun selepas penyelidikan menjadi jelas bahawa kami tidak boleh menggunakan Loki, kami berharap siaran ini akan membantu anda dalam pilihan anda.

Repositori dengan kod yang digunakan dalam artikel terletak di sini.

Sumber: www.habr.com