يا جماعة الخير، السلام عليكم ورحمة الله وبركاته، معكم أخوكم أبو عمر.
خلوني أحكيلكم قصة صارت معي قبل كم سنة، قصة علّمتني درس ما بنساه. كنا في ليلة من ليالي الشتاء الباردة، وفجأة بدأت التنبيهات توصلنا زي المطر على قنوات “سلاك” (Slack). “الموقع بطيء!”، “الطلبات بتفشل!”، “المستخدمين بشتكوا على تويتر!”.
تجمع كل الفريق الهندسي في غرفة حرب افتراضية، والكل بسأل نفس السؤال: “شو اللي بصير؟ وين المشكلة؟”. فتحنا لوحات المراقبة (Dashboards) تبعتنا… كل شي أخضر! استخدام المعالج (CPU) طبيعي، الذاكرة (Memory) تمام، الشبكة مستقرة. بالظاهر، كل شي “عال العال”.
لكن في الحقيقة، “ولّعت الدنيا” والمستخدمين مش قادرين يشتغلوا. قضينا ساعات طويلة، يمكن 6 أو 7 ساعات، واحنا بنشتغل “عالعمياني”. واحد من الشباب بقترح: “يمكن المشكلة في خدمة الدفع”، فبنروح بنعيد تشغيلها. ما بتزبط. واحد ثاني بقول: “أكيد من قاعدة البيانات”، فبنقعد نحلل أبطأ الاستعلامات. برضه ما في فايدة. صرنا نضيف جمل طباعة (`console.log`) في الكود ونعمل `deploy` جديد كل ربع ساعة، بس عشان نعرف وين الطلب “بعلّق”. كنا زي اللي بدور على إبرة في كومة قش، بس في غرفة معتمة تمامًا.
في هذيك الليلة، أدركنا إنه طريقتنا في مراقبة الأنظمة كانت غلط. كنا بنعرف *إنه* في مشكلة، بس ما كنا بنعرف *ليش* أو *وين*. كنا بنراقب، بس ما كنا بنفهم. ومن هون بدأت رحلتنا مع مفهوم غيّر طريقة عملنا بالكامل: **المراقبة الشاملة (Observability)**.
ما هي المراقبة الشاملة (Observability)؟ وليش هي أهم من المراقبة التقليدية؟
كتير ناس بخلطوا بين المراقبة (Monitoring) والمراقبة الشاملة (Observability)، بس الفرق بينهم جوهري وحاسم.
ببساطة شديدة:
- المراقبة التقليدية (Monitoring): هي عملية جمع وعرض بيانات عن أسئلة أنت *تعرفها مسبقاً*. بتسأل: “كم نسبة استخدام المعالج؟”، “كم عدد الأخطاء من نوع 500؟”. المراقبة بتعطيك إجابات على هذه الأسئلة المحددة. هي بتخبرك أن هناك مشكلة.
- المراقبة الشاملة (Observability): هي قدرة النظام على الإجابة عن أسئلة أنت *لم تفكر فيها مسبقاً*. هي مش مجرد أدوات، بل هي خاصية في تصميم نظامك تسمح لك بفهم سلوكه الداخلي المعقد. هي بتساعدك تكتشف لماذا هناك مشكلة.
تخيل المراقبة التقليدية زي لمبة “Check Engine” في سيارتك. بتضوي، فبتعرف إنه في مشكلة. بس شو هي المشكلة بالضبط؟ هل هي من حساس الأكسجين؟ ولا مضخة البنزين؟ ما بتعرف. أما المراقبة الشاملة، فهي زي جهاز الفحص اللي بوصله الميكانيكي بالسيارة، وبعطيه قراءة من كل حساس في المحرك، وبخليه يسأل أي سؤال بده ياه ليعرف أصل العطل.
في عالم اليوم، مع انتشار الخدمات المصغرة (Microservices) والأنظمة الموزعة، لم تعد المراقبة التقليدية كافية. الطلب الواحد ممكن يمر عبر 10 أو 20 خدمة مختلفة قبل ما يرجع للمستخدم. لما تحدث مشكلة، كيف بدك تعرف أي خدمة هي السبب؟ هون بيجي دور المراقبة الشاملة.
الأعمدة الثلاثة للمراقبة الشاملة: السجلات، المقاييس، والتتبعات
تعتمد المراقبة الشاملة على ثلاث ركائز أساسية. لما تجمعهم مع بعض، بتحصل على صورة كاملة وواضحة عن صحة نظامك وسلوكه.
1. السجلات (Logs): “شو اللي صار بالضبط؟”
السجلات هي أبسط أشكال البيانات اللي بنجمعها. هي عبارة عن أحداث فردية مسجلة مع طابع زمني (timestamp). كل مطور بعرفها، من أيام الـ `printf(“here”);`.
لكن السر مش في كتابة السجلات، السر في كتابتها بطريقة “ذكية”. وداعاً للسجلات العشوائية مثل “Error occurred”، وأهلاً بـ “السجلات المنظمة” (Structured Logs).
السجل المنظم، غالباً بصيغة JSON، يحتوي على أزواج من المفاتيح والقيم (key-value pairs) اللي بتعطي سياق كامل للحدث. شوف الفرق:
سجل سيء (غير منظم):
E-mail sent to user after order completion.سجل ممتاز (منظم):
{
"timestamp": "2023-10-27T10:00:05Z",
"level": "INFO",
"message": "E-mail sent successfully",
"event_type": "user_notification",
"user_id": "usr_a1b2c3d4",
"order_id": "ord_x5y6z7w8",
"email_template": "order_confirmation_v2"
}
بالسجل الثاني، بتقدر تبحث عن كل الإيميلات اللي راحت لمستخدم معين، أو كل الأحداث المتعلقة بطلب معين، أو تشوف كم مرة استخدمنا قالب إيميل معين. صار السجل مصدر بيانات غني، مش مجرد نص عشوائي.
نصيحة أبو عمر 📝
اجعل السجلات المنظمة (Structured Logging) هي القاعدة الأساسية في فريقك. استخدم مكتبات تسهل عليك هذا الأمر (مثل Serilog في .NET أو `python-json-logger` في بايثون). صدقني، هذه الخطوة الصغيرة وحدها ستوفر عليك ساعات من البحث والتحليل.
2. المقاييس (Metrics): “كيف الوضع العام؟”
المقاييس هي بيانات رقمية يتم جمعها على فترات زمنية منتظمة (Time-series data). هي اللي بتعطيك النظرة العامة على صحة النظام. أمثلة على المقاييس:
- معدل الطلبات في الثانية (Request rate).
- معدل الأخطاء (Error rate).
- زمن الاستجابة (Latency)، وخصوصاً النسب المئوية مثل p95 و p99 (يعني 95% من الطلبات أسرع من هذا الرقم).
- استخدام المعالج والذاكرة.
- عدد العناصر في طابور انتظار (Queue length).
المقاييس ممتازة لإطلاق التنبيهات (Alerting). لما يرتفع معدل الأخطاء فوق 2% لمدة 5 دقائق، بيوصلك تنبيه. هي بتخبرك إنه في “دخان”، بس ما بتحكيلك وين “النار” بالضبط.
نصيحة أبو عمر 📊
ركز على “الإشارات الذهبية الأربعة” (The Four Golden Signals) اللي حددتها جوجل لفرق SRE:
- الكمون (Latency): كم من الوقت يستغرق الطلب للعودة باستجابة؟
- حركة المرور (Traffic): ما هو حجم الطلب على نظامك؟ (مثلاً، طلبات HTTP في الثانية).
- الأخطاء (Errors): ما هو معدل الطلبات التي تفشل؟
- التشبع (Saturation): ما مدى “امتلاء” نظامك؟ (مثلاً، كم بقي من مساحة القرص أو الذاكرة).
إذاراقبت هذه الأربعة لخدماتك الرئيسية، بتكون قطعت شوط كبير.
3. التتبعات الموزعة (Distributed Tracing): “وين راح الطلب؟”
هذا هو العمود السحري، خصوصاً في عالم الخدمات المصغرة (Microservices). التتبع هو قصة حياة طلب واحد أثناء رحلته عبر الخدمات المختلفة في نظامك.
لما مستخدم يضغط على زر “شراء”، هذا الطلب ممكن يمر بالخطوات التالية:
- يصل إلى الواجهة الأمامية (API Gateway).
- يروح لخدمة المصادقة (Auth Service) ليتأكد من هوية المستخدم.
- بعدين لخدمة المنتجات (Product Service) ليتأكد من توفر المنتج.
- بعدين لخدمة الدفع (Payment Service) ليخصم المبلغ.
- وأخيراً لخدمة الطلبات (Order Service) ليسجل الطلب.
إذا كانت العملية كلها بطيئة، كيف تعرف أي خدمة هي عنق الزجاجة؟
التتبع الموزع بحل هاي المشكلة. كل طلب يدخل النظام يأخذ معرّف فريد اسمه `Trace ID`. هذا المعرّف ينتقل مع الطلب من خدمة لأخرى. كل خطوة داخل الخدمة (مثلاً، استدعاء قاعدة البيانات) تسمى `Span`. من خلال تجميع كل الـ `Spans` اللي بتحمل نفس `Trace ID`، بنقدر نرسم خريطة كاملة لرحلة الطلب ونشوف بالضبط كم أخذت كل خطوة.
النتيجة بتكون شي زي هيك (شكل بياني يسمى Flame Graph):
|------------------- API Gateway (505ms) --------------------|
|-- Auth Service (10ms) --|
|-- Product Service (20ms) --|
|-- Payment Service (450ms) --|
|-- External API Call (440ms) --|
|-- Order Service (25ms) --|
بلمحة بصر، بنعرف إنه 450ms من أصل 505ms ضاعت في خدمة الدفع، وبالتحديد في استدعاء واجهة برمجة تطبيقات خارجية (External API). المشكلة مش من عندنا! في دقيقة واحدة، عرفنا المشكلة اللي كانت ممكن تاخذ منا ساعات من البحث.
كيف ربطنا الخيوط ببعضها: من الظلام إلى النور
نرجع لقصتنا في بداية المقال. بعد هذيك الليلة، قررنا نستثمر في بناء منصة مراقبة شاملة حقيقية. اليوم، لما تصير مشكلة مشابهة، السيناريو بكون مختلف تماماً:
- (مقياس – Metric) يطلق تنبيه: “متوسط زمن الاستجابة (p99 latency) ارتفع إلى ثانيتين!”.
- نفتح لوحة التحكم ونشوف أي خدمة بالضبط اللي صارت بطيئة. لنقل إنها “خدمة التوصيات” (Recommendation Service).
- (تتبع – Trace) نفلتر التتبعات البطيئة لهذه الخدمة. بنفتح تتبع واحد وبنشوف إنه في استعلام معين لقاعدة البيانات بستغرق 1.8 ثانية.
- (سجل – Log) ننسخ معرّف التتبع (`Trace ID`) ونبحث عنه في نظام السجلات. بنلاقي سجل خطأ مرتبط بنفس الطلب بقول: “Query timed out. Index not used.”
النتيجة: في أقل من 5 دقائق، انتقلنا من “الموقع بطيء” إلى “يجب إضافة فهرس (index) لجدول `user_preferences` لتحسين أداء هذا الاستعلام”. انتقلنا من الظلام الدامس إلى وضوح الشمس.
الخلاصة: لا تعملوا بالظلام بعد اليوم 💡
يا إخواني وأخواتي المطورين ومهندسي DevOps، العالم تغير. أنظمتنا صارت أكثر تعقيداً وتوزيعاً من أي وقت مضى. الأدوات القديمة لم تعد كافية. لم يعد كافياً أن نعرف *أن* النظام معطل، بل يجب أن نمتلك القدرة على أن نسأله *لماذا* هو معطل.
الاستثمار في المراقبة الشاملة (Observability) ليس ترفاً، بل هو ضرورة حتمية. هو استثمار في وقتكم، في صحتكم النفسية، وفي سعادة المستخدمين. ابدأوا اليوم، حتى لو بخطوات صغيرة:
- حوّلوا سجلاتكم إلى سجلات منظمة (Structured Logs).
- ابدأوا بجمع المقاييس الأربعة الذهبية لخدماتكم.
- جرّبوا تطبيق التتبع الموزع على مسار واحد حرج في نظامكم.
أدوات مثل Prometheus و Grafana و Loki و Tempo (أو ELK Stack) مفتوحة المصدر وممتازة كنقطة بداية. الأهم من الأداة هو الفكر نفسه: فكر “كيف سأراقب وأفهم هذا الكود الذي أكتبه الآن؟” قبل أن تقع الفأس بالرأس.
أتمنى لكم أنظمة مستقرة، وليالي هادئة. والله يعطيكم العافية.
