Kukusanya kumbukumbu kutoka kwa Loki

Katika Badoo, sisi hufuatilia teknolojia mpya kila mara na kutathmini kama zinafaa kutumika katika mfumo wetu. Tungependa kushiriki mojawapo ya masomo haya na jamii. Imejitolea kwa Loki, mfumo wa kukusanya kumbukumbu.

Loki ni suluhisho la kuhifadhi na kutazama kumbukumbu, na mrundikano huu pia hutoa mfumo unaonyumbulika wa kuzichanganua na kutuma data kwa Prometheus. Mnamo Mei, sasisho lingine lilitolewa, ambalo linakuzwa kikamilifu na waundaji. Tulivutiwa na kile ambacho Loki anaweza kufanya, ni uwezo gani inatoa, na ni kwa kiwango gani inaweza kutumika kama mbadala wa ELK, rundo tunalotumia sasa.

Loki ni nini

Grafana Loki ni seti ya vipengele vya mfumo kamili wa kufanya kazi na magogo. Tofauti na mifumo mingine kama hiyo, Loki inategemea wazo la kuorodhesha metadata ya logi tu - lebo (sawa na katika Prometheus), na kukandamiza magogo yenyewe kuwa vipande tofauti.

Ukurasa wa nyumbani, GitHub

Kabla hatujaingia katika kile unachoweza kufanya na Loki, ninataka kufafanua nini maana ya "wazo la kuorodhesha metadata pekee." Wacha tulinganishe mbinu ya Loki na mbinu ya kuorodhesha katika suluhu za kitamaduni kama vile Elasticsearch, kwa kutumia mfano wa mstari kutoka kwa logi ya 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"

Mifumo ya kitamaduni huchanganua safu mlalo yote, ikijumuisha sehemu zenye idadi kubwa ya thamani za kipekee za kitambulisho cha mtumiaji_id na kipengee, na kuhifadhi kila kitu katika faharasa kubwa. Faida ya mbinu hii ni kwamba unaweza kuendesha maswali magumu haraka, kwani karibu data zote ziko kwenye faharisi. Lakini hii inakuja kwa gharama kwa kuwa index inakuwa kubwa, ambayo hutafsiriwa katika mahitaji ya kumbukumbu. Kwa hivyo, faharasa ya kumbukumbu ya maandishi kamili inalinganishwa kwa ukubwa na kumbukumbu zenyewe. Ili kutafuta haraka kwa njia hiyo, faharisi lazima iwekwe kwenye kumbukumbu. Na magogo zaidi, kwa kasi index inakua na kumbukumbu zaidi hutumia.

Mbinu ya Loki inahitaji kwamba data muhimu tu itolewe kutoka kwa kamba, idadi ya maadili ambayo ni ndogo. Kwa njia hii tunapata faharasa ndogo na tunaweza kutafuta data kwa kuichuja kwa wakati na kwa sehemu zilizowekwa faharasa, na kisha kuchanganua zilizosalia kwa misemo ya kawaida au utafutaji wa kamba ndogo. Mchakato hauonekani kuwa wa haraka zaidi, lakini Loki hugawanya ombi hilo katika sehemu kadhaa na kuzitekeleza kwa sambamba, kuchakata kiasi kikubwa cha data kwa muda mfupi. Idadi ya shards na maombi sambamba ndani yao yanaweza kusanidiwa; kwa hivyo, kiasi cha data ambacho kinaweza kuchakatwa kwa kila kitengo cha muda kinategemea kimstari kiasi cha rasilimali zinazotolewa.

Ubadilishanaji huu kati ya faharasa kubwa, ya haraka na faharasa ndogo, sambamba ya brute-force inaruhusu Loki kudhibiti gharama ya mfumo. Inaweza kusanidiwa kwa urahisi na kupanuliwa kulingana na mahitaji.

Rafu ya Loki ina vipengele vitatu: Promtail, Loki, Grafana. Promtail hukusanya kumbukumbu, kuzichakata na kuzituma kwa Loki. Loki anawaweka. Na Grafana anaweza kuomba data kutoka kwa Loki na kuionyesha. Kwa ujumla, Loki inaweza kutumika sio tu kwa kuhifadhi magogo na kutafuta kupitia kwao. Mkusanyiko mzima hutoa fursa nzuri za kuchakata na kuchambua data inayoingia kwa kutumia njia ya Prometheus.
Maelezo ya mchakato wa ufungaji yanaweza kupatikana hapa.

Utafutaji wa logi

Unaweza kutafuta magogo katika interface maalum ya Grafana - Explorer. Hoja hutumia lugha ya LogQL, ambayo inafanana sana na PromQL inayotumiwa katika Prometheus. Kimsingi, inaweza kuzingatiwa kama grep iliyosambazwa.

Kiolesura cha utafutaji kinaonekana kama hii:

Ombi lenyewe lina sehemu mbili: kiteuzi na kichujio. Kiteuzi ni utafutaji unaotumia metadata iliyoorodheshwa (lebo) ambazo zimegawiwa kumbukumbu, na kichujio ni mfuatano wa utafutaji au regexp unaochuja rekodi zilizobainishwa na kiteuzi. Katika mfano uliotolewa: Katika braces curly kuna selector, kila kitu baada ya ni filter.

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

Kwa sababu ya jinsi Loki anavyofanya kazi, huwezi kuuliza maswali bila kiteuzi, lakini lebo zinaweza kutengenezwa kwa ujumla upendavyo.

Kiteuzi ni thamani ya ufunguo katika viunga vilivyopinda. Unaweza kuchanganya viteuzi na kubainisha hali tofauti za utafutaji kwa kutumia viendeshaji =, != au misemo ya kawaida:

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

Kichujio ni maandishi au regexp ambayo itachuja data yote iliyopokelewa na kiteuzi.

Inawezekana kupata grafu za ad-hoc kulingana na data iliyopokelewa katika hali ya vipimo. Kwa mfano, unaweza kujua ni mara ngapi ingizo lililo na faharisi ya kamba linaonekana kwenye magogo ya nginx:

Maelezo kamili ya uwezo yanaweza kupatikana katika nyaraka LogQL.

Uchanganuzi wa kumbukumbu

Kuna njia kadhaa za kukusanya magogo:

• Kwa kutumia Promtail, sehemu ya kawaida ya rafu ya kukusanya kumbukumbu.
• Moja kwa moja kutoka kwa chombo cha docker kutumia Dereva wa Kuweka Magogo wa Loki Docker.
• Tumia Fasaha au Fasaha Bit, ambayo inaweza kutuma data kwa Loki. Tofauti na Promtail, wana vichanganuzi vilivyotengenezwa tayari kwa karibu aina yoyote ya logi na pia vinaweza kushughulikia magogo ya mistari mingi.

Kawaida Promtail hutumiwa kuchanganua. Inafanya mambo matatu:

• Hupata vyanzo vya data.
• Huambatanisha lebo kwao.
• Inatuma data kwa Loki.

Kwa sasa Promtail inaweza kusoma kumbukumbu kutoka kwa faili za ndani na kutoka kwa jarida la systemd. Lazima iwe imewekwa kwenye kila mashine ambayo magogo hukusanywa.

Kuna muunganisho na Kubernetes: Promtail kiotomatiki, kupitia Kubernetes REST API, inatambua hali ya nguzo na kukusanya kumbukumbu kutoka kwa nodi, huduma au ganda, mara moja inachapisha lebo kulingana na metadata kutoka Kubernetes (jina la ganda, jina la faili, n.k.) .

Unaweza pia kupachika lebo kulingana na data kutoka kwa logi kwa kutumia Pipeline. Pipeline Promtail inaweza kujumuisha aina nne za hatua. Maelezo zaidi ndani nyaraka rasmi, mara moja nitazingatia nuances kadhaa.

1. Hatua za uchanganuzi. Hii ni hatua ya RegEx na JSON. Katika hatua hii, tunatoa data kutoka kwa kumbukumbu hadi kwenye kinachojulikana ramani iliyotolewa. Tunaweza kutoa kutoka kwa JSON kwa kunakili tu sehemu tunazohitaji kwenye ramani iliyotolewa, au kupitia misemo ya kawaida (RegEx), ambapo vikundi vilivyotajwa "hupangwa" kwenye ramani iliyotolewa. Ramani Iliyotolewa ni duka la thamani ya ufunguo, ambapo ufunguo ni jina la sehemu, na thamani ni thamani yake kutoka kwa kumbukumbu.
2. Kubadilisha hatua. Hatua hii ina chaguzi mbili: kubadilisha, ambapo tunaweka sheria za mabadiliko, na chanzo - chanzo cha data cha mabadiliko kutoka kwa ramani iliyotolewa. Ikiwa hakuna sehemu kama hiyo kwenye ramani iliyotolewa, itaundwa. Kwa njia hii inawezekana kuunda lebo ambazo sio msingi wa ramani iliyotolewa. Katika hatua hii tunaweza kudanganya data katika ramani iliyotolewa kwa kutumia nguvu kiasi Kigezo cha Golang. Kwa kuongeza, ni lazima tukumbuke kwamba ramani iliyotolewa hupakiwa kabisa wakati wa uchanganuzi, ambayo inafanya iwezekanavyo, kwa mfano, kuangalia thamani ndani yake: "{{if .tag}thamani ya lebo ipo{end}}". Kiolezo huauni hali, vitanzi, na baadhi ya vitendaji vya kamba kama vile Badilisha na Kata.
3. Hatua za hatua. Katika hatua hii unaweza kufanya kitu na maudhui yaliyotolewa:
   • Unda lebo kutoka kwa data iliyotolewa, ambayo itaorodheshwa na Loki.
   • Badilisha au weka wakati wa tukio kutoka kwa kumbukumbu.
   • Badilisha data (maandishi ya logi) ambayo itaenda kwa Loki.
   • Unda vipimo.
4. Hatua za kuchuja. Hatua ya mechi, ambapo tunaweza kutuma maingizo ambayo hatuhitaji /dev/null au kuyasambaza kwa uchakataji zaidi.

Kwa kutumia mfano wa kuchakata magogo ya kawaida ya nginx, nitaonyesha jinsi unavyoweza kuchanganua magogo kwa kutumia Promtail.

Kwa jaribio, hebu tuchukue kama nginx-proksi picha ya nginx iliyorekebishwa jwilder/nginx-proxy:alpine na daemon ndogo ambayo inaweza kujiuliza kupitia HTTP. Daemon ina miisho kadhaa, ambayo inaweza kutoa majibu ya ukubwa tofauti, na hali tofauti za HTTP na ucheleweshaji tofauti.

Tutakusanya kumbukumbu kutoka kwa vyombo vya docker, ambavyo vinaweza kupatikana kwenye njia /var/lib/docker/containers//-json.log

Katika docker-compose.yml tunasanidi Promtail na kubainisha njia ya usanidi:

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

Ongeza njia ya kumbukumbu kwa promtail.yml (kuna chaguo la "docker" kwenye usanidi, ambayo hufanya jambo lile lile kwenye mstari mmoja, lakini haitakuwa wazi sana):

scrape_configs:
 - job_name: containers

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

Wakati usanidi huu umewashwa, kumbukumbu kutoka kwa vyombo vyote zitatumwa kwa Loki. Ili kuepusha hili, tunabadilisha mipangilio ya nginx ya jaribio kwenye docker-compose.yml - ongeza uwanja wa lebo ya ukataji miti:

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

Kuhariri promtail.yml na kusanidi Pipeline. Ingizo ni pamoja na kumbukumbu za aina zifuatazo:

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

Hatua ya bomba:

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

Tunatoa mtiririko wa uga, attrs, attrs.tag (kama zipo) kutoka kwa JSON inayoingia na kuziweka kwenye ramani iliyotolewa.

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

Ikiwa tuliweza kuweka uga wa lebo kwenye ramani iliyotolewa, kisha kwa kutumia regexp tunatoa majina ya picha na kontena.

 - labels:
     image_name:
     container_name:

Tunaweka lebo. Ikiwa picha_jina na vitufe vya_jina la chombo vinapatikana katika data iliyotolewa, basi thamani zao zitatumwa kwa lebo zinazolingana.

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

Tunatupa kumbukumbu zote ambazo hazina lebo zilizosakinishwa image_name na container_name.

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

Kwa kumbukumbu zote ambazo image_name yake ni nginx.promtail.test, toa sehemu ya kumbukumbu kutoka kwa kumbukumbu ya chanzo na kuiweka kwenye ramani iliyotolewa kwa ufunguo wa safu mlalo.

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

Tunafuta laini ya ingizo na misemo ya kawaida na kuvuta mwenyeji wa nginx na laini ya kumbukumbu ya 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.]+)")?

Changanua logi ya nginx kwa kutumia misemo ya kawaida.

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

Hebu tuchanganue request_url. Kwa kutumia regexp tunabainisha madhumuni ya ombi: kwa data tuli, kwa picha, kwa API na kuweka ufunguo sambamba katika ramani iliyotolewa.

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

Kwa kutumia waendeshaji masharti katika Kiolezo, tunaangalia sehemu zilizosakinishwa kwenye ramani iliyotolewa na kuweka thamani zinazohitajika kwa uga wa request_type: picha, tuli, API. Wape wengine ikiwa itashindwa. request_type sasa ina aina ya ombi.

       - labels:
           api_request:
           virtual_host:
           request_type:
           status:

Tunaweka lebo api_request, virtual_host, request_type na status (hali ya HTTP) kulingana na tulichoweza kuweka kwenye ramani iliyotolewa.

       - output:
           source: nginx_log_row

Badilisha pato. Sasa logi iliyosafishwa ya nginx kutoka kwa ramani iliyotolewa huenda kwa Loki.

Baada ya kuendesha usanidi hapo juu, unaweza kuona kwamba kila ingizo limepewa lebo kulingana na data kutoka kwa logi.

Jambo moja la kukumbuka ni kwamba kupata lebo zilizo na idadi kubwa ya maadili (ukardinali) kunaweza kupunguza kasi ya Loki. Hiyo ni, hupaswi kuweka, kwa mfano, user_id katika index. Soma zaidi kuhusu hili katika makala "Jinsi lebo katika Loki zinavyoweza kufanya hoja za kumbukumbu haraka na rahisi" Lakini hii haimaanishi kuwa huwezi kutafuta kwa user_id bila faharisi. Unahitaji kutumia vichujio unapotafuta ("nyakua" data), na faharasa hapa hufanya kama kitambulisho cha mtiririko.

Taswira ya kumbukumbu

Loki inaweza kufanya kazi kama chanzo cha data kwa grafu za Grafana kwa kutumia LogQL. Vipengele vifuatavyo vinaungwa mkono:

• kiwango - idadi ya rekodi kwa pili;
• hesabu kwa muda - idadi ya rekodi katika safu maalum.

Pia kuna kazi za kujumlisha Sum, Avg na zingine. Unaweza kuunda grafu ngumu kabisa, kwa mfano grafu ya idadi ya makosa ya HTTP:

Chanzo cha data cha kawaida Loki kimepunguzwa kwa utendakazi ikilinganishwa na chanzo cha data cha Prometheus (kwa mfano, huwezi kubadilisha hekaya), lakini Loki inaweza kuunganishwa kama chanzo kwa aina ya Prometheus. Sina hakika kama hii ni tabia iliyoandikwa, lakini kwa kuzingatia majibu ya watengenezaji "Jinsi ya kusanidi Loki kama chanzo cha data cha Prometheus? · Toleo #1222 · grafana/loki”, kwa mfano, ni halali kabisa, na Loki inaoana kikamilifu na PromQL.

Ongeza Loki kama chanzo cha data na aina ya Prometheus na ongeza URL /loki:

Na tunaweza kutengeneza grafu, kana kwamba tunafanya kazi na metriki kutoka Prometheus:

Nadhani hitilafu katika utendakazi ni ya muda na wasanidi watarekebisha hili katika siku zijazo.

Vipimo

Loki hutoa uwezo wa kutoa vipimo vya nambari kutoka kwa kumbukumbu na kuzituma kwa Prometheus. Kwa mfano, logi ya nginx ina idadi ya baiti kwa kila jibu, na vile vile, na urekebishaji fulani wa umbizo la logi la kawaida, muda katika sekunde ambazo ilichukua kujibu. Data hii inaweza kutolewa na kutumwa kwa Prometheus.

Ongeza sehemu nyingine kwa 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

Chaguo hukuruhusu kufafanua na kusasisha vipimo kulingana na data kutoka kwa ramani iliyotolewa. Vipimo hivi havitumwi kwa Loki - vinaonekana kwenye sehemu ya mwisho ya Promtail/metrics. Prometheus lazima isanidiwe ili kupokea data iliyopokelewa katika hatua hii. Katika mfano ulio hapo juu, kwa request_type=“api” tunakusanya kipimo cha histogram. Kwa aina hii ya vipimo ni rahisi kupata percentiles. Kwa tuli na picha, tunakusanya jumla ya baiti na idadi ya safu mlalo ambamo tulipokea baiti ili kukokotoa wastani.

Soma zaidi kuhusu vipimo hapa.

Fungua bandari kwenye Promtail:

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

Hakikisha kuwa vipimo vilivyo na kiambishi awali cha promtail_custom vinaonekana:

Kuanzisha Prometheus. Ongeza matangazo ya kazi:

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

Na tunachora grafu:

Kwa njia hii unaweza kujua, kwa mfano, maswali manne ya polepole zaidi. Unaweza pia kuweka ufuatiliaji wa vipimo hivi.

Kuongeza

Loki inaweza kuwa katika hali ya jozi moja au katika hali ya kugawanyika (hali inayoweza kupanuka kwa mlalo). Katika kesi ya pili, inaweza kuhifadhi data kwenye wingu, na chunks na index huhifadhiwa tofauti. Toleo la 1.5 linatanguliza uwezo wa kuhifadhi mahali pamoja, lakini bado halijapendekezwa kuitumia katika uzalishaji.

Chunk zinaweza kuhifadhiwa katika hifadhi inayooana na S3, na hifadhidata zinazoweza kuongezwa kimlalo zinaweza kutumika kuhifadhi faharasa: Cassandra, BigTable au DynamoDB. Sehemu zingine za Loki - Wasambazaji (kwa maandishi) na Querier (kwa maswali) - hazina uraia na pia hupimwa kwa mlalo.

Katika mkutano wa DevOpsDays Vancouver 2019, mmoja wa washiriki Callum Styan alitangaza kuwa pamoja na Loki mradi wake una petabytes za magogo na faharisi ya chini ya 1% ya saizi ya jumla: "Jinsi Loki Huunganisha Vipimo na Kumbukumbu - Na Hukuokoa Pesa".

Ulinganisho wa Loki na ELK

Ukubwa wa index

Ili kujaribu saizi ya faharisi iliyosababishwa, nilichukua magogo kutoka kwa kontena ya nginx ambayo Bomba hapo juu lilisanidiwa. Faili ya kumbukumbu ilikuwa na mistari 406 yenye ujazo wa jumla wa 624 MB. Kumbukumbu zilitolewa ndani ya saa moja, takriban maingizo 109 kwa sekunde.

Mfano wa mistari miwili kutoka kwa logi:

Ilipoorodheshwa na ELK, hii ilitoa saizi ya faharisi ya 30,3 MB:

Kwa upande wa Loki, hii ilisababisha takriban 128 KB ya faharasa na takriban 3,8 MB ya data katika vipande. Ni vyema kutambua kwamba logi ilitolewa kwa njia ya bandia na haikuwa na aina kubwa ya data. Gzip rahisi kwenye logi ya asili ya Docker JSON iliyo na data ilitoa mgandamizo wa 95,4%, na kwa kuzingatia ukweli kwamba ni logi iliyosafishwa tu ya nginx iliyotumwa kwa Loki yenyewe, mbano wa hadi 4 MB inaeleweka. Jumla ya nambari za kipekee za lebo za Loki zilikuwa 35, ambayo inaelezea saizi ndogo ya faharisi. Kwa ELK logi pia ilifutwa. Kwa hivyo, Loki alibana data asilia kwa 96%, na ELK kwa 70%.

Matumizi ya kumbukumbu

Ikiwa tunalinganisha safu nzima ya Prometheus na ELK, basi Loki "hula" mara kadhaa chini. Ni wazi kuwa huduma ya Go hutumia chini ya huduma ya Java, na kulinganisha saizi ya JVM Heap Elasticsearch na kumbukumbu iliyotengwa kwa ajili ya Loki si sahihi, lakini hata hivyo ni vyema kutambua kwamba Loki hutumia kumbukumbu kidogo zaidi. Faida yake ya CPU sio dhahiri sana, lakini pia iko.

Kasi

Loki "humeza" magogo kwa haraka zaidi. Kasi inategemea mambo mengi - ni aina gani ya magogo, jinsi tulivyo kisasa katika kuzichanganua, mtandao, diski, nk - lakini ni dhahiri zaidi kuliko ELK (katika mtihani wangu - karibu mara mbili zaidi). Hii inafafanuliwa na ukweli kwamba Loki huweka data kidogo sana kwenye faharisi na, ipasavyo, hutumia muda kidogo kuorodhesha. Kwa kasi ya utafutaji, hali ni kinyume: Loki hupunguza kasi ya data kubwa kuliko gigabytes kadhaa, wakati kasi ya utafutaji ya ELK haitegemei ukubwa wa data.

Utafutaji wa logi

Loki ni duni sana kwa ELK kwa suala la uwezo wa utafutaji wa kumbukumbu. Grep yenye misemo ya kawaida ina nguvu, lakini ni duni kwa hifadhidata iliyokomaa. Ukosefu wa maswali mbalimbali, ujumlisho wa lebo pekee, kutokuwa na uwezo wa kutafuta bila lebo - yote haya yanatuwekea kikomo katika kutafuta taarifa za maslahi katika Loki. Hii haimaanishi kuwa hakuna kitu kinachoweza kupatikana kwa kutumia Loki, lakini inafafanua mtiririko wa kufanya kazi na kumbukumbu wakati unapopata tatizo la kwanza kwenye chati za Prometheus, na kisha utumie lebo hizi kutafuta kile kilichotokea kwenye kumbukumbu.

interface

Kwanza kabisa, ni nzuri (samahani, haikuweza kupinga). Grafana ina kiolesura cha kupendeza, lakini Kibana ana kipengele tajiri zaidi.

Faida na hasara za Loki

Mojawapo ya faida ni kwamba Loki inaunganishwa na Prometheus, kwa hivyo tunapata vipimo na kuarifu nje ya kisanduku. Ni rahisi kwa kukusanya kumbukumbu na kuzihifadhi kutoka kwa Kubernetes Pods, kwa kuwa ina ugunduzi wa huduma iliyorithiwa kutoka kwa Prometheus na inaambatisha lebo kiotomatiki.

Upande mbaya ni hati dhaifu. Vitu vingine, kwa mfano, sifa na uwezo wa Promtail, niligundua tu katika mchakato wa kusoma nambari, kwa bahati nzuri ni chanzo wazi. Ubaya mwingine ni uwezo dhaifu wa kuchanganua. Kwa mfano, Loki hawezi kuchanganua kumbukumbu za laini nyingi. Ubaya mwingine ni kwamba Loki ni teknolojia changa (toleo la 1.0 lilikuwa mnamo Novemba 2019).

Hitimisho

Loki ni teknolojia ya kuvutia 100% ambayo inafaa kwa miradi midogo na ya kati, hukuruhusu kutatua shida nyingi za ujumuishaji wa logi, utaftaji wa kumbukumbu, ufuatiliaji na uchambuzi wa kumbukumbu.

Hatutumii Loki katika Badoo kwa sababu tuna mrundikano wa ELK unaotufaa na ambao umekuwa na masuluhisho mbalimbali maalum kwa miaka mingi. Kwetu sisi, kikwazo ni kutafuta kupitia magogo. Kwa karibu GB 100 za kumbukumbu kwa siku, ni muhimu kwetu kuweza kupata kila kitu na kidogo zaidi na kuifanya haraka. Kwa kuweka chati na ufuatiliaji, tunatumia masuluhisho mengine ambayo yameundwa kulingana na mahitaji yetu na kuunganishwa na kila mmoja. Rafu ya Loki ina manufaa yanayoonekana, lakini haitatupa zaidi ya tuliyo nayo, na manufaa yake hakika hayatapita gharama ya uhamiaji.

Na ingawa baada ya utafiti ikawa wazi kuwa hatuwezi kutumia Loki, tunatumai kuwa chapisho hili litakusaidia katika chaguo lako.

Hifadhi iliyo na msimbo uliotumiwa katika kifungu iko hapa.

Chanzo: mapenzi.com