مراقبة الأنظمة الخلفية: تتبّع عملية المستخدم عبر الخدمات

قد تكون كل الخوادم تعمل بينما يفشل المستخدم في إكمال طلبه. نسبة uptime لا تشرح وحدها هل وصل webhook، وهل عولج الدفع، وهل تفعّلت العضوية. المراقبة المفيدة تبدأ من عملية يريد المستخدم إنجازها، ثم تربط خطواتها عبر HTTP وقاعدة البيانات والطابور والخدمة الخارجية.

عرّف النجاح من منظور المنتج

اختر مسارًا مثل إنشاء طلب أو تفعيل اشتراك. دوّن بداية العملية ونهايتها وحالات الفشل المقبولة وغير المقبولة. زمن استجابة endpoint ليس هو زمن إكمال مهمة خلفية؛ قد يعود 202 بسرعة ثم تنتظر المهمة طويلًا. قِس الاثنين حتى لا تخفي استجابة سريعة خدمة متأخرة.

أعط كل إشارة دورًا

Metrics تساعد في ملاحظة تغيّر المعدلات والأزمنة، وLogs تسجّل أحداثًا بتفاصيل محددة، وTraces تربط المقاطع التي شاركت في تنفيذ الطلب. توضح OpenTelemetry مفهوم نشر السياق بين المكوّنات لربط هذه الإشارات. لا يلزم تسجيل كل شيء؛ يلزم أن تستطيع الانتقال من عرض عام للفشل إلى تفاصيل العملية المتأثرة.

صمّم سياقًا لا يسرّب البيانات

مرّر trace context إلى الطلبات الخارجية والرسائل عندما تسمح المكتبات والبروتوكولات بذلك. أضف معرّف العملية الداخلي واسم المكوّن ونتيجة التنفيذ إلى logs منظمة. لا تسجّل access tokens أو محتوى رسائل العميل كاملًا كحل افتراضي للتشخيص. ضع سياسة إخفاء واحتفاظ ووصول، لأن بيانات المراقبة قد تجمع معلومات من أجزاء كثيرة من المنتج.

{
  "event": "membership.activation",
  "operation_id": "op_example_123",
  "status": "retry_scheduled",
  "attempt": 2,
  "duration_ms": 480
}

تجنّب مقاييس عالية التنوع بلا حاجة

إضافة user_id أو order_id كـlabel لكل metric قد تنشئ عددًا ضخمًا من السلاسل الزمنية. استخدم أبعادًا محدودة مثل نوع العملية أو المزوّد أو فئة النتيجة، وضع المعرّفات التفصيلية في logs أو traces وفق السياسة المناسبة. افحص أيضًا تكلفة التخزين والعينة: sampling يقلّل التكلفة لكنه قد يخفي حالات نادرة إذا صُمّم دون هدف.

ابنِ تنبيهًا يستدعي إجراءً

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

جرّب عطلًا محدودًا

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

سيناريو عملي: API سريع والنتيجة متأخرة

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

اختبار جودة التنبيه

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

إعداد: Noor Yasser