لوکی سے نوشتہ جات جمع کرنا

Badoo میں، ہم نئی ٹیکنالوجیز کی مسلسل نگرانی کرتے ہیں اور اس بات کا جائزہ لیتے ہیں کہ آیا وہ ہمارے سسٹم میں استعمال کرنے کے قابل ہیں یا نہیں۔ ہم ان میں سے ایک مطالعہ کمیونٹی کے ساتھ شیئر کرنا چاہیں گے۔ یہ لوکی کے لیے وقف ہے، ایک لاگ ایگریگیشن سسٹم۔

لوکی لاگز کو ذخیرہ کرنے اور دیکھنے کا ایک حل ہے، اور یہ اسٹیک ان کا تجزیہ کرنے اور پرومیتھیس کو ڈیٹا بھیجنے کے لیے ایک لچکدار نظام بھی فراہم کرتا ہے۔ مئی میں، ایک اور اپ ڈیٹ جاری کیا گیا تھا، جسے تخلیق کاروں نے فعال طور پر فروغ دیا ہے. ہم اس بات میں دلچسپی رکھتے تھے کہ لوکی کیا کر سکتا ہے، یہ کیا صلاحیتیں فراہم کرتا ہے، اور یہ کس حد تک ELK کے متبادل کے طور پر کام کر سکتا ہے، اس اسٹیک جو ہم اب استعمال کرتے ہیں۔

لوکی کیا ہے؟

گرافانا لوکی لاگز کے ساتھ کام کرنے کے لیے ایک مکمل نظام کے اجزاء کا ایک مجموعہ ہے۔ دوسرے اسی طرح کے نظاموں کے برعکس، لوکی صرف لاگ میٹا ڈیٹا - لیبلز (پرومیتھیس کی طرح) کی اشاریہ سازی کے خیال پر مبنی ہے، اور خود کو الگ الگ ٹکڑوں میں لاگوں کو سکیڑتا ہے۔

ہوم پیج, GitHub کے

اس سے پہلے کہ ہم اس بات پر غور کریں کہ آپ لوکی کے ساتھ کیا کر سکتے ہیں، میں یہ واضح کرنا چاہتا ہوں کہ "صرف میٹا ڈیٹا کو انڈیکس کرنے کے خیال" سے ہمارا کیا مطلب ہے۔ آئیے nginx لاگ سے لائن کی مثال کا استعمال کرتے ہوئے، روایتی حل جیسے Elasticsearch میں Loki نقطہ نظر اور اشاریہ سازی کے نقطہ نظر کا موازنہ کریں:

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 قدروں والے فیلڈز، اور ہر چیز کو بڑے انڈیکس میں اسٹور کرتے ہیں۔ اس نقطہ نظر کا فائدہ یہ ہے کہ آپ پیچیدہ سوالات کو تیزی سے چلا سکتے ہیں، کیونکہ تقریباً تمام ڈیٹا انڈیکس میں ہے۔ لیکن یہ اس قیمت پر آتا ہے کہ انڈیکس بڑا ہو جاتا ہے، جو میموری کی ضروریات میں ترجمہ کرتا ہے۔ نتیجے کے طور پر، مکمل متن لاگ انڈیکس سائز میں خود لاگز کے مقابلے میں ہے۔ اس کے ذریعے تیزی سے تلاش کرنے کے لیے، انڈیکس کو میموری میں لوڈ کیا جانا چاہیے۔ اور جتنے زیادہ لاگ، انڈیکس اتنی ہی تیزی سے بڑھتا ہے اور اتنی ہی زیادہ میموری استعمال کرتا ہے۔

لوکی اپروچ کا تقاضا ہے کہ صرف ضروری ڈیٹا ہی ایک تار سے نکالا جائے، جس کی قدروں کی تعداد کم ہو۔ اس طرح ہمیں ایک چھوٹا انڈیکس ملتا ہے اور ڈیٹا کو وقت کے لحاظ سے اور انڈیکسڈ فیلڈز کے ذریعے فلٹر کرکے اور پھر باقی کو ریگولر ایکسپریشنز یا سبسٹرنگ سرچ کے ساتھ اسکین کرکے تلاش کرسکتے ہیں۔ یہ عمل سب سے تیز نہیں لگتا ہے، لیکن لوکی درخواست کو کئی حصوں میں تقسیم کرتا ہے اور انہیں متوازی طور پر عمل میں لاتا ہے، بہت کم وقت میں ڈیٹا کی ایک بڑی مقدار پر کارروائی کرتا ہے۔ ان میں شارڈز اور متوازی درخواستوں کی تعداد قابل ترتیب ہے۔ اس طرح، ڈیٹا کی مقدار جس پر وقت کی فی یونٹ کارروائی کی جا سکتی ہے، فراہم کردہ وسائل کی مقدار پر خطی طور پر منحصر ہے۔

ایک بڑے، تیز انڈیکس اور ایک چھوٹے، متوازی بروٹ فورس انڈیکس کے درمیان یہ تجارت لوکی کو سسٹم کی لاگت کو کنٹرول کرنے کی اجازت دیتی ہے۔ اسے لچکدار طریقے سے ترتیب دیا جا سکتا ہے اور ضروریات کے مطابق بڑھایا جا سکتا ہے۔

لوکی اسٹیک تین اجزاء پر مشتمل ہے: پرومٹیل، لوکی، گرافانا۔ پرومٹیل لاگز کو جمع کرتا ہے، ان پر کارروائی کرتا ہے اور انہیں لوکی کو بھیجتا ہے۔ لوکی انہیں رکھتا ہے۔ اور گرافانا لوکی سے ڈیٹا کی درخواست کر سکتا ہے اور اسے ڈسپلے کر سکتا ہے۔ عام طور پر، لوکی کو نہ صرف لاگز کو ذخیرہ کرنے اور ان کے ذریعے تلاش کرنے کے لیے استعمال کیا جا سکتا ہے۔ پورا اسٹیک Prometheus طریقہ کا استعمال کرتے ہوئے آنے والے ڈیٹا کی پروسیسنگ اور تجزیہ کرنے کے بہترین مواقع فراہم کرتا ہے۔
تنصیب کے عمل کی تفصیل مل سکتی ہے۔ یہاں.

نوشتہ جات کے ذریعے تلاش کریں۔

آپ لاگز کو ایک خاص گرافانا انٹرفیس - ایکسپلورر میں تلاش کر سکتے ہیں۔ سوالات LogQL زبان استعمال کرتے ہیں، جو Prometheus میں استعمال ہونے والے PromQL سے بہت ملتی جلتی ہے۔ اصولی طور پر، اسے تقسیم شدہ گریپ کے طور پر سوچا جا سکتا ہے۔

تلاش کا انٹرفیس اس طرح لگتا ہے:

درخواست خود دو حصوں پر مشتمل ہے: سلیکٹر اور فلٹر۔ سلیکٹر انڈیکسڈ میٹا ڈیٹا (لیبلز) کا استعمال کرتے ہوئے ایک تلاش ہے جو لاگز کو تفویض کیا جاتا ہے، اور فلٹر ایک سرچ سٹرنگ یا ریج ایکس ایکس ہے جو سلیکٹر کے ذریعہ بیان کردہ ریکارڈ کو فلٹر کرتا ہے۔ دی گئی مثال میں: گھوبگھرالی منحنی خطوط وحدانی میں ایک سلیکٹر ہوتا ہے، اس کے بعد ہر چیز فلٹر ہوتی ہے۔

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

لوکی کے کام کرنے کے طریقے کی وجہ سے، آپ سلیکٹر کے بغیر سوالات نہیں کر سکتے، لیکن لیبلز کو آپ کی مرضی کے مطابق عام بنایا جا سکتا ہے۔

سلیکٹر گھوبگھرالی منحنی خطوط وحدانی میں کلیدی قدر ہے۔ آپ سلیکٹرز کو یکجا کر سکتے ہیں اور آپریٹرز =, != یا ریگولر ایکسپریشنز کا استعمال کرتے ہوئے تلاش کے مختلف حالات بتا سکتے ہیں:

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

فلٹر ٹیکسٹ یا regexp ہے جو سلیکٹر کو موصول ہونے والے تمام ڈیٹا کو فلٹر کرے گا۔

میٹرکس موڈ میں موصولہ ڈیٹا کی بنیاد پر ایڈہاک گراف حاصل کرنا ممکن ہے۔ مثال کے طور پر، آپ یہ جان سکتے ہیں کہ سٹرنگ انڈیکس پر مشتمل ایک اندراج nginx لاگز میں کتنی بار ظاہر ہوتا ہے:

صلاحیتوں کی مکمل تفصیل دستاویزات میں مل سکتی ہے۔ لاگ کیو ایل.

لاگ پارسنگ

نوشتہ جات جمع کرنے کے کئی طریقے ہیں:

• لاگز کو جمع کرنے کے لیے اسٹیک کا ایک معیاری جزو Promtail استعمال کرنا۔
• براہ راست استعمال کرتے ہوئے ڈوکر کنٹینر سے لوکی ڈوکر لاگنگ ڈرائیور۔
• Fluentd یا Fluent Bit استعمال کریں، جو Loki کو ڈیٹا بھیج سکتا ہے۔ Promtail کے برعکس، ان کے پاس تقریباً کسی بھی قسم کے لاگ کے لیے ریڈی میڈ پارسر ہیں اور یہ ملٹی لائن لاگز کو بھی سنبھال سکتے ہیں۔

عام طور پر پرومٹیل کو پارس کرنے کے لیے استعمال کیا جاتا ہے۔ یہ تین چیزیں کرتا ہے:

• ڈیٹا کے ذرائع تلاش کرتا ہے۔
• ان کے ساتھ لیبل منسلک کرتا ہے۔
• لوکی کو ڈیٹا بھیجتا ہے۔

فی الحال Promtail مقامی فائلوں اور systemd جرنل سے لاگز پڑھ سکتا ہے۔ اسے ہر اس مشین پر انسٹال کیا جانا چاہیے جس سے لاگز جمع کیے جاتے ہیں۔

Kubernetes کے ساتھ انضمام ہے: Promtail خود بخود، Kubernetes REST API کے ذریعے، کلسٹر کی حالت کو پہچانتا ہے اور نوڈ، سروس یا پوڈ سے لاگز اکٹھا کرتا ہے، فوری طور پر Kubernetes سے میٹا ڈیٹا کی بنیاد پر لیبل پوسٹ کرتا ہے (پوڈ کا نام، فائل کا نام، وغیرہ) .

آپ پائپ لائن کا استعمال کرتے ہوئے لاگ سے ڈیٹا کی بنیاد پر لیبل بھی لٹکا سکتے ہیں۔ پائپ لائن پرومٹیل چار قسم کے مراحل پر مشتمل ہو سکتی ہے۔ مزید تفصیلات میں سرکاری دستاویزات، میں فوری طور پر کچھ باریکیوں کو نوٹ کروں گا۔

1. مراحل کو پارس کرنا. یہ RegEx اور JSON مرحلہ ہے۔ اس مرحلے پر، ہم لاگز سے ڈیٹا کو نام نہاد نکالے گئے نقشے میں نکالتے ہیں۔ ہم JSON سے صرف نکالے گئے نقشے میں اپنی ضرورت کے فیلڈز کو کاپی کر کے، یا ریگولر ایکسپریشنز (RegEx) کے ذریعے نکال سکتے ہیں، جہاں نامزد گروپوں کو نکالے گئے نقشے میں "میپ" کیا جاتا ہے۔ نکالا ہوا نقشہ ایک کلیدی قدر کی دکان ہے، جہاں کلید فیلڈ کا نام ہے، اور قیمت لاگز سے اس کی قدر ہے۔
2. مراحل کو تبدیل کریں۔. اس مرحلے میں دو اختیارات ہیں: ٹرانسفارم، جہاں ہم تبدیلی کے اصول مرتب کرتے ہیں، اور ماخذ - نکالے گئے نقشے سے تبدیلی کے لیے ڈیٹا کا ذریعہ۔ اگر نکالے گئے نقشے میں ایسی کوئی فیلڈ نہیں ہے تو اسے بنایا جائے گا۔ اس طرح ایسے لیبل بنانا ممکن ہے جو نکالے گئے نقشے پر مبنی نہ ہوں۔ اس مرحلے پر ہم کافی طاقتور کا استعمال کرتے ہوئے نکالے گئے نقشے میں ڈیٹا کو جوڑ سکتے ہیں۔ گولانگ ٹیمپلیٹ. اس کے علاوہ، ہمیں یاد رکھنا چاہیے کہ نکالا ہوا نقشہ مکمل طور پر تجزیہ کے دوران لوڈ ہوتا ہے، جس کی وجہ سے یہ ممکن ہوتا ہے، مثال کے طور پر، اس میں موجود قدر کی جانچ کرنا: "{{if .tag}ٹیگ ویلیو موجود ہے{end}}"۔ ٹیمپلیٹ کنڈیشنز، لوپس، اور کچھ سٹرنگ فنکشنز جیسے کہ ریپلیس اور ٹرم کو سپورٹ کرتا ہے۔
3. عمل کے مراحل. اس وقت آپ نکالے گئے مواد کے ساتھ کچھ کر سکتے ہیں:
   • نکالے گئے ڈیٹا سے ایک لیبل بنائیں، جسے لوکی کے ذریعے ترتیب دیا جائے گا۔
   • لاگ سے ایونٹ کا وقت تبدیل کریں یا سیٹ کریں۔
   • ڈیٹا (لاگ ٹیکسٹ) کو تبدیل کریں جو لوکی میں جائے گا۔
   • میٹرکس بنائیں۔
4. فلٹرنگ کے مراحل. میچ کا مرحلہ، جہاں ہم یا تو اندراجات بھیج سکتے ہیں جنہیں ہمیں /dev/null کرنے کی ضرورت نہیں ہے یا انہیں مزید کارروائی کے لیے آگے بھیج سکتے ہیں۔

باقاعدہ nginx لاگ پر کارروائی کرنے کی ایک مثال استعمال کرتے ہوئے، میں دکھاؤں گا کہ آپ 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 میں شامل کریں (اس ترتیب میں ایک "docker" آپشن ہے، جو ایک ہی لائن میں ایک ہی کام کرتا ہے، لیکن یہ اتنا واضح نہیں ہوگا):

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 اور کنٹینر_نام کے لیبل نصب نہیں ہیں۔

  - 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 اور اسٹیٹس (HTTP اسٹیٹس) کو اس بنیاد پر سیٹ کیا ہے جو ہم نکالے گئے نقشے میں ڈالنے میں کامیاب ہوئے۔

       - output:
           source: nginx_log_row

آؤٹ پٹ تبدیل کریں۔ اب نکالے گئے نقشے سے صاف کیا گیا nginx لاگ لوکی کو جاتا ہے۔

مندرجہ بالا ترتیب کو چلانے کے بعد، آپ دیکھ سکتے ہیں کہ ہر اندراج کو لاگ کے ڈیٹا کی بنیاد پر لیبل تفویض کیے گئے ہیں۔

ذہن میں رکھنے کی ایک بات یہ ہے کہ بڑی تعداد میں اقدار (کارڈینلٹی) والے لیبلز کو بازیافت کرنا لوکی کو نمایاں طور پر سست کر سکتا ہے۔ یعنی، آپ کو انڈیکس میں، مثال کے طور پر user_id نہیں ڈالنا چاہیے۔ اس کے بارے میں مزید پڑھیں مضمون میںکس طرح لوکی میں لیبل لاگ کے سوالات کو تیز اور آسان بنا سکتے ہیں۔" لیکن اس کا مطلب یہ نہیں ہے کہ آپ اشاریہ جات کے بغیر user_id کے ذریعے تلاش نہیں کر سکتے۔ تلاش کرتے وقت آپ کو فلٹرز استعمال کرنے کی ضرورت ہے (ڈیٹا کو "ہتھیا لیں")، اور یہاں انڈیکس اسٹریم شناخت کنندہ کے طور پر کام کرتا ہے۔

نوشتہ جات کا تصور

Loki LogQL کا استعمال کرتے ہوئے گرافانا گرافس کے لیے ڈیٹا سورس کے طور پر کام کر سکتا ہے۔ مندرجہ ذیل خصوصیات معاون ہیں:

• شرح - فی سیکنڈ ریکارڈ کی تعداد؛
• وقت کے ساتھ شمار کریں — مخصوص رینج میں ریکارڈز کی تعداد۔

جمع کرنے کے افعال Sum، اوسط اور دیگر بھی ہیں۔ آپ کافی پیچیدہ گراف بنا سکتے ہیں، مثال کے طور پر HTTP غلطیوں کی تعداد کا گراف:

پرومیتھیس ڈیٹا سورس کے مقابلے میں معیاری ڈیٹا سورس لوکی کی فعالیت میں کچھ کمی آئی ہے (مثال کے طور پر، آپ لیجنڈ کو تبدیل نہیں کر سکتے)، لیکن لوکی کو پرومیتھیس قسم کے ذریعہ بطور ذریعہ منسلک کیا جا سکتا ہے۔ مجھے یقین نہیں ہے کہ آیا یہ دستاویزی طرز عمل ہے، لیکن ڈویلپرز کے ردعمل کے مطابقلوکی کو پرومیتھیئس ڈیٹا سورس کے بطور کنفیگر کیسے کریں؟ · شمارہ نمبر 1222 · گرافانا/لوکی"، مثال کے طور پر، مکمل طور پر قانونی ہے، اور Loki مکمل طور پر PromQL کے ساتھ مطابقت رکھتا ہے۔

لوکی کو ڈیٹا سورس کے طور پر پرومیتھیس ٹائپ کے ساتھ شامل کریں اور URL /loki شامل کریں:

اور ہم گراف بنا سکتے ہیں، گویا ہم پرومیتھیس کے میٹرکس کے ساتھ کام کر رہے ہیں:

مجھے لگتا ہے کہ فعالیت میں تضاد عارضی ہے اور ڈویلپر مستقبل میں اس کو درست کریں گے۔

میٹرکس

لوکی نوشتہ جات سے عددی میٹرکس نکالنے اور انہیں Prometheus کو بھیجنے کی صلاحیت فراہم کرتا ہے۔ مثال کے طور پر، nginx لاگ میں فی جواب بائٹس کی تعداد شامل ہوتی ہے، ساتھ ہی، معیاری لاگ فارمیٹ کی ایک خاص ترمیم کے ساتھ، جواب دینے میں جو وقت لگتا ہے سیکنڈوں میں ہوتا ہے۔ یہ ڈیٹا نکال کر پرومیتھیس کو بھیجا جا سکتا ہے۔

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

آپشن آپ کو نکالے گئے نقشے سے ڈیٹا کی بنیاد پر میٹرکس کی وضاحت اور اپ ڈیٹ کرنے کی اجازت دیتا ہے۔ یہ میٹرکس لوکی کو نہیں بھیجے جاتے ہیں - یہ پرومٹیل/میٹرکس اینڈ پوائنٹ میں ظاہر ہوتے ہیں۔ اس مرحلے پر موصول ہونے والے ڈیٹا کو حاصل کرنے کے لیے Prometheus کو ترتیب دیا جانا چاہیے۔ مندرجہ بالا مثال میں، request_type="api" کے لیے ہم ایک ہسٹوگرام میٹرک جمع کرتے ہیں۔ اس قسم کے میٹرکس کے ساتھ صد فیصد حاصل کرنا آسان ہے۔ جامد اور تصویر کے لیے، ہم اوسط کا حساب لگانے کے لیے بائٹس کا مجموعہ اور قطاروں کی تعداد جمع کرتے ہیں جن میں ہمیں بائٹس موصول ہوئے ہیں۔

میٹرکس کے بارے میں مزید پڑھیں یہاں.

Promtail پر پورٹ کھولیں:

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

یقینی بنائیں کہ promtail_custom سابقہ ​​کے ساتھ میٹرکس ظاہر ہوں:

پرومیتھیس کا قیام۔ ملازمت کی پیش کش شامل کریں:

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

اور ہم ایک گراف کھینچتے ہیں:

اس طرح آپ تلاش کر سکتے ہیں، مثال کے طور پر، چار سست ترین سوالات۔ آپ ان میٹرکس کے لیے نگرانی بھی ترتیب دے سکتے ہیں۔

اسکیلنگ

لوکی یا تو سنگل بائنری موڈ میں ہو سکتا ہے یا شارڈ موڈ (افقی طور پر توسیع پذیر موڈ) میں۔ دوسری صورت میں، یہ کلاؤڈ میں ڈیٹا کو محفوظ کر سکتا ہے، اور ٹکڑوں اور انڈیکس کو الگ سے محفوظ کیا جاتا ہے۔ ورژن 1.5 ایک جگہ پر ذخیرہ کرنے کی صلاحیت کو متعارف کرایا ہے، لیکن ابھی تک اسے پیداوار میں استعمال کرنے کی سفارش نہیں کی گئی ہے۔

ٹکڑوں کو S3-مطابقت رکھنے والے سٹوریج میں ذخیرہ کیا جا سکتا ہے، اور افقی طور پر توسیع پذیر ڈیٹا بیس کو اشاریہ جات کو ذخیرہ کرنے کے لیے استعمال کیا جا سکتا ہے: Cassandra، BigTable یا DynamoDB۔ لوکی کے دوسرے حصے - ڈسٹری بیوٹرز (تحریر کے لیے) اور کوئئیر (سوالات کے لیے) - بے ریاست ہیں اور افقی طور پر بھی پیمانہ ہیں۔

DevOpsDays Vancouver 2019 کانفرنس میں، شرکاء میں سے ایک Callum Styan نے اعلان کیا کہ Loki کے ساتھ اس کے پروجیکٹ میں لاگز کے پیٹا بائٹس ہیں جن کا انڈیکس کل سائز کے 1% سے بھی کم ہے: "لوکی کس طرح میٹرکس اور لاگز کو جوڑتا ہے - اور آپ کے پیسے بچاتا ہے۔".

لوکی اور ELK کا موازنہ

انڈیکس کا سائز

نتیجے میں آنے والے انڈیکس سائز کو جانچنے کے لیے، میں نے nginx کنٹینر سے لاگز لیے جس کے لیے اوپر کی پائپ لائن ترتیب دی گئی تھی۔ لاگ فائل میں 406 لائنیں تھیں جن کا کل حجم 624 MB ہے۔ لاگز ایک گھنٹے کے اندر تیار کیے گئے، تقریباً 109 اندراجات فی سیکنڈ۔

لاگ سے دو لائنوں کی مثال:

جب ELK کے ذریعہ ترتیب دیا گیا، تو اس نے 30,3 MB کا انڈیکس سائز دیا:

لوکی کے معاملے میں، اس کے نتیجے میں تقریباً 128 KB انڈیکس اور تقریباً 3,8 MB ڈیٹا ٹکڑوں میں حاصل ہوا۔ یہ بات قابل غور ہے کہ لاگ مصنوعی طور پر تیار کیا گیا تھا اور اس میں ڈیٹا کی ایک بڑی قسم نہیں تھی۔ ڈیٹا کے ساتھ اصل Docker JSON لاگ پر ایک سادہ gzip نے 95,4% کا کمپریشن دیا، اور اس حقیقت کو مدنظر رکھتے ہوئے کہ صرف صاف شدہ nginx لاگ ہی لوکی کو بھیجا گیا تھا، 4 MB تک کا کمپریشن سمجھ میں آتا ہے۔ لوکی لیبلز کے لیے منفرد اقدار کی کل تعداد 35 تھی، جو انڈیکس کے چھوٹے سائز کی وضاحت کرتی ہے۔ ELK کے لیے لاگ بھی صاف کر دیا گیا تھا۔ اس طرح، لوکی نے اصل ڈیٹا کو 96٪، اور ELK کو 70٪ تک کمپریس کیا۔

میموری کی کھپت

اگر ہم پورے Prometheus اور ELK اسٹیک کا موازنہ کریں تو لوکی کئی گنا کم "کھاتا ہے"۔ یہ واضح ہے کہ گو سروس جاوا سروس سے کم استعمال کرتی ہے، اور جے وی ایم ہیپ ایلسٹک سرچ کے سائز اور لوکی کے لیے مختص میموری کا موازنہ کرنا غلط ہے، لیکن اس کے باوجود یہ بات قابل غور ہے کہ لوکی بہت کم میموری استعمال کرتا ہے۔ اس کا CPU فائدہ اتنا واضح نہیں ہے، لیکن یہ بھی موجود ہے۔

رفتار

لوکی تیزی سے لاگ ان کرتا ہے۔ رفتار بہت سے عوامل پر منحصر ہے - لاگ کس قسم کے ہیں، ہم ان کو پارس کرنے میں کتنے نفیس ہیں، نیٹ ورک، ڈسک وغیرہ - لیکن یہ یقینی طور پر ELK سے زیادہ ہے (میرے ٹیسٹ میں - تقریباً دو گنا زیادہ)۔ اس کی وضاحت اس حقیقت سے ہوتی ہے کہ لوکی انڈیکس میں بہت کم ڈیٹا رکھتا ہے اور اس کے مطابق، انڈیکسنگ پر کم وقت صرف کرتا ہے۔ تلاش کی رفتار کے ساتھ، صورتحال اس کے برعکس ہے: لوکی کئی گیگا بائٹس سے بڑے ڈیٹا پر نمایاں طور پر سست ہوجاتا ہے، جب کہ ELK کی تلاش کی رفتار ڈیٹا کے سائز پر منحصر نہیں ہے۔

نوشتہ جات کے ذریعے تلاش کریں۔

Loki لاگ تلاش کی صلاحیتوں کے لحاظ سے ELK سے نمایاں طور پر کمتر ہے۔ باقاعدہ اظہار کے ساتھ گریپ طاقتور ہے، لیکن یہ ایک بالغ ڈیٹا بیس سے کمتر ہے۔ رینج کے سوالات کی کمی، صرف لیبلز کے ذریعے جمع ہونا، لیبل کے بغیر تلاش کرنے میں ناکامی - یہ سب ہمیں لوکی میں دلچسپی کی معلومات کی تلاش میں محدود کر دیتے ہیں۔ اس کا مطلب یہ نہیں ہے کہ لوکی کا استعمال کرتے ہوئے کچھ بھی نہیں پایا جا سکتا ہے، لیکن یہ لاگز کے ساتھ کام کرنے کے بہاؤ کی وضاحت کرتا ہے جب آپ کو پہلی بار Prometheus چارٹس میں کوئی مسئلہ نظر آتا ہے، اور پھر لاگز میں کیا ہوا ہے اسے دیکھنے کے لیے ان لیبلز کا استعمال کریں۔

انٹرفیس

سب سے پہلے، یہ خوبصورت ہے (معذرت، مزاحمت نہیں کر سکا)۔ گرافانا کا انٹرفیس اچھا لگ رہا ہے، لیکن کبانا بہت زیادہ خصوصیت سے بھرپور ہے۔

لوکی کے فوائد اور نقصانات

ایک فائدہ یہ ہے کہ لوکی پرومیتھیس کے ساتھ ضم ہو جاتا ہے، اس لیے ہمیں میٹرکس اور الرٹ آؤٹ آف دی باکس ملتا ہے۔ لاگز کو جمع کرنے اور انہیں Kubernetes Pods سے ذخیرہ کرنے کے لیے آسان ہے، کیونکہ اس میں سروس کی دریافت Prometheus سے وراثت میں ملی ہے اور خود بخود لیبل منسلک کر دیتی ہے۔

منفی پہلو کمزور دستاویزات ہے۔ کچھ چیزیں، مثال کے طور پر، Promtail کی خصوصیات اور صلاحیتیں، میں نے صرف کوڈ کے مطالعہ کے دوران ہی دریافت کیں، خوش قسمتی سے یہ اوپن سورس ہے۔ ایک اور نقصان کمزور تجزیہ کرنے کی صلاحیتیں ہیں۔ مثال کے طور پر، لوکی ملٹی لائن لاگز کو پارس نہیں کر سکتا۔ ایک اور نقصان یہ ہے کہ لوکی نسبتاً نوجوان ٹیکنالوجی ہے (ریلیز 1.0 نومبر 2019 میں ہوئی تھی)۔

حاصل يہ ہوا

لوکی ایک 100% دلچسپ ٹیکنالوجی ہے جو چھوٹے اور درمیانے درجے کے پروجیکٹس کے لیے موزوں ہے، جو آپ کو لاگ ایگریگیشن، لاگ سرچ، مانیٹرنگ اور لاگ انالیسس کے بہت سے مسائل کو حل کرنے کی اجازت دیتی ہے۔

ہم Badoo میں Loki کا استعمال نہیں کرتے ہیں کیونکہ ہمارے پاس ELK اسٹیک ہے جو ہمارے لیے موزوں ہے اور جو کئی سالوں میں مختلف حسب ضرورت حلوں کے ساتھ بڑھا ہوا ہے۔ ہمارے لیے ٹھوکریں نوشتہ جات میں تلاش کر رہی ہیں۔ تقریباً 100 جی بی لاگز فی دن کے ساتھ، ہمارے لیے یہ ضروری ہے کہ ہم سب کچھ اور کچھ زیادہ تلاش کر سکیں اور اسے جلدی کریں۔ چارٹنگ اور مانیٹرنگ کے لیے، ہم دوسرے حل استعمال کرتے ہیں جو ہماری ضروریات کے مطابق ہوتے ہیں اور ایک دوسرے کے ساتھ مربوط ہوتے ہیں۔ لوکی اسٹیک کے ٹھوس فوائد ہیں، لیکن یہ ہمیں اس سے زیادہ نہیں دے گا جو ہمارے پاس پہلے سے ہے، اور اس کے فوائد یقینی طور پر منتقلی کی لاگت سے زیادہ نہیں ہوں گے۔

اور اگرچہ تحقیق کے بعد یہ واضح ہو گیا کہ ہم لوکی کا استعمال نہیں کر سکتے، ہمیں امید ہے کہ یہ پوسٹ آپ کے انتخاب میں آپ کی مدد کرے گی۔

مضمون میں استعمال شدہ کوڈ کے ساتھ ذخیرہ موجود ہے۔ یہاں.

ماخذ: www.habr.com