تقسيم الحدود للسجلات والمؤشرات والتتبع

رد الفعل الأول للعديد من الفرق عند محاولة تكملة إمكانية الملاحظة هو “ربط السجلات والمؤشرات والتتبع”.

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

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

حكمي هو: **لا ينبغي رسم حدود السجلات والمؤشرات والتتبع من خلال “الشكل الذي تبدو عليه البيانات” ولكن من خلال “القرار الذي يجب اتخاذه بعد ذلك”. **

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

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

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

يجب أن يكون القرار الأول الحقيقي هو المؤشرات.

عندما يكون هناك خلل في الخط، فإن الخطوة الأولى عادة ما تكون “الحكم على ما إذا كان الأمر يستحق التعامل معه على الفور”.

هذه الخطوة هي الأكثر ملاءمة للمؤشرات. ظاهرياً، يبدو أن المؤشر أكثر تقدماً، لكنه في الواقع أقرب إليه وأرخص.

يجب أن يجيب نظام المؤشرات الجيد على الأسئلة التالية خلال عشرات الثواني:

• هل معدل الخطأ في تزايد أم أنه مجرد ضجيج عرضي؟
• هل تباين التأخير عالمي أم يتركز على واجهة معينة؟
• أن يكون التأثير على جهاز، أو غرفة كمبيوتر، أو سلسلة الاتصال بأكملها؛
• هل حدثت المشكلة للتو أم أنها مستمرة لمدة نصف ساعة؟

هذه المشاكل تؤدي في الأساس إلى نفس الشيء: **استخدام تجميع منخفض التكلفة للمعلومات مقابل أحكام عملية عالية القيمة. **

ولذلك، فإن أهم مبدأ لتصميم المؤشرات هو “أنها يمكنها أيضًا دعم عملية صنع القرار بعد التجميع”.

تقوم العديد من الفرق بإنشاء مؤشرات سيئة عن طريق استخدام الحقول ذات العناصر الأساسية العالية التي لا ينبغي تضمينها في المؤشرات، مثل user_id، وorder_id، وtrace_id، وعناوين URL الكاملة، ورسائل الخطأ الديناميكية. وهذا أمر مُرضٍ للغاية على المدى القصير، ويبدو أن كل شيء يمكن القيام به؛ وفي المدى المتوسط، سيبدأ التوسع في التخزين، وتباطؤ الاستعلام، وأبعاد الإنذار في الخروج عن نطاق السيطرة؛ والنتيجة على المدى الطويل هي عادة أن الفريق نفسه يخشى استخدام منصة المؤشرات.

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

بمجرد أن يكون السؤال الذي تريد طرحه هو “ما هو الأمر الذي فشل؟”، لم يعد السؤال الذي يجب على المؤشر الإجابة عليه بمفرده.

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

غالبًا ما يُساء فهم التتبع على أنه “تسجيل أكثر تقدمًا من التسجيل”. هذا سوف يستخدمه مباشرة.

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

• هل البطء ناتج عن البوابة أو التطبيق أو قاعدة البيانات أو التبعيات الخارجية؟
• إعادة المحاولة، والتي يتم تضخيم القفزة؛
• إذا كان مستوى P99 لواجهة معينة مرتفعًا جدًا، فهل يتعلق الأمر بخدمة معينة في اتجاه مجرى النهر؟
• يبدأ الطلب غير الطبيعي بالانحراف عن المسار الطبيعي بعد المرور عبر تلك الخدمات.

بمعنى آخر، **التتبع يوفر بنية رابط، وليس مشهدًا كاملاً. **

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

لقد رأيت العديد من الفرق تحاول جعله مصدرًا موحدًا للحقيقة بمجرد بدء التتبع: يجب تعليق نص SQL الأصلي، ويجب تعليق إدخال المستخدم، ويجب تعليق نص الاستجابة الكامل، ويجب تعليق جميع معلمات إعادة المحاولة. النتيجة النهائية هي:

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

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

فإذا كان ثقيلًا جدًا لدرجة أنه لا يمكن الاحتفاظ به عالميًا بشكل مستقر، أو ثقيل جدًا لدرجة أن الاستعلام عنه ولو مرة واحدة يكون مؤلمًا، فهذا يعني أنه تم تجاوز الحدود.

السجل ليس نظام المؤشر الثاني، بل هو المادة النهائية لجمع الأدلة

السجل هو الأسهل لإساءة الحكم لأنه يبدو أنه يمكنه الاحتفاظ بأي شيء.

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

ولكن على وجه التحديد لأنه يحتوي على أعلى إنتروبيا معلوماتية، فهو الأقل ملاءمة لـ “المراقبة العالمية المستمرة”.

إن استخدام السجلات كمصدر رئيسي للمراقبة له ثلاث عواقب مشتركة.

أولاً، تكلفة الاستعلام مرتفعة. ** في كل مرة يتم استخلاص استنتاجات مؤقتة من الحقائق الأصلية، وهي بطيئة وقليلة الثبات.

ثانيا الصوت مزعج جدا ** عندما يكون حجم السجل كبيرًا، سيقوم الفريق بشكل طبيعي بتقليل الطباعة؛ وبمجرد تقليل الطباعة، غالبًا ما تفتقر الفروع الرئيسية إلى الأدلة؛ في النهاية، سيتأرجح الجميع ذهابًا وإيابًا بين “هناك الكثير مما يمكن رؤيته” و"القليل جدًا مما لا يمكن رؤيته".

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

المكان الأنسب للسجل هو استخدام المؤشرات لتحديد “هناك بالفعل مشكلة هنا” واستخدام التتبع لمعرفة “ربما تكمن المشكلة هنا”، ثم استخدامها لاستعادة طلب محدد.

وبعبارة أخرى، يجب أن تخدم السجلات غرض الطب الشرعي، وليس الدوريات.

التقسيم البسيط للعمل أكثر فعالية من “العناصر الثلاثة”

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

يمكن تقسيم عملية استكشاف الأخطاء وإصلاحها عبر الإنترنت إلى ثلاث خطوات.

1. استخدم المؤشرات أولاً لتحديد ما إذا كانت هناك مشاكل نظامية؛
2. ثم استخدم التتبع لتقريب المشكلة إلى مرحلة الخدمة والربط؛
3. أخيرًا، استخدم السجل لشرح سبب سير الطلب على هذا النحو.

إذا لم يتمكن التصميم المضمن من دعم هذا التسلسل، فعادةً ما يكون ذلك بسبب تعيين المسؤوليات بشكل خاطئ.

فيما يلي طريقة مقيدة نسبيًا للكتابة:

func CreateOrder(ctx context.Context, req CreateOrderReq) error {
  start := time.Now()
  defer metrics.OrderCreateLatency.Observe(time.Since(start).Seconds())

  ctx, span := tracer.Start(ctx, "order.create")
  defer span.End()
  span.SetAttributes(
    attribute.String("payment_provider", req.Provider),
    attribute.Bool("has_coupon", req.CouponID != ""),
  )

  err := service.Create(ctx, req)
  if err != nil {
    metrics.OrderCreateErrors.WithLabelValues(classify(err)).Inc()
    logger.Error("create order failed",
      "request_id", requestid.FromContext(ctx),
      "provider", req.Provider,
      "err", err,
    )
    return err
  }
  return nil
}

هناك ثلاثة حدود هنا تم تقييدها عمدًا.

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

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

سوء فهم شائع: فهم “قابلية المراقبة الموحدة” على أنها “تجميع كافة البيانات”

تتحدث العديد من المنصات الآن عن المراقبة الموحدة. ولا حرج في هذا في حد ذاته، المشكلة تكمن في طريقة تنفيذه.

تفهم بعض الفرق التوحيد على أنه “تدخل جميع البيانات إلى منصة واحدة، وجميع الحقول متصلة ببعضها البعض، ومن الأفضل حل جميع المشكلات باستعلام واحد”. هذه الفكرة مغرية لأنها تبدو وكأنها تزيل حدود الأداة؛ ولكن في الهندسة، غالبًا ما يلغي حدود التكلفة.

الاتجاه الصحيح للتوحيد هو ربطها مع احتكاك منخفض.

على سبيل المثال:

• يمكن أن تقفز إنذارات المؤشر مباشرة إلى الخدمات والنوافذ الزمنية ذات الصلة؛
• يمكن للتتبع العثور على السجل المقابل وفقًا لـ request_id أو رمز الخطأ؛
• يمكن للسجلات جلب سياق التتبع بدلاً من العمل بشكل مستقل.

وهذا ما يسمى تشاينا يونيكوم، وليس الاستخدام المختلط.

الخطر الحقيقي هو أن جميع الأسئلة لا يمكن الإجابة عليها إلا من خلال أثقل طبقة من البيانات.

أمثلة مضادة وحدود: لا تتطلب جميع الأنظمة مجموعة كاملة مكونة من ثلاث قطع

اعترف أيضًا أنه في بعض المشاهد لا يلزم إخبار الحدود بشكل كامل.

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

لذلك تقول هذه المقالة: **طالما أنك قررت القيام بثلاثة أشياء، فلا تدعها تحل محل بعضها البعض. **

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

ملخص

الشيء الأكثر رعبًا في إمكانية الملاحظة هو أن كل طبقة تريد الإجابة على جميع الأسئلة.

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

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