افتح الجهاز المستهدف في القائمة لتحريره. في شريط عناوين المتصفح، سترى شيئا مثل:
https://user.dotcom-monitor.com/ClientID/DeviceEdit?pid=dc7f4ff2ca944dekjh1078b96707002& deviceId=63698 & taskId=132834
معرف الجهاز = 63698 هو معرف الجهاز.
taskId=132834 هو معرف المهمة.
معرف حساب متوفر في صفحة بدء تحديد حساب في قائمة الحسابات المتاحة.
بمجرد تسجيل الدخول ، ابحث عن معرف حسابك عند الإشارة إلى قائمة الحساب على الشريط الجانبي الأيسر.
بمجرد تسجيل الدخول إلى حساب رئيسي ، يمكنك العثور على معرفات الأقسام الخاصة بك ضمن أقسام إعدادات > حساب الحساب>.
Each test in LoadView has a unique ID. Using the test ID you can call a specific scenario while configuring LoadView integration (e.g., for Jenkins or CircleCl builds).
The Test ID can be found on the test page.
يوفر هذا النهج القدرة على تحديد كيفية تفسير Dotcom-Monitor للاستجابات بعناية على أنها إما استجابات “أعلى” أو “أسفل”. يتم تحقيق ذلك باستخدام المرشحات.
بالمناسبة ، يمكن أيضا تطبيق مرشح على جهاز (قطع تشغيل كاذب) وعلى أي نوع من التقارير.
تحدد التصفية حالات أعلى/أسفل باستخدام المعايير التالية القابلة للتعديل:
تتوفر جميع الفلاتر وإعداداتها في تكوين > عوامل التصفية. بعد تطبيق فلتر على جهاز، تستند جميع إشعارات الجهاز إلى معايير الفلتر. يتم تعيين “الفلتر الافتراضي” لجميع الأجهزة الجديدة. يحتوي المرشح الافتراضي على تكوين متوازن ومناسب لمعظم أجهزة المراقبة.
صيغة حساب وقت التوقف هي كما يلي:
1. ترتبط مدة التوقف مباشرة بالتكوينات داخل الفلتر:
2. مدة الحالة “غير المحددة“. يمكن تعيين حالة غير محددة عندما تصبح حالة كل وكيل مشارك في المراقبة غير محددة. تعتبر حالة الوكيل غير محددة إذا لم يقدم الوكيل أي استجابة (خطأ أو نجاح) في فترة زمنية معينة:
مدة وقت انتظار الاستجابة = (العدد الإجمالي للوكلاء +1) تردد مراقبة × + 15 دقيقة
على سبيل المثال ، نستخدم ثلاثة عوامل مراقبة وتردد مراقبة لمدة 5 دقائق. سينتظر كل وكيل استجابة لمدة وقت انتظار الاستجابة = (3+1)×5+15 دقيقة = 35 دقيقة. بمجرد انتهاء الوقت وعدم تلقي أي رد، يقوم الوكيل بالإبلاغ عن غير محدد.
3. مدة الحالة “المؤجلة“. سيؤدي تأجيل الجهاز في أي لحظة إلى إيقاف أي نشاط مراقبة حتى تتم إعادة تمكينه.
4. المدة المستثناة حسب الجدول الزمني. كيان آخر يمكن أن يؤثر بشكل كبير على حسابات وقت التشغيل / التوقف هو الجداول. هذا خيار لإدارة المراقبة أثناء الصيانة الروتينية. يمكن تأجيل المراقبة لأيام محددة من الأسبوع بالإضافة إلى ساعات ودقائق محددة خلال اليوم. لإعداد جدول، اتبع التعليمات.
سيؤدي أي تغيير في إعدادات الجهاز (بما في ذلك إعادة تشغيل الجهاز) أثناء حالة التعطل إلى إعادة تعيين الحالة حتى لا يتم إرسال تنبيه وقت التشغيل.
مثل:
لنفترض أن لدينا جهازا مراقبا من 7 مواقع ومجموعة فلتر أنه يجب على 3 مواقع الإبلاغ عن خطأ لحالة التوقف . أولا ، عقدة المراقبة (الوكيل) 1) يكتشف خطأ بينما لا يزال الباقون يبلغون عن النجاح ، ثم الثاني (الوكيل) 2) وفي الثلث الأخير يكتشف واحد (وكيل 4) خطأ في T4 الذي يؤدي إلى مرشح لتعيين وقت التوقف عن العمل بدءا من هذه اللحظة. ستبقى حالة الأسفل حتى تقوم بتعيين تأجيل افتراضي عند T5 بسبب عدد أخطاء الوكيل التي تبلغ عن أخطاء أعلى من 3 معدلة طوال هذا الوقت. الفجوة الزمنية بين T6 و T7 هي مثال على حقيقة أننا نحصل على الاستجابة الأولى مع تأخير (يشمل وقت معالجة جلسة المراقبة تأخيرات نقل الشبكة والتنفيذ نفسه) ، لذلك يتم حساب الوقت “المؤجل” على أنه ∆ (T7-T5) (مؤجل 2nd). مرة أخرى ، نقع في وقت التوقف عن العمل فقط في الخطأ الثالثالثالث من العامل 3 وندخل في حالة الصعود فقط على استجابة T9 ، عندما يصبح عدد الوكلاء الفاشلين أقل من المعدل في الفلتر. هنا تأتي صيغة حساب ٪ من وقت التوقف النهائي لهذه الحالة:
يستخدم LoadView خوادم حاقن التحميل من Amazon Web Services (AWS) وخدمات Azure السحابية. يحتوي Dotcom-Monitor على 17 منطقة جغرافية يمكن ذكر خوادم حاقن التحميل ويمكن إنشاء الحمل منها. في كل منطقة ، يمكن إنشاء حوالي 500 حاقن تحميل.
تعتمد حدود السعة على نوع منصة المراقبة بسبب الاختلاف في خوارزميات تنفيذ الاختبار:
يتم حساب الحد الأقصى لنوع معين من اختبار التحميل باستخدام الصيغة التالية:
500 × 16 × عدد المستخدمين المتزامنين لكل حاقن تحميل = الحد الأقصى لحمل المستخدم
ابحث عن حدود سعة الحمولة الناتجة أدناه:
| اختبار تحميل HTTP (S) (ServerView) | اختبار تحميل صفحة الويب (BrowserView) | اختبار تحميل تطبيق الويب (UserView) |
| 8,000,000 مستخدم | عدد المستخدمين 225,000 | عدد المستخدمين 225,000 |
يقع وكيل المراقبة "شنغهاي" (الصين) خلف جدار الحماية العظيم للصين ، والذي تديره الحكومة الصينية مباشرة. لدى الحكومة الصينية قاعدة تصفية معمول بها لجميع حركة المرور على الإنترنت وهي ليست عامة. يتم تعديل قواعد التصفية هذه بشكل متكرر ، مما يؤثر بدوره على نتائج المراقبة من وكيل شنغهاي ، الصين.
https://youtu.be/4py8zE5EtFc?si=LnpflrvFK1ESWYWQ
يمكنك تحرير مواقع وكيل المراقبة لأجهزة متعددة في وقت واحد على شاشة
إدارة الأجهزة
.
باختصار ، تقوم مهام UserView و BrowserView Platforms بتحميل صفحة ويب في متصفح حقيقي وتنفيذ جميع مكونات الصفحة ، بينما تستخدم مهمة HTTP (S) متصفحا "اصطناعيا" محاكيا وتقوم فقط بتنزيل عنصر الصفحة الذي تم طلبه دون تقديم.
لمزيد من التفاصيل، راجع الاختلافات بين المراقبة عبر HTTP(S) وعبر BrowserView/UserView والاختلافات في قياس الوقت بين مهام HTTP(S) وBrowserView/UserView.
بشكل افتراضي، تتعرف خوادم Exchange على ما إذا كان عنوان البريد الإلكتروني محليا أم لا. إذا كانت هذه هي الحالة ، فإن الخادم لا يرسل البريد الإلكتروني عبر الإنترنت العام. هذا هو الافتراضي لمعظم خوادم البريد الإلكتروني.
إذا كنت ترغب في اختبار الإرسال والاستلام عبر الإنترنت العام ، فإننا نوصي باستخدام شاشة البريد الإلكتروني ذهابا وإيابا + حساب بريد إلكتروني تابع ل 3rd مثل Gmail.
تتطلب مراقبة البريد الإلكتروني ذهابا وإيابا استخدام بروتوكولات POP3 أو IMAP إما في موقعك أو في الطرفالثالث (gmail).
هناك ثلاث طرق لاختبار ذلك مع رحلة ذهاب وإياب:
يقوم بروتوكول ActiveSync أيضا بتنفيذ رحلة ذهاب وإياب. تختبر المزامنة النشطة القدرة على إرسال بريد إلكتروني من جهاز بعيد (مواقع المراقبة الخاصة بنا) واسترداد بريد إلكتروني من الخادم بواسطة هذا الجهاز البعيد. لكنه لا يرسل البريد الإلكتروني من خادم مزامنة نشط إلى آخر لأن حساب الإرسال والاستقبال هما نفس الحساب على نفس الخادم ، لذلك يجد أقصر طريق إلى عنوان محلي لا يتطلب إرسال الرسالة إلى الإنترنت العام حتى يتم استرداد الرسالة من جهاز بعيد (مواقع المراقبة الخاصة بنا).
فيما يلي الفرق بين Round Trip و ActiveSync - يمكنك رؤية البريد الإلكتروني يتحرك عبر خوادم متعددة باستخدام موفر بريد إلكتروني تابع لجهة 3rd مثل Gmail ، بينما يوجد البريد الإلكتروني على خادم 1 باستخدام activesync:
يتم تأمين واجهة برمجة التطبيقات بواسطة عنوان IP للسماح للمستخدمين المصرح لهم بالوصول فقط. عند تكوين تكامل واجهة برمجة تطبيقات الويب (إدارة > > التكامل الجديد)، يجب تمكين الوصول إلى البيانات خارج حساب Dotcom-Monitor الخاص بك عبر واجهة برمجة تطبيقات الويب. يرجى زيارة كيفية إدراج عناوين IP في القائمة البيضاء للوصول إلى واجهة برمجة تطبيقات الويب للحصول على التفاصيل.
لمزيد من المعلومات حول كيفية استخدام واجهة برمجة التطبيقات، تفضل بزيارة صفحة بدء استخدام واجهة برمجة التطبيقات.
يقوم Dotcom-Monitor تلقائيا بإزالة البيانات من النظام وفقا للجدول التالي.
للحسابات النشطة:
ينطبق نهج الاستبقاء هذا على جميع أنواع المهام.
لا يتم الاحتفاظ ببيانات الحساب التجريبي وفقا لهذا الجدول الزمني ويمكن حذفها في أي وقت بعد انتهاء صلاحية الإصدار التجريبي.
قد تتم إزالة بيانات الحساب المغلق من النظام في غضون 60 يوما من آخر تسجيل دخول مستخدم للحساب.
بعد إعداد المهام باستخدام التنبيهات وبدء تشغيلها ، قد تجد نفسك تتلقى تنبيهات متعددة ، ولكن عند التحقق من الخدمة أو موقع الويب ، يبدو كل شيء على ما يرام. من المهم الانتباه إلى محتويات التنبيهات من أجل معرفة سبب الخطأ. قد تحتوي بعض الأخطاء على رموز خطأ Dotcom-Monitor مخصصة، بينما قد تحتوي أخطاء أخرى على رموز حالة http التي يمكن أن تساعدك في فك تشفير سبب الخطأ.
نظرا للطبيعة التفصيلية لقدرات مراقبة Dotcom-Monitor ، قد ترغب في تعديل التنبيهات أو التقارير أو البرامج النصية المسجلة لاستبعاد عناصر أو أخطاء معينة للقضاء على الإيجابيات الخاطئة. وتشمل بعض هذه الأسباب ما يلي:
يمكنك ضبط هذه الإيجابيات الخاطئة عن طريق إنشاء فلاتر وتطبيق الفلتر على التنبيهات والتقارير الخاصة بالجهاز المخالف.
يمكنك أيضا تمكين التحقق الإيجابي الكاذب على أجهزتك. سيؤدي ذلك إلى تشغيل سلسلة من عمليات التحقق من موقع يكتشف فشل المراقبة من أجل التأكد من أن الجهاز يخطئ أكثر من مرة
أسهل طريقة لإنشاء عدد كبير من عناصر الكائنات (الأجهزة / المهام / الفلاتر / الجداول الزمنية / إلخ.) في نظام Dotcom-Monitor هي فتح تذكرة دعم وطلب المساعدة من فريق الدعم.
يرجى الاستعداد لتقديم جدول بيانات يحتوي على قائمة بجميع الكائنات التي تريد إنشاؤها. إذا لزم الأمر ، يجب إرفاق جدول البيانات بتذكرة الدعم ، حتى يتمكن الدعم من إجراء التغييرات اللازمة لك.
بمجرد إنشاء لوحة معلومات، يمكنك عرضها في أي وقت عن طريق نسخ عنوان URL ولصقه في نافذة متصفح جديدة. ليس من الضروري تسجيل الدخول إلى النظام لعرض لوحة معلومات.
للعثور على عنوان URL للوحة المعلومات ،
يمكنك الآن حفظ عنوان URL في ملف أو إرسال عنوان URL بالبريد الإلكتروني إلى الآخرين أو لصقه في نافذة المتصفح ووضع إشارة مرجعية على العنوان للوصول إليه بسهولة في المستقبل.
يمكنك إسكات تنبيهات الأجهزة الفردية لمدة تصل إلى 24 ساعة من "إدارة الأجهزة" بالنقر فوق الإجراءات الموجودة بجوار الجهاز، وتحديد "صمت التنبيه"، وإسكات الصوت للفترة المطلوبة.
لإسكات أجهزة متعددة في وقت واحد ، انقر فوق مربع الاختيار بجوار كل جهاز ترغب في إسكاته ، ثم انقر فوق الزر "تنبيه الصمت" أعلى القائمة ، وحدد الفترة التي تريدها.
يمكنك أيضا استخدام واجهة برمجة التطبيقات لإسكات التنبيهات لأكثر من 24 ساعة. للحصول على معلومات حول كيفية القيام بذلك ، قم بالدفع API: تعطيل التنبيهات لجهاز.
توفر أنظمة Dotcom-Monitor مجموعة قوية من أدوات المراقبة التي يجب تعديلها بعناية للكشف عن مستوى الأداء المطلوب لكل هدف مراقب. نظرا لعدد عوامل التنبيه وتنوعها ، قد تحتاج إلى تعديل بعض الإعدادات على شاشاتك من أجل القضاء على الإيجابيات الخاطئة.
لتحديد ما إذا كانت التنبيهات التي تتلقاها صالحة، راجع هذه المقالة حول تحديد الإيجابيات الخاطئة.
إذا كنت لا تزال لا ترغب في تلقي تنبيهات بالطريقة التي تم تكوينها بها حاليا، فإن تشغيل تقرير عبر الإنترنت من "إدارة الأجهزة" للوقت الذي تلقيت فيه التنبيهات سيمنحك مزيدا من التبصر حول ما يؤدي إلى تشغيل التنبيهات.
إذا كان الخطأ الموجود في التقرير عبر الإنترنت ينص على "انتهت صلاحية الحد الأقصى للمهلة (300) مهمة" ، فهذا يعني أن المهمة استغرقت وقتا أطول لإكمالها من الحد الأقصى للمهلة المحددة للمهمة. قد يشير هذا إلى وجود مشكلة مشروعة ، ولكن الأمر متروك لك لتحديد النقطة التي تحتاج فيها إلى تلقي تنبيهات. إذا كنت تشعر أنك تتلقى الكثير من التنبيهات، فيمكنك تحرير المهمة وزيادة الحد الأقصى للمهلة.
إذا كنت تراقب من مواقع متعددة، ولكنك تواجه مشكلات من موقع واحد فقط، فهناك العديد من الأشياء التي يمكنك التحقق منها.
إذا كان الوصول إلى الخادم محدودا عبر عنوان IP ، فيجب عليك التأكد من إضافة عناوين IP لجميع مواقع المراقبة إلى قائمة الوصول إلى عنوان IP الخاص بك.
إذا كان الخادم يتطلب شهادة للوصول إلى المحتوى، فيجب عليك فتح تذكرة دعم لتحميل الشهادة إلى كل موقع مراقبة.
إذا كنت تواجه مشكلات من موقع في الصين ، فقد ترى نتائج "جدار الحماية العظيم للصين". نظرا لأن الحكومة الصينية تحتفظ برقابة مشددة على المحتوى الذي يمكن الوصول إليه من داخل البلاد ، في بعض الأحيان يتم تصفية المحتوى على أنه يتعذر الوصول إليه أو يتم خنق عرض النطاق الترددي لمواقع معينة بحيث تنتهي مهلة العناصر من الموقع. في هذه الحالات ، غالبا ما يكون هناك القليل الذي يمكنك القيام به لأن الحكومة الصينية تسيطر على الشبكة.
إذا كنت تواجه مشكلات من موقع واحد أو عدد قليل من المواقع المحددة، فيمكنك فتح تذكرة دعم وسيعمل فريق الدعم لدينا معك لتحديد المشكلات المحتملة الأخرى. في بعض الأحيان قد تكون هناك مشكلات في توجيه خادم DNS بشكل غير صحيح أو عكس بحث DNS أو مشكلة خاصة بموقع المراقبة.
إذا كنت تقوم بتشغيل برنامج نصي UserView، فقد تحتاج إلى إضافة تأخير إلى البرنامج النصي لمنح الموقع المزيد من الوقت لتحميل كافة العناصر بشكل صحيح. يمكنك أيضا تكرار الخطوة ، مثل النقر فوق href بعد إضافة تأخير ، لذلك في حالة عدم عرض الرابط على الصفحة في المرة الأولى ، سيحاول النقر فوقه مرة أخرى.
هناك عدد من العوامل التي تحدد ما إذا كان سيتم إرسال رسالة تنبيه وإلى من سيتم إرسالها.
عند إنشاء جهاز، يتم تطبيق فلتر افتراضي تلقائيا على جميع الأجهزة. يتطلب عامل التصفية الافتراضي أن يتلقى أكثر من موقع واحد (ما لم تحدد موقعا واحدا فقط) الخطأ قبل تشغيل التنبيه. يتم ذلك للقضاء على التنبيهات الإيجابية الكاذبة عندما يعاني موقع واحد من زوبعة شبكة صغيرة. يمكنك إنشاء فلتر لا يتطلب أكثر من موقع واحد ، ولكن كن على دراية بأنك ستتلقى على الأرجح العديد من التنبيهات الإيجابية الكاذبة بسبب الطبيعة غير المنضبطة لحركة المرور على الإنترنت.
إذا قمت بتطبيق جدول زمني على جهاز، فلن تتم مراقبة الجهاز خلال الفترات غير المجدولة، لذلك لن يتم تسجيل أي بيانات لتنبيه. نوصي بعدم تطبيق جدول زمني مباشرة على أجهزتك بحيث يتم مراقبة النظام 24/7 حتى لو كنت لا ترغب في تلقي تنبيهات على مدار الساعة. يمكنك تطبيق الجداول الزمنية على مجموعات تنبيهات مختلفة بحيث لا تتلقى المجموعات المختلفة تنبيهات إلا أثناء نوبات عملها، على سبيل المثال.
عند إعداد تنبيهات المجموعة، يمكنك تحديد ما إذا كان يجب أن تتلقى المجموعة إشعارا على الفور عند اكتشاف الخطأ، أو ما إذا كان يجب أن يكون هناك تأخير بين وقت اكتشاف الخطأ لأول مرة ووقت إرسال الخطأ. على سبيل المثال، ربما يكون لديك مجموعة دعم من المستوى الثاني يتم إعلامها فقط عند استمرار حدوث خطأ بعد 30 دقيقة من تلقي دعم الطبقة الأولى تنبيها.
بشكل افتراضي، يتم تشغيل التحقق الإيجابي الخاطئ. وهذا يعني أنه إذا واجه موقع المراقبة خطأ، فإنه يحاول إعادة إنشاء الخطأ قبل إرسال رسالة خطأ. لا نوصي بتعطيل هذا لأنه سيزيد من خطر تلقي تنبيهات إيجابية كاذبة ، ومع ذلك ، إذا كانت مهمتك تستغرق وقتا طويلا بشكل خاص لإكمال تكرار واحد ، فقد ترغب في إيقاف تشغيل الفحص الإيجابي الخاطئ بحيث تتلقى أخطاء على الفور بدلا من 10 دقائق بعد اكتشاف الخطأ الأول (5 دقائق لإكمال المهمة الأولى ، ثم عند اكتشاف الخطأ ، 5 دقائق أخرى لتأكيد الخطأ)
لاحظ أنه يمكن إعداد مجموعات التنبيه واستخدامها لأجهزة متعددة. إذا لاحظت أن شخصا ما لا يتلقى تنبيها، فتأكد من وجود معلومات الاتصال الخاصة به في جميع المجموعات الضرورية. كن حذرا عند تحرير الأشخاص أو إزالتهم من المجموعات لأنه يمكن استخدام هذه المجموعة لأجهزة إضافية.
هناك العديد من الأخطاء المختلفة التي يمكن أن تحدث أثناء وصول موقع الويب جزئيا أو كليا. تتضمن بعض الأخطاء الأكثر شيوعا التي يمكن أن تحدث أثناء استمرار توفر موقع الويب الخاص بك ما يلي:
إذا حدد الخطأ حدوث مهلة، فقم بتحرير تفاصيل مهمة المراقبة وابحث عن قيمة الحد الأقصى للمهلة. إذا كنت تتلقى العديد من أخطاء المهلة ، فقد ترغب في التفكير في زيادة الحد الأقصى لقيمة المهلة أو إزالتها تماما. بدلا من ذلك، يمكنك إجراء تحديثات على موقعك لتحسين سرعة التحميل أو استضافة عناصر فردية في شبكة توزيع المحتوى (CDN). إذا لم تقم بتحديد قيمة الحد الأقصى للمهلة، فإن المهلة الافتراضية لمهمة ما هي 120 ثانية.
إذا كانت المهمة تتضمن التحقق من صحة كلمة رئيسية أو صورة معينة تم العثور عليها على الصفحة، فقد يستمر تحميل بقية المحتوى بشكل صحيح أثناء فقدان العنصر المتوقع.
قد تفشل بعض عمليات التحقق من الصحة إذا كانت المهمة تبحث عن عنصر قبل تحميل العنصر بالكامل. إذا كانت المهمة عبارة عن برنامج نصي UserView ، فقد تحتاج إلى إضافة تأخير زمني قبل التحقق من صحة هذا العنصر المحدد.
في بعض الأحيان ، نظرا لمشكلات الشبكات المختلفة عبر الإنترنت أو موفري الخدمات المحليين ، قد لا يتمكن أحد خوادم DNS المحددة أو ذات المستوى الأعلى من التأهل الكامل لدقة DNS لموقعك. في هذه الحالة، تستمر معظم المتصفحات في الاستعلام عن خادم DNS التالي المتاح وإكمال الدقة، ولكن بناء على كيفية إعداد المراقبة، قد تستمر في تلقي تنبيهات. لمزيد من المعلومات حول كيفية استكشاف أخطاء DNS وإصلاحها، تفضل بزيارة مقالة قاعدة المعارف هنا.
في تفاصيل التقرير عبر الإنترنت ، عندما أقوم بتوسيع جلسة مراقبة فردية لعرض التفاصيل الدقيقة للخطوات ، لماذا نرى أخطاء ولكن مهمة المراقبة الشاملة تنجح؟
هناك عدد من الحالات التي يؤدي فيها عنصر فردي أو مكالمة إلى خادم تتم مراقبته إلى استجابة تم وضع علامة عليها أو خطأ. عادة ما يتم ملاحظة هذه الردود بعلامة تعجب حمراء وقد يكون النص رماديا قليلا.
