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

لهذا السبب، فإن سجلًا منقسمًا بالتساوي بين TCP_DENIED/407 وTCP_TUNNEL/200 لا يثبت تلقائيًا معدل فشل بنسبة خمسين بالمئة. حدد أولًا ما إذا كانت المدخلات تشكل أزواج تحدي وإعادة محاولة.

احسب الشيء الذي يهمك فعلًا

القياسالعدد
تحديات المصادقةردود الوكيل التي تطلب المصادقة
محاولات الوكيلالمعاملات الفردية التي سجلها الوسيط
المهام المكتملةعمليات التطبيق التي تصل إلى نتيجتها المقصودة

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

أبقِ أيضًا النفق الناجح منفصلًا عن عملية الموقع الناجحة. قبول CONNECT ينشئ النفق؛ ولا يزال بإمكان الوجهة أن تفشل أثناء TLS أو أن تعيد خطأ تطبيق لاحقًا.

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

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