أنظمتنا كانت صندوقًا أسود: كيف أنقذنا Prometheus و Grafana من جحيم الأعطال الصامتة؟

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

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

في نهاية ذلك الأسبوع المنهك، وبعد أن وجدنا المشكلة بالصدفة البحتة (تسريب في اتصالات قاعدة البيانات)، جلسنا معًا وقلنا: “خلص، بكفي! لازم نغير طريقة شغلنا. لا يمكن أن نبقى عميانًا هكذا”. من هنا بدأت رحلتنا مع ما يسمى بـ “قابلية المراقبة” (Observability)، وكانت بوابتنا لهذا العالم هي الأداتان الرائعتان: Prometheus و Grafana.

ما هو “الصندوق الأسود” الذي كنا نعيش فيه؟

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

هذا بالضبط كان حال أنظمتنا. كنا نطلق الكود إلى بيئة الإنتاج (Production) ونأمل خيرًا. كانت أدواتنا الوحيدة هي:

• سجلات الأخطاء (Logs): مفيدة بعد وقوع الكارثة، لكنها لا تمنعها. هي مثل تقرير الطبيب الشرعي، يخبرك بسبب الوفاة، لكنه لا ينقذ المريض.
• أداة `ping` البسيطة: تخبرنا إذا كان الخادم “حيًا” أم “ميتًا”، لكنها لا تخبرنا أي شيء عن “صحته”. قد يكون الخادم يعمل، لكنه يختنق من الداخل.

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

المنقذان: مقدمة سريعة عن Prometheus و Grafana

هنا يأتي دور البطلين في قصتنا. هما ليسا حلًا سحريًا، بل أدوات تتطلب فهمًا وعملًا، لكن نتائجهما كانت أشبه بالسحر بالنسبة لنا.

Prometheus: جامع البيانات الذي لا ينام

ببساطة، بروميثيوس هو نظام مراقبة وقاعدة بيانات متخصصة في تخزين “المقاييس” (Metrics) على شكل سلاسل زمنية (Time-series data). فكر فيه كشخص فضولي جدًا، كل بضع ثوانٍ، يذهب ويسأل كل جزء من نظامك: “مرحبًا أيها الخادم، كم استهلاك المعالج لديك الآن؟”، “مرحبًا أيتها الخدمة (Service)، كم عدد الطلبات التي تلقيتها في الدقيقة الأخيرة؟”، “مرحبًا يا قاعدة البيانات، كم عدد الاتصالات المفتوحة لديك؟”.

يقوم Prometheus بسحب (Pull) هذه المعلومات بشكل دوري وتخزينها مع طابع زمني دقيق. هذا يسمح لك بالعودة بالزمن ورؤية كيف كانت حالة النظام في أي لحظة. الجميل في Prometheus أنه لا يراقب فقط مقاييس البنية التحتية (CPU, RAM, Disk)، بل يمكنك جعله يراقب مقاييس خاصة بتطبيقك أنت (Custom Application Metrics)، مثل عدد المستخدمين المسجلين، عدد عمليات الشراء، إلخ.

Grafana: لوحة التحكم الفنية

إذا كان Prometheus هو جامع البيانات الدؤوب، فإن Grafana هو الفنان الذي يحول هذه البيانات الخام إلى لوحات فنية رائعة ومفهومة. Grafana هي أداة مفتوحة المصدر لتصوير البيانات (Data Visualization) وإنشاء لوحات تحكم (Dashboards).

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

باختصار: Prometheus يجمع البيانات، و Grafana يعرضها بشكل جميل ومفهوم.

رحلة التنفيذ: من النظرية إلى التطبيق العملي

الكلام النظري جميل، لكن “الشغل على الأرض” هو المحك الحقيقي. إليكم خطواتنا العملية التي اتبعناها.

الخطوة الأولى: تنصيب Prometheus وتكوينه

تنصيب Prometheus سهل نسبيًا، خاصة مع وجود Docker. لكن الجزء الأهم هو ملف الإعدادات `prometheus.yml`. هذا الملف يخبر Prometheus أين يجد “الأهداف” (Targets) التي يجب أن يسحب منها البيانات.

هذا مثال بسيط جدًا لملف `prometheus.yml`:

global:
  scrape_interval: 15s # كل كم ثانية يقوم بسحب البيانات

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

  - job_name: 'my-app' # اسم المهمة لمراقبة تطبيقنا
    static_configs:
      - targets: ['192.168.1.10:8080'] # عنوان IP ومنفذ تطبيقنا

في هذا المثال، نخبر Prometheus أن يسحب البيانات من نفسه (على المنفذ 9090) ومن تطبيقنا الذي يعمل على عنوان `192.168.1.10` والمنفذ `8080`.

الخطوة الثانية: جعل تطبيقاتنا “تتكلم” لغة Prometheus

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

لحسن الحظ، توجد مكتبات عميل (Client Libraries) لكل لغات البرمجة تقريبًا تجعل هذه العملية سهلة جدًا. هذه العملية تسمى “Instrumentation”.

مثال بسيط باستخدام Python و Flask:

from flask import Flask, Response
from prometheus_client import Counter, generate_latest

app = Flask(__name__)

# إنشاء عداد جديد لتتبع عدد الطلبات
http_requests_total = Counter('http_requests_total', 'Total number of HTTP requests')

@app.route('/')
def hello():
    # كلما تم طلب هذه الصفحة، قم بزيادة العداد
    http_requests_total.inc()
    return "Hello, World!"

@app.route('/metrics')
def metrics():
    # هذه هي نقطة النهاية التي سيزورها Prometheus
    return Response(generate_latest(), mimetype='text/plain; version=0.0.4')

if __name__ == '__main__':
    app.run(host='0.0.0.0', port=8080)

الآن، إذا قمت بتشغيل هذا التطبيق وزرت الصفحة الرئيسية (`/`) عدة مرات، ثم ذهبت إلى `/metrics`، سترى شيئًا كهذا:

# HELP http_requests_total Total number of HTTP requests
# TYPE http_requests_total counter
http_requests_total 5.0

هذا هو! تطبيقك الآن يتحدث لغة Prometheus.

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

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

بعد ذلك، تبدأ المتعة. لنقم بإنشاء أول لوحة (Panel) لنا لعرض معدل الطلبات على تطبيقنا:

1. أنشئ لوحة تحكم جديدة (New Dashboard) وأضف لوحة جديدة (Add Panel).
2. في حقل الاستعلام (Query)، اختر مصدر البيانات Prometheus.
3. اكتب استعلامًا بلغة PromQL. لعرض معدل الطلبات في آخر 5 دقائق، نكتب:

   rate(http_requests_total[5m])

4. اختر نوع الرسم البياني (مثلاً Time series).
5. احفظ اللوحة، وشاهد السحر يحدث! سترى رسمًا بيانيًا يتحدث مباشرة مع تطبيقك ويعرض معدل الطلبات عليه بشكل حي.

النتائج المذهلة: كيف تغير كل شيء؟

بعد تطبيق هذا النظام، تغيرت طريقة عملنا جذريًا. لم نعد ننتظر شكاوى المستخدمين.

• اكتشاف الأعطال الصامتة: في إحدى المرات، لاحظنا من خلال رسم بياني في Grafana أن استخدام الذاكرة لإحدى خدماتنا يزداد ببطء وبشكل ثابت (Memory Leak). لم يكن قد سبب أي مشكلة بعد، لكننا علمنا أنه قنبلة موقوتة. تمكنا من تحليل المشكلة وإصلاحها ونشر التحديث قبل أن يشعر أي مستخدم بأي شيء.
• فهم أعمق للنظام: أصبحنا نرى العلاقة بين ارتفاع عدد المستخدمين النشطين وزيادة الحمل على قاعدة البيانات. هذا ساعدنا في تحسين استعلاماتنا (Queries) وتوسيع البنية التحتية بشكل مدروس.
• نوم هانئ وثقة أكبر: الأهم من كل شيء، هو راحة البال. أصبح لدينا “عيون” داخل النظام. قمنا بإعداد تنبيهات (Alerts) باستخدام Alertmanager (رفيق Prometheus)، بحيث يرسل لنا إشعارًا إذا تجاوز استخدام المعالج حدًا معينًا، أو إذا زاد معدل الأخطاء. لم نعد نخاف من عطلة نهاية الأسبوع.

نصائح من قلب المعركة (من خبرة أبو عمر)

إذا كنت تفكر في سلوك هذا الطريق، اسمح لي أن أقدم لك بعض النصائح العملية:

• ابدأ بسيطًا: لا تحاول مراقبة كل شيء من اليوم الأول. ابدأ بمقاييس البنية التحتية الأساسية (CPU, Memory, Disk) ثم أضف مقياسًا أو اثنين من أهم المقاييس في تطبيقك (مثل عدد الطلبات ومعدل الأخطاء).
• راقب ما يهم حقًا: هناك مفهوم يسمى “The Four Golden Signals” (الإشارات الذهبية الأربع) من Google، وهو نقطة بداية ممتازة:
  1. الكمون (Latency): كم من الوقت يستغرقه طلب الخدمة للرد.
  2. حجم الحركة (Traffic): مدى الطلب على نظامك (مثل الطلبات في الثانية).
  3. الأخطاء (Errors): معدل الطلبات التي تفشل.
  4. التشبع (Saturation): مدى “امتلاء” خدمتك (مثل استخدام الذاكرة أو المعالج).
• التنبيهات أهم من لوحات التحكم: لوحة التحكم رائعة، لكن لا أحد يراقبها 24/7. الأهم هو إعداد تنبيهات ذكية وفعالة (Alerting) تخبرك بالمشكلة عندما تحدث. استخدم Alertmanager مع Prometheus لهذا الغرض.
• اجعل المقاييس ثقافة: لا تجعل المراقبة مهمة شخص واحد. اعرض لوحات التحكم على شاشات في المكتب. ناقش الرسوم البيانية في اجتماعات الفريق. عندما يرى المطورون تأثير الكود الذي يكتبونه مباشرة على أداء النظام، يصبحون أكثر حرصًا ومسؤولية.

الخلاصة: لا تقبل بالصناديق السوداء 🚫

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

لا تنتظر حتى تحترق أنظمتك وتقضي عطلة نهاية الأسبوع في إطفاء الحرائق. ابدأ اليوم، ولو بخطوة صغيرة. أعطِ أنظمتك صوتًا لتخبرك عندما تتألم، قبل أن تصرخ. صدقني، ستشكر نفسك لاحقًا. بالتوفيق! 💪