تجميع السجلات من 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&amp;item_id=34234 HTTP/1.1" 500 8102 "-" "Stub_Bot/3.0" "0.001"

تقوم الأنظمة التقليدية بتحليل الصف بأكمله ، بما في ذلك الحقول التي تحتوي على العديد من قيم user_id و item_id الفريدة ، وتخزين كل شيء في فهارس كبيرة. تتمثل ميزة هذا الأسلوب في أنه يمكنك تشغيل الاستعلامات المعقدة بسرعة ، نظرًا لأن جميع البيانات تقريبًا موجودة في الفهرس. لكن عليك أن تدفع ثمن ذلك لأن الفهرس يصبح كبيرًا ، وهو ما يترجم إلى متطلبات الذاكرة. ونتيجة لذلك ، فإن فهرس النص الكامل للسجلات يمكن مقارنته من حيث الحجم بالسجلات نفسها. من أجل البحث بسرعة فيه ، يجب تحميل الفهرس في الذاكرة. وكلما زاد عدد السجلات ، زادت سرعة المؤشر وزادت مساحة الذاكرة التي يستهلكها.

يتطلب نهج Loki استخراج البيانات الضرورية فقط من السلسلة ، وعدد قيمها صغير. بهذه الطريقة نحصل على فهرس صغير ويمكننا البحث في البيانات عن طريق تصفيتها حسب الوقت والحقول المفهرسة ، ثم مسح الباقي باستخدام التعبيرات العادية أو عمليات البحث عن السلاسل الفرعية. لا تبدو العملية الأسرع ، لكن Loki يقسم الطلب إلى عدة أجزاء وينفذها بالتوازي ، ومعالجة كمية كبيرة من البيانات في وقت قصير. عدد القطع والطلبات المتوازية فيها قابل للتكوين ؛ وبالتالي ، فإن كمية البيانات التي يمكن معالجتها لكل وحدة زمنية تعتمد خطيًا على مقدار الموارد المتوفرة.

تسمح هذه المفاضلة بين مؤشر سريع كبير ومؤشر صغير للقوة الغاشمة المتوازية لـ Loki بالتحكم في تكلفة النظام. يمكن تكوينه وتوسيعه بمرونة وفقًا لاحتياجاتك.

تتكون مجموعة Loki من ثلاثة مكونات: Promtail و Loki و Grafana. يقوم Promtail بجمع السجلات ومعالجتها وإرسالها إلى Loki. لوكي يحتفظ بهم. ويمكن لـ Grafana طلب البيانات من Loki وإظهارها. بشكل عام ، يمكن استخدام Loki ليس فقط لتخزين السجلات والبحث فيها. يوفر المكدس بأكمله فرصًا رائعة لمعالجة البيانات الواردة وتحليلها باستخدام طريقة Prometheus.
يمكن العثور على وصف لعملية التثبيت هنا.

بحث في السجل

يمكنك البحث في السجلات في واجهة خاصة Grafana - Explorer. تستخدم الاستعلامات لغة LogQL ، والتي تشبه إلى حد بعيد لغة PromQL التي يستخدمها Prometheus. من حيث المبدأ ، يمكن اعتباره بمثابة grep موزع.

تبدو واجهة البحث كما يلي:

يتكون الاستعلام نفسه من جزأين: المحدد والتصفية. المحدِّد عبارة عن بحث عن طريق البيانات الوصفية المفهرسة (العلامات) التي يتم تعيينها للسجلات ، والمرشح عبارة عن سلسلة بحث أو تعبير عادي يقوم بتصفية السجلات المحددة بواسطة المحدد. في المثال المعطى: في الأقواس المتعرجة - المحدد ، كل شيء بعده - المرشح.

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

نظرًا للطريقة التي يعمل بها Loki ، لا يمكنك تقديم طلبات بدون محدد ، ولكن يمكن جعل الملصقات عامة بشكل تعسفي.

المحدد هو القيمة الرئيسية للقيمة في الأقواس المتعرجة. يمكنك دمج المحددات وتحديد شروط بحث مختلفة باستخدام = ،! = عوامل أو تعبيرات عادية:

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

عامل التصفية هو نص أو تعبير عادي يقوم بتصفية جميع البيانات التي يتلقاها المحدد.

من الممكن الحصول على رسوم بيانية مخصصة بناءً على البيانات المستلمة في وضع المقاييس. على سبيل المثال ، يمكنك معرفة معدل التكرار في سجلات nginx لإدخال يحتوي على سلسلة الفهرس:

يمكن العثور على وصف كامل للميزات في الوثائق LogQL.

تحليل السجل

هناك عدة طرق لتجميع السجلات:

بمساعدة Promtail ، مكون قياسي للمكدس لجمع السجلات.
مباشرة من استخدام حاوية عامل الميناء سائق Loki Docker Logging.
استخدم Fluentd أو Fluent Bit الذي يمكنه إرسال البيانات إلى Loki. على عكس Promtail ، لديهم محللون جاهزون لأي نوع من السجلات تقريبًا ويمكنهم التعامل مع السجلات متعددة الأسطر أيضًا.

عادة ما يستخدم Promtail للتحليل. يفعل ثلاثة أشياء:

يبحث عن مصادر البيانات.
إرفاق تسميات لهم.
يرسل البيانات إلى Loki.

يستطيع Promtail حاليًا قراءة السجلات من الملفات المحلية ومن مجلة systemd. يجب تثبيته على كل جهاز يتم جمع السجلات منه.

يوجد تكامل مع Kubernetes: يكتشف Promtail تلقائيًا حالة المجموعة من خلال Kubernetes REST API ويجمع السجلات من عقدة أو خدمة أو قاعدة ، وينشر الملصقات فورًا استنادًا إلى البيانات الوصفية من Kubernetes (اسم المجموعة واسم الملف وما إلى ذلك).

يمكنك أيضًا تعليق الملصقات استنادًا إلى البيانات من السجل باستخدام خط الأنابيب. يمكن أن يتكون Pipeline Promtail من أربعة أنواع من المراحل. مزيد من التفاصيل - في الوثائق الرسمية، سألاحظ على الفور بعض الفروق الدقيقة.

مراحل الاعراب. هذه هي مرحلة RegEx و JSON. في هذه المرحلة ، نقوم باستخراج البيانات من السجلات إلى ما يسمى بالخريطة المستخرجة. يمكنك الاستخراج من JSON ببساطة عن طريق نسخ الحقول التي نحتاجها في الخريطة المستخرجة ، أو من خلال التعبيرات العادية (RegEx) ، حيث يتم "تعيين" المجموعات المسماة في الخريطة المستخرجة. الخريطة المستخرجة عبارة عن مخزن ذي قيمة مفتاح ، حيث يكون المفتاح هو اسم الحقل ، والقيمة هي قيمته من السجلات.
مراحل التحول. تحتوي هذه المرحلة على خيارين: التحويل ، حيث نقوم بتعيين قواعد التحويل ، والمصدر - مصدر البيانات للتحويل من الخريطة المستخرجة. إذا لم يكن هناك مثل هذا الحقل في الخريطة المستخرجة ، فسيتم إنشاؤه. وبالتالي ، من الممكن إنشاء ملصقات لا تستند إلى الخريطة المستخرجة. في هذه المرحلة ، يمكننا معالجة البيانات الموجودة في الخريطة المستخرجة باستخدام ملف قالب golang. بالإضافة إلى ذلك ، يجب أن نتذكر أن الخريطة المستخرجة يتم تحميلها بالكامل أثناء التحليل ، مما يجعل من الممكن ، على سبيل المثال ، التحقق من القيمة الموجودة فيها: "{{if .tag} قيمة العلامة موجودة {end}}". يدعم القالب الشروط والحلقات وبعض وظائف السلسلة مثل استبدال وتقليم.
مراحل العمل. في هذه المرحلة ، يمكنك عمل شيء ما بالمستخرج:
- قم بإنشاء تسمية من البيانات المستخرجة ، والتي سيتم فهرستها بواسطة Loki.
- قم بتغيير أو تعيين وقت الحدث من السجل.
- قم بتغيير البيانات (نص السجل) التي ستنتقل إلى Loki.
- إنشاء المقاييس.
مراحل التصفية. مرحلة المطابقة ، حيث يمكننا إما إرسال السجلات التي لا نحتاج إليها / dev / null ، أو إرسالها لمزيد من المعالجة.

باستخدام مثال معالجة سجلات nginx العادية ، سأوضح كيف يمكنك تحليل السجلات باستخدام Promtail.

للاختبار ، دعنا نأخذ nginx image jwilder / nginx-proxy المعدل: alpine as nginx-proxy وخفي صغير يمكنه الاستعلام عن نفسه عبر HTTP. يحتوي البرنامج الخفي على العديد من نقاط النهاية ، حيث يمكنه تقديم ردود بأحجام مختلفة ، مع حالات HTTP مختلفة وبتأخيرات مختلفة.

سنجمع السجلات من حاويات عامل التحميل ، والتي يمكن العثور عليها على طول المسار / var / lib / docker / container / / -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 (يوجد خيار "عامل إرساء" في التكوين يقوم بنفس الشيء في سطر واحد ، ولكنه لن يكون واضحًا جدًا):

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 وقم بإعداد خط أنابيب. السجلات كالتالي:

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

نتجاهل جميع السجلات التي لا تحتوي على تسميات اسم_صورة و "اسم_حاوية".

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

باستخدام عوامل التشغيل الشرطية في القالب ، نتحقق من الحقول المثبتة في الخريطة المستخرجة وقمنا بتعيين القيم المطلوبة لحقل نوع_الطلب: صورة ، ثابتة ، واجهة برمجة التطبيقات. تعيين أخرى إذا فشلت. الآن request_type يحتوي على نوع الطلب.

       - labels:
           api_request:
           virtual_host:
           request_type:
           status:

قمنا بتعيين التسميات api_request و virtual_host و request_type و status (حالة HTTP) بناءً على ما تمكنا من وضعه في الخريطة المستخرجة.

       - output:
           source: nginx_log_row

تغيير الإخراج. الآن ينتقل سجل nginx الذي تم تنظيفه من الخريطة المستخرجة إلى Loki.

بعد تشغيل التكوين أعلاه ، يمكنك أن ترى أن كل إدخال تم تسميته بناءً على البيانات من السجل.

ضع في اعتبارك أن استخراج الملصقات التي تحتوي على عدد كبير من القيم (العلاقة الأساسية) يمكن أن يبطئ Loki بشكل كبير. وهذا يعني أنه لا يجب أن تضع في الفهرس ، على سبيل المثال ، user_id. اقرأ المزيد عن هذا في المقالكيف يمكن للتسميات في Loki أن تجعل استعلامات السجل أسرع وأسهل". لكن هذا لا يعني أنه لا يمكنك البحث عن طريق user_id بدون فهارس. من الضروري استخدام عوامل التصفية عند البحث ("الاستيلاء" وفقًا للبيانات) ، ويعمل الفهرس هنا كمعرف دفق.

تصور السجل

يمكن أن يعمل Loki كمصدر بيانات لمخططات Grafana باستخدام LogQL. الميزات التالية مدعومة:

المعدل - عدد السجلات في الثانية ؛
العد بمرور الوقت - عدد السجلات في النطاق المحدد.

هناك أيضًا دالات تجميعية Sum و Avg وغيرها. يمكنك إنشاء رسوم بيانية معقدة للغاية ، على سبيل المثال ، رسم بياني لعدد أخطاء HTTP:

يعد مصدر بيانات Loki الافتراضي أقل فاعلية من مصدر بيانات Prometheus (على سبيل المثال ، لا يمكنك تغيير وسيلة الإيضاح) ، ولكن يمكن توصيل Loki كمصدر من نوع Prometheus. لست متأكدًا مما إذا كان هذا سلوكًا موثقًا ، ولكن بالحكم على رد المطورين "كيفية تكوين Loki كمصدر بيانات بروميثيوس؟ · العدد رقم 1222 · grafana / loki"، على سبيل المثال ، إنه قانوني تمامًا كما أن Loki متوافق تمامًا مع PromQL.

أضف Loki كمصدر بيانات بكتابة Prometheus وألحق URL / loki:

ويمكنك عمل رسوم بيانية ، كما لو كنا نعمل بمقاييس من بروميثيوس:

أعتقد أن التناقض في الوظائف مؤقت وسيقوم المطورون بإصلاحه في المستقبل.

المقاييس

يوفر 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

يتيح لك الخيار تحديد المقاييس وتحديثها استنادًا إلى البيانات من الخريطة المستخرجة. لا يتم إرسال هذه المقاييس إلى Loki - فهي تظهر في نقطة نهاية Promtail / metrics. يجب تكوين بروميثيوس لتلقي البيانات من هذه المرحلة. في المثال أعلاه ، بالنسبة إلى 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']

وارسم رسم بياني:

بهذه الطريقة يمكنك معرفة ، على سبيل المثال ، أبطأ أربعة طلبات. يمكنك أيضًا تكوين المراقبة لهذه المقاييس.

تدريج

يمكن أن يكون Loki في كل من الوضع الثنائي الفردي والمشترك (الوضع القابل للتحجيم أفقيًا). في الحالة الثانية ، يمكنه حفظ البيانات في السحابة ، ويتم تخزين القطع والفهرس بشكل منفصل. في الإصدار 1.5 ، يتم تنفيذ القدرة على التخزين في مكان واحد ، ولكن لا يوصى باستخدامها في الإنتاج بعد.

يمكن تخزين القطع في تخزين متوافق مع S3 ، ويمكن استخدام قواعد البيانات القابلة للتوسع أفقيًا لتخزين الفهارس: Cassandra أو BigTable أو DynamoDB. أجزاء أخرى من Loki - الموزعون (للكتابة) و Querier (للاستعلامات) - عديمة الجنسية وأيضًا مقياس أفقي.

في مؤتمر DevOpsDays Vancouver 2019 ، أعلن أحد المشاركين Callum Styan أنه مع Loki يحتوي مشروعه على بيتابايت من السجلات بمؤشر أقل من 1٪ من الحجم الإجمالي: "كيف يربط Loki المقاييس والسجلات - ويوفر لك المال".

مقارنة بين Loki و ELK

حجم الفهرس

لاختبار حجم الفهرس الناتج ، أخذت سجلات من حاوية nginx التي تم تكوين خط الأنابيب أعلاه من أجلها. احتوى ملف السجل على 406 سطرًا بحجم إجمالي يبلغ 624 ميجابايت. تم إنشاء السجلات في غضون ساعة ، ما يقرب من 109 سجل في الثانية.

مثال على سطرين من السجل:

عند فهرستها بواسطة ELK ، أعطى هذا حجم فهرس يبلغ 30,3 ميجابايت:

في حالة Loki ، أعطى هذا حوالي 128 كيلوبايت من الفهرس وحوالي 3,8 ميغابايت من البيانات في أجزاء. من الجدير بالذكر أن السجل تم إنشاؤه بشكل مصطنع ولا يحتوي على مجموعة متنوعة من البيانات. أعطى ملف gzip البسيط الموجود في سجل Docker JSON الأصلي مع البيانات ضغطًا بنسبة 95,4٪ ، وبالنظر إلى أنه تم إرسال سجل nginx الذي تم تنظيفه فقط إلى Loki نفسه ، فإن الضغط إلى 4 ميغابايت أمر مفهوم. كان العدد الإجمالي للقيم الفريدة لملصقات Loki 35 ، وهو ما يفسر الحجم الصغير للفهرس. بالنسبة لـ ELK ، تم أيضًا مسح السجل. وهكذا ، ضغط Loki البيانات الأصلية بنسبة 96٪ ، و ELK بنسبة 70٪.

استهلاك الذاكرة

إذا قارنا مجموعة بروميثيوس وإيلك بأكملها ، فإن لوكي "يأكل" عدة مرات أقل. من الواضح أن خدمة Go تستهلك أقل من خدمة Java ، ومقارنة حجم Heap Elasticsearch JVM والذاكرة المخصصة لـ Loki غير صحيحة ، ولكن مع ذلك ، تجدر الإشارة إلى أن Loki يستخدم ذاكرة أقل بكثير. ميزة وحدة المعالجة المركزية الخاصة بها ليست واضحة جدًا ، ولكنها موجودة أيضًا.

سرعة

Loki "يلتهم" السجلات بشكل أسرع. تعتمد السرعة على العديد من العوامل - أي نوع من السجلات ، ومدى تعقيد تحليلنا لها ، والشبكة ، والقرص ، وما إلى ذلك - لكنها بالتأكيد أعلى من سرعة ELK (في الاختبار الذي أجريته - مرتين تقريبًا). يفسر ذلك حقيقة أن Loki يضع بيانات أقل بكثير في الفهرس ، وبالتالي ، يقضي وقتًا أقل في الفهرسة. في هذه الحالة ، يتم عكس الموقف مع سرعة البحث: يتباطأ Loki بشكل ملحوظ على البيانات الأكبر من بضعة غيغابايت ، بينما بالنسبة لـ ELK ، لا تعتمد سرعة البحث على حجم البيانات.

بحث في السجل

Loki أدنى بكثير من ELK من حيث إمكانيات البحث في السجل. يعد Grep مع التعبيرات النمطية أمرًا قويًا ، ولكنه أدنى من قاعدة بيانات البالغين. عدم وجود استعلامات النطاق ، والتجميع فقط من خلال التسميات ، وعدم القدرة على البحث بدون تسميات - كل هذا يحد من البحث عن المعلومات التي تهم Loki. هذا لا يعني أنه لا يمكن العثور على أي شيء باستخدام Loki ، ولكنه يحدد تدفق العمل مع السجلات ، عندما تجد مشكلة في مخططات Prometheus لأول مرة ، ثم ابحث عما حدث في السجلات باستخدام هذه التسميات.

السطح البيني

أولاً ، إنه جميل (آسف ، لم أستطع المقاومة). يتمتع Grafana بواجهة جميلة المظهر ، لكن Kibana أكثر فاعلية.

إيجابيات وسلبيات لوكي

من بين الإيجابيات ، يمكن ملاحظة أن Loki يتكامل مع Prometheus ، على التوالي ، نحصل على مقاييس وتنبيه خارج الصندوق. إنه ملائم لجمع السجلات وتخزينها باستخدام Kubernetes Pods ، حيث يحتوي على اكتشاف خدمة موروث من Prometheus ويقوم بإرفاق الملصقات تلقائيًا.

من السلبيات - وثائق رديئة. بعض الأشياء ، مثل ميزات وقدرات Promtail ، اكتشفتها فقط في عملية دراسة الكود ، فائدة المصادر المفتوحة. عيب آخر هو ضعف قدرات التحليل. على سبيل المثال ، لا يمكن لـ Loki تحليل السجلات متعددة الأسطر. أيضًا ، تشمل العيوب حقيقة أن Loki هي تقنية حديثة نسبيًا (الإصدار 1.0 كان في نوفمبر 2019).

اختتام

Loki هي تقنية مثيرة للاهتمام بنسبة 100٪ وهي مناسبة للمشاريع الصغيرة والمتوسطة ، مما يسمح لك بحل العديد من مشاكل تجميع السجلات ، والبحث في السجلات ، ومراقبة السجلات وتحليلها.

نحن لا نستخدم Loki في Badoo ، لأن لدينا مجموعة ELK التي تناسبنا والتي تم تضخيمها مع العديد من الحلول المخصصة على مر السنين. بالنسبة لنا ، فإن حجر العثرة هو البحث في السجلات. مع وجود ما يقرب من 100 غيغابايت من السجلات يوميًا ، من المهم بالنسبة لنا أن نكون قادرين على العثور على كل شيء وأكثر قليلاً والقيام بذلك بسرعة. للرسم والمراقبة ، نستخدم حلولًا أخرى مصممة خصيصًا لاحتياجاتنا ومتكاملة مع بعضها البعض. تتمتع مكدس Loki بفوائد ملموسة ، لكنها لن تمنحنا أكثر مما لدينا ، ولن تفوق فوائدها تكلفة الهجرة تمامًا.

وعلى الرغم من أنه تبين بعد البحث أنه لا يمكننا استخدام Loki ، نأمل أن تساعدك هذه المشاركة في الاختيار.

يقع المستودع الذي يحتوي على الكود المستخدم في المقالة هنا.

المصدر: www.habr.com

جمع السجلات من Loki