asynch esperar ping() función setInterval(). ¿Cómo hacerla inteligente?
El siguiente código hace ping a un bloque de ubicación NGINX en mi servidor NGINX para darte un estado de verificación de salud.
const ping = async () => {
const url = `http://10.10.1.100/status`;
const postData = {
method: 'POST', // *GET, POST, PATCH, DELETE, etc.
mode: 'cors', // no-cors, *cors, same-origin
cache: 'no-cache', // *default, no-cache, reload, force-cache, only-if-cached
headers: {
'Content-Type': 'text/plain; charset=ASCII'
},
body: 'PING'
}
try {
let factor = 1;
let timeout = 3000; // ms
let start = (new Date()).getTime();
const request = await fetch(url, postData);
let delta = new Date().getTime() - start;
delta *= (factor || 1);
if(delta > timeout) throw new Error(`PONG > ${timeout}ms. ¿Servidor desconectado?`);
if(!request.ok) throw new Error(`${request.status} ${request.statusText}`);
const response = await request.text();
if(!response) throw new Error(`${response}`);
document.getElementById('serverPongSpeed').innerText = `${delta.toFixed(0)}ms`;
// Haz algo...
console.log(`%c${delta.toFixed(0)}ms ${response}`, "color: #c6ff00"); // Verde Limón A400
} catch (error) {
console.log(error);
}
}
El bloque de ubicación NGINX:
location = /status {
access_log off;
default_type text/plain;
add_header "Access-Control-Allow-Methods" "POST";
add_header "Content-Type" "text/plain";
return 200 "PONG";
}
Ahora lo ejecuto de esta manera:
setInterval(ping, 3000); // Cada 3 segundos
El problema es que, durante las pruebas, cuando apago NGINX para ver qué sucede, el PING no se interrumpe. Simplemente sigue enviando solicitudes POST.
Tal vez haya un error que no estoy capturando. O tal vez no haya error porque el fetch tiene un tiempo de espera mayor. Tal vez establecer un tiempo de espera fetch de 3 segundos generarí aalgo para que yo pueda capturar.
davy.ai
Explicación del código de verificación de estado de NGINX
El código proporcionado en javascript establece una función llamada
pingque envía una solicitud POST a un bloque de ubicación NGINX ubicado en `http://10.10.1.100/status`. El bloque de ubicación NGINX responde con un código de estado 200 y el texto “PONG” si todo está funcionando correctamente. La función establece un tiempo de espera de 3000ms (3 segundos) para que se complete la solicitud. Si la respuesta tarda más tiempo, la función arroja un error.La función utiliza
fetchpara realizar la solicitud POST, que es una función incorporada en los navegadores web modernos que permite obtener recursos a través de la red de manera asíncrona y no bloqueante.El bloque de ubicación NGINX está configurado para devolver una respuesta como contenido de texto sin formato, sin registro de acceso y permitiendo solo el método HTTP POST. Este es un patrón común para configurar un punto final de verificación de estado simple en NGINX.
Problemas identificados con la implementación actual
La implementación actual no captura ningún error cuando el servidor NGINX está fuera de línea, lo que significa que el
setIntervalcontinuará llamando a la funciónpingy no habrá indicación ni retroalimentación de que el servidor está caído.La función no establece ningún tiempo de espera para la llamada
fetch, lo que significa que podría quedarse colgada indefinidamente si el servidor NGINX no responde.Posibles mejoras
Para manejar el escenario cuando el servidor NGINX está caído, la llamada
fetchpodría devolver un código de estado de error (por ejemplo, 500), que la función podría capturar y manejar en consecuencia. Además, la función podría establecer un número máximo de intentos antes de asumir que el servidor está caído, basándose en un contador que se incrementaría en cada fallo.Para evitar que la llamada
fetchse quede colgada indefinidamente, se podría agregar un parámetro de tiempo de espera a las opciones defetchde la función, que desencadenaría un error si el servidor no responde dentro de un período de tiempo de espera.Aquí hay un ejemplo de cómo agregar un tiempo de espera de 3 segundos a las opciones de
postData:En general, la función
pingproporciona una forma simple y efectiva de verificar la salud de un servidor NGINX, pero con algunos mecanismos adicionales de manejo de errores y tiempo de espera, podría ser más sólida y confiable.