المراقبة كوداً (MaC): كيف أنقذتنا من جحيم التنبيهات العشوائية؟

يا هلا بالشباب الطيبة، معكم أخوكم أبو عمر.

خليني أحكيلكم قصة صارت معي قبل كم سنة، قصة علّمتني درس ما بنساه. كانت ليلة جمعة، الأجواء هادية والكل مرتاح في بيته بعد أسبوع شغل طاحن. أنا كنت عامل فنجان قهوة سادة وقاعد بقرا كتاب. فجأة، التلفون “ولّع”… إشعارات من Slack، مكالمات من PagerDuty، إيميلات… كإنها القيامة قامت على سيرفراتنا. “السيرفر الرئيسي لا يستجيب!”، “استخدام المعالج 100%!”، “الذاكرة على وشك الانفجار!”.

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

المصيبة الأكبر صارت بعدها بكم أسبوع. حصل عطل حقيقي وخطير، لكن ما حدا انتبهله بسرعة. ليش؟ لأنه الكل صار عامل “mute” لقناة التنبيهات من كثرة الإنذارات الكاذبة. صرنا بالضبط مثل قصة “الراعي الكذاب والذئب”. لما كان الذئب حقيقي، ما حدا صدّق. هذا الجحيم، جحيم “الذئب قادم”، هو اللي دفعنا نبحث عن حل جذري. والحل كان “المراقبة كوداً” أو Monitoring as Code (MaC).

ما هي مشكلة المراقبة التقليدية؟

قبل ما نحكي عن الحل، خلينا نفصّل المشكلة. الطريقة التقليدية لضبط التنبيهات كانت تتم من خلال واجهات رسومية (UIs). بتفوت على Grafana أو Datadog أو أي أداة ثانية، بتكبس كم كبسة، بتعمل “drag and drop”، وبتعيّن قاعدة تنبيه جديدة. حلو وسهل، صح؟ لأ، مش دايماً.

هذه الطريقة تخفي وراءها كوارث حقيقية على المدى الطويل:

• الفوضى وعدم الاتساق: كل مهندس إله طريقته. واحد بحط عتبة التنبيه (threshold) على 80%، والثاني على 85%. واحد بكتب وصف واضح للتنبيه، والثاني بكتب “Server Down”. مع الوقت، بصير عندك غابة من التنبيهات اللي ما إلها لا أول ولا آخر.
• غياب الشفافية وسجل التغييرات: لو تنبيه مهم انحذف بالخطأ، أو تغيّرت قيمته وصار يسبب ضجيج، كيف بدك تعرف “مين غيّر الإعدادات ومتى وليش؟”. صعب جداً تتعقب التغييرات اللي بتصير بالكبيس. ما في `git blame` على الواجهة الرسومية!
• صعوبة التوسع: تخيل عندك 100 خدمة (microservice). هل يعقل إنك رح تعمل 100 داشبورد و 500 قاعدة تنبيه يدوياً؟ وإذا قررت تغير معيار معين في كل التنبيهات، هل رح تلف عليهم واحد واحد؟ شغل مش منطقي.
• كابوس التعافي من الكوارث (Disaster Recovery): لو نظام المراقبة نفسه “وقع” أو احتجت تنقله على داتا سنتر جديدة، كيف بدك ترجع كل الإعدادات اللي أخذت منك شهور لتبنيها؟ رح تبدأ من الصفر.

المراقبة كوداً (MaC): المنقذ المنتظر

ببساطة شديدة، “المراقبة كوداً” هي ممارسة إدارة إعدادات المراقبة (مثل قواعد التنبيه والداشبوردات) على شكل ملفات كود (غالباً YAML أو JSON)، وتخزين هذه الملفات في نظام إدارة نُسخ مثل Git.

يعني بدل ما تكبس كبسات، بتكتب كود. هذا التحول البسيط في العقلية بحل كل المشاكل اللي حكينا عنها فوق. كيف؟

1. التوحيد والاتساق (Standardization & Consistency)

لما تكون كل قواعد التنبيه مكتوبة في ملفات، بنقدر نفرض معايير موحدة. ممكن نعمل قوالب (templates) جاهزة. أي مطور جديد بده يضيف مراقبة لخدمته، ما عليه إلا ينسخ القالب ويغير كم متغير بسيط. الكل بصير يحكي نفس اللغة.

نصيحة من أبو عمر: أنشئوا مستودع (repository) خاص بإعدادات المراقبة. وقبل ما أي تغيير يتم قبوله، لازم يمر على مراجعة الزملاء (Peer Review) من خلال Pull Request. هذا بيضمن إنه ما في تغييرات عشوائية بتصير، والكل بتعلم من بعضه.

2. الشفافية الكاملة وسجل التغييرات

هنا تظهر قوة Git. أي تغيير على أي قاعدة تنبيه بكون مسجل. بنقدر نستخدم `git log` لنشوف تاريخ التغييرات كلها، وبنقدر نستخدم `git blame` لنعرف مين بالضبط اللي كتب أو عدّل سطر معين ومتى. إذا صار أي خطأ، الرجوع للنسخة السابقة بكون بكبسة زر (`git revert`).

3. الأتمتة والنشر المستمر (Automation & CI/CD)

بما إنه الإعدادات صارت كود، بنقدر نعملها أتمتة. بنبني مسار عمل (pipeline) بسيط:

1. المطور يعمل `push` للتغييرات على مستودع الـ Git.
2. الـ CI/CD pipeline (مثل Jenkins أو GitHub Actions) بيشتغل تلقائياً.
3. بيقوم بفحص الملفات والتأكد من صحتها (linting & validation).
4. إذا كل شي تمام، بيقوم بنشر الإعدادات الجديدة على Prometheus أو نظام المراقبة تبعك بشكل آلي.

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

تطبيق عملي: MaC مع Prometheus و Alertmanager

الحكي النظري حلو، بس خلينا نشوف مثال عملي. في فريقنا، نعتمد بشكل كبير على Prometheus لجمع المقاييس (metrics) و Alertmanager لإدارة التنبيهات.

هيكلية المستودع (Repo Structure)

أول خطوة هي تنظيم الملفات بشكل مرتب. هيكلية بسيطة ومقترحة لمستودع المراقبة ممكن تكون كالتالي:

monitoring-config/
├── alertmanager/
│   └── config.yml         # إعدادات Alertmanager الرئيسية
├── prometheus/
│   ├── prometheus.yml     # الإعدادات الرئيسية لـ Prometheus
│   └── rules/
│       ├── service-a.rules.yml
│       ├── service-b.rules.yml
│       └── node.rules.yml
└── README.md

كتابة قواعد التنبيه (Alerting Rules)

هاي هي “الضربة”. بدل ما نعملها بالواجهة الرسومية، بنكتبها بملف YAML. شوفوا هالمثال لقاعدة بتنبّه إذا استخدام الذاكرة في أي حاوية (container) تجاوز 85% لمدة 5 دقائق:

groups:
- name: container.memory.alerts
  rules:
  - alert: ContainerMemoryUsageHigh
    # التعبير الحسابي: حساب نسبة استخدام الذاكرة
    expr: (sum(container_memory_working_set_bytes{name!=""}) by (name) / sum(container_spec_memory_limit_bytes{name!=""}) by (name)) * 100 > 85
    # فترة الانتظار: لا ترسل التنبيه إلا إذا استمر الوضع لـ 5 دقائق لتجنب التنبيهات المتقطعة
    for: 5m
    # التصنيفات: معلومات إضافية للتوجيه والتجميع
    labels:
      severity: warning # مستوى الخطورة
    # الشروحات: الرسالة التي ستصل للمهندس المناوب
    annotations:
      summary: "High memory usage in container {{ $labels.name }}"
      description: "Container {{ $labels.name }} has been using over 85% of its memory for the last 5 minutes. Current value: {{ $value | printf '%.2f' }}%."

نصيحة من أبو عمر: ركزوا منيح على حقل `annotations`. الـ `summary` لازم يكون قصير وواضح. أما الـ `description`، فهذا كنز! حطوا فيه معلومات تفصيلية، القيمة الحالية، ورابط لدليل التشغيل (runbook) اللي بشرح للمهندس المناوب شو لازم يعمل خطوة بخطوة. هذا بقلل التوتر وقت الحوادث بشكل كبير.

إدارة الضجيج مع Alertmanager

الـ Alertmanager هو العقل المدبر وراء تقليل الضجيج. من خلال ملف `config.yml` تبعه، بنقدر نعمل أشياء عبقرية:

• التجميع (Grouping): لو 20 سيرفر بنفس الكلستر صار عندهم نفس المشكلة، بدل ما يوصلك 20 تنبيه، Alertmanager بجمعهم في تنبيه واحد بيقول “20 سيرفر يعانون من مشكلة X”.
• الكبت (Inhibition): لو عندك تنبيه بقول “الكلستر غير متاح”، بتقدر تعمل قاعدة تكبت (تمنع) كل التنبيهات الأقل أهمية اللي طالعة من نفس الكلستر. منطقي، إذا الكلستر كله واقع، أكيد السيرفرات اللي جواته رح تكون واقعة!
• التوجيه (Routing): بتقدر توجه التنبيهات حسب خطورتها. مثلاً، تنبيهات `severity: critical` تروح على PagerDuty وتصحّي المهندس من نومه، بينما تنبيهات `severity: warning` تروح على قناة Slack للمتابعة في الصباح.

الخلاصة: من الفوضى إلى السيطرة الكاملة 👍

تبني “المراقبة كوداً” ما كان مجرد تغيير تقني، بل كان تحول ثقافي في الفريق. انتقلنا من حالة فوضى وتخمين وردة فعل، إلى حالة من النظام والوضوح والعمل الاستباقي. صرنا نثق بتنبيهاتنا. لما يوصل تنبيه الآن، بنعرف إنه حقيقي ومهم ويستدعي انتباهنا.

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

نصيحة أخيرة من أبو عمر: لا تخاف تبدأ صغير. مش لازم تحوّل كل أنظمتك بيوم وليلة. ابدأ بفريق واحد، بخدمة واحدة. حوّل قاعدة تنبيه واحدة من الواجهة الرسومية إلى كود. لما يشوفوا باقي الفرق كيف شغلكم صار مرتب ومنظم، رح يجوا يسألوك “يا جماعة، كيف عملتوها؟”. وقتها، ابعثلهم هالمقالة. 😉

بالتوفيق يا أبطال!