مقارنة أدوات المراقبة: Prometheus مقابل New Relic مقابل Grafana

في أي بنية تحتية حديثة للتطبيقات (خاصة تطبيقات الويب والميكرو سيرفيس)، تصبح مراقبة الأداء Prometheus Grafana New Relic جزءًا أساسيًا من نجاح المشروع. بدون مراقبة جيدة لن تعرف:

• لماذا التطبيق بطيء فجأة؟
• هل المشكلة من قاعدة البيانات أم الشبكة أم الكود نفسه؟
• هل تحتاج إلى توسيع الخوادم أم تحسين الاستعلامات؟

في هذا المقال سنقدّم مقارنة عملية بين ثلاث من أشهر أدوات المراقبة: Prometheus، Grafana، New Relic، مع التركيز على:

• متى تستخدم كل أداة؟
• آليات جمع المقاييس (Metrics) من تطبيقات بايثون وDjango
• ميزات التنبيه (Alerting) ولوحات العرض (Dashboards)
• كيف تختار الحل الأنسب لبنيتك التحتية؟

إذا كنت مهتمًا أكثر بالجانب البرمجي في بايثون، يمكنك الرجوع أيضًا إلى: تعلم لغة برمجة بايثون، أو البرمجة غير المتزامنة في بايثون لفهم تأثير النماذج المختلفة على الأداء.

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

قبل أن نقارن بين الأدوات، يجب أن نفهم ما الذي نراقبه بالضبط في بيئة الإنتاج:

• مقاييس البنية التحتية: CPU، RAM، I/O، الشبكة.
• مقاييس التطبيق: زمن الاستجابة، عدد الطلبات في الثانية، أخطاء HTTP.
• مقاييس قواعد البيانات: زمن تنفيذ الاستعلامات، عدد الاتصالات، عدد الـ Locks.
• Logs وسلاسل التتبّع (Traces) في الأنظمة الموزعة.

أي أداة مراقبة جدية يجب أن توفّر على الأقل:

1. جمع المقاييس من مصادر مختلفة (Scraping أو Agents).
2. تخزين المقاييس مع دعم الاستعلام الزمني.
3. إنشاء لوحات تحكم (Dashboards) لعرض الأداء بشكل بصري.
4. نظام تنبيه (Alerts) يعتمد على قواعد أو ذكاء اصطناعي.

نظرة عامة سريعة على كل أداة

1. ما هو Prometheus؟

Prometheus هو نظام مفتوح المصدر لجمع المقاييس الزمنية (Time-Series Metrics)، طُوّر في الأصل داخل شركة SoundCloud وأصبح اليوم جزءًا من Cloud Native Computing Foundation (CNCF). أهم خصائصه:

• يعمل بأسلوب Pull: يقوم بقراءة المقاييس من Endpoints (مثل /metrics في تطبيقك).
• يخزن البيانات في قاعدة زمنية مدمجة به.
• يدعم لغة استعلام قوية PromQL.
• مصمم للبيئات السحابية وKubernetes وميكرو سيرفيس.

Prometheus ممتاز لـ:

• مراقبة البنية التحتية (خوادم، حاويات، Kubernetes Nodes).
• مراقبة تطبيقات الويب والخدمات الصغيرة (Microservices).
• الأنظمة التي تحتاج إلى تحكم كامل، بدون إرسال بيانات لطرف ثالث.

2. ما هو Grafana؟

Grafana ليست أداة لجمع المقاييس بحد ذاتها، بل هي منصة Visualization وDashboards. تُستخدم عادةً مع قواعد بيانات للمقاييس مثل Prometheus، InfluxDB، Loki، Elasticsearch، وغيرها.

• يمكن ربطها مع عشرات Data Sources مختلفة.
• توفّر لوحات جاهزة Templates لمراقبة Linux، Nginx، PostgreSQL… إلخ.
• تدعم التنبيهات Alerts (خاصة في الإصدارات الحديثة).

بعبارة بسيطة: كثيرون يخلطون بين Prometheus وGrafana، لكنهما مكملان لبعضهما: Prometheus يجمع ويخزن المقاييس، وGrafana تعرضها في Dashboards مرئية.

3. ما هو New Relic؟

New Relic هي منصة مدفوعة (مع طبقة مجانية محدودة) لمراقبة الأداء تشمل:

• APM (Application Performance Monitoring)
• Logs
• Metrics
• Traces

تتميز New Relic بـ:

• سهولة التركيب: فقط تثبيت Agent في السيرفر أو داخل التطبيق.
• دعم لغات عديدة: Python، Java، .NET، Node.js، PHP، Go… إلخ.
• لوحات جاهزة، وتشخيص تلقائي لمشاكل الأداء (Bottlenecks).
• إمكانيات قويّة لـ Distributed Tracing وError Analytics.

من أشهر حالات استخدام New Relic: فرق DevOps والشركات التي تريد حلاً جاهزًا بالكامل مع دعم وخدمات سحابية.

مقارنة معمارية بين Prometheus وNew Relic وGrafana

طريقة جمع المقاييس

• Prometheus: يعتمد أسلوب Pull – يزور Endpoints ويقوم بـ Scrape للمقاييس المُعرّضة (Exposed) بتنسيق خاص.
• New Relic: يعتمد غالبًا أسلوب Agent – برنامج مُثبّت على السيرفر أو ضمن التطبيق يرسل بيانات إلى سحابة New Relic (Push).
• Grafana: لا تجمع مقاييس بنفسها؛ بل تقرأ وتعرض بيانات من Data Sources أخرى.

التخزين (Storage)

• Prometheus: يحتوي على Storage داخلي، يمكن توسيعه عبر حلول مثل Thanos أو Cortex.
• New Relic: Managed Storage في السحابة (لا تحتاج للتفكير في إدارة التخزين).
• Grafana: لا تخزن المقاييس نفسها، فقط إعدادات الداشبورد والتنبيهات، وتعتمد على الـ Data Source لتخزين المقاييس.

لوحات التحكم (Dashboards)

• Prometheus: الواجهة الأساسية للاستعلام فقط، ليست قوية بصريًا.
• Grafana: الأقوى في الداشبورد، مرونة عالية في الرسم والفلترة والتحكم.
• New Relic: توفر Dashboards جاهزة ومتقدمة مرتبطة بـ APM وLogs وTraces.

الترخيص والتكلفة

• Prometheus: مجاني ومفتوح المصدر، لكن تحتاج بنيتك الخاصة أو Kubernetes/Cloud.
• Grafana: نسخة Community مجانية، ونسخ Enterprise مدفوعة، مع خدمة Grafana Cloud.
• New Relic: نموذج SaaS مدفوع بالاشتراك، مع طبقة مجانية محدودة (عدد Events/GB معين).

جمع المقاييس من تطبيقات بايثون وDjango باستخدام Prometheus

1. إعداد تطبيق بايثون بسيط مع Prometheus

سنفترض أنّ لديك خدمة بسيطة مكتوبة بـ Python، وتريد تعريض مقاييسها ليراقبها Prometheus.

الخطوة 1: تثبيت مكتبة prometheus_client

pip install prometheus_client

الخطوة 2: إنشاء مقاييس بسيطة

مثال Service HTTP بسيط باستخدام مكتبة prometheus_client فقط:

from prometheus_client import start_http_server, Counter, Histogram
import time
import random

REQUEST_COUNT = Counter(
    'app_request_count',
    'Total number of requests',
    ['method', 'endpoint']
)

REQUEST_LATENCY = Histogram(
    'app_request_latency_seconds',
    'Request latency',
    ['endpoint']
)

def process_request(endpoint: str):
    REQUEST_COUNT.labels(method='GET', endpoint=endpoint).inc()
    with REQUEST_LATENCY.labels(endpoint=endpoint).time():
        # منطق العمل الفعلي
        time.sleep(random.uniform(0.1, 0.5))

if __name__ == '__main__':
    # فتح منفذ لتقديم /metrics
    start_http_server(8000)
    while True:
        process_request('/hello')
        time.sleep(1)

عند تشغيل هذه الخدمة، سيصبح Endpoint http://localhost:8000/metrics متاحًا، ويمكن لـPrometheus قراءته.

2. جمع المقاييس من تطبيق Django

لـ Django هناك مكتبات جاهزة تجعل الأمر أسهل كثيرًا مثل django-prometheus.

الخطوة 1: تثبيت django-prometheus

pip install django-prometheus

الخطوة 2: تعديل settings.py

INSTALLED_APPS = [
    'django_prometheus',
    # ...
]

MIDDLEWARE = [
    'django_prometheus.middleware.PrometheusBeforeMiddleware',
    # بقية الـ Middleware العادية
    'django_prometheus.middleware.PrometheusAfterMiddleware',
]

الخطوة 3: تعديل urls.py

from django.urls import path, include

urlpatterns = [
    # ...
    path('', include('django_prometheus.urls')),
]

بهذه الخطوات، سيقوم django-prometheus تلقائيًا بتعريض مقاييس مثل:

• عدد الطلبات لكل View
• زمن استجابة الـ Views
• أخطاء DB، وعدد Queries، … إلخ

غالبًا سيكون Endpoint اسمه /metrics أو حسب تعريفك في الـ URL، وهنا يأتي دور Prometheus لعمل Scrape بشكل دوري.

3. إعداد Prometheus لقراءة المقاييس من Django

ملف إعداد Prometheus غالبًا اسمه prometheus.yml، يمكنك إضافة Job جديد:

scrape_configs:
  - job_name: 'django-app'
    static_configs:
      - targets: ['your-django-hostname:8000']

بهذا الشكل، Prometheus سيزور http://your-django-hostname:8000/metrics باستمرار لجمع المقاييس.

جمع المقاييس من بايثون وDjango باستخدام New Relic

1. إنشاء حساب وتثبيت Agent بايثون

• تقوم بإنشاء حساب في New Relic.
• تدخل إلى قسم APM > Add more data > Python.
• ستجد أوامر مخصّصة مثل:

pip install newrelic

ثم يتم إنشاء ملف إعداد newrelic.ini بواسطة:

newrelic-admin generate-config YOUR_LICENSE_KEY newrelic.ini

2. تشغيل تطبيق Django مع New Relic

بدلًا من تشغيل تطبيقك بأمر مباشر مثل:

gunicorn myproject.wsgi

ستستخدم:

NEW_RELIC_CONFIG_FILE=newrelic.ini newrelic-admin run-program \
    gunicorn myproject.wsgi

New Relic Agent سيبدأ في:

• قياس زمن الاستجابة لكل View.
• تحليل استعلامات قاعدة البيانات.
• جمع الأخطاء واستثناءات Python.
• إرسال كل تلك البيانات في الخلفية إلى منصة New Relic.

ميزة New Relic أنها تحتاج إعداد أقل في الكود نفسه، وغالبًا لا تضطر لتعديل الدوال والفيوز بنفسك، لأن Agent يحقن نفسه في طبقات Django وWSGI.

3. متى تفضّل New Relic مع بايثون وDjango؟

• لو كنت تريد APM كامل بسرعة، مع Traces وTransaction Details جاهزة.
• لو لا تريد إدارة Prometheus/Grafana بنفسك.
• لو البيئة Production لديك على خوادم متعددة وتريد واجهة موحّدة وسحابيّة.

استخدام Grafana مع Prometheus لعرض المقاييس

التركيب الأكثر شيوعًا في عالم المراقبة مفتوحة المصدر هو: Prometheus + Grafana.

1. ربط Grafana مع Prometheus

بعد تثبيت Grafana والدخول للوحة التحكم:

1. اذهب إلى Configuration > Data Sources.
2. اختر Prometheus.
3. أدخل عنوان Prometheus (مثل: http://prometheus:9090).
4. احفظ الإعدادات.

2. إنشاء Dashboard لمراقبة Django

يمكنك إما:

• استيراد Dashboard جاهز من Grafana Labs (ابحث عن “Django Prometheus”).
• أو إنشاء Dashboard جديد، إضافة Panels، وكتابة استعلامات PromQL مثل:

rate(app_request_count[5m])

أو:

histogram_quantile(0.95, sum(rate(app_request_latency_seconds_bucket[5m])) by (le))

بهذه الطريقة تحصل على:

• معدل الطلبات في الثانية RPS.
• زمن استجابة P95 أو P99.
• مقارنة الـ Endpoints المختلفة في Django.

3. إعداد التنبيهات في Grafana

ابتداءً من الإصدارات الحديثة، Grafana تحتوي على Unified Alerting، يمكن إضافة قواعد مثل:

• لو تجاوز P95 latency قيمة معينة لمدة 5 دقائق.
• لو زاد عدد أخطاء HTTP 5xx عن نسبة معينة.

وتستطيع إرسال التنبيهات إلى:

• Slack
• Microsoft Teams
• Email
• Webhook (لأي نظام خارجي)

مقارنة ميزات التنبيه واللوحات بين الأدوات

Prometheus Alertmanager

• يُستخدم مع Prometheus لعمل إدارة لتنبيهات المقاييس.
• تعريف التنبيهات يكون باستخدام PromQL في ملف إعدادات.
• يدعم تجميع (Grouping) وSilencing (إيقاف التنبيه مؤقتًا).
• يدعم وجهات مثل: Email، Slack، Webhooks.

Grafana Alerts

• يمكن تعريف التنبيهات من داخل الـ Dashboard نفسها.
• تستطيع الجمع بين مصادر بيانات مختلفة في تنبيه واحد.
• واجهة رسومية أسهل من ملفات YAML لـ Alertmanager.

تنبيهات New Relic

• واجهة سحابية بالكامل، سهلة الاستخدام.
• Rules مبنية على مقاييس APM، Logs، Synthetics… إلخ.
• يدعم سياسات متقدمة (مثل: شرط متتابع أو عدة شروط مركبة).
• تقارير جاهزة عن مدى استقرار التطبيق وSLA.

متى تستخدم Prometheus + Grafana؟ ومتى تستخدم New Relic؟

حالات تفضيل Prometheus + Grafana

• عندما تريد حلًا مفتوح المصدر بالكامل، والتحكم في كل شيء بنفسك.
• حين تكون بنيتك على Kubernetes أو Docker Swarm وتريد مراقبة عميقة للحاويات.
• لو كان لديك فريق DevOps لديه خبرة في إدارة أنظمة المراقبة.
• لو كانت حساسية البيانات عالية ولا تريد إرسالها خارج شركتك.

حالات تفضيل New Relic

• الشركات الناشئة أو الفرق التي تريد حل Managed دون عناء إدارة السيرفرات.
• حاجة قوية إلى APM متكامل مع Distributed Tracing وError Analytics بسهولة.
• عدم الرغبة في بناء Stack كامل (Prometheus + Grafana + Loki + Alertmanager..).
• وجود استعداد للدفع مقابل الراحة والدعم.

مقارنة مختصرة

أمثلة عملية لسيناريوهات اختيار الأداة الأنسب

سيناريو 1: مشروع Django صغير على VPS واحد

• عدد المستخدمين متوسط، سيرفر واحد (أو اثنان) وPostgreSQL.
• أهم شيء: مراقبة استهلاك الموارد وزمن استجابة الـ API.

اختيار مناسب:

• Prometheus + Grafana بشكل بسيط، أو حتى Prometheus فقط.
• يمكنك إعداد node_exporter لمراقبة السيرفر + django-prometheus للتطبيق.
• إنشاء Dashboards بسيطة في Grafana للـ CPU, RAM, Latency.

سيناريو 2: منصة SaaS متوسطة بعدة خدمات Microservices

• مبنية على Kubernetes.
• تستخدم Python / Go / Node.

اختيار مناسب:

• Stack كامل: Prometheus + Grafana + Alertmanager.
• لكل Service، تعريض /metrics مع Labels تدل على الخدمة والبيئة (prod، staging…).
• استخدام Dashboards جاهزة لـ Kubernetes في Grafana.

سيناريو 3: شركة لديها عدة فرق وتطبيقات بلغات مختلفة

• Django، .NET، Java، PostgreSQL، Redis… إلخ.
• التركيز على سرعة كشف مشاكل الأداء دون إدارة منصات إضافية.

اختيار مناسب:

• اعتماد New Relic كمنصة رئيسية لـ APM.
• إضافة Agents لكل تطبيق وقاعدة بيانات مدعومة.
• استخدام Dashboards وتنبيهات New Relic الجاهزة.

دمج Prometheus وNew Relic في بيئة واحدة

بعض الفرق تختار مزيجًا من الأدوات، مثلاً:

• استخدام Prometheus + Grafana لمراقبة البنية التحتية الداخلية والخدمات الحساسة.
• استخدام New Relic لـ APM التفصيلي فقط لتطبيقات محددة.

هذا السيناريو منطقي عندما:

• تريد مزايا APM المتقدمة في New Relic لبعض الأنظمة الحرجة.
• لكن في نفس الوقت تريد تجنّب إرسال كل المقاييس الداخلية الحساسة للخارج.

نصائح عملية لاختيار حل مراقبة يناسب بنيتك التحتية

1. قيّم حجم وتعقيد نظامك
   - لو كان النظام بسيطًا، لا تبالغ في التعقيد بأكثر من أداة تحتاج إدارة مستمرة.
   - لو كان النظام موزعًا وكبيرًا، استثمر في Stack قوي من البداية.
2. حدّد من سيدير المراقبة
   - هل لديك فريق DevOps متخصص؟ Prometheus + Grafana خيار ممتاز.
   - لا يوجد فريق متخصص؟ حلول SaaS مثل New Relic أو Datadog تكون أسهل.
3. فكّر في التكلفة على المدى البعيد
   - Prometheus مجاني، لكن تكلفة الخوادم والصيانة والوقت ليست مجانية.
   - New Relic مدفوع، لكن يوفر وقت التطوير والصيانة.
4. ابدأ صغيرًا، ثم توسّع
   - يمكنك بدء مراقبة Django فقط، ثم إضافة قاعدة البيانات، ثم البنية التحتية… إلخ.
   - لا تحاول بناء نظام مراقبة كامل من اليوم الأول، ركّز على أهم المقاييس أولًا.
5. احرص على ربط المراقبة بسير عمل التطوير
   - عند كل نشر (Deploy)، راقب المقاييس قبل وبعد النشر.
   - استخدم التنبيهات لتحذير الفريق مبكرًا قبل أن يشعر المستخدمون بالمشكلة.

كيف تؤثر طريقة البرمجة في بايثون على المقاييس؟

أدوات المراقبة لا تكفي وحدها؛ يجب أن تفهم كيف يؤثر نمط الكود على تلك المقاييس. على سبيل المثال:

• استخدام Threading في بايثون (راجع: Threading في بايثون) يمكن أن يحسّن عدد الطلبات المتزامنة، لكنه قد يزيد تعقيد الـ Debugging.
• البرمجة غير المتزامنة async/await (راجع: البرمجة غير المتزامنة في بايثون) تقلل زمن الانتظار في I/O، لكن تحتاج أن تقيس جيدًا تأثيرها على Latency وThroughput.
• اختيار قاعدة البيانات (مثل مقارنة PostgreSQL مقابل MySQL) يؤثر مباشرة على زمن الاستعلامات، وهو ما يظهر بوضوح في لوحات Prometheus / New Relic.