مراقبة الأنظمة باستخدام Prometheus وGrafana

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

وعندما نتحدث عن المراقبة الحديثة، يظهر اسمان لا يكاد أي فريق DevOps أو SRE يتجاوزهما: Prometheus وGrafana. الأول يتولى جمع المقاييس وتخزينها والاستعلام عنها، والثاني يحول الأرقام الجافة إلى لوحات مفهومة بصريًا تساعدك على رؤية صحة النظام في لحظتها. والجميل في هذا الثنائي أنه لا يقتصر على الشركات الكبيرة، بل يمكن لأي مطور أو فريق صغير أن يبدأ به ويستفيد منه منذ اليوم الأول. أنت لا تحتاج إلى بنية معقدة كي تستفيد من الرؤية؛ أحيانًا يكفي أن ترى استهلاك CPU، الذاكرة، زمن الاستجابة، وعدد الأخطاء لتكتشف نصف المشاكل قبل أن تتحول إلى أزمة.

لماذا نحتاج إلى مراقبة الأنظمة أصلًا؟

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

المراقبة الجيدة لا تعني فقط اكتشاف الأعطال بعد وقوعها، بل تعني أيضًا فهم السلوك الطبيعي للنظام. عندما تعرف أن استهلاك الذاكرة عادةً يكون بين 40% و55% ثم تراه يقفز إلى 92% بشكل مفاجئ، يصبح لديك إنذار مبكر قبل الانهيار. وعندما ترى أن زمن الاستجابة كان 120ms ثم صار 900ms بعد تحديث معيّن، فهذه إشارة مهمة جدًا لمراجعة ما نُشر. المراقبة تمنحك ذاكرة رقمية؛ فهي تحفظ لك ما لا يستطيع الإنسان تذكّره بدقة.

ما هو Prometheus؟

Prometheus هو نظام مفتوح المصدر لمراقبة المقاييس، صُمم لجمع البيانات الزمنية Time Series Data، أي البيانات التي تتغير مع الوقت مثل استهلاك المعالج، حجم الذاكرة، عدد الطلبات، الأخطاء، أو طول الطوابير. يعتمد على نموذج بسيط وفعال: أنت تعرض المقاييس من خلال endpoint خاص غالبًا بصيغة /metrics، ثم يقوم Prometheus بسحبها دوريًا عبر ما يسمى Pull Model.

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

ما هو Grafana؟

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

ميزة Grafana ليست فقط في الجمال البصري، بل في طريقة تحويل البيانات إلى قصة مفهومة. بدل أن ترى عشرات القيم المتفرقة، يمكنك أن تبني لوحة تبين CPU، الذاكرة، نسبة الأخطاء، زمن الاستجابة، وعدد الطلبات في نفس الشاشة. بهذه الطريقة تصبح لديك صورة متكاملة عن النظام، لا مجرد أرقام متناثرة. وفي لحظات التوتر، عندما يحدث خلل فعلي، تكون الشاشة الجيدة أقرب إلى صديق صادق يخبرك أين تبدأ البحث.

الفكرة المعمارية: كيف يعمل Prometheus مع Grafana؟

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

يمكن تلخيص المسار كالتالي:
التطبيق أو النظام ➜ exporter أو endpoint metrics ➜ Prometheus ➜ Grafana

هذا يعني أنك لا تعرض تطبيقك مباشرة للمراقبة البصرية، بل تجعل Prometheus هو الوسيط المنظم. ومع الوقت، يمكنك إضافة التنبيهات عبر Alertmanager، وتوسيع النظام ليشمل خوادم متعددة، قواعد بيانات، حاويات Docker، أو عنقود Kubernetes كامل.

المفاهيم الأساسية التي يجب فهمها

قبل الدخول في التطبيق العملي، من المفيد فهم بعض المصطلحات التي ستقابلها كثيرًا. المقاييس Metrics هي الأرقام التي نقيسها بمرور الوقت. السلاسل الزمنية Time Series هي تلك المقاييس عندما يتم تسجيلها مع طابع زمني. الـ Labels هي وسوم تضيفها للمقياس كي تتمكن من التمييز بين الخدمات أو الحالات المختلفة. مثلًا، قد يكون لديك مقياس لعدد الطلبات مع label يحدد اسم الخدمة أو نوع الطلب أو حالة الاستجابة.

هناك أيضًا أنواع مختلفة من المقاييس في Prometheus مثل Counter وGauge وHistogram وSummary. الـ Counter يزداد فقط، مثل عدد الطلبات الناجحة. الـ Gauge يمكن أن يزيد أو ينقص، مثل استخدام الذاكرة. الـ Histogram يستخدم لتوزيع القيم ضمن buckets، وهو مفيد جدًا لقياس أزمنة الاستجابة. أما Summary فيعطي تصورًا إحصائيًا متقدمًا عن القيم المقاسة.

فهم هذه الأنواع ليس تفصيلًا نظريًا فقط، بل هو ما يحدد كيف تصمم مراقبتك. إذا استخدمت Counter لمشكلة تحتاج Gauge، أو العكس، ستنتهي بلوحات مضللة لا تعكس الواقع بدقة. والمراقبة السيئة قد تكون أخطر من غياب المراقبة، لأنها تمنحك إحساسًا زائفًا بالأمان.

تثبيت Prometheus بسرعة

يمكن تشغيل Prometheus بعدة طرق: من الحزمة الثنائية، عبر Docker، أو داخل Kubernetes. ولأن كثيرًا من الفرق تبدأ بسرعة عبر Docker، فإليك مثالًا عمليًا بسيطًا باستخدام Docker Compose.

version: "3.8"

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

volumes:
  prometheus_data:

ثم ملف الإعدادات الأساسي:

global:
  scrape_interval: 15s
  evaluation_interval: 15s

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

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

إضافة Node Exporter لمراقبة الخادم

إذا أردت مراقبة السيرفر نفسه، مثل CPU والذاكرة والقرص والشبكة، فـ Node Exporter هو الخيار الأشهر. هذا الـ exporter يوفّر للمرة الأولى نظرة دقيقة على حالة الجهاز الذي يعمل عليه. ويمكن تشغيله بسهولة أيضًا عبر Docker Compose.

version: "3.8"

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

ثم نضيفه إلى Prometheus:

global:
  scrape_interval: 15s
  evaluation_interval: 15s

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

  - job_name: "node_exporter"
    static_configs:
      - targets: ["localhost:9100"]

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

فهم PromQL بطريقة عملية

لغة PromQL هي القلب التحليلي في Prometheus. من خلالها تستطيع استخراج المعنى من البيانات الخام. على سبيل المثال، لمعرفة نسبة استخدام المعالج، أو معدل الطلبات، أو متوسط زمن الاستجابة، تحتاج إلى استعلامات دقيقة. لا توجد حاجة لحفظ كل شيء عن ظهر قلب في البداية، لكن المهم أن تفهم المنطق.

إذا كان لديك Counter لعدد الطلبات، فغالبًا ستستخدم rate() لمعرفة معدل الزيادة خلال فترة زمنية. وإذا أردت معرفة قيمة حالية مثل استهلاك الذاكرة، فغالبًا ستتعامل مع Gauge. مثال عملي:

rate(http_requests_total[5m])

هذا الاستعلام يعطينا معدل الطلبات في آخر 5 دقائق. أما إذا أردت النسبة المئوية للخطأ، فقد تستخدم شيئًا شبيهًا بـ:

sum(rate(http_requests_total{status=~"5.."}[5m])) 
/
sum(rate(http_requests_total[5m])) * 100

هذا النوع من الاستعلامات يتيح لك أن ترى جودة الخدمة من خلال نسبة الأخطاء، وليس فقط عدد الطلبات. لأن الرقم الكبير وحده لا يهم دائمًا؛ قد تكون الخدمة تستقبل آلاف الطلبات، لكن 8% منها تفشل، وهذه مشكلة حقيقية حتى لو بدا الرسم البياني مزدحمًا ومطمئنًا في الظاهر.

مراقبة تطبيق ويب بسيط

لنفترض أن لديك تطبيقًا مبنيًا بـ Python Flask وتريد مراقبته. يمكنك استخدام مكتبة Prometheus الرسمية لعرض المقاييس. المثال التالي يوضح كيف تعرض عدد الطلبات وزمن الاستجابة.

from flask import Flask, Response
from prometheus_client import Counter, Histogram, generate_latest, CONTENT_TYPE_LATEST
import time

app = Flask(__name__)

REQUEST_COUNT = Counter('app_requests_total', 'Total number of requests')
REQUEST_LATENCY = Histogram('app_request_latency_seconds', 'Request latency in seconds')

@app.route("/")
def home():
    REQUEST_COUNT.inc()
    start_time = time.time()
    time.sleep(0.2)  # محاكاة بعض العمل
    REQUEST_LATENCY.observe(time.time() - start_time)
    return "Hello from monitored app!"

@app.route("/metrics")
def metrics():
    return Response(generate_latest(), mimetype=CONTENT_TYPE_LATEST)

if __name__ == "__main__":
    app.run(host="0.0.0.0", port=5000)

بعد تشغيل التطبيق، سيبدأ Prometheus بسحب /metrics مثل أي مصدر بيانات آخر. هذه الفكرة ممتازة لأنها تسمح لك بمراقبة تطبيقك من الداخل. لم تعد تعتمد فقط على مراقبة النظام على مستوى الخادم، بل أضفت رؤية داخلية لسلوك التطبيق نفسه.

مثال بلغة PHP/Laravel

كثير من المواقع العربية تعمل على Laravel أو PHP، ومن المهم جدًا أن يكون لديك تصور واضح عن مراقبة التطبيقات بهذه البيئة أيضًا. في Laravel يمكنك إنشاء middleware أو service بسيطة لقياس الطلبات أو زمن التنفيذ ثم تصديرها بطريقة مناسبة. ليس المطلوب دائمًا أن تبني كل شيء من الصفر؛ أحيانًا يكفي استخدام مكتبة جاهزة، لكن من المفيد أن تفهم المبدأ.

مثال مبسط جدًا لفكرة قياس زمن التنفيذ داخل middleware:

<?php

namespace App\Http\Middleware;

use Closure;
use Illuminate\Support\Facades\Log;

class TrackRequestTime
{
    public function handle($request, Closure $next)
    {
        $start = microtime(true);

        $response = $next($request);

        $duration = microtime(true) - $start;

        Log::info('Request duration', [
            'path' => $request->path(),
            'duration_seconds' => $duration,
        ]);

        return $response;
    }
}

هذا المثال لا يصدر المقاييس مباشرة إلى Prometheus، لكنه يوضح الفكرة: أن تبدأ بجمع إشارة مفيدة عن السلوك، ثم تربطها لاحقًا بنظام مراقبة مناسب. في البيئات الاحترافية، ستفضل إرسال metric proper إلى endpoint /metrics بدل الاعتماد على logs فقط، لأن metrics أسهل في التتبع على مدى طويل وأكثر ملاءمة للرسوم البيانية والتنبيهات.

لماذا تُعد الـ exporters مهمة جدًا؟

الـ exporters هي الجسر بين Prometheus ومصادر البيانات المختلفة. هناك Exporter للنظام، Exporter لـ MySQL، Exporter لـ PostgreSQL، Exporter لـ Redis، Exporter لـ Nginx، وحتى Exporters لأنظمة خاصة جدًا. الفكرة أن Prometheus يظل موحدًا في طريقة جمع البيانات، بينما تتكفل الـ exporters بتوفير المقاييس من الخدمات المختلفة.

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

بناء Dashboard احترافية في Grafana

عندما تبدأ في Grafana، قد تميل إلى وضع كل شيء في شاشة واحدة. لكن اللوحات الجيدة ليست مكتظة، بل واضحة ومركزة. لوحة المراقبة الناجحة تعطيك الجواب عن أسئلة محددة: هل النظام صحي؟ هل هناك ضغط على CPU؟ هل الذاكرة في خطر؟ هل زاد عدد الأخطاء؟ هل زمن الاستجابة مستقر؟ هل قاعدة البيانات بدأت تتأخر؟

في Grafana يمكنك إنشاء dashboard تضم panels متنوعة: Graphs، Stat، Gauge، Table، Heatmap، وTime series. على سبيل المثال، يمكنك بناء لوحة للخادم تشمل:

• نسبة CPU

• الذاكرة المستعملة

• المساحة على القرص

• عدد الطلبات في الدقيقة

• نسبة الأخطاء

• متوسط زمن الاستجابة

إحدى أهم المهارات هنا هي اختيار المقاييس المناسبة لكل لوحة. ليس كل رقم يستحق أن يوضع في صفحة المراقبة الرئيسية. عليك أن تفكر كما يفكر المشغل أثناء الأزمة: ما أول شيء أريد أن أعرفه؟ وما المؤشر الذي سيخبرني بسرعة أين أبحث؟

مثال على إعداد Grafana مع Prometheus عبر Docker Compose

version: "3.8"

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

  grafana:
    image: grafana/grafana:latest
    container_name: grafana
    ports:
      - "3000:3000"
    environment:
      - GF_SECURITY_ADMIN_USER=admin
      - GF_SECURITY_ADMIN_PASSWORD=admin123
    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:
  prometheus_data:
  grafana_data:

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

التنبيهات: لأن الرؤية وحدها لا تكفي

المراقبة بدون تنبيهات تشبه كاميرا المراقبة من دون حارس ينظر إليها. أنت ترى ما يحدث، لكنك لا تُنبّه عندما يتجاوز النظام الحد المقبول. هنا يأتي دور Alerting، وغالبًا يُستخدم معه Alertmanager في منظومة Prometheus.

يمكنك أن تكتب قواعد تنبيه عندما يرتفع CPU لفترة طويلة، أو عندما تمتلئ المساحة، أو عندما تتجاوز نسبة الأخطاء حدًا معينًا. مثال لقاعدة تنبيه بسيطة:

groups:
  - name: system-alerts
    rules:
      - alert: HighCPUUsage
        expr: avg(rate(node_cpu_seconds_total{mode!="idle"}[5m])) * 100 > 80
        for: 5m
        labels:
          severity: warning
        annotations:
          summary: "High CPU usage detected"
          description: "CPU usage is above 80% for more than 5 minutes."

هذا المثال يوضح فكرة مهمة جدًا: لا تطلق التنبيه بسبب لحظة عابرة، بل استخدم for للتأكد من أن الحالة مستمرة. لأن الأنظمة الحقيقية فيها تقلبات طبيعية، ولو أزعجت نفسك بتنبيهات كاذبة كثيرة فسوف تفقد ثقتك في التنبيه كله. التنبيه الجيد ليس الأكثر عددًا، بل الأكثر صدقًا.

مراقبة قواعد البيانات

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

في MySQL مثلًا يمكنك استخدام mysql_exporter لمراقبة الاتصالات المفتوحة، معدل الاستعلامات، الأخطاء، القفل، ومؤشرات الأداء الأساسية. في PostgreSQL توجد أيضًا صادرات مشابهة. وهنا تتضح قيمة Prometheus: لا يهم نوع النظام طالما يوجد طريقة لتصدير المقاييس. يمكنك أن ترى التأثير الحقيقي على استقرار الخدمة بدل الاكتفاء بالتخمين.

عند مراقبة قاعدة البيانات، لا تركز فقط على عدد الاتصالات. أحيانًا العدد ليس المشكلة، بل زمن الاستجابة، أو عدد الاستعلامات البطيئة، أو التخزين المؤقت، أو القفل. ومن المفيد جدًا أن تربط لوحات قاعدة البيانات مع لوحات التطبيق. عندما ترى ارتفاعًا في زمن الاستجابة في نفس الدقيقة التي ارتفع فيها lock wait، تصبح القصة أوضح بكثير.

مراقبة Docker

إذا كانت خدماتك تعمل داخل حاويات، فالمراقبة تصبح أكثر أهمية، لأن الحاوية قد تبدو خفيفة من الخارج بينما تستهلك الموارد من الداخل بشكل غير متوقع. يمكنك مراقبة مضيف Docker عبر Node Exporter، كما يمكنك تتبع أداء الحاويات نفسها باستخدام cAdvisor أو أدوات أخرى متخصصة.

هذا مفيد عندما يكون لديك عدة خدمات تعمل معًا: API، worker، cache، database، reverse proxy. في بيئة كهذه، يصعب جدًا فهم المشكلة من سجل التطبيق وحده. أما عندما ترى استهلاك الموارد على مستوى الحاويات والخادم معًا، يصبح التشخيص أكثر نضجًا. ستعرف مثلًا أن خدمة worker هي التي تستهلك الذاكرة، أو أن حاوية معينة تعيد التشغيل باستمرار، أو أن الازدحام سببه خدمة خارجية محددة.

مراقبة Kubernetes

في Kubernetes، تصبح المراقبة جزءًا من البنية نفسها. عدد الـ pods، حالة الـ deployments، rescheduling، readiness، liveness، استهلاك العقد، وحجم الـ requests كلها عناصر مهمة جدًا. وغالبًا يتم استخدام Prometheus وGrafana داخل الـ cluster أو خارجه لمراقبة البنية كلها.

في هذه البيئة، من المفيد جدًا استخدام kube-state-metrics مع node exporter وPrometheus، لأن كل واحد منها يغطي زاوية مختلفة. kube-state-metrics يعرض الحالة المنطقية للـ Kubernetes objects، بينما node exporter يراقب العقد نفسها، وPrometheus يجمع كل ذلك في مكان واحد. وهنا يمكن بناء لوحات تعرض:

• عدد الـ pods الجاهزة

• الـ deployments غير المستقرة

• استهلاك كل node

• أخطاء الـ scheduling

• زمن بدء الحاويات

وفي الواقع، أهم ما يميز المراقبة في Kubernetes هو أنها تمنعك من النظر إلى التطبيق فقط، وتدفعك إلى رؤية النظام كمنظومة كاملة. فالمشكلة قد لا تكون في الكود أصلًا، بل في جدولة الموارد أو limits أو الشبكة الداخلية أو policy معينة.

أفضل الممارسات في تصميم المراقبة

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

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

ومن المهم كذلك أن تسمي المقاييس بوضوح. الأسماء الغامضة تجعل اللوحات مربكة بعد فترة. استخدم أسماء تعبر عن الشيء المقاس مباشرة، وراعِ أن تكون labels مفيدة وليست كثيرة بشكل مبالغ فيه. كثرة الـ labels قد تسبب تعقيدًا وعبئًا على التخزين والتحليل. المراقبة الجيدة نظيفة ومحددة، وليست فوضى مبهرة.

الأخطاء الشائعة التي يقع فيها كثير من الفرق

أحد أكثر الأخطاء شيوعًا هو بناء dashboard جميلة جدًا لكنها لا تُستخدم وقت الحاجة. بعض اللوحات تبدو احترافية لكنها لا تجيب عن أي سؤال عملي. الخطأ الثاني هو الاعتماد على metrics دون logs أو traces. المراقبة الحديثة تُبنى غالبًا على ثلاثية: metrics وlogs وtraces. كل واحدة تكمل الأخرى، وغياب إحداها يترك فراغًا في الصورة.

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

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

مثال عملي على تنبيه المساحة على القرص

groups:
  - name: disk-alerts
    rules:
      - alert: DiskSpaceAlmostFull
        expr: (node_filesystem_avail_bytes{fstype!="tmpfs"} / node_filesystem_size_bytes{fstype!="tmpfs"}) * 100 < 10
        for: 10m
        labels:
          severity: critical
        annotations:
          summary: "Disk space is almost full"
          description: "Available disk space is below 10% for more than 10 minutes."

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

كيف تنقل المراقبة من مرحلة التجربة إلى مرحلة الإنتاج؟

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

من الجيد أيضًا أن تعتمد naming convention واضحة للـ jobs والـ instances والـ labels. وعندما تكبر البنية، ستفرح جدًا أنك بدأت بنظام مرتب منذ البداية. كذلك لا تنس التوثيق الداخلي. اكتب ماذا تعني كل لوحة، وماذا يفعل كل تنبيه، ومن المسؤول عن الاستجابة عند حدوثه. لأن المراقبة ليست مشروعًا فرديًا؛ إنها معرفة جماعية داخل الفريق.

الجانب الإنساني في المراقبة

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

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

خلاصة عملية

إذا أردت البدء اليوم، فابدأ بخطوات صغيرة وواضحة. ثبّت Prometheus، أضف Node Exporter، اربط Grafana، ثم ابنِ لوحة بسيطة تعرض CPU والذاكرة والقرص وزمن الاستجابة. بعد ذلك أضف تنبيهًا واحدًا مهمًا، مثل امتلاء القرص أو ارتفاع الأخطاء. ثم وسّع المراقبة تدريجيًا إلى التطبيق وقاعدة البيانات والحاويات.

لا تحاول بناء “منظومة مثالية” من اليوم الأول. الأفضل أن تبني منظومة مفهومة ومفيدة، ثم تطورها باستمرار. المراقبة الناجحة ليست مشروعًا يُنجز مرة واحدة، بل عادة تشغيلية تنمو مع النظام. وكلما كانت بياناتك أوضح، كان قراراتك أفضل، وكانت خدمة المستخدمين أكثر استقرارًا.

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