HTTPS
Monitoreo de sitios web y APIs
Una página o un endpoint, obtenidos desde cuatro continentes.
Pruébalo ahora
Una comprobación, desde un lugar, ahora mismo, y nada se guarda. Un monitor verifica desde cada ubicación en la que operamos y confirma un fallo desde otros dos continentes antes de que alguien sea despertado, lo cual una sola mirada no puede mostrarte.
Para qué sirve
La comprobación con la que todos comienzan y en la que la mayoría de los productos se detienen. Solicitamos la URL, seguimos o rechazamos redirecciones según lo indiques y leemos el código de estado.
Un código de estado por sí solo es una promesa débil. Un sitio puede devolver 200 mientras sirve una página de error, una pantalla de inicio de sesión, una copia en caché del martes pasado o un contenedor vacío que no se pudo renderizar. Por eso, la comprobación también puede requerir que una frase esté presente, que una redirección llegue a un lugar específico, que un campo JSON contenga un valor particular y que una respuesta llegue dentro de un tiempo que configures. Esos son los fallos que un código de estado no puede detectar.
Como cada chequeo aquí, se ejecuta desde Amsterdam, New York, Sydney and Singapore, y un fallo se confirma desde otros dos continentes antes de despertar a nadie. Cómo funciona.
Lo que puedes configurar
Todo lo siguiente está en el formulario cuando añades uno, en todos los planes.
- Método
- GET, HEAD, POST, PUT, PATCH o DELETE. HEAD es el valor predeterminado educado para una página de la que solo necesitas saber que existe.
- Estado esperado
- Qué códigos cuentan como saludables. Un 401 es correcto para un endpoint que debería rechazarte, y decirlo evita que informemos tu autenticación funcionando como una caída.
- Palabra clave
- Una frase que debe estar presente o ausente. La forma más económica de detectar un 200 que en realidad es una página de error.
- Aserciones JSON
- Una ruta y el valor que debería contener, para una API que responde 200 con un cuerpo que dice lo contrario.
- Redirecciones
- Sigue la cadena o trata una redirección como la respuesta. Con una ubicación esperada, esto detecta un sitio redirigido silenciosamente a donde no debería estar.
- Lento es un fallo
- Un tiempo de respuesta por encima del cual la comprobación cuenta como degradada en lugar de activa, y cuántos seguidos antes de que lo digamos.
- Autenticación
- Basic o Bearer. Almacenado encriptado, desencriptado por el plano de control y entregado a la sonda con la asignación en lugar de darle a una máquina alquilada la clave de todo.
- Encabezados y cuerpo
- Todo lo que la solicitud necesite. Un encabezado por línea y un cuerpo para los métodos que lo requieran.
- Timeout
- Cuánto tiempo esperar antes de considerarlo un fallo.
- Confirmaciones
- Cuántos otros continentes deben estar de acuerdo antes de que alguien sea despertado. Cero está disponible y rara vez es lo que quieres.
Preguntas
¿Qué significa un 502 o un 503, y enviarás una alerta por ello?
Un 502 es el servidor frontal diciendo que el de atrás dio una respuesta que no pudo usar, y un 503 es un servidor diciendo que no está aceptando solicitudes, que es lo que la mayoría de los frameworks devuelven mientras reinician. Ambos fallan el chequeo por defecto, porque el predeterminado espera 2xx y 3xx. Si un código es correcto para ese endpoint, ponlo en la lista de estados esperados y deja de ser una interrupción.
¿Verificas la cadena de certificados SSL/TLS?
Sí. El chequeo se conecta como lo haría un navegador, contra el almacén de confianza público, así que un intermedio faltante, un certificado autofirmado, un nombre de host que no coincide o uno expirado fallan el chequeo con un error TLS en lugar de un código de estado. Lo que no hace es contar los días restantes, que es el trabajo del monitor de certificados SSL/TLS. La verificación se puede desactivar por monitor para un host interno que conozcas.
¿Puedo monitorear un endpoint de API en lugar de una página?
Para eso están las opciones de solicitud, y es por eso que no hay un tipo de monitor API separado que se desvíe de este. Elige POST, PUT, PATCH o DELETE, añade headers y un cuerpo, autentica con credenciales básicas o bearer, acepta los códigos de estado que sean correctos y verifica una ruta en el JSON que regrese.
¿Cuál es la diferencia entre un timeout y una respuesta lenta?
Un timeout es un chequeo que nunca obtuvo una respuesta dentro de los segundos que permitiste, y se reporta como un fallo sin código de estado, aparte de una conexión que fue rechazada directamente. Lento es una respuesta que llegó y tomó demasiado tiempo: establece un tiempo de respuesta por encima del cual el chequeo cuenta como degradado, y cuántos seguidos antes de que alguien se entere.
¿Sigues las redirecciones?
No, a menos que lo digas, lo cual sorprende a la gente lo suficiente como para valer la pena explicarlo. Un sitio que empieza a responder 302 a una página de estacionamiento está roto, y un chequeador que lo sigue silenciosamente y encuentra un 200 lo reportaría como saludable. Activa el seguimiento cuando el redireccionamiento sea el objetivo y nombra la ubicación en la que esperas terminar.
¿La comprobación ejecuta JavaScript o renderiza la página?
No, y lo decimos en lugar de implicar lo contrario. Obtiene el documento que el servidor envía y lo lee, así que un chequeo de palabras clave tiene que coincidir con algo en el HTML en lugar de algo que un framework pinta después. Para una página renderizada en el navegador, verifica el código de estado, el tiempo de respuesta y una frase que esté realmente en la respuesta.
¿El tiempo de respuesta es lo que experimentan mis visitantes?
Es el tiempo que nuestra sonda esperó, desde la solicitud hasta la respuesta, en una conexión sin caché fría y sin navegador delante. Eso lo convierte en un excelente detector para un servidor que se está volviendo más lento y un mal modelo de una persona en un teléfono. El monitoreo de usuario real y los Core Web Vitals responden a la otra pregunta y este chequeo no pretende hacerlo.
¿Por qué no simplemente usar curl desde un cron job?
Para una URL desde una máquina, un cron job realmente es la mayor parte de esto, y cualquiera que te diga lo contrario está vendiendo algo. Lo que no te da es un lugar para ejecutarlo que no pueda morir silenciosamente: un chequeo en una caja que ha perdido su red no reporta nada, lo cual parece exactamente como si todo estuviera bien. Tampoco te dice si hay un enlace roto entre tú y el sitio o si el sitio está roto, que es para lo que sirve verificar desde dos continentes más, y aún te deja construir la parte que despierta a alguien.
¿En qué se diferencia esto de un chequeo sintético basado en navegador?
Un chequeo sintético utiliza un navegador real, así que ve cosas que nosotros no podemos: una página que se renderiza en blanco porque un script falló, un botón que dejó de funcionar, una fuente que nunca cargó. Este chequeo hace la solicitud y lee la respuesta, lo que significa que no puede ver nada de eso. Lo que te da en cambio es un chequeo lo suficientemente barato como para ejecutarlo cada treinta segundos desde tres continentes, en cada URL que tengas, en lugar de un puñado de recorridos unas pocas veces por hora. Responden preguntas diferentes y mucha gente quiere ambos.