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

بتذكرها زي كإنها إمبارح. الساعة كانت 2 بعد نص الليل، يوم جمعة. الجوال ضوّى، وصوت رسالة واتساب كسر هدوء الغرفة. كانت من مدير المشروع: “أبو عمر، الموقع واقع! شو القصة؟”. قلبي نغزني، فتحت اللابتوب بسرعة وأنا بدعي بيني وبين حالي تكون مشكلة بسيطة. وراها رسالة ثانية، وثالثة… من فريق الدعم، من زبون مهم، وحتى قريبي اللي بستخدم التطبيق بعتلي “يا خال، التطبيق مش شغال!”.

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

الفوضى الخلاقة: مرحلة ما قبل المراقبة

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

• التوتر الدائم: كل مطور في الفريق كان خايف من “مكالمة نص الليل”. ما في إجازة أو عطلة نهاية أسبوع كاملة بدون قلق.
• إطفاء الحرائق (Firefighting): بدل ما نطور ميزات جديدة ونحسن المنتج، كان معظم وقتنا يضيع في تشخيص المشاكل وإصلاحها بشكل طارئ.
• فقدان الثقة: كل مرة الموقع بوقع فيها، كنا بنخسر جزء من ثقة المستخدمين. والمنافسين ما بستنوا حدا.
• تخمين أعمى: لما تحصل مشكلة، كنا زي اللي بدور على إبرة في كومة قش. السيرفر بطيء؟ يمكن المشكلة في قاعدة البيانات، أو يمكن الـ CPU، أو يمكن الشبكة… كنا بنضيع ساعات في التخمين.

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

الضوء في آخر النفق: التعرف على ثنائي الإنقGاذ Prometheus و Grafana

لما بلشنا نبحث عن حلول، كان في خيارات كثيرة. لكن اسمين كانوا يتكرروا في كل مكان: Prometheus و Grafana. هالثنائي مع بعض بشكلوا نظام مراقبة مفتوح المصدر، قوي جداً، ويستخدم من قبل شركات عملاقة زي SoundCloud و Uber وغيرها الكثير.

شو هو Prometheus؟ (What is Prometheus?)

ببساطة، Prometheus هو “جامع البيانات”. تخيله زي الدكتور اللي بفحص مريض كل كم ثانية. هو برنامج بروح على تطبيقاتك وسيرفراتك (اللي بنسميها targets) وبسألها: “كيف وضعك؟ كم استهلاك الـ CPU عندك؟ كم طلبية استقبلتي في آخر دقيقة؟ كم خطأ صار؟”.

بقوم Prometheus بتخزين هاي الإجابات (اللي بنسميها metrics أو مقاييس) مع الطابع الزمني تبعها في قاعدة بيانات خاصة اسمها Time-Series Database. أهم ما يميزه:

• نموذج السحب (Pull Model): هو اللي ببادر وبروح “بسحب” البيانات من تطبيقاتك، وهذا بعطيك تحكم مركزي وسهل.
• الـ Exporters: طب لو تطبيقي ما بحكي “لغة” Prometheus؟ هون بيجي دور الـ Exporters. هي برامج صغيرة بتشتغل جنب تطبيقك أو سيرفرك، وبتقوم بترجمة حالته لمقاييس بفهمها Prometheus. في exporters لكل شي تقريباً: للسيرفرات (Node Exporter)، لقواعد البيانات (Postgres Exporter)، وللـ Web Servers (Nginx Exporter) وغيره.
• لغة الاستعلام PromQL: عنده لغة استعلام قوية جداً اسمها PromQL بتخليك تحلل البيانات وتعمل عمليات حسابية معقدة عليها بسهولة.

وإيش قصة Grafana؟ (And what’s the deal with Grafana?)

إذا كان Prometheus هو الدكتور اللي بجمع البيانات، فـ Grafana هو شاشة العرض اللي في غرفة العناية المركزة. هو اللي بحول كل الأرقام والبيانات اللي جمعها Prometheus لرسومات بيانية جميلة ومفهومة ولوحات مراقبة (Dashboards).

Grafana ما بخزن أي بيانات، هو فقط أداة عرض. بتشبكه على مصدر بيانات (Data Source) زي Prometheus، وبتحكيله: “يا Grafana، ارسملي استهلاك الـ CPU لآخر 6 ساعات”، وهو بقوم بسؤال Prometheus عن البيانات وبعرضلك إياها بشكل حلو ومنظم. قوته تكمن في مرونته وقدرته على الاتصال بعشرات مصادر البيانات المختلفة، مش بس Prometheus.

يلا نشتغل: خطوات عملية لبناء نظام المراقبة الأول

الحكي النظري حلو، بس خلينا نشوف كيف بنقدر نبني نظام أساسي للمراقبة بخطوات بسيطة. رح نستخدم Docker و Docker Compose عشان نسهل العملية.

الخطوة الأولى: تجهيز البيئة باستخدام Docker

أنشئ ملف جديد باسم docker-compose.yml وحط فيه الكود التالي. هذا الملف رح يشغلنا 3 حاويات (containers): واحدة لـ Prometheus، وواحدة لـ Grafana، وواحدة لـ Node Exporter (عشان نراقب السيرفر اللي شغال عليه Docker).

version: '3.8'

services:
  prometheus:
    image: prom/prometheus:latest
    container_name: prometheus
    ports:
      - "9090:9090"
    volumes:
      - ./prometheus:/etc/prometheus/
    command:
      - '--config.file=/etc/prometheus/prometheus.yml'
    restart: unless-stopped

  grafana:
    image: grafana/grafana:latest
    container_name: grafana
    ports:
      - "3000:3000"
    volumes:
      - grafana-data:/var/lib/grafana
    restart: unless-stopped

  node_exporter:
    image: prom/node-exporter:latest
    container_name: node_exporter
    ports:
      - "9100:9100"
    restart: unless-stopped

volumes:
  grafana-data:

الخطوة الثانية: إعداد Prometheus لجمع البيانات (Scraping)

في نفس المجلد، أنشئ مجلد جديد اسمه prometheus وبداخله ملف اسمه prometheus.yml. هذا هو ملف الإعدادات الرئيسي لـ Prometheus.

global:
  scrape_interval: 15s # كل 15 ثانية بروح يجيب البيانات

scrape_configs:
  - job_name: 'prometheus'
    static_configs:
      - targets: ['localhost:9090']

  - job_name: 'node_exporter'
    static_configs:
      - targets: ['node_exporter:9100']

شرح سريع: في هذا الملف، عرفنا لـ Prometheus شغلتين لازم يراقبهم (jobs):

1. prometheus: عشان يراقب حاله.
2. node_exporter: عشان يراقب السيرفر تبعنا. استخدمنا اسم الخدمة node_exporter كما هو معرف في ملف الـ docker-compose.

الآن، شغل كل شي عن طريق الأمر: docker-compose up -d

إذا كل شي تمام، بتقدر تفتح المتصفح على http://localhost:9090 ورح تشوف واجهة Prometheus. لو رحت على Status -> Targets، المفروض تشوف إن prometheus و node_exporter حالتهم UP.

الخطوة الثالثة: بناء لوحة المراقبة الأولى في Grafana

الآن للجزء الممتع! خلينا نعرض البيانات هاي بشكل حلو.

1. افتح المتصفح على http://localhost:3000. اسم المستخدم وكلمة المرور الافتراضية هم admin.
2. إضافة مصدر البيانات (Data Source):
   • من القائمة الجانبية، روح على أيقونة الترس (Configuration) -> Data Sources.
   • اضغط على “Add data source” واختار Prometheus.
   • في خانة الـ URL، اكتب http://prometheus:9090. ليش prometheus؟ لأنه هذا هو اسم الخدمة داخل شبكة Docker اللي أنشأها docker-compose.
   • انزل للآخر واضغط “Save & test”. المفروض تطلعلك رسالة خضرا “Data source is working”.
3. استيراد لوحة مراقبة جاهزة:
   

   نصيحة من أبو عمر: لا تعيد اختراع العجلة! في آلاف لوحات المراقبة الجاهزة على موقع Grafana.com. بدل ما تبني لوحة من الصفر لمراقبة السيرفر، خلينا نستورد واحدة جاهزة لـ Node Exporter.

   • من القائمة الجانبية، روح على أيقونة الزائد (+) -> Import.
   • في خانة “Import via grafana.com”، اكتب رقم الـ ID للوحة المراقبة. واحدة من أشهر اللوحات لـ Node Exporter هي 1860.
   • اضغط Load. في الصفحة التالية، اختار مصدر البيانات Prometheus اللي عملناه قبل شوي.
   • اضغط Import، ومبروك! صار عندك لوحة مراقبة كاملة بتعرض كل تفاصيل السيرفر: CPU, Memory, Disk, Network… كل هذا بكبسة زر.

تأمل المنظر. في أقل من 10 دقائق، انتقلت من لا شيء إلى لوحة مراقبة احترافية بتعطيك رؤية كاملة عن صحة السيرفر تبعك. تخيل قوة هذا الشيء لما تطبقه على كل خدماتك وتطبيقاتك!

من المراقبة إلى الاستبصار (Observability): ما بعد لوحات المراقبة

اللي عملناه هذا هو حجر الأساس، وهو يغطي أول وأهم ركن من أركان ما يسمى بـ Observability (الاستبصار أو قابلية الملاحظة)، وهو الـ Metrics (المقاييس).

لكن لتوصل لمرحلة الاستبصار الكامل، في ركنين ثانيين مهمين:

• Logs (السجلات): هي رسائل نصية بتوصف أحداث معينة حصلت في التطبيق (مثال: “User logged in”, “Failed to connect to database”). أدوات مثل Loki (اللي بتشتغل بشكل رائع مع Grafana) بتساعدك تجمعها وتحللها.
• Traces (الآثار): بتتبع مسار الطلب الواحد (request) عبر الخدمات المختلفة في نظامك. لو عندك نظام Microservices، الـ Traces بتفرجيك وين الطلب قضى معظم وقته أو وين حصل الخطأ. أدوات مثل Jaeger أو Tempo بتساعدك في هذا المجال.

الجميل في الموضوع إن Grafana بتقدر تكون الواجهة الموحدة لكل هاي الأعمدة الثلاثة، فبصير عندك مكان واحد تشوف منه كل شي بخص نظامك.

التنبيهات (Alerting): درهم وقاية خير من قنطار علاج

لوحات المراقبة رائعة، لكنك ما رح تضل تطلع عليها 24 ساعة. هون بيجي دور التنبيهات. Prometheus عنده نظام تنبيهات قوي اسمه Alertmanager.

بتقدر تعرف قواعد (rules) بسيطة، مثلاً:

groups:
- name: node_alerts
  rules:
  - alert: InstanceDown
    expr: up == 0
    for: 5m
    labels:
      severity: 'critical'
    annotations:
      summary: 'Instance {{ $labels.instance }} down'
      description: '{{ $labels.instance }} of job {{ $labels.job }} has been down for more than 5 minutes.'

هاي القاعدة بتحكي: “إذا أي instance كانت حالتها down (يعني up == 0) لمدة 5 دقائق متواصلة، ابعث تنبيه critical”.

هذا التنبيه بتقدر توصله على Slack, Email, PagerDuty, Telegram… أي شي بدك إياه. هيك، بدل ما يصحيك المستخدم من النوم، بصحيك Prometheus، وبعطيك 5 دقايق تحل المشكلة قبل ما حدا يحس عليها. هذا هو الفرق بين العمل الارتجالي (Reactive) والعمل الاستباقي (Proactive).

خلاصة الحكي والنصيحة الأخيرة 💡

رحلتنا من الاعتماد على شكاوى المستخدمين إلى بناء نظام مراقبة قوي كانت نقلة نوعية في طريقة عملنا. تحولنا من فريق “إطفاء حرائق” متوتر إلى فريق هادئ وواثق، قادر على اكتشاف المشاكل وحلها قبل أن تؤثر على المستخدمين.

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

النصيحة الأخيرة من أبو عمر:
ابدأ صغيراً. لا تحاول تراقب كل شي من أول يوم. ابدأ بأهم مؤشر: “هل تطبيقي يعمل؟” (مقياس up). بعدين ضيف مؤشرات الأداء الأساسية (CPU, Memory, Latency). مع الوقت، رح تكبر لوحات المراقبة تبعتك مع نمو فهمك لنظامك. ولا تنسَ، المراقبة مش مجرد أداة، هي ثقافة بتبنيها في فريقك. ثقافة الشفافية والمسؤولية والتحسين المستمر. يلا، شدوا حيلكم!