من العمى التشغيلي إلى البصيرة الكاملة: رحلتي مع Prometheus و Grafana لإنقاذ أنظمتنا

أذكرها وكأنها البارحة، الساعة الثانية فجراً والهاتف يرن بنغمة خصصتها للمكالمات الطارئة من العمل. على الطرف الآخر كان صوت مدير المشروع متوتراً: “أبو عمر، الموقع واقع! العملاء في الخليج يشتكون، وشو القصة؟”. قفزت من سريري، وبدأ العرق البارد يتصبب وأنا أفتح اللابتوب. دخلت على السيرفرات، نظرت في سجلات الأخطاء (Logs)، بحرٌ من النصوص التي لا بداية لها ولا نهاية. استغرق الأمر مني ومن الفريق ساعتين من البحث المحموم لنجد أن خدمة صغيرة مسؤولة عن الدفع قد استهلكت كل ذاكرة السيرفر وتوقفت، مما أدى لانهيار كل شيء.

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

كانت تلك اللحظة هي نقطة التحول. قررنا أننا لن نكون فريق إطفاء حرائق بعد الآن، بل سنبني منارة تضيء لنا كل زاوية في بنيتنا التحتية. من هنا بدأت رحلتنا مع Prometheus و Grafana.

ما قبل العاصفة: حياة في ظل العمى التشغيلي

قبل أن ندخل في الحل، دعوني أصف لكم حالنا “قبل”. ربما تجدون أنفسكم في هذا الوصف:

• الاعتماد على سجلات الأخطاء (Logs): كانت السجلات هي عيننا الوحيدة. وعندما يحدث خطأ، كنا نغوص في آلاف الأسطر من النصوص نحاول إيجاد الإبرة في كومة القش. هذا أسلوب تفاعلي (Reactive)، لا استباقي (Proactive).
• “هل يعمل؟”: كانت أداتنا الرئيسية للمراقبة هي فتح الموقع وتجربته يدوياً! إذا فتح، فهو يعمل. مشكلة هذا الأسلوب أنه لا يخبرك عن المشاكل الخفية: بطء في الاستجابة، استهلاك عالٍ للموارد قد يؤدي لانهيار وشيك.
• المستخدم هو نظام الإنذار: أسوأ سيناريو ممكن، وهو أن يكون أول من يكتشف المشكلة هو المستخدم النهائي عبر شكوى أو مراجعة سلبية. هذا يدمر السمعة والثقة.

كنا، بالبلدي، عمياناً. ندير أنظمة معقدة دون أن نرى مؤشراتها الحيوية. تماماً كقيادة سيارة بدون لوحة عدادات.

الضوء في آخر النفق: تقديم Prometheus

عندما بدأنا البحث عن حل، كان اسم Prometheus يتردد في كل مجتمعات الـ DevOps. لم يكن مجرد أداة، بل كان فلسفة جديدة في المراقبة.

ما هو Prometheus بالضبط؟

ببساطة، Prometheus هو قاعدة بيانات من نوع “السلاسل الزمنية” (Time-Series Database) مصممة خصيصاً لجمع وتخزين المقاييس (Metrics). فكر فيه كطبيب يسجل نبضات قلب المريض، ضغط دمه، ومعدل تنفسه كل ثانية. هذه الأرقام هي المقاييس، وتسجيلها عبر الزمن هو ما يفعله Prometheus.

المقاييس يمكن أن تكون أي شيء رقمي:

• استخدام المعالج (CPU) والذاكرة (RAM) للسيرفر.
• عدد الطلبات (HTTP Requests) التي يستقبلها تطبيقك في الثانية.
• عدد الأخطاء من نوع 500.
• عدد المستخدمين المسجلين حالياً.
• زمن استجابة قاعدة البيانات.

كيف يعمل؟ (نموذج السحب – Pull Model)

أجمل ما في Prometheus هو بساطة فكرته. بدلاً من أن تقوم تطبيقاتك بإرسال بياناتها إليه (Push)، يقوم Prometheus بنفسه بـ “سحب” (Pull) البيانات من تطبيقاتك بشكل دوري (كل 15 ثانية مثلاً).

للقيام بذلك، يجب أن تقوم تطبيقاتك بعرض مقاييسها على نقطة نهاية (endpoint) معينة، عادة ما تكون /metrics. يقوم Prometheus بزيارة هذه الصفحة، يقرأ المقاييس النصية البسيطة، ويخزنها.

لنبدأ العمل: مثال عملي

لنجعل الأمر عملياً. تخيل أن لدينا تطبيق Node.js بسيط، ونريد مراقبة عدد الطلبات التي تصله.

1. تجهيز التطبيق (Instrumentation):

أولاً، نضيف مكتبة Prometheus الرسمية لتطبيقنا:

npm install prom-client

ثم، نعدل كود التطبيق ليقوم بتسجيل المقاييس وعرضها:

const express = require('express');
const client = require('prom-client');

const app = express();
const port = 3000;

// تفعيل جمع المقاييس الافتراضية (CPU, Memory, etc.)
const collectDefaultMetrics = client.collectDefaultMetrics;
collectDefaultMetrics({ timeout: 5000 });

// إنشاء مقياس جديد: عدّاد لطلبات HTTP
const httpRequestCounter = new client.Counter({
  name: 'http_requests_total',
  help: 'Total number of HTTP requests',
  labelNames: ['method', 'route', 'status_code']
});

// Middleware لزيادة العدّاد مع كل طلب
app.use((req, res, next) => {
  res.on('finish', () => {
    httpRequestCounter.inc({
      method: req.method,
      route: req.path,
      status_code: res.statusCode
    });
  });
  next();
});

app.get('/', (req, res) => {
  res.send('أهلاً بك في تطبيقي يا أبو عمر!');
});

app.get('/error', (req, res) => {
  res.status(500).send('حدث خطأ ما!');
});

// نقطة النهاية التي سيزورها Prometheus
app.get('/metrics', async (req, res) => {
  res.set('Content-Type', client.register.contentType);
  res.end(await client.register.metrics());
});

app.listen(port, () => {
  console.log(`التطبيق يعمل على http://localhost:${port}`);
});

الآن إذا شغلت هذا التطبيق وزرت الرابط http://localhost:3000/metrics، سترى نصاً يحتوي على جميع المقاييس!

2. إعداد Prometheus:

نحتاج الآن لملف إعداد بسيط لـ Prometheus (اسمه prometheus.yml) ليقوم بسحب هذه البيانات:

global:
  scrape_interval: 15s # كل 15 ثانية

scrape_configs:
  - job_name: 'my-nodejs-app'
    static_configs:
      - targets: ['localhost:3000'] # عنوان التطبيق الذي سنراقبه

عند تشغيل Prometheus مع هذا الإعداد، سيبدأ فوراً بجمع البيانات من تطبيقنا. أصبح لدينا الآن بيانات، لكنها لا تزال مجرد أرقام في قاعدة بيانات.

جعل البيانات جميلة: Grafana يدخل المشهد

Prometheus هو العقل الجامع للبيانات، لكننا نحتاج إلى عيون لنرى هذه البيانات. هنا يأتي دور Grafana.

“إذا كان Prometheus هو من يجمع كل الحقائق والأرقام، فإن Grafana هو الفنان الذي يرسم لك لوحة مفهومة من هذه الأرقام.”

Grafana هي أداة مفتوحة المصدر لإنشاء لوحات تحكم (Dashboards) تفاعلية وجميلة. هي الواجهة التي ستنظر إليها كل صباح مع فنجان قهوتك لتطمئن على صحة أنظمتك.

الربط بين Prometheus و Grafana

العملية بسيطة جداً:

1. تثبّت Grafana.
2. تدخل إلى واجهته، وتذهب إلى “Data Sources”.
3. تختار Prometheus وتضع عنوان السيرفر الذي يعمل عليه (مثلاً http://localhost:9090).
4. تضغط “Save & Test”، وسيخبرك Grafana أن كل شيء على ما يرام.

بناء أول لوحة تحكم

الآن يبدأ المرح الحقيقي. لنقم بإنشاء رسم بياني يوضح عدد طلبات HTTP التي أنشأناها قبل قليل.

• في Grafana، أنشئ لوحة تحكم جديدة (New Dashboard) ثم لوحة جديدة (New Panel).
• في خانة الاستعلام (Query)، اختر Prometheus كمصدر للبيانات.
• اكتب الاستعلام التالي بلغة PromQL (لغة استعلام Prometheus): rate(http_requests_total[5m])

هذا الاستعلام يعني: “أعطني معدل التغيير في عدّاد http_requests_total خلال آخر 5 دقائق”. والنتيجة؟ رسم بياني حي ومباشر يوضح لك عدد الطلبات في الثانية!

يمكنك الآن إضافة رسوم بيانية أخرى: استخدام الذاكرة، ضغط المعالج، معدل الأخطاء (rate(http_requests_total{status_code=~"5.."}[5m]))، وهكذا. في غضون ساعة، يمكنك بناء لوحة تحكم شاملة تعطيك نظرة 360 درجة على صحة تطبيقك.

نصائح أبو عمر الذهبية للمراقبة الفعالة

بعد سنوات من استخدام هذا الثنائي الرائع، هذه بعض النصائح من القلب:

1. ابدأ بالأساسيات: لا تحاول مراقبة كل شيء من اليوم الأول. ركز على “الإشارات الذهبية الأربع” (The Four Golden Signals) التي وضعتها Google:
   • الكمون (Latency): كم من الوقت يستغرق طلبك ليتم خدمته؟
   • حجم الطلبات (Traffic): ما مدى الطلب على نظامك؟ (مثلاً، طلبات HTTP في الثانية).
   • الأخطاء (Errors): ما هو معدل فشل الطلبات؟
   • التشبع (Saturation): ما مدى “امتلاء” نظامك؟ (مثلاً، استخدام الذاكرة 90%).
2. لوحات التحكم يجب أن تروي قصة: لا تكدس الرسوم البيانية. نظمها بطريقة منطقية. مثلاً، لوحة تحكم للـ “نظرة العامة”، وأخرى لتفاصيل “قاعدة البيانات”، وثالثة لـ “خدمة الدفع”.
3. المراقبة ليست كافية، التنبيه هو الأهم: استخدم Alertmanager (أداة تأتي مع Prometheus) لإعداد تنبيهات ذكية. لا تنبه على كل شيء، فقط على ما يتطلب تدخلاً بشرياً. مثلاً: “أرسل لي تنبيهاً على Slack إذا ارتفع معدل أخطاء 5xx فوق 2% لمدة 5 دقائق”.
4. اجعلها جزءاً من ثقافتك: شجع كل المطورين على إضافة مقاييس (Metrics) مع كل ميزة جديدة يطورونها. المراقبة ليست وظيفة شخص واحد، بل مسؤولية الفريق بأكمله.

الخلاصة: من الظلام إلى النور 💡

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

الاستثمار في المراقبة الجيدة ليس رفاهية، بل هو أساس أي نظام برمجي ناجح وموثوق. إنه الفرق بين فريق ينام قرير العين، وفريق ينتظر الكارثة التالية. فلا تبقوا في الظلام، هناك أدوات رائعة وبسيطة مثل Prometheus و Grafana يمكنها أن تضيء لكم الطريق. يلا يا جماعة، ابدأوا اليوم!