En mi aplicación, estoy haciendo ping a un servidor y esperando una respuesta. Estoy usando esto para determinar si el servidor está disponible y responde o no.
¿Es esta una forma confiable de determinar la disponibilidad? Supongo que un firewall podría estar filtrando el tráfico icmp ... ¿Hay algún otro inconveniente? ¿Hay un método más confiable?
Respuestas:
La mejor manera de saber si un servicio remoto determinado está activo es pedirle que atienda una solicitud de la manera en que debe hacerlo; de hecho, es la única forma de saber realmente que algo funciona correctamente.
Como ejemplo, siempre obtengo que mis equilibradores de carga obtengan una respuesta 'cabeza' real de nuestros servidores web, puede hacer lo mismo para una pequeña selección en un cuadro de DB si lo desea, o lo que sea que su servidor real atienda. Como consejo, puede crear un 'online.txt' (o el nombre que desee) en sus servidores web, haga que sus LB intenten obtener ese archivo y, si falla, elimina el servidor del VIP, esto es Una buena manera de sacar manualmente los servidores individuales de sus VIP simplemente cambiando el nombre de un solo archivo.
Ping solo prueba la capacidad de responder a los pings, por lo que ese es el sistema operativo base, partes de la pila de IP y los enlaces físicos, pero eso es todo, todo lo demás podría estar inactivo y no lo sabría.
Sé que esto se menciona a continuación, pero vale la pena repetirlo una y otra vez.
Las solicitudes de eco ICMP (también conocido como "Pings") (también conocido como ICMP Tipo 8) se integran en la especificación de la pila de IP, sí, pero no es necesario implementarlas ni utilizarlas. De hecho, hay una gran cantidad de proveedores de Internet que se niegan a reenviarlos y descartan silenciosamente esas solicitudes, ya que son una forma de ataque a la red (llamada pingflood).
Como se mencionó anteriormente, esto lo maneja el sistema operativo (específicamente en el nivel de pila de red) y, por lo tanto, corresponde a la configuración del sistema operativo responder a esos o no. Si esto está desactivado (¿una precaución de seguridad?), No puede hacer nada para recibir respuestas de ping desde el otro extremo. Por eso no es confiable.
La mayoría de las veces, sí, sin embargo:
algunos servidores bloquean las solicitudes de ping
el hecho de que el servidor responda no significa automáticamente que el sitio web (o cualquier servicio que espere usar) esté funcionando , también debe verificar si la respuesta coincide con el contenido esperado.
Es cierto que en muchas ocasiones el tráfico ICMP se filtra, por lo que podría no ser confiable ...
Una mejor manera quizás podría ser hacer telnet al servidor en el puerto de servicio que le interesa.
es decir, telnet 127.0.0.1 8080
Si solo se requiere que el servidor responda a los pings, este es un buen método para determinar su disponibilidad. Si es necesario proporcionar, por ejemplo, un servicio web, debe realizar alguna forma de prueba para ver si funciona de manera similar para los servicios de archivos, etc.
ping tiene 2 inconvenientes:
una mejor solución es verificar su puerto udp / tcp directamente, para ver si el servicio aún está disponible ... :-)
Existen herramientas especiales para pruebas y monitoreo como Nagios / Icinga .
Con estas herramientas puede (por supuesto) hacer verificaciones con varias pruebas de ping pero también hacer verificaciones de sus servicios.
Todas las comprobaciones pueden usar el valor devuelto para clasificar el resultado como "bueno", "advertencia" y "crítico" y pueden escribirse en casi todos los lenguajes de programación.
Por supuesto, no es fácil de configurar (como apuntar y hacer clic), pero es personalizable, confiable y extensible. Funciona bien en varias distribuciones de Linux y Unix.
Pruebe los servicios que está buscando, solo hacer ping a un servidor no significa que los servicios estén funcionando.
Por ejemplo:
Imagine un servidor web con docenas de sitios web, luego necesito saber si los sitios web están ARRIBA, hice un pequeño script en php y lo ejecuté cada 10 minutos.
El guión hace lo siguiente ->
<?php
$website1 = "http://www.mywebsite.com/";
$myWebsite = file_get_contents($website1);
$message = 'My website' . $website1 . ' is DOWN at the moment.';
if (empty($myWebsite)) mail('mail@server.com', 'Website is DOWN', $message);
?>
pingAntes de iniciar nuestro servicio systemd que intenta una conexión ssh, usamos para hacer una comprobación previa de que el host está encendido y accesible. Esto ahorra algo de tiempo de depuración, ya que el systemctl startcomando fallará inmediatamente, en lugar de fallar silenciosamente y perderse en la jungla de Journalctl.
Tenga en cuenta que ping no es "confiable" en el mismo sentido que TCP. Si tiene una mala conexión (o una pila de red defectuosa, gracias a Intel mpss ) y se están descartando paquetes, puede fallar un solo ping de paquete. Por otro lado, una conexión TCP es confiable contra paquetes descartados. Entonces, irónicamente, una conexión ssh podría funcionar inmediatamente después de una sola ping falla . Entonces, si usa ping para hacer una verificación de cordura, asegúrese de permitir alguna falla.
Solo mis dos centavos: tenemos una aplicación heredada que usa este método y tuvimos que repararla porque el ping no era suficiente para determinar la disponibilidad del servicio.
Ping simplemente muestra que el servidor es capaz de escuchar, pero en nuestro caso el servicio no pudo iniciarse sin intervención humana.
Como resultado, las unidades, que ingenuamente asumían que el servidor estaba disponible, intentaban conectarse y agotar el tiempo de espera. En lugar de mostrar nuestro mensaje "El servidor no está disponible".
-
Nuestra aplicación actual, que se comunica a través de XMLHTTPRequests a un servidor web, envía un mensaje formado al que el servidor responderá con un código de estado. El servidor calcula el código de estado realizando una serie de comprobaciones para garantizar que varios subsistemas estén en línea (DB, los directorios necesarios se pueden escribir, etc.)
Si, en circunstancias normales, su servidor responde al ping, es útil hacerlo a intervalos de un minuto para verificar si responde. Por supuesto, esto solo le dice que hay un servidor en esa dirección IP y que hay una ruta de red desde el origen del ping hasta el destino. Establecer un umbral para el tiempo de respuesta puede permitirle controlar también el estado de la red. Si está haciendo ping a un servidor en Internet, puede haber poco que pueda hacer para arreglar la red, pero si un cliente llama para quejarse, ya estará al tanto del problema. Hacer ping a google.com además también es útil. Si usted y Google están inactivos, algo está sucediendo.
Como otros han mencionado, es importante monitorear que el servicio que está brindando está respondiendo y que su rendimiento es correcto. Es decir, es posible que desee comprobar por qué una era web que generalmente responde en un segundo ahora responde que tengo 10 segundos.
Entonces, saber que un servicio no responde y está fallando en el ping le brinda mucha más información que un solo enfoque. Además, si también supervisa los procesos, sabiendo que el ping responde, el servicio no responde y el servidor web no tiene la cantidad correcta de procesos que le indica dónde buscar primero.
Puede volverse loco con el monitoreo, así que solo monitoree lo suficiente como para decirle cuando algo malo ha sucedido o se está volviendo peligroso. Es decir, demasiados intercambios,> 90% de uso de disco, alto io de disco, 100% de CPU por períodos prolongados y recuerde que el monitoreo es solo un ataque de denegación de servicio llevado a cabo muy lentamente.
Ping (Packet Internet Groper) le hace saber si su sistema se está comunicando con el sistema con el que desea establecer una conexión a través de la red. Incluso hace ping, no significa que el servicio, por ejemplo, el servicio RemoteRegistry se esté ejecutando.
Sin embargo, para solucionar cualquier problema, es necesario hacer ping. Puede solucionar de forma remota cualquier problema. Por lo tanto, ping tiene su propia importancia.
La mejor manera que uso en mis scripts es
#rsh servername.com "date"
Mon Sep 19 04:42:20 PDT 2011
en lugar de rsh se pueden usar alternativas como remsh. Esto garantiza que su sistema remoto se inicie por completo y que pueda ejecutar comandos en él. El ping simple no es suficiente ya que durante el arranque cuando se inician los servicios de red, el sistema comienza a responder al ping.
rsh? De Verdad? ¿Por qué no usar sshen su lugar?
rshvs sshaparte, ¿cómo puede ser capaz de ejecutar date(suponiendo que lo es, para empezar) decir algo sobre si un servidor web, un servidor SMTP, un servidor DNS, un servidor de base de datos local o qué otra cosa se está ejecutando y puede atender solicitudes? Es mejor pedir el servicio específico del que desea verificar la disponibilidad (que podría ser un shell remoto, pero seguro que no tiene que serlo).
Cuando reinicio un servidor de Windows abro un cuadro de símbolo del sistema e ingreso
ping <box> -t
Primero, sugerirá que está disponible: esa es la caja que se cae. Entonces obtendrá un montón de "tiempo de espera de solicitud". Cuando empiezas a recibir respuestas, la caja está arriba.