إعداد تنبيهات (Alerts) لإرسال رسالة إذا ارتفع استهلاك المعالج عن 90%

إعداد تنبيهات لإرسال رسالة إذا ارتفع استهلاك المعالج عن 90%

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

هذا السيناريو يمثل تطبيقاً عملياً لمفهوم المراقبة الذي تناولناه سابقاً في مقال لماذا المراقبة حتمية في الـ DevOps؟ مقدمة في Prometheus و Grafana. وسنعتمد هنا على بنية مرنة تتكون من Prometheus لجمع المقاييس، وNode Exporter لقراءة مؤشرات النظام، وAlertmanager لإرسال الرسائل إلى البريد أو Telegram أو Slack.

المعمارية الصحيحة للتنبيه قبل كتابة القواعد

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

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

المكونات المطلوبة

• Prometheus يعمل على خادم المراقبة.
• Node Exporter مثبت على الخادم الهدف.
• Alertmanager لاستقبال التنبيهات.
• قناة إرسال مثل البريد الإلكتروني أو Webhook.

إضافة الخادم إلى نظام المراقبة

إذا لم يكن الخادم مسجلاً داخل إعدادات Prometheus فلن توجد أي بيانات يمكن البناء عليها. داخل ملف الإعداد الأساسي أضف مهمة جمع خاصة بخوادم Linux التي تشغل Node Exporter.

global:
  scrape_interval: 15s

rule_files:
  - /etc/prometheus/alerts.yml

alerting:
  alertmanagers:
    - static_configs:
        - targets:
            - "localhost:9093"

scrape_configs:
  - job_name: "node-exporters"
    static_configs:
      - targets:
          - "192.168.1.20:9100"
        labels:
          instance_name: "web-prod-01"
          environment: "production"

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

كتابة قاعدة التنبيه لارتفاع المعالج

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

الاستعلام التالي يحسب نسبة انشغال المعالج اعتماداً على مقياس node_cpu_seconds_total مع استبعاد حالة idle. ضع القاعدة في ملف التنبيهات.

groups:
  - name: cpu-alerts
    rules:
      - alert: HighCPUUsage
        expr: 100 - (avg by(instance) (rate(node_cpu_seconds_total{mode="idle"}[5m])) * 100) > 90
        for: 2m
        labels:
          severity: critical
          team: ops
        annotations:
          summary: "High CPU usage on {{ $labels.instance }}"
          description: "CPU usage exceeded 90% for more than 2 minutes on {{ $labels.instance }}."

شرح عناصر القاعدة

• expr: المعادلة التي تحسب نسبة استخدام المعالج.
• for: يشترط استمرار الحالة دقيقتين قبل إطلاق التنبيه.
• severity: يفيد في الفرز والتوجيه حسب مستوى الخطورة.
• annotations: النص الذي سيظهر داخل الرسالة المرسلة.

لا تضبط التنبيه على تجاوز فوري دون مهلة زمنية، لأن ذلك يسبب Alert Fatigue ويجعل الفريق يتجاهل الرسائل الحرجة فعلاً. التنبيه الناجح يجب أن يكون حساساً للمشكلة، لا حساساً للضجيج.

تهيئة Alertmanager لإرسال الرسالة

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

route:
  receiver: "email-alerts"
  group_by: ["alertname", "instance"]
  group_wait: 30s
  group_interval: 5m
  repeat_interval: 1h

receivers:
  - name: "email-alerts"
    email_configs:
      - to: "ops@example.com"
        from: "alertmanager@example.com"
        smarthost: "smtp.example.com:587"
        auth_username: "alertmanager@example.com"
        auth_password: "StrongPasswordHere"
        require_tls: true

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

promtool check config /etc/prometheus/prometheus.yml
promtool check rules /etc/prometheus/alerts.yml
systemctl restart prometheus
systemctl restart alertmanager

اختبار التنبيه عملياً بشكل آمن

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

yes > /dev/null &
yes > /dev/null &
yes > /dev/null &
yes > /dev/null &

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

pkill yes

تحسين جودة التنبيه في البيئات المتقدمة

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

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

احمِ قنوات التنبيه وبيانات SMTP أو Webhook ولا تترك كلمات المرور داخل مستودع الكود. استخدم متغيرات بيئية أو مخازن أسرار مخصصة، تماماً كما نفعل عند إدارة الأسرار لحماية كلمات المرور ومفاتيح API في الأتمتة.

الخلاصة

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

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