أذكرها جيداً تلك الليلة، كانت حوالي الثانية صباحاً بتوقيت القدس. كنت قد انتهيت للتو من مشاهدة فيلم وبدأت أستعد للنوم، حين اهتز هاتفي برسالة عاجلة على مجموعة الفريق: “الموقع واقع! كل شيء لا يستجيب!”.
يا الله، شعور أعرفه جيداً ويعرفه كل مبرمج ومسؤول نظام. شعور ثقيل في المعدة وتسارع في نبضات القلب. فتحت اللابتوب بسرعة، وبدأنا كفريق رحلة البحث المحمومة. “شو القصة يا جماعة؟” (ما الأمر يا جماعة؟)، سألت وأنا أفتح عشرات النوافذ الطرفية (terminals) وأتصل بالسيرفرات. هل هو ضغط على قاعدة البيانات؟ هل نفدت الذاكرة (RAM)؟ هل امتلأ القرص الصلب؟
كنا كمن يبحث عن إبرة في كومة قش في الظلام. نفتح ملفات الـ logs الضخمة، ونحاول قراءة آخر الأسطر، كل واحد منا يطرح نظرية. بعد ساعة ونصف من التوتر والبحث العشوائي، اكتشفنا المشكلة: أحد العمليات في الخلفية (background process) تسربت منها الذاكرة ببطء على مدار أيام حتى استهلكت كل ذاكرة السيرفر وتسببت في انهياره بالكامل.
في تلك اللحظة، وبعد أن أعدنا تشغيل الخدمة، لم أشعر بالراحة بقدر ما شعرت بالإحباط. المشكلة لم تكن في الـ Memory Leak بحد ذاته، بل في أننا لم نره قادماً. كنا عمياناً تماماً. مراقبتنا كانت مجرد رد فعل متأخر، صرخة استغاثة بعد وقوع الكارثة. هنا قررنا أن هذا الوضع لا يمكن أن يستمر، وأننا بحاجة إلى عيون تراقب نظامنا باستمرار. كانت تلك بداية رحلتنا مع Prometheus و Grafana.
المشكلة: المراقبة كرد فعل (The Reactive Nightmare)
قبل أن نتبنى الأدوات الحديثة، كانت استراتيجيتنا للمراقبة، إن صح تسميتها استراتيجية، بسيطة وساذجة للغاية. كانت تتلخص في النقاط التالية:
- الاعتماد على شكاوى المستخدمين: أول من يكتشف المشكلة هو المستخدم، وهذا أسوأ سيناريو ممكن لأنه يؤثر مباشرة على سمعة المنتج وثقة العملاء.
- الغوص في السجلات (Logs) بعد الكارثة: السجلات مهمة، لكن الاعتماد عليها وحدها بعد تعطل النظام يشبه تشريح الجثة لمعرفة سبب الوفاة. مفيد، ولكنه متأخر جداً.
- غياب البيانات التاريخية: لم يكن لدينا أي فكرة عن أداء النظام قبل ساعة أو يوم أو أسبوع. هل استهلاك الذاكرة هذا طبيعي؟ هل عدد الطلبات على الخادم في ازدياد؟ لا إجابات.
- التخمين بدلاً من التحليل: في كل مرة تحدث مشكلة، نبدأ جلسة تخمين جماعية. هذا يستهلك وقتاً ثميناً ويزيد من التوتر والضغط على الفريق.
هذا النهج “التفاعلي” أو “رد الفعل” جعلنا في حالة طوارئ دائمة، فريق إطفاء حرائق بدلاً من مهندسين يبنون أنظمة قوية ومستقرة. كنا بحاجة إلى نقلة نوعية نحو المراقبة الاستباقية (Proactive Monitoring) ومفهوم الـ Observability.
الحل يلوح في الأفق: تقديم Prometheus و Grafana
الـ Observability أو “القابلية للمراقبة” هي قدرتك على فهم ما يحدث داخل نظامك من خلال النظر إلى بياناته الخارجية. بدلاً من انتظار النظام ليصرخ “لقد تعطلت!”، أنت تسأله باستمرار “كيف حالك؟”. وهنا يأتي دور بطلي قصتنا.
ما هو Prometheus؟
ببساطة، Prometheus هو “جامع البيانات”. تخيله كشخص دؤوب يذهب كل بضع ثوانٍ (مثلاً كل 15 ثانية) ويسأل كل خدمة من خدماتك وكل سيرفر من سيرفراتك عن حالها: “كم تستهلك من المعالج؟”، “كم لديك من ذاكرة فارغة؟”، “كم عدد الطلبات التي استقبلتها؟”.
يقوم Prometheus بتخزين هذه الإجابات (التي تسمى Metrics) في قاعدة بيانات خاصة مصممة للبيانات المتسلسلة زمنياً (Time-Series Data). أهم ما يميزه:
- نموذج السحب (Pull Model): هو من يبادر بالذهاب و”سحب” البيانات من الخدمات، مما يسهل عملية الإعداد.
- لغة استعلام قوية (PromQL): تتيح لك طرح أسئلة معقدة على البيانات التي جمعها.
- نظام تنبيهات مدمج: يمكنه إطلاق تنبيهات إذا تجاوزت قيمة معينة حداً قمت بتحديده مسبقاً.
وماذا عن Grafana؟
إذا كان Prometheus هو جامع البيانات الصامت، فإن Grafana هو الفنان الذي يحول هذه البيانات إلى لوحات فنية مفهومة. Prometheus يجمع الأرقام، و Grafana يرسمها.
Grafana هي أداة تصور (Visualization) مفتوحة المصدر تتصل بمصادر بيانات مختلفة (وأشهرها Prometheus)، وتتيح لك إنشاء لوحات معلومات (Dashboards) تفاعلية وجميلة. بدلاً من النظر إلى أرقام مجردة مثل node_memory_MemAvailable_bytes 2137128960، يمكنك رؤية رسم بياني يوضح تغير الذاكرة المتاحة على مدار الوقت.
رحلة الإعداد: من الصفر إلى لوحة المراقبة الأولى
الكلام النظري جميل، لكن دعونا نرى كيف يمكن تطبيق هذا عملياً. سأريكم كيف بدأنا بخطوات بسيطة باستخدام Docker، وهي طريقة ممتازة للبدء والتجربة.
الخطوة الأولى: تنصيب Prometheus
أفضل طريقة للبدء هي باستخدام Docker Compose. أنشئ ملفاً باسم docker-compose.yml وضع فيه الكود التالي:
version: '3.7'
services:
prometheus:
image: prom/prometheus:v2.37.0
container_name: prometheus
ports:
- "9090:9090"
volumes:
- ./prometheus.yml:/etc/prometheus/prometheus.yml
command:
- '--config.file=/etc/prometheus/prometheus.yml'
الآن، نحتاج إلى ملف الإعدادات prometheus.yml. أنشئه في نفس المجلد:
global:
scrape_interval: 15s # كل كم ثانية يقوم بسحب البيانات
scrape_configs:
- job_name: 'prometheus' # مهمة لمراقبة بروميثيوس نفسه
static_configs:
- targets: ['localhost:9090']
نصيحة من أبو عمر: ابدأ ببساطة. في هذا الإعداد، نحن نطلب من Prometheus أن يراقب نفسه. هذه خطوة أولى ممتازة للتأكد من أن كل شيء يعمل كما هو متوقع قبل إضافة أهداف أخرى.
شغل الآن الخدمة باستخدام الأمر: docker-compose up -d. يمكنك الآن زيارة http://localhost:9090 ورؤية واجهة Prometheus.
الخطوة الثانية: جمع بيانات السيرفر مع Node Exporter
الآن نريد مراقبة السيرفر نفسه (المعالج، الذاكرة، القرص الصلب، الشبكة). لهذا نستخدم أداة اسمها Node Exporter. هي مجرد برنامج صغير تشغله على السيرفر الذي تريد مراقبته، وهو يعرض بيانات السيرفر بتنسيق يفهمه Prometheus.
أضف node-exporter إلى ملف docker-compose.yml:
# ... (prometheus service from before)
node-exporter:
image: prom/node-exporter:v1.3.1
container_name: node-exporter
ports:
- "9100:9100"
restart: unless-stopped
الآن، علينا أن نخبر Prometheus بوجود هذا الهدف الجديد. عدّل ملف prometheus.yml:
# ... (global section from before)
scrape_configs:
- job_name: 'prometheus'
static_configs:
- targets: ['localhost:9090']
- job_name: 'node-exporter'
static_configs:
# استخدم host.docker.internal للوصول للـ host machine من داخل الكونتينر
- targets: ['host.docker.internal:9100']
أعد تشغيل الخدمات: docker-compose up -d --force-recreate. إذا ذهبت إلى واجهة Prometheus ثم إلى Status > Targets، يجب أن ترى الآن هدفين (prometheus و node-exporter) وكلاهما في حالة UP.
الخطوة الثالثة: إضفاء الجمال على البيانات مع Grafana
لدينا الآن البيانات، لكننا نريد رؤيتها بشكل جميل. لنضف Grafana إلى المزيج. عدّل ملف docker-compose.yml للمرة الأخيرة:
# ... (prometheus and node-exporter services)
grafana:
image: grafana/grafana-oss:8.5.2
container_name: grafana
ports:
- "3000:3000"
restart: unless-stopped
volumes:
- grafana-data:/var/lib/grafana
volumes:
grafana-data:
شغل كل شيء مرة أخرى: docker-compose up -d.
الآن اتبع هذه الخطوات البسيطة:
- افتح Grafana بالذهاب إلى
http://localhost:3000. - سجل الدخول باستخدام اسم المستخدم
adminوكلمة المرورadmin. سيطلب منك تغييرها. - من القائمة الجانبية، اذهب إلى Connections > Data Sources > Add data source.
- اختر Prometheus.
- في حقل URL، اكتب
http://prometheus:9090. (نستخدم اسم الخدمة لأنهم في نفس شبكة Docker). - اضغط Save & test. يجب أن ترى رسالة نجاح خضراء.
- الآن، الجزء السحري. من القائمة الجانبية، اذهب إلى Dashboards > New > Import.
- في حقل “Import via grafana.com”، اكتب الـ ID التالي:
1860. هذه لوحة معلومات مشهورة جداً لـ Node Exporter. - اضغط Load، ثم اختر Prometheus كمصدر بيانات، واضغط Import.
مبروك! لديك الآن لوحة معلومات احترافية تعرض لك كل شيء عن سيرفرك: استهلاك المعالج، الذاكرة، استخدام القرص، حركة الشبكة، والمزيد. هذا هو المنظر الذي كان ينقصنا في تلك الليلة المشؤومة.
نصيحة من أبو عمر: لا تعيد اختراع العجلة! مجتمع Grafana مليء بلوحات المراقبة الجاهزة (Dashboards) لكل شيء تقريباً. ابدأ بواحدة جاهزة ثم عدّل عليها لتناسب احتياجاتك الخاصة.
ما بعد الأساسيات: التنبيهات (Alerting) وفن المراقبة الحقيقية
رؤية البيانات شيء رائع، لكننا لا نريد أن نظل نحدق في الشاشة طوال اليوم. نريد أن يخبرنا النظام بنفسه عندما يكون هناك شيء على وشك الحدوث. هنا يأتي دور التنبيهات.
يمكنك إعداد قواعد في Prometheus، إذا تحققت، يتم إرسال تنبيه إلى مكون آخر يسمى Alertmanager (يمكن إضافته أيضاً لـ Docker Compose)، والذي بدوره يرسل لك إشعاراً عبر Slack، البريد الإلكتروني، أو أي وسيلة أخرى.
على سبيل المثال، يمكننا كتابة قاعدة تنبيه بسيطة في ملف منفصل (e.g., alert.rules.yml) لتحذيرنا إذا انخفضت مساحة القرص الصلب عن 20%:
groups:
- name: NodeExporterAlerts
rules:
- alert: HostLowDiskSpace
expr: (node_filesystem_avail_bytes{mountpoint="/", fstype!="rootfs"} / node_filesystem_size_bytes{mountpoint="/", fstype!="rootfs"}) * 100 < 20
for: 2m
labels:
severity: warning
annotations:
summary: "Disk space is low on instance {{ $labels.instance }}"
description: "Only {{ $value | printf `%.2f` }}% of disk space is free on {{ $labels.instance }}."
هذه القاعدة تقول: “إذا كانت المساحة المتاحة على القرص أقل من 20% لمدة دقيقتين متواصلتين، أطلق تنبيهاً”. هذا هو جوهر المراقبة الاستباقية. الآن، بدلاً من أن نتعطل فجأة بسبب امتلاء القرص، سيصلنا إشعار قبلها بوقت كافٍ لاتخاذ إجراء.
الخلاصة: من إطفاء الحرائق إلى هندسة الوقاية 👨🚒➡️👷♂️
رحلتنا من المراقبة التفاعلية إلى الاستباقية لم تكن مجرد تغيير تقني، بل كانت تغييراً في العقلية. انتقلنا من فريق يعيش في خوف دائم من “ماذا سيتعطل بعد ذلك؟” إلى فريق واثق يمتلك الأدوات اللازمة لرؤية المشاكل قبل حدوثها.
قبل Prometheus و Grafana، كنا نعيش في جحيم “لماذا تعطل كل شيء فجأة؟”. الآن، نعيش في عالم من البيانات الواضحة والقرارات المستنيرة. لم نعد نطفئ الحرائق، بل أصبحنا نمنعها من الاشتعال أصلاً.
نصيحتي الأخيرة لك: المراقبة ليست ترفاً، بل هي أساس أي نظام برمجي ناجح ومستقر. ابدأ اليوم، ولو بخطوة صغيرة مثل التي شرحتها في هذا المقال، وستشكر نفسك كثيراً في المستقبل. ستنام قرير العين وأنت تعلم أن لديك عيوناً ساهرة لا تنام تراقب أنظمتك. 🚀
