لوڪي کان لاگ گڏ ڪرڻ

Badoo تي، اسان مسلسل نئين ٽيڪنالاجي جي نگراني ڪندا آهيون ۽ اندازو لڳايو ته ڇا اهي اسان جي سسٽم ۾ استعمال ڪرڻ جي قابل آهن. اسان انهن مان هڪ مطالعي کي ڪميونٽي سان حصيداري ڪرڻ چاهيندا. اهو Loki لاء وقف آهي، هڪ لاگ مجموعي نظام.

Loki لاگز کي محفوظ ڪرڻ ۽ ڏسڻ لاءِ هڪ حل آهي، ۽ هي اسٽيڪ پڻ انهن جو تجزيو ڪرڻ ۽ پروميٿيس ڏانهن ڊيٽا موڪلڻ لاءِ هڪ لچڪدار نظام فراهم ڪري ٿو. مئي ۾، هڪ ٻي تازه ڪاري جاري ڪئي وئي، جيڪا فعال طور تي تخليق ڪندڙن پاران ترقي ڪئي وئي آهي. اسان کي دلچسپي هئي ته لوڪي ڇا ڪري سگهي ٿو، ڪهڙيون صلاحيتون مهيا ڪري ٿي، ۽ ڪهڙي حد تائين اهو ڪم ڪري سگهي ٿو ELK جي متبادل طور، اسٽيڪ جيڪو اسان هاڻي استعمال ڪريون ٿا.

Loki ڇا آهي

گرافانا لوڪي لاگن سان ڪم ڪرڻ لاء مڪمل سسٽم لاء اجزاء جو هڪ سيٽ آهي. ٻين ساڳين سسٽمن جي برعڪس، لوڪي صرف لاگ ميٽاداٽا - ليبلز (جيئن ئي پروميٿيوس ۾) کي ترتيب ڏيڻ جي خيال تي ٻڌل آهي، ۽ لاگن کي پاڻ کي الڳ حصن ۾ دٻائڻ.

گهر جو صفحو, GitHub

ان کان اڳ جو اسان حاصل ڪريون ته توهان لوڪي سان ڇا ڪري سگهو ٿا، مان واضح ڪرڻ چاهيان ٿو ته اسان جو مطلب ڇا آهي "صرف ميٽا ڊيٽا کي ترتيب ڏيڻ جو خيال." اچو ته لوڪي جي نقطه نظر جو مقابلو ڪريون ۽ روايتي حلن ۾ انڊيڪسنگ جي نقطه نظر جهڙوڪ Elasticsearch، nginx log مان هڪ لڪير جو مثال استعمال ڪندي:

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 ويلز شامل آهن، ۽ هر شيءِ کي وڏي انگن اکرن ۾ محفوظ ڪن ٿا. هن طريقي جو فائدو اهو آهي ته توهان پيچيده سوالن کي جلدي هلائي سگهو ٿا، ڇاڪاڻ ته تقريبن سموري ڊيٽا انڊيڪس ۾ آهي. پر اهو هڪ قيمت تي اچي ٿو ته انڊيڪس وڏي ٿي وڃي ٿي، جيڪا ميموري گهرجن ۾ ترجمو ڪري ٿي. نتيجي طور، مڪمل-ٽيڪسٽ لاگ انڊيڪس سائيز ۾ پاڻ کي لاگ ان جي مقابلي ۾ آهي. ان جي ذريعي جلدي ڳولڻ لاء، انڊيڪس کي ميموري ۾ لوڊ ڪيو وڃي. ۽ وڌيڪ لاگ، انڊيڪس تيزيء سان وڌندو آهي ۽ وڌيڪ ياداشت ان کي استعمال ڪندو آهي.

لوڪي طريقي جي ضرورت آهي ته صرف ضروري ڊيٽا هڪ تار مان ڪڍيا وڃن، جن جي قيمتن جو تعداد ننڍڙو آهي. اهڙيءَ طرح اسان هڪ ننڍي انڊيڪس حاصل ڪريون ٿا ۽ ڊيٽا کي ڳولي سگهون ٿا ان کي فلٽر ڪري وقت جي حساب سان ۽ انڊيڪس ٿيل فيلڊز ذريعي، ۽ پوءِ باقي کي اسڪين ڪري ريگيولر ايڪسپريسشن يا سب اسٽرينگ سرچ سان. اهو عمل تيز ترين نه ٿو لڳي، پر لوڪي درخواست کي ڪيترن ئي حصن ۾ ورهائي ٿو ۽ انهن کي متوازي طور تي عمل ڪري ٿو، ٿوري وقت ۾ ڊيٽا جي وڏي مقدار کي پروسيس ڪري ٿو. انهن ۾ شارڊ ۽ متوازي درخواستن جو تعداد ترتيب ڏيڻ جي قابل آهي. اهڙيء طرح، ڊيٽا جو مقدار جيڪو پروسيس ڪري سگهجي ٿو في يونٽ وقت جي فراهم ڪيل وسيلن جي مقدار تي منحصر آهي.

هي واپار بند هڪ وڏي، تيز انڊيڪس ۽ هڪ ننڍڙي، متوازي برٽ فورس انڊيڪس جي وچ ۾ لوڪي کي سسٽم جي قيمت کي ڪنٽرول ڪرڻ جي اجازت ڏئي ٿو. اهو لچڪدار ترتيب ڏئي سگهجي ٿو ۽ ضرورتن مطابق وڌايو وڃي.

لوڪي اسٽيڪ ٽن حصن تي مشتمل آهي: پرومٽيل، لوڪي، گرافانا. Promtail لاگ گڏ ڪري ٿو، انهن کي پروسيس ڪري ٿو ۽ انهن کي لوڪي ڏانهن موڪلي ٿو. لوڪ انهن کي رکي ٿو. ۽ گرافانا لوڪي کان ڊيٽا جي درخواست ڪري سگهي ٿو ۽ ان کي ڏيکاري ٿو. عام طور تي، Loki استعمال ڪري سگهجي ٿو نه صرف لاگ ان کي محفوظ ڪرڻ ۽ انهن جي ذريعي ڳولڻ لاء. سڄو اسٽيڪ پروميٿيوس طريقي سان استعمال ڪندي ايندڙ ڊيٽا کي پروسيسنگ ۽ تجزيو ڪرڻ لاء بهترين موقعا فراهم ڪري ٿو.
تنصيب جي عمل جي وضاحت ملي سگهي ٿي هتي.

لاگن ذريعي ڳولھيو

توهان لاگز کي خاص گرافانا انٽرفيس ۾ ڳولي سگهو ٿا - ايڪسپلورر. سوالن ۾ LogQL ٻولي استعمال ٿئي ٿي، جيڪا Prometheus ۾ استعمال ٿيل PromQL سان بلڪل ملندڙ جلندڙ آهي. اصول ۾، اهو سمجهي سگهجي ٿو ورهايل گريپ جي طور تي.

سرچ انٽرفيس هن طرح نظر اچي ٿو:

درخواست پاڻ ٻن حصن تي مشتمل آهي: چونڊيندڙ ۽ فلٽر. سليڪٽر انڊيڪس ٿيل ميٽاڊيٽا (ليبلز) استعمال ڪندي ڳولا آهي جيڪي لاگز کي لڳايو ويو آهي، ۽ فلٽر هڪ سرچ اسٽرنگ يا ريجڪس آهي جيڪو چونڊيندڙ طرفان بيان ڪيل رڪارڊ کي فلٽر ڪري ٿو. ڏنل مثال ۾: گھمڻ واري ڪنگڻ ۾ ھڪڙو چونڊيندڙ آھي، ان کان پوء سڀ ڪجھ فلٽر آھي.

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

لوڪي جي ڪم ڪرڻ جي طريقي جي ڪري، توھان بغير چونڊيندڙ کان سوال نٿا ڪري سگھو، پر ليبل توھان جي پسند وانگر عام ڪري سگھجن ٿا.

هڪ چونڊيندڙ هڪ اهم-قيمتي قدر آهي گھڙيل braces ۾. توھان چونڊيندڙن کي گڏ ڪري سگھوٿا ۽ مختلف ڳولھا جون حالتون بيان ڪري سگھوٿا آپريٽرز =، != يا باقاعده اظهار:

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

هڪ فلٽر متن يا regexp آهي جيڪو چونڊيندڙ طرفان حاصل ڪيل سڀني ڊيٽا کي فلٽر ڪندو.

ميٽرڪس موڊ ۾ حاصل ڪيل ڊيٽا جي بنياد تي ايڊ-هاڪ گرافس حاصل ڪرڻ ممڪن آهي. مثال طور، توهان اهو ڳولي سگهو ٿا ته ڪيترا ڀيرا داخل ٿيڻ واري اسٽرنگ انڊيڪس تي مشتمل آهي nginx لاگز ۾:

صلاحيتن جي مڪمل وضاحت دستاويز ۾ ملي سگهي ٿي LogQL.

لاگ پارسنگ

لاگ گڏ ڪرڻ جا ڪيترائي طريقا آهن:

• Promtail استعمال ڪندي، لاگ گڏ ڪرڻ لاء اسٽيڪ جو هڪ معياري حصو.
• ڊاکر ڪنٽينر مان سڌو استعمال ڪندي Loki Docker لاگنگ ڊرائيور.
• Fluentd يا Fluent Bit استعمال ڪريو، جيڪو Loki ڏانهن ڊيٽا موڪلي سگھي ٿو. Promtail جي برعڪس، انهن وٽ تقريباً ڪنهن به قسم جي لاگ لاءِ تيار ڪيل پارسر آهن ۽ اهي ملٽي لائن لاگز کي به سنڀالي سگهن ٿا.

عام طور تي Promtail parsing لاء استعمال ڪيو ويندو آهي. اهو ٽي شيون ڪري ٿو:

• ڊيٽا ذريعن کي ڳولي ٿو.
• انهن سان ليبل ڳنڍي ٿو.
• Loki ڏانهن ڊيٽا موڪلي ٿو.

في الحال Promtail مقامي فائلن مان لاگ پڙهي سگهي ٿو ۽ سسٽم ڊي جرنل مان. اهو هر مشين تي نصب ٿيڻ گهرجي جنهن مان لاگ گڏ ڪيا ويا آهن.

ڪبرنيٽس سان گڏ انٽيگريشن آهي: Promtail خود بخود، Kubernetes REST API ذريعي، ڪلستر جي حالت کي سڃاڻي ٿو ۽ نوڊ، سروس يا پوڊ کان لاگ گڏ ڪري ٿو، فوري طور تي ڪبرنيٽس (پوڊ جو نالو، فائل جو نالو، وغيره) جي ميٽا ڊيٽا جي بنياد تي ليبل پوسٽ ڪري ٿو. .

توهان پائپ لائن استعمال ڪندي لاگ مان ڊيٽا جي بنياد تي ليبل پڻ لڪائي سگهو ٿا. پائيپ لائين پروٽيل چئن قسمن جي مرحلن تي مشتمل ٿي سگھي ٿو. وڌيڪ تفصيل ۾ سرڪاري دستاويز، مان فوري طور تي ڪجهه نوٽس نوٽ ڪندس.

1. تجزيي جا مرحلا. هي RegEx ۽ JSON اسٽيج آهي. هن مرحلي تي، اسان لاگن مان ڊيٽا ڪڍيو ٿا جنهن کي نام نهاد نڪتل نقشي ۾. اسان JSON مان ڪڍي سگھون ٿا صرف انھن فيلڊن کي نقل ڪري جن جي اسان کي ضرورت آھي ڪڍيل نقشي ۾، يا ريگيولر ايڪسپريسشن (RegEx) ذريعي، جتي نالي ٿيل گروپن کي ڪڍيا ويا آھن نقشي ۾ ”نقشي ٿيل“. ڪڍيل نقشو هڪ اهم-قدر جو دڪان آهي، جتي ڪيئي فيلڊ جو نالو آهي، ۽ قيمت لاگ ان مان ان جي قيمت آهي.
2. مرحلن کي تبديل ڪريو. هن اسٽيج ۾ ٻه آپشن آهن: ٽرانسفارم، جتي اسان تبديليءَ جا قاعدا مقرر ڪريون ٿا، ۽ ماخذ - ڪڍيل نقشي مان تبديليءَ لاءِ ڊيٽا جو ذريعو. جيڪڏهن ڪڍيل نقشي ۾ اهڙي ڪا به فيلڊ نه آهي، اهو ٺاهيو ويندو. انهي طريقي سان اهو ممڪن آهي ته ليبل ٺاهڻ لاء جيڪي نڪتل نقشي تي ٻڌل نه آهن. هن اسٽيج تي اسان ڊيٽا کي هٿي وٺائي سگھون ٿا ڪڍيل نقشي ۾ استعمال ڪندي ڪافي طاقتور گولانگ سانچو. ان کان علاوه، اسان کي ياد رکڻ گهرجي ته ڪڍيل نقشو مڪمل طور تي parsing دوران لوڊ ڪيو ويندو آهي، جيڪو اهو ممڪن بڻائي ٿو، مثال طور، ان ۾ قيمت چيڪ ڪرڻ لاء: “{{if .tag}tag value موجود آهي{end}}”. ٽيمپليٽ حالتن، لوپس، ۽ ڪجهه اسٽرنگ افعال کي سپورٽ ڪري ٿو جهڙوڪ تبديل ڪريو ۽ ٽرم.
3. عمل جا مرحلا. هن نقطي تي توهان ڪڍيل مواد سان ڪجهه ڪري سگهو ٿا:
   • ڪڍيل ڊيٽا مان هڪ ليبل ٺاهيو، جيڪو لوڪي طرفان ترتيب ڏنو ويندو.
   • لاگ مان واقعي جو وقت تبديل ڪريو يا سيٽ ڪريو.
   • ڊيٽا کي تبديل ڪريو (لاگ ٽيڪسٽ) جيڪو وڃو لوڪي ڏانهن.
   • ميٽرڪ ٺاهيو.
4. فلٽرنگ جا مرحلا. ميچ اسٽيج، جتي اسان يا ته داخل ڪري سگھون ٿا جيڪي اسان کي /dev/null ڪرڻ جي ضرورت ناهي يا انهن کي وڌيڪ پروسيسنگ لاء اڳتي وڌايو.

باقاعده نينڪس لاگز جي پروسيسنگ جو هڪ مثال استعمال ڪندي، مان ڏيکاريندس ته توهان ڪيئن لاگ ان کي پارس ڪري سگهو ٿا Promtail استعمال ڪندي.

ٽيسٽ لاءِ، اچو ته وٺو nginx-proxy هڪ تبديل ٿيل nginx تصوير jwilder/nginx-proxy:alpine ۽ هڪ ننڍڙو ڊيمون جيڪو پاڻ کي HTTP ذريعي پڇي سگھي ٿو. ڊيمن وٽ ڪيترائي آخري نقطا آھن، جن کي اھو مختلف سائزن جا جواب ڏئي سگھي ٿو، مختلف HTTP حالتن سان ۽ مختلف دير سان.

اسان ڊاکر ڪنٽينرز مان لاگ گڏ ڪنداسين، جيڪي رستي ۾ ڳولي سگهجن ٿا /var/lib/docker/containers/ / -json.log

docker-compose.yml ۾ اسان Promtail ترتيب ڏيون ٿا ۽ ترتيب ڏيڻ جو رستو بيان ڪريو:

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 ڏانهن لاگز ڏانهن رستو شامل ڪريو (ڪانفگ ۾ ”ڊاڪر“ آپشن آهي، جيڪو ساڳيو ڪم هڪ لڪير ۾ ڪري ٿو، پر اهو ايترو واضح نه هوندو):

scrape_configs:
 - job_name: containers

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

جڏھن ھي ٺاھ ٺاھيو ويندو، سڀني ڪنٽينرز مان لاگز لوڪي ڏانھن موڪليا ويندا. هن کان بچڻ لاء، اسان docker-compose.yml ۾ ٽيسٽ nginx جي سيٽنگون تبديل ڪريون ٿا - لاگنگ ٽيگ فيلڊ شامل ڪريو:

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

promtail.yml کي تبديل ڪرڻ ۽ پائپ لائن کي ترتيب ڏيڻ. ان پٽ ۾ هيٺين قسم جا لاگ شامل آهن:

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

اسان ايندڙ JSON مان فيلڊ اسٽريم، attrs، attrs.tag (جيڪڏهن اهي موجود آهن) ڪڍيون ۽ انهن کي ڪڍيل نقشي ۾ رکون.

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

جيڪڏهن اسان ڪڍيل نقشي ۾ ٽيگ فيلڊ کي منظم ڪيو، پوء regexp استعمال ڪندي اسان تصوير ۽ ڪنٽينر جا نالا ڪڍيون ٿا.

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

اچو ته پارس ڪريون 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}}"

ٽيمپليٽ ۾ مشروط آپريٽرز استعمال ڪندي، اسان ڪڍيل نقشي ۾ نصب ٿيل فيلڊ چيڪ ڪريون ٿا ۽ درخواست_ قسم جي فيلڊ لاءِ گهربل قدر مقرر ڪريون ٿا: فوٽو، جامد، API. جيڪڏهن اهو ناڪام ٿئي ته ٻيو مقرر ڪريو. request_type هاڻي درخواست جي قسم تي مشتمل آهي.

       - labels:
           api_request:
           virtual_host:
           request_type:
           status:

اسان ليبل سيٽ ڪيو api_request، virtual_host، request_type ۽ status (HTTP اسٽيٽس) ان بنياد تي جيڪو اسان ڪڍيا نقشي ۾ رکڻ لاءِ منظم ڪيو.

       - output:
           source: nginx_log_row

پيداوار تبديل ڪريو. ھاڻي نڪتل نقشي مان صاف ٿيل نينڪس لاگ لوڪي ڏانھن وڃي ٿو.

مٿي ڏنل ترتيب کي هلائڻ کان پوء، توهان ڏسي سگهو ٿا ته هر داخلا لاگ ان ڊيٽا جي بنياد تي ليبل لڳايو ويو آهي.

ذهن ۾ رکڻ لاءِ هڪ شيءِ اها آهي ته وڏي تعداد ۾ قدرن سان ليبل ٻيهر حاصل ڪرڻ (ڪارڊنيالٽي) لوڪي کي تمام گهڻو سست ڪري سگهي ٿو. اهو آهي، توهان کي نه رکڻ گهرجي، مثال طور، انڊيڪس ۾ user_id. هن مضمون ۾ وڌيڪ پڙهو "ڪيئن لوڪي ۾ ليبل لاگ سوالن کي تيز ۽ آسان بڻائي سگھن ٿا" پر هن جو مطلب اهو ناهي ته توهان انڊيڪس کانسواءِ user_id ذريعي ڳولي نٿا سگهو. توھان کي فلٽر استعمال ڪرڻ جي ضرورت آھي جڏھن ڳولھيو (ڊيٽا کي ”پڙھيو“)، ۽ انڊيڪس ھتي ڪم ڪري ٿو ھڪڙي نديءَ جي سڃاڻپ ڪندڙ.

لاگن جو تصور

Loki LogQL استعمال ڪندي گرافانا گرافس لاءِ ڊيٽا ماخذ طور ڪم ڪري سگھي ٿو. ھيٺيون خاصيتون سپورٽ آھن:

• شرح - في سيڪنڊ رڪارڊ جو تعداد؛
• وقت تي ڳڻڻ - مخصوص حد ۾ رڪارڊ جو تعداد.

اتي پڻ مجموعا افعال Sum، Avg ۽ ٻيا آھن. توهان ڪافي پيچيده گراف ٺاهي سگهو ٿا، مثال طور HTTP غلطين جي تعداد جو گراف:

معياري ڊيٽا جو ماخذ Loki Prometheus ڊيٽا ماخذ جي مقابلي ۾ ڪارڪردگي ۾ ڪجهه گھٽجي ويو آهي (مثال طور، توهان ڏند ڪٿا کي تبديل نٿا ڪري سگهو)، پر Loki کي Prometheus قسم سان ذريعو طور ڳنڍجي سگھجي ٿو. مون کي پڪ ناهي ته اهو دستاويزي رويي آهي، پر ڊولپرز جي جواب جي ذريعي فيصلو ڪندي "لوڪي کي پروميٿيوس ڊيٽا ماخذ طور ڪيئن ترتيب ڏيو؟ · شمارو نمبر 1222 · گرافانا/لوڪي"، مثال طور، مڪمل طور تي قانوني آهي، ۽ Loki مڪمل طور تي PromQL سان مطابقت رکي ٿو.

Loki شامل ڪريو ڊيٽا ماخذ طور پروميٿيوس ٽائپ سان ۽ URL /loki شامل ڪريو:

۽ اسان گراف ٺاهي سگهون ٿا، ڄڻ ته اسان پروميٿيس جي ميٽرڪس سان ڪم ڪري رهيا آهيون:

مان سمجهان ٿو ته ڪارڪردگي ۾ تفاوت عارضي آهي ۽ ڊولپرز هن کي مستقبل ۾ درست ڪندا.

ميٽرڪس

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

اختيار توهان کي وضاحت ۽ تازه ڪاري ڪرڻ جي اجازت ڏئي ٿو ميٽرڪ جي بنياد تي ڪڍيل نقشي مان ڊيٽا. اهي ميٽرڪس لوڪي ڏانهن نه موڪليا ويا آهن - اهي ظاهر ٿيندا آهن 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']

۽ اسان هڪ گراف ٺاهي:

هن طريقي سان توهان ڳولي سگهو ٿا، مثال طور، چار سست ترين سوال. توھان پڻ سيٽ ڪري سگھوٿا انھن ميٽرڪ لاءِ مانيٽرنگ.

اسڪيلنگ

لوڪ يا ته ٿي سگهي ٿو اڪيلو بائنري موڊ ۾ يا شارڊ ٿيل موڊ ۾ (افقي طور تي اسڪيلبل موڊ). ٻئين صورت ۾، اهو بادل تي ڊيٽا محفوظ ڪري سگهي ٿو، ۽ ٽڪر ۽ انڊيڪس الڳ الڳ محفوظ ٿيل آهن. نسخو 1.5 هڪ جڳهه تي ذخيرو ڪرڻ جي صلاحيت متعارف ڪرايو آهي، پر اهو اڃا تائين ان کي پيداوار ۾ استعمال ڪرڻ جي سفارش ناهي.

حصن کي S3-مطابقت رکندڙ اسٽوريج ۾ ذخيرو ڪري سگھجي ٿو، ۽ افقي طور تي اسپيبلبل ڊيٽابيس انڊيڪس کي ذخيرو ڪرڻ لاء استعمال ڪري سگھجن ٿيون: Cassandra، BigTable يا DynamoDB. لوڪي جا ٻيا حصا - تقسيم ڪندڙ (لکڻ لاءِ) ۽ ڪوئرر (سوالن لاءِ) - بي رياست آهن ۽ افقي طور تي ماپيل آهن.

DevOpsDays Vancouver 2019 ڪانفرنس ۾، شرڪت ڪندڙن مان هڪ ڪالم اسٽيان اعلان ڪيو ته لوڪي سان هن جي پروجيڪٽ ۾ لاگس جا پيٽابائيٽس آهن جن جي انڊيڪس ڪل سائيز جي 1٪ کان گهٽ آهي: “ڪيئن لوڪي ميٽرڪ ۽ لاگز سان تعلق رکي ٿو - ۽ توهان کي پئسا بچائي ٿو".

لوڪي ۽ ELK جو مقابلو

انڊيڪس سائيز

نتيجن واري انڊيڪس سائيز کي جانچڻ لاءِ، مون نينڪس ڪنٽينر مان لاگز کنيا، جن لاءِ مٿي ڏنل پائپ لائن ترتيب ڏنل هئي. لاگ فائل ۾ 406 لائينون شامل آھن جن جو ڪل حجم 624 MB آھي. لاگز هڪ ڪلاڪ اندر ٺاهيا ويا، لڳ ڀڳ 109 داخلائون في سيڪنڊ.

لاگ مان ٻن لائينن جو مثال:

جڏهن ELK پاران ترتيب ڏنل، هن هڪ انڊيڪس سائيز 30,3 MB ڏني:

لوڪي جي صورت ۾، ان جي نتيجي ۾ تقريبن 128 KB انڊيڪس ۽ تقريبن 3,8 MB ڊيٽا حصن ۾. اهو قابل ذڪر آهي ته لاگ ان مصنوعي طور تي ٺاهي وئي هئي ۽ ڊيٽا جي وڏي قسم نه هئي. اصل ڊاکر JSON لاگ تي هڪ سادي gzip ڊيٽا سان گڏ 95,4٪ جو ڪمپريشن ڏنو، ۽ انهي حقيقت کي نظر ۾ رکندي ته صرف صاف ٿيل نينڪس لاگ لوڪي ڏانهن موڪليو ويو هو، 4 MB تائين ڪمپريشن سمجهي سگهجي ٿو. لوڪي ليبلز لاءِ منفرد قدرن جو ڪل تعداد 35 هو، جيڪو انڊيڪس جي ننڍڙي سائيز کي بيان ڪري ٿو. ELK لاءِ لاگ پڻ صاف ڪيو ويو. اهڙيء طرح، لوڪي اصل ڊيٽا کي 96٪، ۽ ELK پاران 70٪ کي دٻايو.

ياداشت جي استعمال

جيڪڏهن اسان پوري پروميٿيوس ۽ اي ايل ڪي اسٽيڪ جو مقابلو ڪريون ٿا، ته پوءِ لوڪ ”کائي“ ڪيترائي ڀيرا گهٽ. اهو واضح آهي ته هڪ گو سروس جاوا سروس کان گهٽ استعمال ڪري ٿي، ۽ JVM Heap Elasticsearch ۽ Loki لاءِ مختص ڪيل ياداشت جي ماپ جو مقابلو ڪرڻ غلط آهي، پر ان جي باوجود اهو قابل ذڪر آهي ته لوڪي تمام گهٽ ميموري استعمال ڪري ٿي. ان جو سي پي يو فائدو ايترو واضح ناهي، پر اهو پڻ موجود آهي.

اسپيڊ

لوڪي ”ڀڄي ٿو“ لاگ تيزيءَ سان. رفتار ڪيترن ئي عنصر تي منحصر آهي - ڪهڙي قسم جا لاگ آهن، اسان انهن کي پارس ڪرڻ ۾ ڪيترو نفيس آهيون، نيٽ ورڪ، ڊسڪ، وغيره - پر اهو ضرور ELK کان وڌيڪ آهي (منهنجي ٽيسٽ ۾ - اٽڪل ٻه ڀيرا وڌيڪ). اها حقيقت اها وضاحت ڪئي وئي آهي ته لوڪي انڊيڪس ۾ تمام گهٽ ڊيٽا رکي ٿو ۽، مطابق، انڊيڪس تي گهٽ وقت خرچ ڪري ٿو. ڳولا جي رفتار سان، صورتحال ان جي ابتڙ آهي: لوڪي خاص طور تي ڪيترن ئي گيگا بائيٽ کان وڏي ڊيٽا تي سست ٿئي ٿي، جڏهن ته ELK جي ڳولا جي رفتار ڊيٽا جي سائيز تي منحصر ناهي.

لاگن ذريعي ڳولھيو

Loki لاگ سرچ جي صلاحيتن جي لحاظ کان ELK کان تمام گھٽ آھي. باقاعده اظهار سان Grep طاقتور آهي، پر اهو هڪ بالغ ڊيٽابيس کان گهٽ آهي. رينج جي سوالن جي کوٽ، صرف ليبلز جي ذريعي گڏ ڪرڻ، ليبل جي بغير ڳولڻ جي ناڪامي - هي سڀ اسان کي لوڪ ۾ دلچسپي جي معلومات جي ڳولا ۾ محدود ڪري ٿو. ان جو مطلب اهو ناهي ته لوڪي استعمال ڪندي ڪجھ به نه ملي سگهي ٿو، پر اهو لاگز سان ڪم ڪرڻ جي وهڪري کي بيان ڪري ٿو جڏهن توهان پهريون ڀيرو پروميٿيس چارٽس ۾ ڪو مسئلو ڳوليندا آهيو، ۽ پوء اهي ليبل استعمال ڪريو لاگ ان ۾ ڇا ٿيو آهي.

انٽرفيس

سڀ کان پهريان، اهو خوبصورت آهي (معاف ڪجو، مزاحمت نه ٿي سگهي). گرافانا هڪ ​​سٺو ڏسڻ وارو انٽرفيس آهي، پر ڪبانا تمام گهڻي خاصيت سان مالا مال آهي.

لوڪي جا فائدا ۽ نقصان

هڪ فائدو اهو آهي ته لوڪي پروميٿيوس سان ضم ٿي وڃي ٿي، تنهنڪري اسان کي باڪس مان ميٽرڪس ۽ خبرداري حاصل ٿئي ٿي. اهو لاگ گڏ ڪرڻ ۽ انهن کي ڪبرنيٽس پوڊس مان محفوظ ڪرڻ لاءِ آسان آهي، ڇاڪاڻ ته ان ۾ سروس دريافت آهي جيڪا پروميٿيس کان ورثي ۾ ملي ٿي ۽ خودڪار طور تي ليبل ڳنڍي ٿي.

ڪمزور دستاويز آهي. ڪجھ شيون، مثال طور، Promtail جون خاصيتون ۽ صلاحيتون، مون صرف ڪوڊ جي مطالعي جي عمل ۾ دريافت ڪيو، خوش قسمتي سان اھو کليل ذريعو آھي. هڪ ٻيو نقصان ڪمزور تجزيي جي صلاحيت آهي. مثال طور، Loki گھڻن لائن لاگن کي پارس نٿو ڪري سگھي. ٻيو نقصان اهو آهي ته لوڪي هڪ نسبتا نوجوان ٽيڪنالاجي آهي (رليز 1.0 نومبر 2019 ۾ هو).

ٿڪل

Loki هڪ 100٪ دلچسپ ٽيڪنالاجي آهي جيڪا ننڍي ۽ وچولي درجي جي منصوبن لاءِ موزون آهي، جيڪا توهان کي لاگ ايگريگيشن، لاگ سرچ، مانيٽرنگ ۽ لاگ تجزيو جا ڪيترائي مسئلا حل ڪرڻ جي اجازت ڏئي ٿي.

اسان Badoo ۾ Loki استعمال نٿا ڪريون ڇاڪاڻ ته اسان وٽ هڪ ELK اسٽيڪ آهي جيڪو اسان لاءِ مناسب آهي ۽ جيڪو ڪيترن سالن کان مختلف ڪسٽم حلن سان وڌي ويو آهي. اسان لاءِ، ٺڳيءَ وارو بلاڪ لاگن ذريعي ڳولي رهيو آهي. هر روز لڳ ڀڳ 100 GB لاگ ان سان، اهو ضروري آهي ته اسان لاءِ سڀ ڪجهه ڳولڻ جي قابل ٿي وڃون ۽ ٿورڙو وڌيڪ ۽ جلدي ڪريو. چارٽنگ ۽ مانيٽرنگ لاءِ، اسان ٻيا حل استعمال ڪريون ٿا جيڪي اسان جي ضرورتن مطابق ۽ ھڪ ٻئي سان ضم ٿيل آھن. لوڪي اسٽيڪ جا خاص فائدا آهن، پر اهو اسان کي ان کان وڌيڪ نه ڏيندو جيڪو اسان وٽ اڳ ۾ ئي آهي، ۽ ان جا فائدا يقيني طور تي لڏپلاڻ جي قيمت کان وڌيڪ نه هوندا.

۽ جيتوڻيڪ تحقيق کان پوءِ اهو واضح ٿيو ته اسان لوڪي استعمال نٿا ڪري سگهون، اسان کي اميد آهي ته هي پوسٽ توهان جي پسند ۾ مدد ڪندي.

آرٽيڪل ۾ استعمال ڪيل ڪوڊ سان گڏ مخزن واقع آهي هتي.

جو ذريعو: www.habr.com