وظائف مراقبة DNS وتحديثات الميزات
يعد نظام خادم أسماء النطاقات (DNS) أحد أهم اللبنات الأساسية للإنترنت ، ومع ذلك ، غالبا ما يساء فهمه ويؤخذ كأمر مسلم به. يشبه نظام DNS أساس منزل مخفي في الغالب ، ويتم تجاهله ، ولا تتم مناقشته.
ومع ذلك ، مثل المنزل الذي يعاني من مشاكل في الأساس ، إذا كانت هناك مشكلة في DNS ، فإن كل شيء على رأس أو يعتمد على نظام DNS – الشبكات والاتصال وتجربة المستخدم – يتأثر. لذلك ، نعتقد أن عملية DNS هي جزء لا يتجزأ من المراقبة. لأنه في حالة فشل عملية DNS ، فلن يتمكن معظم المستخدمين من الوصول إلى الموارد عبر الإنترنت التي يتم استهلاكها.
بشكل افتراضي، يقوم Dotcom-Monitor بحل أسماء المضيفين بدءا من خوادم الجذر. يضمن حل أسماء المضيفين من خوادم الجذر عدم كسر سلسلة DNS ويمكن حل أسماء المضيفين إلى عنوان IP المناسب لهم أثناء التحقق. في حين أن حل اسم المضيف من الخادم الجذر يوفر الفحص الأكثر شمولا ، بالنسبة لبعض العملاء وفي ظل ظروف معينة يمكن أن يسبب مشاكل.
مراقبة المشكلات بسبب حل اسم المضيف من خادم الجذر
- زيادة الوقت الإجمالي للمراقبة – يتم زيادة الوقت الإجمالي لإجراء فحص المراقبة لأن دقة DNS يمكن أن تستغرق بضع ثوان. في بعض الحالات ، عندما يكون مثيل المراقبة سريعا بشكل خاص (أي تنزيل بكسل HTTP) ، قد تمثل دقة DNS غالبية الوقت الإجمالي لإجراء المراقبة. على هذا النحو ، لن تعكس المراقبة تجربة المستخدم العادي لموقع الويب أو المورد عبر الإنترنت. لذلك ، إذا كان العميل أكثر اهتماما بمراقبة تجربة الزائر المتكرر لموقع ويب ، فإن مراقبة انتشار DNS من خادم الجذر غير مناسب.
- لا يمكن التحكم في حل DNS ، وبالتالي فإن مشكلات DNS غير ذات صلة – في بعض الحالات ، لا تخضع عملية حل DNS لسيطرة العميل ، وبالتالي يفضلون تجاهل مشكلات DNS وانقطاعه. في حين أنه من المهم أن تكون على دراية بمشكلات حل DNS لأنها تحظر وصول المستخدم النهائي إلى الخدمات ، إلا أنه ليس من المفيد للعميل تلقي تنبيهات المراقبة والتقارير حول مشكلات DNS التي لا يمكنه التحكم فيها.
التحكم في عمليات التحقق من أداء دقة DNS
يتمتع مستخدمو Dotcom-Monitor بتحكم واسع في كيفية تنفيذ دقة DNS لمهام المراقبة الخاصة بهم. استنادا إلى تعليقات المستخدمين الشاملة، تتوفر أربعة خيارات DNS مختلفة لحل أسماء المضيفين لمراقبة المهام:
1. الجهاز المخزن مؤقتا (الخيار الافتراضي) – عند تعيين هذا الخيار ، سيقوم Dotcom-Monitor بحل اسم مضيف مرة واحدة لكل مثيل من التحقق. لذلك ، إذا كانت هناك إشارات إلى نفس اسم المضيف في مهمة واحدة أو أكثر داخل نفس الجهاز ، فسيحدث بحث DNS مرة واحدة ثم يتم تخزينه مؤقتا طوال مدة تسجيل الوصول إلى هذا الجهاز.
معظم الفحوصات سريعة إلى حد ما ويتم إجراؤها في أقل من دقيقة واحدة ، لذلك قررت أنه لا يوجد سبب لحل نفس المضيف كل بضع ثوان. الجانب السلبي لهذا الخيار هو أن بيانات الأداء يمكن أن تختلف لكل مهمة في نفس الجهاز. لذلك ، إذا كنت تراقب عنواني URL في نفس الجهاز على نفس المضيف ، فسيكون عنوان URL الأول دائما أبطأ ، لأنه سيتضمن وقت البحث عن DNS ، بينما سيستخدم عنوان URL الثاني عنوان IP DNS المخزن مؤقتا وستكون دقة DNS سريعة جدا.
2. غير مخبأ – عند تعيين هذا الخيار ، يعمل كل فحص على حل اسم المضيف الذي يتم نشره من خوادم الجذر. هذا مفيد لضمان أوقات موحدة حيث سيتم إجراء بحث DNS في كل مرة. ومع ذلك ، يمكن أن يؤدي خيار عدم التخزين المؤقت إلى زيادة الحمل على خوادم DNS بشكل كبير ويزيد أيضا من وقت الاستجابة لمراقبة المهام.
لا يتوفر هذا الخيار لمنصات مراقبة BrowserView أو UserView المستندة إلى المتصفح ، نظرا لأنه ليس من العملي حل نفس اسم المضيف مئات المرات في غضون ثوان قليلة من التحقق. على سبيل المثال ، فكر في صفحة ويب تحتوي على العديد من العناصر على نفس الخادم والتي تحتوي جميعها على دقة DNS منفصلة عن الخادم الجذر. في هذا النوع من السيناريوهات، يكون الحل مرة واحدة لكل شيك كافيا.
3. TTL Live – هذا الخيار يحاكي تجربة المستخدم الحقيقي بشكل أفضل. يقوم Dotcom-Monitor بحل اسم المضيف مرة واحدة وتخزينه مؤقتا لقيمة وقت الحياة (TTL) في موقع المراقبة. قد تختلف قيمة TTL من بضع ثوان إلى بضعة أسابيع. يتم التحكم في TTL بواسطة خادم DNS الذي يستضيف الاسم.
من المهم ملاحظة أنه إذا تم تعيين خيار TTL Live وفشل خادم DNS ، فقد لا يكتشف Dotcom-Monitor الفشل حتى تنتهي صلاحية TTL (والتي قد تستغرق أياما أو أسابيع). يوصى بهذا الخيار فقط إذا لم تكن المراقبة للحصول على حل DNS مناسب أولوية.
4. خادم DNS محدد – سيقوم هذا الخيار بالاستعلام عن خادم DNS محدد لحل مضيف لعنوان IP. هذا مفيد في مواقف محددة ، على سبيل المثال ، إذا كنت تعرف أن معظم عملائك يستخدمون خدمة تخزين مؤقت عامة ، مثل 8.8.8.8 من Google أو 8.8.4.4. في هذه الحالة ، يمكنك تعيين خادم DNS على أحد عناوين IP الخاصة ب Google. طالما أن نظام أسماء النطاقات المحدد من Google يوفر استجابة صالحة، فلن يكتشف Dotcom-Monitor خطأ في نظام أسماء النطاقات، حتى إذا كان خادم DNS المسؤول عن النطاق لا يعمل بشكل صحيح.
يتضمن موقف آخر ما إذا كنت تعرف الخوادم المسؤولة عن دقة الاسم ولا تهتم بدقة سلسلة DNS بأكملها. في هذه الحالة، يمكنك تحديد خادم DNS لاستخدامه لدقة DNS. يمكن أن يوفر هذا الخيار أوقات حل DNS أفضل أيضا ، نظرا لأن Dotcom-Monitor لا يحتاج إلى نشر بحث من خادم الجذر ويمكن أن ينتقل مباشرة إلى خادم DNS المناسب. ومع ذلك، قد لا يكتشف هذا الخيار كافة المشكلات المتعلقة بنظام أسماء النطاقات.
[divider top=”no”]استخدام خيارات حل DNS لحل مشكلات محددة
كما هو مذكور أعلاه ، فإن كل خيار من خيارات دقة DNS له إيجابيات وسلبيات. تتيح القدرة على تخصيص عملية حل DNS المرونة التي تخدم بشكل أفضل موقفا وحاجة محددة. بشكل عام ، غالبا ما يوصى باستخدام الخيار الافتراضي ، Device Cached. ومع ذلك ، في ظل ظروف معينة ، قد تكون خيارات حل DNS الأخرى حلا قيما لمعالجة مشكلات محددة.
