HTTPS
مراقبة المواقع وAPIs
صفحة أو نقطة نهاية، يتم جلبها من أربع قارات.
جربه الآن
فحص واحد، من مكان واحد، الآن، ولا يتم حفظ أي شيء. يقوم المراقب بالفحص من كل موقع نعمل فيه ويؤكد الفشل من ثلاث قارات قبل أن يتم إيقاظ أي شخص، وهو ما لا يمكن أن يظهره فحص واحد.
ما الغرض منه
الفحص الذي يبدأ به الجميع، والذي تتوقف عنده معظم المنتجات. نطلب URL، نتبع أو نرفض إعادة التوجيه كما تقول، ونقرأ رمز الحالة.
رمز الحالة بمفرده هو وعد ضعيف. يمكن أن يعيد الموقع 200 أثناء تقديم صفحة خطأ، شاشة تسجيل الدخول، نسخة مخزنة من الثلاثاء الماضي، أو قشرة فارغة فشلت في العرض. لذلك يمكن أن يتطلب الفحص أيضًا وجود عبارة، إعادة توجيه إلى مكان معين، حقل JSON يحمل قيمة معينة، ووصول الاستجابة داخل وقت تحدده. هذه هي الإخفاقات التي لا يمكن لرمز الحالة رؤيتها.
مثل كل فحص هنا، يتم من Amsterdam, New York, Sydney and Singapore، ويتم تأكيد الفشل من ثلاث قارات قبل أن يتم إيقاظ أي شخص. كيف يعمل ذلك.
ما يمكنك ضبطه
كل ما هو أدناه موجود في النموذج عند إضافة واحد، على كل خطة.
- الطريقة
- GET، HEAD، POST، PUT، PATCH أو DELETE. HEAD هو الافتراضي المهذب لصفحة تحتاج فقط إلى معرفة وجودها.
- الحالة المتوقعة
- أي الرموز تعتبر صحية. 401 صحيح لنقطة نهاية يجب أن ترفضك، وقول ذلك يمنعنا من الإبلاغ عن عمل المصادقة الخاصة بك كتعطل.
- الكلمة المفتاحية
- عبارة يجب أن تكون موجودة، أو يجب أن تكون غائبة. الطريقة الأرخص لاكتشاف 200 التي هي في الواقع صفحة خطأ.
- تأكيدات JSON
- مسار والقيمة التي يجب أن يحملها، لـ API التي تجيب بـ 200 مع جسم يقول خلاف ذلك.
- إعادة التوجيه
- اتبع السلسلة، أو اعتبر إعادة التوجيه كالإجابة. مع موقع متوقع، هذا يكتشف موقعًا تم إعادة توجيهه بهدوء إلى مكان لا يجب أن يكون فيه.
- البطء هو فشل
- وقت استجابة أعلى من ذلك يعتبر الفحص متدهورًا بدلاً من كونه نشطًا، وعدد المرات المتتالية قبل أن نقول ذلك.
- المصادقة
- Basic أو Bearer. يتم تخزينها مشفرة، فك تشفيرها بواسطة لوحة التحكم، وتسليمها إلى المجس مع المهمة بدلاً من إعطاء آلة مستأجرة المفتاح لكل شيء.
- الرؤوس والجسم
- أي شيء يحتاجه الطلب. رأس واحد لكل سطر، وجسم للطرق التي تحتاج إلى واحد.
- مهلة
- كم من الوقت يجب الانتظار قبل اعتباره فشلًا.
- التأكيدات
- كم عدد القارات الأخرى التي يجب أن توافق قبل أن يتم تنبيه أي شخص. الصفر متاح ونادرًا ما يكون ما تريده.
الأسئلة
ماذا يعني 502 أو 503، وهل ستنبه بشأنه؟
502 هو الخادم الأمامي يخبرك أن الخادم الخلفي أعطى إجابة لا يمكن استخدامها، و503 هو خادم يقول إنه لا يقبل الطلبات، وهو ما تعيده معظم الأطر أثناء إعادة التشغيل. كلاهما يفشل الفحص افتراضيًا لأن الافتراضي يتوقع 2xx و3xx. إذا كان الكود صحيحًا لذلك النقطة النهائية، أضفه إلى قائمة الحالات المتوقعة وسيتوقف عن كونه انقطاعًا.
هل تتحقق من سلسلة شهادات SSL/TLS؟
نعم. الفحص يتصل بالطريقة التي يتصل بها المتصفح، باستخدام مخزن الثقة العام، لذا فإن الشهادة الوسيطة المفقودة، أو الشهادة الموقعة ذاتيًا، أو عدم تطابق اسم المضيف، أو الشهادة المنتهية الصلاحية تفشل الفحص بخطأ TLS بدلاً من كود الحالة. ما لا يفعله هو حساب الأيام المتبقية، وهو وظيفة مراقب شهادة SSL/TLS. يمكن تعطيل التحقق لكل مراقب لمضيف داخلي تعرفه.
هل يمكنني مراقبة نقطة نهاية API بدلاً من صفحة؟
هذا هو الغرض من خيارات الطلب، ولهذا السبب لا يوجد نوع مراقب API منفصل يختلف عن هذا. اختر POST أو PUT أو PATCH أو DELETE، أضف رؤوسًا وجسمًا، قم بالمصادقة باستخدام بيانات اعتماد أساسية أو Bearer، وقبل أي أكواد حالة صحيحة، وتحقق من مسار في JSON الذي يعود.
ما الفرق بين المهلة والاستجابة البطيئة؟
مهلة هي فحص لم يحصل على إجابة داخل الثواني التي سمحت بها، ويتم الإبلاغ عنها كفشل بدون كود حالة، باستثناء اتصال تم رفضه تمامًا. بطيء هو إجابة وصلت واستغرقت وقتًا طويلاً: قم بتعيين وقت استجابة يتجاوز فيه الفحص يُعتبر متدهورًا، وعدد المرات المتتالية قبل أن يسمع أي شخص عن ذلك.
هل تتبع إعادة التوجيه؟
ليس إلا إذا قلت ذلك، مما يفاجئ الناس بما يكفي ليكون جديرًا بالتوضيح. الموقع الذي يبدأ بالإجابة بـ302 لصفحة انتظار يكون معطلاً، والمراقب الذي يتبعها بهدوء ويجد 200 سيبلغ عن ذلك كأنه صحي. قم بتشغيل المتابعة عندما يكون التحويل هو الهدف، وسمّ الموقع الذي تتوقع الوصول إليه.
هل يقوم الفحص بتشغيل JavaScript أو عرض الصفحة؟
لا، ونقول ذلك بدلاً من الإيحاء بخلاف ذلك. يقوم بجلب المستند الذي يرسله الخادم ويقرأه، لذا يجب أن يتطابق فحص الكلمات المفتاحية مع شيء في HTML بدلاً من شيء يرسمه إطار العمل لاحقًا. بالنسبة لصفحة يتم عرضها في المتصفح، تحقق من كود الحالة، وقت الاستجابة، وعبارة موجودة بالفعل في الاستجابة.
هل وقت الاستجابة هو ما يختبره زواري؟
إنه الوقت الذي انتظر فيه مسبارنا، من الطلب إلى الاستجابة، على اتصال بدون ذاكرة تخزين مؤقت باردة وبدون متصفح أمامه. هذا يجعله إنذارًا ممتازًا لخادم يصبح أبطأ ونموذجًا ضعيفًا لشخص واحد على الهاتف. مراقبة المستخدم الحقيقي وCore Web Vitals تجيب على السؤال الآخر وهذا الفحص لا يدعي ذلك.
لماذا لا تستخدم curl من خلال cron job؟
بالنسبة إلى عنوان URL واحد من جهاز واحد، فإن وظيفة cron تقوم بمعظم هذا، وأي شخص يخبرك بغير ذلك يبيع شيئًا. ما لا يوفره لك هو مكان للتشغيل لا يمكن أن يتوقف بهدوء: فحص على جهاز فقد شبكته لا يبلغ عن شيء، مما يبدو تمامًا وكأن كل شيء على ما يرام. كما أنه لا يميز بين رابط مكسور بينك وبين الموقع وبين تعطل الموقع نفسه، وهو ما يهدف إليه الفحص من ثلاث قارات، ولا يزال يترك لك بناء الجزء الذي يوقظ شخصًا ما.
كيف يختلف هذا عن فحص اصطناعي يعتمد على المتصفح؟
الفحص الاصطناعي يشغل متصفحًا حقيقيًا، لذا يرى أشياء لا يمكننا رؤيتها: صفحة تظهر فارغة لأن نصًا برمجيًا فشل، زر توقف عن العمل، خط لم يتم تحميله أبدًا. هذا الفحص يقوم بإجراء الطلب وقراءة الإجابة، مما يعني أنه لا يمكنه رؤية أي من ذلك. ما يقدمه لك بدلاً من ذلك هو فحص رخيص بما يكفي لتشغيله كل ثلاثين ثانية من ثلاث قارات، على كل عنوان URL لديك، بدلاً من عدد قليل من الرحلات عدة مرات في الساعة. يجيبون على أسئلة مختلفة ويريد الكثير من الناس كلاهما.