كنا نكتشف الأعطال بالصدفة: كيف أنقذنا Prometheus و Grafana من جحيم ‘أخبرني العميل أن الموقع لا يعمل’؟

يا الله شو بتذكر هداك اليوم… كانت ليلة جمعة، والساعة حوالي 11 بالليل. كنت قاعد بحضر فيلم ومستمتع بالهدوء، وفجأة برن التلفون. على الشاشة اسم أهم عميل عنا. قلبي بلش يدق بسرعة، لأنه ما حدا برن بهيك وقت إلا لمصيبة.

فتحت الخط بصوت حاولت أخليه طبيعي: “أهلاً يا باشمهندس، خير إن شاء الله؟”. إجا الجواب اللي كنت خايف منه: “أبو عمر، الموقع واقع! شو القصة يا زلمة؟ الزباين بحكوا معي!”.

في هذيك اللحظة، طار النوم والفيلم والهدوء. ركضت على اللابتوب، وبلشت رحلة العذاب اللي كل مطور بنية تحتية بعرفها: بفوت SSH على السيرفر الأول، بكتب `top`، بشوف الحمل طبيعي. بفوت على الثاني، بشيك على مساحة القرص بـ `df -h`، كله تمام. بفتح الـ logs بـ `tail -f /var/log/nginx/error.log`، ما في شي واضح. صرت زي الأعمى اللي بدور على إبرة بكومة قش، والعميل كل خمس دقايق يرجع يرن. بعد ساعة من التخبيص والبحث العشوائي، اكتشفت إنه قاعدة البيانات عليها ضغط مش طبيعي بسبب query معينة كانت بتستهلك كل الموارد.

هذيك الليلة، بعد ما حليت المشكلة، قعدت مع حالي وسألت نفسي: “هل يعقل إنه في 2024، طريقتنا الوحيدة لنعرف إنه في مشكلة هي لما العميل يحكيلنا؟”. كانت هذه الحادثة هي القشة التي قصمت ظهر البعير، والبداية لرحلتنا مع عالم المراقبة الاستباقية باستخدام Prometheus و Grafana.

لماذا نقع في فخ “أخبرني العميل”؟

قبل أن نغوص في الحلول التقنية، دعونا نعترف بالمشكلة. معظم الفرق، خصوصاً في البدايات، تتبع نهج “رد الفعل” (Reactive Approach). هذا يعني أننا ننتظر حدوث المشكلة، ثم نبدأ بالبحث عن حل. هذا النهج له تكاليف باهظة:

• فقدان الثقة والسمعة: عندما يجد العميل أن موقعك لا يعمل، تتأثر ثقته في خدمتك.
• خسائر مالية: كل دقيقة توقف تعني خسارة في الإيرادات المحتملة.
• إرهاق الفريق: لا يوجد شيء أكثر إرهاقاً من العمل في وضع “إطفاء الحرائق” المستمر.

الحل هو الانتقال إلى نهج “استباقي” (Proactive Approach)، حيث نكتشف المشاكل المحتملة ونحلها قبل أن تؤثر على المستخدم النهائي. وهنا يأتي دور أبطال قصتنا: Prometheus و Grafana.

مقدمة سريعة: من هما Prometheus و Grafana؟

ببساطة شديدة، تخيل أن لديك جيشاً من الجواسيس الصغار (Prometheus) منتشرين في كل أنحاء مملكتك (سيرفراتك وتطبيقاتك)، يجمعون لك كل صغيرة وكبيرة على مدار الساعة. ثم لديك غرفة عمليات مركزية فخمة (Grafana) تعرض لك كل تقارير هؤلاء الجواسيس على شاشات ورسوم بيانية جميلة وسهلة الفهم.

• Prometheus: هو نظام مفتوح المصدر لجمع المقاييس (Metrics) وتخزينها كسلاسل زمنية (Time-series data). هو “جامع البيانات” الذكي.
• Grafana: هي منصة مفتوحة المصدر لعرض البيانات وتحليلها وإنشاء لوحات تحكم (Dashboards). هي “الفنان” الذي يحول البيانات الخام إلى لوحة فنية مفهومة.

كيف يعمل Prometheus؟ (الآلية ببساطة)

يتبع Prometheus نموذج “السحب” (Pull Model). هذا يعني أنه يقوم بشكل دوري بزيارة أهداف (Targets) محددة مسبقاً (مثل سيرفراتك أو تطبيقاتك) ويسحب منها المقاييس عبر طلب HTTP بسيط. هذه الأهداف يجب أن تعرض مقاييسها على مسار معين (عادة /metrics) بصيغة يفهمها Prometheus.

نصيحة من أبو عمر: قد تتساءل، “وماذا عن الأنظمة التي لا تعرض مقاييسها بشكل ذاتي؟”. هنا يأتي دور ما يسمى بالـ “Exporters”. هي برامج صغيرة تعمل كوسيط، تجمع المقاييس من نظام معين (مثل قاعدة بيانات MySQL أو سيرفر Linux) وتعرضها بالصيغة التي يحبها Prometheus. أشهر مثال هو node_exporter لمراقبة مقاييس النظام (CPU, RAM, Disk).

لنطبق عملياً: مراقبة سيرفر لينكس

الكلام النظري جميل، لكن دعونا “نشمر عن أيدينا” ونرى كيف يمكننا تطبيق هذا عملياً. لنفترض أننا نريد مراقبة المقاييس الأساسية لسيرفر ويب يعمل بنظام لينكس.

الخطوة 1: تثبيت وتشغيل Node Exporter على السيرفر الهدف

أولاً، سنقوم بتثبيت node_exporter على السيرفر الذي نريد مراقبته. يمكنك تحميل أحدث إصدار من الموقع الرسمي. بعد فك الضغط، يمكنك تشغيله ببساطة.

# على السيرفر الذي تريد مراقبته
wget https://github.com/prometheus/node_exporter/releases/download/v1.7.0/node_exporter-1.7.0.linux-amd64.tar.gz
tar xvfz node_exporter-1.7.0.linux-amd64.tar.gz
cd node_exporter-1.7.0.linux-amd64
./node_exporter

الآن، إذا فتحت المتصفح على http://YOUR_SERVER_IP:9100/metrics، سترى كمية هائلة من النصوص. هذه هي المقاييس التي يعرضها الـ exporter وجاهزة ليقرأها Prometheus.

الخطوة 2: إخبار Prometheus عن الهدف الجديد

الآن ننتقل إلى السيرفر الذي يعمل عليه Prometheus. سنقوم بتعديل ملف الإعدادات الخاص به (عادة اسمه prometheus.yml) لنخبره عن “الجاسوس” الجديد الذي زرعناه.

# ملف prometheus.yml
scrape_configs:
  - job_name: 'prometheus' # لمراقبة بروميثيوس نفسه
    static_configs:
      - targets: ['localhost:9090']

  - job_name: 'node_exporter_webserver'
    static_configs:
      - targets: ['YOUR_SERVER_IP:9100'] # أضفنا هذا القسم

بعد حفظ الملف، أعد تشغيل Prometheus. سيبدأ فوراً بسحب البيانات من سيرفر الويب الخاص بك كل فترة زمنية محددة (scrape_interval).

من البيانات إلى لوحة فنية: دور Grafana

الآن لدينا البيانات، لكنها مخزنة في Prometheus وغير قابلة للقراءة بشكل بشري. هنا يأتي دور Grafana لتحويل هذا الكنز من البيانات إلى ذهب مرئي.

الخطوة 1: ربط Grafana بـ Prometheus

بعد تثبيت Grafana، أول خطوة هي إضافة Prometheus كمصدر للبيانات (Data Source). العملية بسيطة جداً من خلال الواجهة الرسومية:

1. اذهب إلى Configuration -> Data Sources.
2. اضغط على “Add data source”.
3. اختر Prometheus.
4. في حقل الـ URL، أدخل عنوان سيرفر Prometheus الخاص بك (مثلاً http://PROMETHEUS_IP:9090).
5. اضغط “Save & Test”. يجب أن ترى رسالة نجاح.

الخطوة 2: بناء أول لوحة عرض (Panel)

لنبنِ لوحة عرض بسيطة لمراقبة استخدام المعالج (CPU).

1. أنشئ لوحة تحكم جديدة (Dashboard) واضغط “Add new panel”.
2. في محرر اللوحة، تأكد من أن مصدر البيانات هو Prometheus الذي أضفته.
3. في حقل الاستعلام (Query)، سنكتب شيئاً بلغة PromQL (لغة استعلامات Prometheus).

لا تخف من الكود التالي، سأشرحه بالتفصيل. لحساب نسبة استخدام الـ CPU كنسبة مئوية، يمكننا استخدام الاستعلام التالي:

100 - (avg by (instance) (irate(node_cpu_seconds_total{mode="idle"}[5m])) * 100)

• node_cpu_seconds_total{mode="idle"}: هذا هو المقياس الخام الذي يجمعه node_exporter، وهو عداد يوضح كم ثانية كان المعالج في وضع الخمول (idle).
• irate(...[5m]): هذه الدالة تحسب معدل الزيادة “اللحظي” للعداد خلال آخر 5 دقائق.
• avg by (instance) (...): نحسب متوسط القيمة لكل سيرفر (instance).
• * 100: لتحويلها إلى نسبة مئوية.
• 100 - ...: بما أننا حسبنا نسبة الخمول، نطرحها من 100 لنحصل على نسبة الاستخدام.

بمجرد كتابة هذا الاستعلام، سترى رسماً بيانياً جميلاً يظهر استخدام الـ CPU على سيرفرك بمرور الوقت. يا سلام!

نصيحة عملية من أبو عمر: لست مضطراً لإعادة اختراع العجلة في كل مرة. مجتمع Grafana مليء بلوحات التحكم الجاهزة (Pre-built Dashboards). يمكنك الذهاب إلى موقع Grafana الرسمي والبحث عن “Node Exporter Full” مثلاً (رقم اللوحة 1860 مشهور جداً)، واستيرادها بضغطة زر لتحصل على لوحة تحكم شاملة لمراقبة السيرفر. “ليش نغلب حالنا ونبدأ من الصفر؟”.

المستوى المتقدم: التنبيهات التي تنقذ الموقف

المراقبة المرئية رائعة، لكننا لا نستطيع التحديق في الشاشات 24/7. القوة الحقيقية تكمن في إعداد التنبيهات (Alerting) التي تخبرنا بوجود مشكلة *قبل* أن تصل للعميل.

يقوم Prometheus بتقييم قواعد (Rules) معينة بشكل مستمر. إذا تحقق شرط معين في إحدى هذه القواعد، فإنه يطلق تنبيهاً (Alert). ثم يقوم مكون آخر يسمى Alertmanager باستلام هذه التنبيهات، وتجميعها، وتوجيهها إلى الوجهة الصحيحة (مثل إيميل، Slack, PagerDuty).

على سبيل المثال، يمكننا كتابة قاعدة تنبيه في Prometheus لإعلامنا إذا تجاوز استخدام المعالج 85% لمدة تزيد عن 5 دقائق:

# في ملف قواعد التنبيهات
groups:
- name: server_alerts
  rules:
  - alert: HighCpuUsage
    expr: 100 - (avg by (instance) (irate(node_cpu_seconds_total{mode="idle"}[5m])) * 100) > 85
    for: 5m
    labels:
      severity: critical
    annotations:
      summary: "High CPU usage on instance {{ $labels.instance }}"
      description: "CPU usage is above 85% for the last 5 minutes on {{ $labels.instance }}."

مع هذه القاعدة، بدلاً من أن يتصل بك العميل ليلاً، ستصلك رسالة على Slack تقول: “انتباه: استخدام المعالج مرتفع على السيرفر X”. الآن لديك الوقت الكافي للتحقيق في المشكلة وحلها بهدوء بينما الخدمة لا تزال تعمل، وقبل أن يشعر أي مستخدم بأي شيء.

الخلاصة: استثمر في راحة بالك 🧘‍♂️

الرحلة من “أخبرني العميل” إلى “اكتشفنا المشكلة قبل حدوثها” هي نقلة نوعية في طريقة تفكيرنا كمهندسين ومطورين. الأدوات مثل Prometheus و Grafana ليست مجرد تقنيات معقدة، بل هي استثمار مباشر في استقرار أنظمتنا، وفي سمعة منتجاتنا، والأهم من ذلك كله، في راحة بالنا وقدرتنا على النوم ليلاً.

لا تنتظر مكالمة منتصف الليل التالية. ابدأ اليوم، ولو بخطوات بسيطة. قم بتثبيت node_exporter على سيرفر واحد، اربطه بـ Prometheus، واعرض بياناته على Grafana. ستكتشف أن القوة التي تمنحك إياها رؤية ما يحدث داخل أنظمتك لا تقدر بثمن.

تذكر دائماً، المراقبة ليست ترفاً، بل هي أساس أي نظام برمجي ناجح وموثوق. استثمروا في المراقبة، عشان تناموا الليل مرتاحين زي أبو عمر 😉.