ما هي المراقبة (Observability)؟ السجلات والمقاييس والتتبعات

خلاصة سريعة: المراقبة (Observability) قدرة النظام على كشف حالته الداخلية من مخرجاته: السجلات والمقاييس والتتبعات. وهي تختلف عن الرصد التقليدي الذي يسأل عن أعطال متوقعة، لأنها تتيح طرح أسئلة لم تُعدّ لها مسبقًا. وتبدأ من المسارات الحرجة، وتُضبط بأهداف خدمة واقعية، وإلا صارت بيانات كثيرة وتنبيهات لا تُقرأ.

ما هي المراقبة (Observability)؟

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

والفرق بينها وبين الرصد التقليدي أن الأخير يسأل عن أعطال متوقعة مسبقًا: هل الخادم يعمل؟ وهل ارتفع المعالج؟ أما المراقبة فتتيح أسئلة لم تُعدّ لها لوحة جاهزة، مثل: لماذا تأخر طلب مستخدم بعينه عند الساعة 14:07؟

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

ما الفرق بين السجلات والمقاييس والتتبعات؟

تُجمع الإشارات الثلاث معًا، ولكل واحدة سؤال تجيب عنه:

• المقاييس (Metrics): أرقام مجمّعة على فترات، مثل عدد الطلبات في الدقيقة وزمن الاستجابة عند النسبة المئوية 95. خفيفة التخزين، مناسبة للتنبيه والاتجاهات، ولا تحمل تفاصيل الطلب الواحد.
• السجلات (Logs): أحداث نصية موقوتة تحمل تفاصيل ما جرى، مثل رسالة خطأ ومعرّف الطلب. غنية بالسياق، ثقيلة الحجم، وتحتاج فهرسة وضبطًا للحقول.
• التتبعات (Traces): سجل لمسار طلب واحد عبر الخدمات، مقسّم إلى مقاطع (Spans) يحمل كل منها مدته وحالته. تكشف أين ذهب الوقت وأي خدمة تسببت في البطء.

والمقاييس تنبّهك إلى وجود مشكلة، والتتبعات تدلك على موضعها، والسجلات تشرح سببها. ولهذا يُربط الثلاثة بمعرّف مشترك للطلب (Trace ID)، فينتقل المحلل من الرقم إلى المسار إلى الرسالة دون تخمين.

كيف تعمل منظومة المراقبة عمليًا؟

تبدأ المنظومة بالتجهيز (Instrumentation) داخل التطبيق: مكتبة تسجل الطلبات الصادرة والواردة، وتقيس زمن كل استدعاء، وتربط السجلات بالتتبع الحالي. ويوحّد معيار OpenTelemetry هذه الخطوة، فيصبح التطبيق مستقلًا عن الخادم الذي يستقبل البيانات.

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

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

ما مؤشرات الخدمة وأهدافها وميزانية الخطأ؟

مؤشر مستوى الخدمة (SLI) قياس لما يشعر به المستخدم: نسبة الطلبات الناجحة، وزمن الاستجابة، وتوافر الخدمة. وهدف مستوى الخدمة (SLO) قيمة مستهدفة لهذا المؤشر خلال فترة محددة، مثل «95% من الطلبات تُنجز في أقل من 300 ميلي ثانية خلال 30 يومًا».

والفرق بين الهدف والواقع هو ميزانية الخطأ (Error Budget): مقدار ما يمكن أن يخفق قبل خرق الهدف. وهي أداة قرار لا أداة عقاب؛ فإذا استُنفدت الميزانية، توقف الفريق عن إضافة المخاطر ووجّه جهده إلى الاستقرار. وإذا بقيت الميزانية كاملة دائمًا، فالهدف متساهل ولا يحمي المستخدم.

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

لماذا يتعب الفريق من التنبيهات؟

إجهاد التنبيه (Alert Fatigue) حالة يفقد فيها الفريق الثقة بالتنبيهات لأن أكثرها لا يستدعي فعلًا. وتنشأ من ربط التنبيه بكل مؤشر ممكن، ومن عتبات ثابتة لا تراعي طبيعة الحمل، ومن تكرار التنبيه نفسه عشرات المرات في الحادثة الواحدة.

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

بماذا نبدأ في التجهيز؟

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

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

ما حدود المراقبة ومتى تقلق؟

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

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

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

أسئلة شائعة

مقالات ذات صلة

• ما هي الخدمات المصغرة (Microservices)؟
• ما هو Kubernetes؟
• ما هو DevOps؟
• ما هو Ping؟ وكيف يقيس زمن الاستجابة؟

المصادر

• OpenTelemetry, What is OpenTelemetry? — تحديث 21 أكتوبر 2026
• IBM Think, What is observability? — تحديث 26 أغسطس 2026
• Google SRE Book, Monitoring Distributed Systems — 2017
• NIST, Guide to Computer Security Log Management (SP 800-92) — سبتمبر 2006

صورة الغلاف: IAEA Imagebank / Wikimedia Commons، بموجب رخصة CC BY.