في المشهد الحديث لتطوير التطبيقات، ليست الملاحظة مجرد رفاهية؛ بل هي ضرورة. بينما توفر المقاييس والأثر رؤى قيمة حول أداء النظام، تقدم السجلات السياق التفصيلي والزمني اللازم لتشخيص المشكلات المعقدة. ومع ذلك، غالباً ما تكون بيانات السجلات الخام غير منظمة، ضخمة الحجم، وصعبة الاستعلام. هنا تبرز قوة الجمع بين Grafana و Grafana Loki.
سيأخذك هذا الدليل عبر بنية مجموعة Grafana Loki، موضحاً كيفية تصور السجلات بفعالية. سنركز على الأنماط المتوسطة إلى المتقدمة، بما في ذلك تحليل السجلات، والتصفية بناءً على الملصقات، وبناء لوحات معلومات قابلة للتنفيذ.
فهم بنية Loki
قبل الغوص في التكوين، من الضروري فهم سبب تميز Loki عن مجموعة ELK (Elasticsearch و Logstash و Kibana). على عكس Elasticsearch، الذي يقوم بفهرسة جميع محتويات السجلات، تستخدم Loki طريقة مشابهة لـ Prometheus. فهي تقوم بفهرسة البيانات الوصفية فقط (الملصقات) وتخزين أسطر السجلات الفعلية في كتل. يؤدي هذا القرار المعماري إلى انخفاض كبير في تكاليف البنية التحتية وتحسين أداء الاستعلام لمعظم حالات الاستخدام.
المكونات الأساسية هي:
- Loki: نظام تجميع السجلات نفسه.
- Promtail: الوكيل الذي يعمل على مضيفيك أو مجموعات العناقيد، حيث يتتبع السجلات ويرسلها إلى Loki.
- Grafana: طبقة التصور التي تستعلم Loki لعرض البيانات.
تكوين Promtail للبيانات المنظمة
يعد التعامل مع النصوص غير المنظمة أحد أكبر التحديات في تصور السجلات. لجعل السجلات قابلة للاستعلام في Grafana، يجب إثراؤها بالملصقات، ومن الأفضل تحليلها إلى تنسيقات منظمة مثل JSON.
يوضح أدناه مثالاً عملياً للتكوين لملف `promtail.yaml`. يوضح هذا التكوين كيفية استهداف سجلات Kubernetes، واستخراج ملصقات محددة، وتحليل حمولات JSON من الإخراج القياسي للتطبيق.
server:
http_listen_port: 9080
grpc_listen_port: 0
positions:
filename: /tmp/positions.yaml
clients:
- url: http://loki:3100/loki/api/v1/push
scrape_configs:
- job_name: kubernetes-pods
kubernetes_sd_configs:
- role: pod
# إعادة التسمية لاستخراج البيانات الوصفية
relabel_configs:
- source_labels: [__meta_kubernetes_pod_label_app]
target_label: app
- source_labels: [__meta_kubernetes_namespace]
target_label: namespace
# تحليل سجلات JSON لتحسين التصور
pipeline_stages:
- json:
expressions:
level: level
message: msg
trace_id: traceID
من خلال استخراج `level` و `message` و `trace_id` إلى حقول، يمكن لـ Grafana عرضها كأعمدة أو عوامل تصفية محددة، مما يحسن تجربة المستخدم للمطورين الذين يعالجون المشكلات بشكل كبير.
كتابة استعلامات سجلات فعالة
بمجرد تدفق سجلاتك إلى Loki، تحتاج إلى معرفة كيفية استعلامها بفعالية. تستخدم Loki صيغة LogQL التي تجمع بين محددات التدفق ومعالجات تدفق السجلات.
يبدو الاستعلام الأساسي كالتالي:
{app="frontend", namespace="production"}
هذا يعيد جميع السجلات لتطبيق الواجهة الأمامية في مساحة الاسم الإنتاجية. لجعل هذه البيانات مفيدة، يجب أن تسلسل معالجات تدفق السجلات. على سبيل المثال، لتصفية الأخطاء الحرجة فقط:
{app="frontend", namespace="production"} |~ "ERROR"
يستخدم المشغل `|~` مطابقة التعبيرات النمطية. للتصفية الأكثر تعقيداً، يمكنك استخراج الحقول التي تم تحليلها في الخطوة السابقة:
{app="frontend", namespace="production"} | json | level="error"
فهم هذه الأنابيب يتيح لك إنشاء لوحات معلومات ديناميكية حيث يمكن للمستخدمين التبديل بين سجلات التحذير والأخطاء بسلاسة.
بناء لوحات معلومات قابلة للتنفيذ
التصور هو الخطوة الأخيرة. في Grafana، يمكنك إنشاء لوحة معلومات وإضافة لوحة "سجلات". تكمن القوة الحقيقية في ربط المقاييس بالسجلات. من خلال تكوين روابط اللوحات، يمكنك النقر على ارتفاع في مقياس استخدام وحدة المعالجة المركزية والتنقل فوراً في سجلات الأخطاء المقابلة باستخدام استبدال المتغيرات.
على سبيل المثال، إذا كان لديك لوحة تظهر تأخيراً عالياً في الطلبات، يمكنك إضافة رابط يقوم تلقائياً بتصفية السجلات بنفس نطاق الوقت وعلامة الخدمة، مما يوفر سياقاً فورياً للشذوذ.
الخاتمة
يحول تصور السجلات باستخدام Grafana و Loki تدفقات النصوص الفوضوية إلى أصول منظمة وقابلة للاستعلام. من خلال الاستفادة من التسمية المناسبة، وتحليل JSON، واستعلامات LogQL الفعالة، يمكن للمطورين ومهندسي الموثوقية (SREs) تقليل متوسط وقت الإصلاح (MTTR) بشكل كبير. بينما يتطلب الإعداد الأولي انتباهاً للتفاصيل، فإن الفوائد طويلة المدى في توفير التكاليف والكفاءة التشغيلية تجعله خياراً قوياً لاستراتيجيات الملاحظة الحديثة. ابدأ بتنفيذ تسجيل منظم في تطبيقاتك، وشاهد كيف يتطور سير عمل التصحيح الخاص بك من إطفاء الحرائق التفاعلي إلى التحليل الاستباقي.