ការប្រមូលកំណត់ហេតុពី Loki

យើងនៅ Badoo កំពុងតាមដានជានិច្ចនូវបច្ចេកវិទ្យាថ្មីៗ និងវាយតម្លៃថាតើត្រូវប្រើវានៅក្នុងប្រព័ន្ធរបស់យើងឬអត់។ យើងចង់ចែករំលែកការសិក្សាមួយក្នុងចំណោមការសិក្សាទាំងនេះជាមួយសហគមន៍។ វាត្រូវបានឧទ្ទិសដល់ Loki ដែលជាប្រព័ន្ធប្រមូលផ្តុំកំណត់ហេតុ។

Loki គឺជាដំណោះស្រាយសម្រាប់ការរក្សាទុក និងមើលកំណត់ហេតុ ហើយជង់នេះក៏ផ្តល់នូវប្រព័ន្ធដែលអាចបត់បែនបានសម្រាប់ការវិភាគ និងបញ្ជូនទិន្នន័យទៅកាន់ Prometheus ផងដែរ។ នៅក្នុងខែឧសភា ការអាប់ដេតមួយផ្សេងទៀតត្រូវបានចេញផ្សាយ ដែលត្រូវបានផ្សព្វផ្សាយយ៉ាងសកម្មដោយអ្នកបង្កើត។ យើងចាប់អារម្មណ៍លើអ្វីដែល Loki អាចធ្វើបាន លក្ខណៈពិសេសអ្វីដែលវាផ្តល់ និងកម្រិតណាដែលវាអាចដើរតួជាជម្រើសជំនួស ELK ដែលជាជង់ដែលយើងប្រើឥឡូវនេះ។

តើឡូគីគឺជាអ្វី

Grafana Loki គឺជាសំណុំនៃសមាសធាតុសម្រាប់ប្រព័ន្ធកត់ត្រាពេញលេញ។ មិនដូចប្រព័ន្ធស្រដៀងគ្នាផ្សេងទៀតទេ Loki គឺផ្អែកលើគំនិតនៃការធ្វើលិបិក្រមតែទិន្នន័យមេតានៃកំណត់ហេតុ - ស្លាក (ដូចនៅក្នុង Prometheus) ហើយបង្រួមកំណត់ហេតុដោយខ្លួនឯងដោយផ្នែកម្ខាងៗទៅជាកំណាត់ដាច់ដោយឡែក។

ទំព័រដើម, GitHub

មុនពេលខ្ញុំចូលទៅក្នុងអ្វីដែលអ្នកអាចធ្វើបានជាមួយ Loki ខ្ញុំចង់បញ្ជាក់ពីអ្វីដែលមានន័យដោយ "គំនិតនៃការធ្វើលិបិក្រមតែទិន្នន័យមេតា" ។ ចូរយើងប្រៀបធៀបវិធីសាស្រ្ត Loki និងវិធីសាស្រ្តធ្វើលិបិក្រមនៅក្នុងដំណោះស្រាយបែបប្រពៃណី ដូចជា Elasticsearch ដោយប្រើឧទាហរណ៍នៃបន្ទាត់ពីកំណត់ហេតុ 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"

ប្រព័ន្ធប្រពៃណីញែកជួរទាំងមូល រួមទាំងវាលដែលមានតម្លៃ user_id និង item_id ប្លែកៗជាច្រើន ហើយរក្សាទុកអ្វីគ្រប់យ៉ាងជាលិបិក្រមធំៗ។ អត្ថប្រយោជន៍នៃវិធីសាស្រ្តនេះគឺថាអ្នកអាចដំណើរការសំណួរស្មុគ្រស្មាញបានយ៉ាងឆាប់រហ័ស ដោយសារទិន្នន័យស្ទើរតែទាំងអស់ស្ថិតនៅក្នុងលិបិក្រម។ ប៉ុន្តែអ្នកត្រូវចំណាយសម្រាប់ការនេះនៅក្នុងនោះលិបិក្រមក្លាយជាធំដែលបកប្រែទៅជាតម្រូវការអង្គចងចាំ។ ជាលទ្ធផល លិបិក្រមអត្ថបទពេញនៃកំណត់ហេតុគឺអាចប្រៀបធៀបបានក្នុងទំហំទៅនឹងកំណត់ហេតុខ្លួនឯង។ ដើម្បីស្វែងរកយ៉ាងឆាប់រហ័ស លិបិក្រមត្រូវតែផ្ទុកទៅក្នុងអង្គចងចាំ។ ហើយការកត់ត្រាកាន់តែច្រើន សន្ទស្សន៍កើនឡើងកាន់តែលឿន និងការប្រើប្រាស់អង្គចងចាំកាន់តែច្រើន។

វិធីសាស្រ្ត Loki តម្រូវឱ្យមានតែទិន្នន័យចាំបាច់ប៉ុណ្ណោះដែលត្រូវបានស្រង់ចេញពីខ្សែអក្សរដែលជាចំនួននៃតម្លៃដែលតូច។ វិធីនេះយើងទទួលបានលិបិក្រមតូចមួយ ហើយអាចស្វែងរកទិន្នន័យដោយត្រងវាតាមពេលវេលា និងវាលដែលបានធ្វើលិបិក្រម ហើយបន្ទាប់មកស្កេនអ្វីដែលនៅសល់ដោយប្រើកន្សោមធម្មតា ឬការស្វែងរកខ្សែអក្សររង។ ដំណើរការនេះហាក់ដូចជាមិនលឿនបំផុតនោះទេ ប៉ុន្តែ Loki បំបែកសំណើទៅជាផ្នែកជាច្រើន ហើយប្រតិបត្តិពួកវាស្របគ្នា ដោយដំណើរការទិន្នន័យមួយចំនួនធំក្នុងរយៈពេលដ៏ខ្លី។ ចំនួននៃ shards និងសំណើប៉ារ៉ាឡែលនៅក្នុងពួកវាគឺអាចកំណត់រចនាសម្ព័ន្ធបាន; ដូច្នេះចំនួនទិន្នន័យដែលអាចដំណើរការក្នុងមួយឯកតានៃពេលវេលាគឺអាស្រ័យទៅលើបរិមាណនៃធនធានដែលបានផ្តល់។

ការដោះដូររវាងសន្ទស្សន៍ធំ លឿន និងសន្ទស្សន៍កម្លាំង brute-force ស្របគ្នាតូចមួយអនុញ្ញាតឱ្យ Loki គ្រប់គ្រងថ្លៃដើមនៃប្រព័ន្ធ។ វាអាចត្រូវបានកំណត់រចនាសម្ព័ន្ធបត់បែន និងពង្រីកតាមតម្រូវការ។

ជង់ Loki មានសមាសធាតុបីគឺ Promtail, Loki, Grafana ។ Promtail ប្រមូលកំណត់ហេតុ ដំណើរការពួកវា ហើយបញ្ជូនវាទៅ Loki ។ Loki រក្សាពួកគេ។ ហើយ Grafana អាចស្នើសុំទិន្នន័យពី Loki ហើយបង្ហាញវា។ ជាទូទៅ Loki អាចត្រូវបានប្រើមិនត្រឹមតែសម្រាប់ការរក្សាទុកកំណត់ហេតុ និងការស្វែងរកតាមរយៈពួកវាប៉ុណ្ណោះទេ។ ជង់ទាំងមូលផ្តល់នូវឱកាសដ៏អស្ចារ្យសម្រាប់ដំណើរការ និងវិភាគទិន្នន័យចូលដោយប្រើវិធី Prometheus ។
ការពិពណ៌នាអំពីដំណើរការដំឡើងអាចរកបាន នៅទីនេះ.

ការស្វែងរកកំណត់ហេតុ

អ្នកអាចស្វែងរកកំណត់ហេតុនៅក្នុងចំណុចប្រទាក់ពិសេស Grafana — Explorer ។ សំណួរប្រើភាសា LogQL ដែលស្រដៀងនឹង PromQL ដែលប្រើដោយ Prometheus ។ ជាគោលការណ៍ វាអាចត្រូវបានគិតថាជា grep ចែកចាយ។

ចំណុចប្រទាក់ស្វែងរកមើលទៅដូចនេះ៖

សំណួរខ្លួនវាមានពីរផ្នែក៖ ឧបករណ៍ជ្រើសរើស និងតម្រង។ ឧបករណ៍ជ្រើសរើសគឺជាការស្វែងរកដោយទិន្នន័យមេតាដែលបានធ្វើលិបិក្រម (ស្លាក) ដែលត្រូវបានកំណត់ទៅកំណត់ហេតុ ហើយតម្រងគឺជាខ្សែអក្សរស្វែងរក ឬ regexp ដែលត្រងចេញនូវកំណត់ត្រាដែលកំណត់ដោយអ្នកជ្រើសរើស។ នៅក្នុងឧទាហរណ៍ខាងលើ: នៅក្នុងតង្កៀបអង្កាញ់ - ឧបករណ៍ជ្រើសរើសអ្វីគ្រប់យ៉ាងបន្ទាប់ពី - តម្រង។

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

ដោយសារតែវិធីដែល Loki ដំណើរការ អ្នកមិនអាចបង្កើតសំណួរដោយគ្មានឧបករណ៍ជ្រើសរើសទេ ប៉ុន្តែស្លាកអាចត្រូវបានបង្កើតជាទូទៅតាមដែលអ្នកចូលចិត្ត។

ឧបករណ៍ជ្រើសរើសគឺជាតម្លៃគន្លឹះនៃតម្លៃនៅក្នុងដង្កៀបអង្កាញ់។ អ្នកអាចបញ្ចូលគ្នានូវឧបករណ៍ជ្រើសរើស និងបញ្ជាក់លក្ខខណ្ឌស្វែងរកផ្សេងៗគ្នាដោយប្រើសញ្ញាប្រមាណវិធី =, != ឬកន្សោមធម្មតា៖

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

តម្រងគឺជាអត្ថបទ ឬ regexp ដែលនឹងត្រងទិន្នន័យទាំងអស់ដែលទទួលបានដោយអ្នកជ្រើសរើស។

វាអាចទៅរួចដើម្បីទទួលបានក្រាហ្វអាដហុកដោយផ្អែកលើទិន្នន័យដែលទទួលបានក្នុងទម្រង់ម៉ែត្រ។ ឧទាហរណ៍ អ្នកអាចស្វែងយល់ពីភាពញឹកញាប់នៃការកើតឡើងនៅក្នុងកំណត់ហេតុ nginx នៃធាតុដែលមានខ្សែអក្សរសន្ទស្សន៍៖

ការពិពណ៌នាពេញលេញនៃលក្ខណៈពិសេសអាចរកបាននៅក្នុងឯកសារ LogQL.

ការវិភាគកំណត់ហេតុ

មានវិធីជាច្រើនដើម្បីប្រមូលកំណត់ហេតុ៖

• ដោយមានជំនួយពី Promtail ដែលជាសមាសធាតុស្តង់ដារនៃជង់សម្រាប់ប្រមូលកំណត់ហេតុ។
• ដោយផ្ទាល់ពីធុង docker ដោយប្រើ កម្មវិធីបញ្ជាកំណត់ហេតុ Loki Docker ។
• ប្រើ Fluentd ឬ Fluent Bit ដែលអាចបញ្ជូនទិន្នន័យទៅ Loki ។ មិនដូច Promtail ពួកគេមានឧបករណ៍ញែកដែលត្រៀមរួចជាស្រេចសម្រាប់កំណត់ហេតុស្ទើរតែគ្រប់ប្រភេទ ហើយក៏អាចគ្រប់គ្រងកំណត់ហេតុច្រើនជួរផងដែរ។

ជាធម្មតា Promtail ត្រូវបានប្រើសម្រាប់ការញែក។ វាធ្វើបីយ៉ាង៖

• ស្វែងរកប្រភពទិន្នន័យ។
• ភ្ជាប់ស្លាកទៅពួកគេ។
• បញ្ជូនទិន្នន័យទៅ Loki ។

បច្ចុប្បន្ន Promtail អាចអានកំណត់ហេតុពីឯកសារមូលដ្ឋាន និងពីទិនានុប្បវត្តិ systemd ។ វាត្រូវតែត្រូវបានដំឡើងនៅលើម៉ាស៊ីននីមួយៗដែលកំណត់ហេតុត្រូវបានប្រមូល។

មានការរួមបញ្ចូលជាមួយ Kubernetes៖ Promtail រកឃើញស្ថានភាពនៃចង្កោមដោយស្វ័យប្រវត្តិតាមរយៈ Kubernetes REST API ហើយប្រមូលកំណត់ហេតុពីថ្នាំង សេវាកម្ម ឬផត ដោយដាក់ស្លាកភ្លាមៗដោយផ្អែកលើទិន្នន័យមេតាពី Kubernetes (ឈ្មោះផត ឈ្មោះឯកសារ។ល។)។

អ្នកក៏អាចព្យួរស្លាកដោយផ្អែកលើទិន្នន័យពីកំណត់ហេតុដោយប្រើ Pipeline ។ Pipeline Promtail អាចមានបួនប្រភេទនៃដំណាក់កាល។ ព័ត៌មានលម្អិតបន្ថែម - in ឯកសារផ្លូវការខ្ញុំនឹងកត់សម្គាល់ភ្លាមៗនូវការ nuances មួយចំនួន។

1. ដំណាក់កាលវិភាគ. នេះគឺជាដំណាក់កាល RegEx និង JSON ។ នៅដំណាក់កាលនេះ យើងស្រង់ទិន្នន័យចេញពីកំណត់ហេតុចូលទៅក្នុងអ្វីដែលគេហៅថា ផែនទីស្រង់ចេញ។ យើងអាចស្រង់ចេញពី JSON ដោយគ្រាន់តែចម្លងវាលដែលយើងត្រូវការទៅក្នុងផែនទីដែលបានស្រង់ចេញ ឬតាមរយៈកន្សោមធម្មតា (RegEx) ដែលក្រុមដែលមានឈ្មោះត្រូវបាន "គូសវាស" ទៅក្នុងផែនទីដែលបានស្រង់ចេញ។ ផែនទីដែលបានស្រង់ចេញគឺជាឃ្លាំងតម្លៃដែលគ្រាប់ចុចគឺជាឈ្មោះរបស់វាល ហើយតម្លៃគឺជាតម្លៃរបស់វាពីកំណត់ហេតុ។
2. ដំណាក់កាលផ្លាស់ប្តូរ. ដំណាក់​កាល​នេះ​មាន​ជម្រើស​ពីរ៖ ប្លែង ដែល​យើង​កំណត់​ច្បាប់​បំប្លែង និង​ប្រភព - ប្រភព​ទិន្នន័យ​សម្រាប់​ការ​បំប្លែង​ពី​ផែនទី​ស្រង់​ចេញ។ ប្រសិនបើមិនមានវាលបែបនេះនៅក្នុងផែនទីដែលបានស្រង់ចេញទេនោះវានឹងត្រូវបានបង្កើត។ ដូច្នេះវាអាចធ្វើទៅបានដើម្បីបង្កើតស្លាកដែលមិនផ្អែកលើផែនទីដែលបានស្រង់ចេញ។ នៅដំណាក់កាលនេះ យើងអាចរៀបចំទិន្នន័យនៅក្នុងផែនទីដែលបានស្រង់ចេញដោយប្រើថាមពលខ្លាំង គំរូ golang. លើសពីនេះ យើងត្រូវតែចងចាំថា ផែនទីដែលបានស្រង់ចេញត្រូវបានផ្ទុកពេញកំឡុងពេលញែក ដែលធ្វើឱ្យវាអាចធ្វើទៅបាន ឧទាហរណ៍ ដើម្បីពិនិត្យមើលតម្លៃនៅក្នុងវា៖ “{{if .tag}តម្លៃស្លាកមាន{end}}”។ ពុម្ពគាំទ្រលក្ខខណ្ឌ រង្វិលជុំ និងមុខងារខ្សែអក្សរមួយចំនួនដូចជា ជំនួស និងកាត់។
3. ដំណាក់កាលនៃសកម្មភាព. នៅដំណាក់កាលនេះ អ្នកអាចធ្វើអ្វីមួយជាមួយការដកស្រង់៖
   • បង្កើតស្លាកពីទិន្នន័យដែលបានស្រង់ចេញ ដែលនឹងត្រូវបានធ្វើលិបិក្រមដោយ Loki ។
   • ផ្លាស់ប្តូរ ឬកំណត់ពេលវេលាព្រឹត្តិការណ៍ពីកំណត់ហេតុ។
   • ផ្លាស់ប្តូរទិន្នន័យ (កំណត់ហេតុអត្ថបទ) ដែលនឹងទៅ Loki ។
   • បង្កើតរង្វាស់។
4. ដំណាក់កាលត្រង. ដំណាក់កាលនៃការប្រកួត ដែលយើងអាចផ្ញើកំណត់ត្រាដែលយើងមិនត្រូវការ /dev/null ឬផ្ញើពួកវាសម្រាប់ដំណើរការបន្ថែម។

ដោយប្រើឧទាហរណ៍នៃដំណើរការកំណត់ហេតុ nginx ធម្មតា ខ្ញុំនឹងបង្ហាញពីរបៀបដែលអ្នកអាចញែកកំណត់ហេតុដោយប្រើ Promtail ។

សម្រាប់ការធ្វើតេស្ត សូមយករូបភាព nginx ដែលបានកែប្រែ jwilder/nginx-proxy:alpine ជា nginx-proxy និងដេមិនតូចមួយដែលអាចសួរខ្លួនឯងតាមរយៈ HTTP ។ ដេមិន​មាន​ចំណុច​បញ្ចប់​ជា​ច្រើន ដែល​វា​អាច​ផ្តល់​ការ​ឆ្លើយ​តប​ដែល​មាន​ទំហំ​ខុស​គ្នា ដោយ​មាន​ស្ថានភាព HTTP ខុស​គ្នា និង​មាន​ការ​ពន្យារ​ពេល​ផ្សេង​គ្នា។

យើង​នឹង​ប្រមូល​កំណត់​ហេតុ​ពី docker containers ដែល​អាច​រក​ឃើញ​តាម​ផ្លូវ /var/lib/docker/containers/ / -json.log

នៅក្នុង docker-compose.yml យើងកំណត់រចនាសម្ព័ន្ធ Promtail ហើយបញ្ជាក់ផ្លូវទៅកាន់ config៖

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

បន្ថែមផ្លូវទៅកាន់កំណត់ហេតុទៅកាន់ promtail.yml (មានជម្រើស "docker" នៅក្នុង config ដែលធ្វើដូចគ្នាក្នុងបន្ទាត់មួយ ប៉ុន្តែវាមិនច្បាស់ទេ)៖

scrape_configs:
 - job_name: containers

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

នៅពេលដែលការកំណត់រចនាសម្ព័ន្ធនេះត្រូវបានបើក Loki នឹងទទួលបានកំណត់ហេតុពីកុងតឺន័រទាំងអស់។ ដើម្បីជៀសវាងបញ្ហានេះ យើងផ្លាស់ប្តូរការកំណត់នៃការធ្វើតេស្ត nginx នៅក្នុង docker-compose.yml - បន្ថែមការកត់ត្រាទៅក្នុងវាលស្លាក៖

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

កែសម្រួល promtail.yml និងដំឡើង Pipeline ។ កំណត់ហេតុមានដូចខាងក្រោម៖

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

ដំណាក់កាលបំពង់៖

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

យើងទាញយកវាលស្ទ្រីម attrs attrs.tag (ប្រសិនបើមាន) ពី JSON ចូល ហើយដាក់វាចូលទៅក្នុងផែនទីស្រង់ចេញ។

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

ប្រសិនបើវាអាចធ្វើទៅបានដើម្បីដាក់វាលស្លាកនៅក្នុងផែនទីដែលបានស្រង់ចេញនោះដោយប្រើ regexp យើងស្រង់ឈ្មោះរូបភាពនិងកុងតឺន័រ។

 - labels:
     image_name:
     container_name:

យើងកំណត់ស្លាក។ ប្រសិនបើគ្រាប់ចុច image_name និង container_name ត្រូវបានរកឃើញនៅក្នុងទិន្នន័យដែលបានស្រង់ចេញ នោះតម្លៃរបស់ពួកគេនឹងត្រូវបានកំណត់ទៅស្លាកដែលសមរម្យ។

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

យើងបោះបង់កំណត់ហេតុទាំងអស់ដែលមិនមានស្លាក image_name និង container_name កំណត់។

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

សម្រាប់កំណត់ហេតុទាំងអស់ដែលឈ្មោះ image_name ស្មើនឹង nginx.promtail.test ទាញយកវាលកំណត់ហេតុចេញពីកំណត់ហេតុប្រភព ហើយដាក់វាទៅក្នុងផែនទីដែលបានស្រង់ចេញដោយប្រើគ្រាប់ចុចជួរដេក។

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

យើងសម្អាតបន្ទាត់បញ្ចូលជាមួយកន្សោមធម្មតា ហើយទាញម៉ាស៊ីននិម្មិត nginx និងបន្ទាត់កំណត់ហេតុ 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.]+)")?

ញែកកំណត់ហេតុ nginx ជាមួយកន្សោមធម្មតា។

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

ញែកសំណើ_url។ ដោយមានជំនួយពី regexp យើងកំណត់គោលបំណងនៃសំណើ៖ ដើម្បីឋិតិវន្ត រូបថត ទៅ API និងកំណត់សោដែលត្រូវគ្នានៅក្នុងផែនទីដែលបានស្រង់ចេញ។

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

ដោយប្រើប្រតិបត្តិករតាមលក្ខខណ្ឌនៅក្នុង Template យើងពិនិត្យមើលវាលដែលបានដំឡើងនៅក្នុងផែនទីដែលបានស្រង់ចេញ ហើយកំណត់តម្លៃដែលត្រូវការសម្រាប់វាល request_type: photo, static, API។ ចាត់ចែងផ្សេងទៀតប្រសិនបើបរាជ័យ។ ឥឡូវនេះ request_type មានប្រភេទសំណើ។

       - labels:
           api_request:
           virtual_host:
           request_type:
           status:

យើងកំណត់ស្លាក api_request, virtual_host, request_type និងស្ថានភាព (ស្ថានភាព HTTP) ដោយផ្អែកលើអ្វីដែលយើងបានគ្រប់គ្រងដើម្បីដាក់នៅក្នុងផែនទីដែលបានស្រង់ចេញ។

       - output:
           source: nginx_log_row

ផ្លាស់ប្តូរទិន្នផល។ ឥឡូវនេះកំណត់ហេតុ nginx ដែលត្រូវបានសម្អាតពីផែនទីដែលបានស្រង់ចេញទៅកាន់ Loki ។

បន្ទាប់ពីដំណើរការការកំណត់ខាងលើ អ្នកអាចមើលឃើញថាធាតុនីមួយៗត្រូវបានដាក់ស្លាកដោយផ្អែកលើទិន្នន័យពីកំណត់ហេតុ។

សូមចងចាំថាការស្រង់ចេញស្លាកជាមួយនឹងចំនួនដ៏ច្រើននៃតម្លៃ (cardinality) អាចបន្ថយល្បឿន Loki យ៉ាងខ្លាំង។ នោះគឺអ្នកមិនគួរដាក់នៅក្នុងលិបិក្រមឧទាហរណ៍ user_id ។ សូមអានបន្ថែមអំពីរឿងនេះនៅក្នុងអត្ថបទរបៀបដែលស្លាកនៅក្នុង Loki អាចធ្វើឱ្យសំណួរកំណត់ហេតុកាន់តែលឿន និងងាយស្រួលជាងមុន"។ ប៉ុន្តែនេះមិនមានន័យថាអ្នកមិនអាចស្វែងរកដោយ user_id ដោយគ្មានលិបិក្រមទេ។ វាចាំបាច់ក្នុងការប្រើតម្រងនៅពេលស្វែងរក ("ចាប់យក" យោងទៅតាមទិន្នន័យ) ហើយលិបិក្រមនៅទីនេះដើរតួជាអ្នកកំណត់អត្តសញ្ញាណស្ទ្រីម។

ការមើលឃើញកំណត់ហេតុ

Loki អាចដើរតួជាប្រភពទិន្នន័យសម្រាប់គំនូសតាង Grafana ដោយប្រើ LogQL ។ មុខងារខាងក្រោមត្រូវបានគាំទ្រ៖

• អត្រា - ចំនួនកំណត់ត្រាក្នុងមួយវិនាទី;
• រាប់តាមពេលវេលា - ចំនួនកំណត់ត្រានៅក្នុងជួរដែលបានផ្តល់ឱ្យ។

វាក៏មានមុខងារសរុប ផលបូក មធ្យម និងផ្សេងៗទៀតផងដែរ។ អ្នកអាចបង្កើតក្រាហ្វដ៏ស្មុគស្មាញ ឧទាហរណ៍ ក្រាហ្វនៃចំនួនកំហុស HTTP៖

ប្រភពទិន្នន័យលំនាំដើមរបស់ Loki មានមុខងារតិចជាងប្រភពទិន្នន័យ Prometheus បន្តិច (ឧទាហរណ៍ អ្នកមិនអាចផ្លាស់ប្តូររឿងព្រេងបានទេ) ប៉ុន្តែ Loki អាចត្រូវបានភ្ជាប់ជាប្រភពប្រភេទ Prometheus ។ ខ្ញុំ​មិន​ប្រាកដ​ថា​តើ​នេះ​ជា​អាកប្បកិរិយា​ដែល​បាន​ចង​ក្រង​ជា​ឯកសារ​ឬ​អត់​នោះ​ទេ ប៉ុន្តែ​ការ​វិនិច្ឆ័យ​ដោយ​ការ​ឆ្លើយ​តប​ពី​អ្នក​អភិវឌ្ឍន៍។តើធ្វើដូចម្តេចដើម្បីកំណត់រចនាសម្ព័ន្ធ Loki ជាប្រភពទិន្នន័យ Prometheus? · លេខ 1222 · grafana/loki” ជាឧទាហរណ៍ វាគឺស្របច្បាប់ឥតខ្ចោះ ហើយ Loki គឺត្រូវគ្នាយ៉ាងពេញលេញជាមួយ PromQL ។

បន្ថែម Loki ជាប្រភពទិន្នន័យដែលមានប្រភេទ Prometheus ហើយបន្ថែម URL /loki៖

ហើយយើងអាចបង្កើតក្រាហ្វ ដូចជាយើងកំពុងធ្វើការជាមួយម៉ែត្រពី Prometheus៖

ខ្ញុំគិតថាភាពខុសគ្នានៃមុខងារគឺបណ្តោះអាសន្ន ហើយអ្នកអភិវឌ្ឍន៍នឹងជួសជុលវានៅពេលអនាគត។

ម៉ែត្រ

Loki ផ្តល់នូវសមត្ថភាពក្នុងការទាញយកម៉ែត្រលេខពីកំណត់ហេតុ ហើយបញ្ជូនវាទៅ Prometheus ។ ឧទាហរណ៍ កំណត់ហេតុ nginx មានចំនួនបៃក្នុងមួយការឆ្លើយតប ហើយជាមួយនឹងការកែប្រែជាក់លាក់នៃទម្រង់កំណត់ហេតុស្តង់ដារ ពេលវេលាគិតជាវិនាទីដែលវាត្រូវការដើម្បីឆ្លើយតប។ ទិន្នន័យនេះអាចត្រូវបានស្រង់ចេញ និងផ្ញើទៅកាន់ Prometheus ។

បន្ថែមផ្នែកមួយទៀតទៅ 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

ជម្រើសអនុញ្ញាតឱ្យអ្នកកំណត់ និងធ្វើបច្ចុប្បន្នភាពម៉ែត្រដោយផ្អែកលើទិន្នន័យពីផែនទីដែលបានស្រង់ចេញ។ ម៉ែត្រទាំងនេះមិនត្រូវបានផ្ញើទៅ Loki ទេ - ពួកវាបង្ហាញនៅក្នុង Promtail /metrics endpoint។ Prometheus ត្រូវតែត្រូវបានកំណត់រចនាសម្ព័ន្ធដើម្បីទទួលទិន្នន័យពីដំណាក់កាលនេះ។ ក្នុងឧទាហរណ៍ខាងលើ សម្រាប់ request_type="api" យើងប្រមូលម៉ែត្រអ៊ីស្តូក្រាម។ ជាមួយនឹងប្រភេទម៉ែត្រនេះ វាងាយស្រួលក្នុងការទទួលបានភាគរយ។ សម្រាប់ឋិតិវន្ត និងរូបថត យើងប្រមូលផលបូកនៃបៃ និងចំនួនជួរដេកដែលយើងបានទទួលបៃដើម្បីគណនាជាមធ្យម។

សូមអានបន្ថែមអំពីម៉ែត្រ នៅទីនេះ.

បើកច្រកនៅលើ Promtail៖

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

យើងធ្វើឱ្យប្រាកដថាម៉ែត្រដែលមានបុព្វបទ promtail_custom បានបង្ហាញខ្លួន៖

ការដំឡើង Prometheus ។ បន្ថែមដំណឹងការងារ៖

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

ហើយគូរក្រាហ្វ៖

វិធីនេះអ្នកអាចរកឃើញឧទាហរណ៍ សំណួរយឺតបំផុតចំនួនបួន។ អ្នកក៏អាចកំណត់រចនាសម្ព័ន្ធការត្រួតពិនិត្យសម្រាប់ម៉ែត្រទាំងនេះផងដែរ។

ការធ្វើមាត្រដ្ឋាន

Loki អាច​មាន​ទាំង​របៀប​ប្រព័ន្ធ​គោលពីរ​តែមួយ និង​បំបែក (របៀប​ដែល​អាច​ធ្វើ​មាត្រដ្ឋាន​បាន)។ ក្នុងករណីទីពីរ វាអាចរក្សាទុកទិន្នន័យទៅក្នុងពពក ហើយកំណាត់ និងលិបិក្រមត្រូវបានរក្សាទុកដោយឡែកពីគ្នា។ នៅក្នុងកំណែ 1.5 សមត្ថភាពក្នុងការរក្សាទុកនៅកន្លែងមួយត្រូវបានអនុវត្ត ប៉ុន្តែវាមិនទាន់ត្រូវបានគេណែនាំឱ្យប្រើវានៅក្នុងការផលិតនោះទេ។

កំណាត់អាចត្រូវបានរក្សាទុកក្នុងទំហំផ្ទុកដែលត្រូវគ្នាជាមួយ S3 ហើយមូលដ្ឋានទិន្នន័យដែលអាចធ្វើមាត្រដ្ឋានបានដោយផ្ដេកអាចត្រូវបានប្រើដើម្បីរក្សាទុកសន្ទស្សន៍៖ Cassandra, BigTable ឬ DynamoDB ។ ផ្នែកផ្សេងទៀតនៃ Loki - អ្នកចែកចាយ (សម្រាប់ការសរសេរ) និង Querier (សម្រាប់សំណួរ) - គឺគ្មានរដ្ឋ ហើយក៏អាចធ្វើមាត្រដ្ឋានផ្ដេកផងដែរ។

នៅក្នុងសន្និសិទ DevOpsDays Vancouver 2019 អ្នកចូលរួមម្នាក់ឈ្មោះ Callum Styan បានប្រកាសថាជាមួយនឹង Loki គម្រោងរបស់គាត់មានកំណត់ហេតុចំនួន petabytes ជាមួយនឹងសន្ទស្សន៍តិចជាង 1% នៃទំហំសរុប៖ "របៀបដែល Loki ទាក់ទងម៉ែត្រនិងកំណត់ហេតុ - ហើយសន្សំលុយអ្នក។"។

ការប្រៀបធៀប Loki និង ELK

ទំហំសន្ទស្សន៍

ដើម្បីសាកល្បងទំហំលិបិក្រមលទ្ធផល ខ្ញុំបានយកកំណត់ហេតុពីកុងតឺន័រ nginx ដែលបំពង់ខាងលើត្រូវបានកំណត់រចនាសម្ព័ន្ធ។ ឯកសារកំណត់ហេតុមាន 406 បន្ទាត់ដែលមានបរិមាណសរុប 624 មេកាបៃ។ កំណត់​ហេតុ​ត្រូវ​បាន​បង្កើត​ឡើង​ក្នុង​រយៈ​ពេល​មួយ​ម៉ោង​ប្រហែល 109 កំណត់ត្រា​ក្នុង​មួយ​វិនាទី។

ឧទាហរណ៍នៃបន្ទាត់ពីរពីកំណត់ហេតុ៖

នៅពេលធ្វើលិបិក្រមដោយ ELK វាផ្តល់ទំហំលិបិក្រម 30,3 MB៖

ក្នុងករណី Loki នេះបានផ្តល់លិបិក្រមប្រហែល 128 KB និងទិន្នន័យប្រហែល 3,8 MB ជាកំណាត់។ គួរកត់សម្គាល់ថាកំណត់ហេតុត្រូវបានបង្កើតដោយសិប្បនិម្មិត ហើយមិនមានទិន្នន័យច្រើនប្រភេទទេ។ gzip សាមញ្ញនៅលើកំណត់ហេតុ Docker JSON ដើមដែលមានទិន្នន័យបានផ្តល់ការបង្ហាប់ 95,4% ហើយបានផ្តល់ឱ្យថាមានតែកំណត់ហេតុ nginx ដែលត្រូវបានសម្អាតប៉ុណ្ណោះត្រូវបានបញ្ជូនទៅ Loki ខ្លួនវា ការបង្ហាប់ដល់ 4 MB គឺអាចយល់បាន។ ចំនួនសរុបនៃតម្លៃតែមួយគត់សម្រាប់ស្លាក Loki គឺ 35 ដែលពន្យល់ពីទំហំតូចនៃសន្ទស្សន៍។ សម្រាប់ ELK កំណត់ហេតុក៏ត្រូវបានសម្អាតផងដែរ។ ដូច្នេះ Loki បានបង្ហាប់ទិន្នន័យដើម 96% និង ELK 70% ។

ការប្រើប្រាស់អង្គចងចាំ

ប្រសិនបើយើងប្រៀបធៀបជង់ Prometheus និង ELK ទាំងមូល នោះ Loki "ញ៉ាំ" តិចជាងច្រើនដង។ វាច្បាស់ណាស់ថាសេវា Go ប្រើប្រាស់តិចជាងសេវា Java ហើយការប្រៀបធៀបទំហំនៃ JVM Heap Elasticsearch និងអង្គចងចាំដែលបានបែងចែកសម្រាប់ Loki គឺមិនត្រឹមត្រូវទេ ប៉ុន្តែទោះជាយ៉ាងណាក៏ដោយ គួរកត់សម្គាល់ថា Loki ប្រើប្រាស់អង្គចងចាំតិចជាងច្រើន។ អត្ថប្រយោជន៍ CPU របស់វាមិនសូវច្បាស់ទេ ប៉ុន្តែវាក៏មានវត្តមានផងដែរ។

ល្បឿន

Loki "លេបត្របាក់" កត់ត្រាកាន់តែលឿន។ ល្បឿនអាស្រ័យលើកត្តាជាច្រើន - តើកំណត់ហេតុប្រភេទណា របៀបដែលយើងញែកពួកវា បណ្តាញ ថាស។ល។ - ប៉ុន្តែវាពិតជាខ្ពស់ជាង ELK (នៅក្នុងការធ្វើតេស្តរបស់ខ្ញុំ - ប្រហែលពីរដង) នេះត្រូវបានពន្យល់ដោយការពិតដែលថា Loki ដាក់ទិន្នន័យតិចជាងច្រើនទៅក្នុងលិបិក្រម ហើយតាមនោះ ចំណាយពេលតិចលើការធ្វើលិបិក្រម។ ក្នុងករណីនេះ ស្ថានភាពត្រូវបានបញ្ច្រាស់ជាមួយនឹងល្បឿនស្វែងរក៖ Loki ថយចុះគួរឱ្យកត់សម្គាល់លើទិន្នន័យធំជាងពីរបីជីហ្គាបៃ ខណៈដែលសម្រាប់ ELK ល្បឿនស្វែងរកមិនអាស្រ័យលើទំហំទិន្នន័យទេ។

ការស្វែងរកកំណត់ហេតុ

Loki គឺទាបជាង ELK យ៉ាងខ្លាំងនៅក្នុងលក្ខខណ្ឌនៃសមត្ថភាពស្វែងរកកំណត់ហេតុ។ Grep ជាមួយនឹងកន្សោមធម្មតាគឺមានឥទ្ធិពលប៉ុន្តែវាទាបជាងមូលដ្ឋានទិន្នន័យចាស់ទុំ។ កង្វះនៃជួរសំណួរ ការប្រមូលផ្តុំដោយស្លាកតែប៉ុណ្ណោះ អសមត្ថភាពក្នុងការស្វែងរកដោយគ្មានស្លាក - ទាំងអស់នេះកំណត់យើងក្នុងការស្វែងរកព័ត៌មានដែលចាប់អារម្មណ៍លើ Loki ។ នេះមិនមានន័យថាគ្មានអ្វីអាចត្រូវបានរកឃើញដោយប្រើ Loki នោះទេ ប៉ុន្តែវាកំណត់លំហូរនៃការធ្វើការជាមួយកំណត់ហេតុ នៅពេលអ្នករកឃើញបញ្ហាដំបូងនៅក្នុងតារាង Prometheus ហើយបន្ទាប់មកប្រើស្លាកទាំងនេះដើម្បីរកមើលអ្វីដែលបានកើតឡើងនៅក្នុងកំណត់ហេតុ។

ចំណុចប្រទាក់

ដំបូងវាស្អាតណាស់ (សុំទោស មិនអាចទ្រាំបាន)។ Grafana មានចំណុចប្រទាក់មើលទៅស្អាត ប៉ុន្តែ Kibana មានមុខងារច្រើនជាង។

គុណសម្បត្តិនិងគុណវិបត្តិរបស់ Loki

ក្នុងចំណោមគុណសម្បត្តិ វាអាចត្រូវបានកត់សម្គាល់ថា Loki រួមបញ្ចូលជាមួយ Prometheus រៀងគ្នា យើងទទួលបានម៉ែត្រ និងការជូនដំណឹងចេញពីប្រអប់។ វាងាយស្រួលសម្រាប់ការប្រមូលកំណត់ហេតុ និងរក្សាទុកពួកវាជាមួយ Kubernetes Pods ដោយសារតែវាមានការរកឃើញសេវាកម្មដែលទទួលមរតកពី Prometheus និងភ្ជាប់ស្លាកដោយស្វ័យប្រវត្តិ។

នៃ minuses - ឯកសារមិនល្អ។ រឿងមួយចំនួនដូចជាលក្ខណៈពិសេស និងសមត្ថភាពរបស់ Promtail ខ្ញុំបានរកឃើញតែនៅក្នុងដំណើរការនៃការសិក្សាកូដ អត្ថប្រយោជន៍នៃប្រភពបើកចំហប៉ុណ្ណោះ។ គុណវិបត្តិមួយទៀតគឺសមត្ថភាពវិភាគខ្សោយ។ ឧទាហរណ៍ Loki មិនអាចញែកកំណត់ហេតុច្រើនជួរបានទេ។ ដូចគ្នានេះផងដែរគុណវិបត្តិរួមមានការពិតដែលថា Loki គឺជាបច្ចេកវិទ្យាវ័យក្មេង (ការចេញផ្សាយ 1.0 គឺនៅក្នុងខែវិច្ឆិកា 2019) ។

សេចក្តីសន្និដ្ឋាន

Loki គឺជាបច្ចេកវិទ្យាគួរឱ្យចាប់អារម្មណ៍ 100% ដែលសាកសមសម្រាប់គម្រោងខ្នាតតូច និងមធ្យម ដែលអនុញ្ញាតឱ្យអ្នកដោះស្រាយបញ្ហាជាច្រើននៃការប្រមូលផ្តុំកំណត់ហេតុ ការស្វែងរកកំណត់ហេតុ ការត្រួតពិនិត្យ និងការវិភាគកំណត់ហេតុ។

យើងមិនប្រើ Loki នៅក្នុង Badoo ទេ ពីព្រោះយើងមានជង់ ELK ដែលសាកសមនឹងយើង ហើយដែលត្រូវបានធំធាត់ជាមួយនឹងដំណោះស្រាយផ្ទាល់ខ្លួនជាច្រើនឆ្នាំមកនេះ។ សម្រាប់ពួកយើង ការជំពប់ដួលកំពុងស្វែងរកតាមរយៈកំណត់ហេតុ។ ជាមួយនឹងកំណត់ហេតុស្ទើរតែ 100 ជីកាបៃក្នុងមួយថ្ងៃ វាជារឿងសំខាន់សម្រាប់ពួកយើងដើម្បីអាចស្វែងរកអ្វីៗគ្រប់យ៉ាង និងតិចតួចបន្ថែមទៀត ហើយធ្វើវាបានយ៉ាងឆាប់រហ័ស។ សម្រាប់តារាង និងការត្រួតពិនិត្យ យើងប្រើដំណោះស្រាយផ្សេងទៀតដែលតម្រូវតាមតម្រូវការរបស់យើង ហើយរួមបញ្ចូលជាមួយគ្នាទៅវិញទៅមក។ ជង់ Loki មានអត្ថប្រយោជន៍ជាក់ស្តែង ប៉ុន្តែវានឹងមិនផ្តល់ឱ្យយើងច្រើនជាងយើងមានរួចហើយ ហើយអត្ថប្រយោជន៍របស់វាប្រាកដជាមិនលើសតម្លៃនៃការធ្វើចំណាកស្រុកនោះទេ។

ហើយទោះបីជាបន្ទាប់ពីការស្រាវជ្រាវវាច្បាស់ថាយើងមិនអាចប្រើ Loki ក៏ដោយក៏យើងសង្ឃឹមថាការប្រកាសនេះនឹងជួយអ្នកក្នុងការជ្រើសរើស។

ឃ្លាំងដែលមានលេខកូដដែលប្រើក្នុងអត្ថបទមានទីតាំងនៅ នៅទីនេះ.

ប្រភព: www.habr.com