☰

Ocasionalmente ocurren diferentes errores de rizo

tag-icon • tag-icon centos curl
Ocasionalmente ocurren diferentes errores de rizo

Tengo un servidor web que ejecuta Centos7 y realiza solicitudes curl a otros recursos. Con una velocidad de 5 a 10 solicitudes por segundo, todo funciona bien, excepto que obtengo diferentes errores de rizo cada 2 a 10 minutos. Creo que empezó a suceder con el tiempo a medida que crecía el número de solicitudes, lo que me hace pensar que tiene algo que ver con la red, pero soy un novato total en esto. ¿Cómo saber qué causa estos errores y qué puedo hacer al respecto?

Network: CURL error 56: TCP connection reset by peer
Network: CURL error 7: Failed to connect to ip: Network is unreachable
Network: CURL error 18: transfer closed with 1473 bytes remaining to read

Respuesta1

Lo más probable es que la causa de estos errores pueda clasificarse generalmente como "SNAFU"... Situación normal, totalmente jodida.

Internet es una vasta red de computadoras y dispositivos de red interconectados. Esas otras máquinas, sobre las que no tienes control, no siempre hacen lo que deberían. Sufren cortes de energía. Tienen fallas de hardware. Son golpeados por la radiación cósmica. Estas cosas pasan.

Las tecnologías de redes que sustentan Internet están diseñadas teniendo esto en mente. La razón por la que Internet funciona es por un enorme nivel de redundancia. Si falla un intento de conectarse a un destino a través de una ruta... el último "salto" de esa cadena que funcionó recordará el error e intentará un "siguiente salto" diferente para comunicaciones futuras. En realidad, es mucho más complicado que esto... pero entiendes la esencia.

La mayoría de las aplicaciones web reintentarán las conexiones fallidas específicamente para aprovechar esta redundancia. Sin embargo, no todos. Cuanto más simple sea la aplicación, más probabilidades habrá de que simplemente falle. Esto se vuelve especialmente cierto en el caso de aplicaciones terminales que aplican principios *nix de herramientas pequeñas de un solo trabajo. Reintentar es el trabajo de otra herramienta. curles una de esas aplicaciones. segúnla curlpágina de manual:

--rever

Si se devuelve un error transitorio cuando curl intenta realizar una transferencia, lo volverá a intentar varias veces antes de darse por vencido.Establecer el número en 0 hace que curl no haga reintentos (cual es el predeterminado). Error transitorio significa: un tiempo de espera, un código de respuesta FTP 4xx o un código de respuesta HTTP 408 o 5xx.

No estoy seguro exactamente de cuál es su caso de uso para curlrecuperar recursos, pero si está usando curl para proporcionar recursos de forma automatizada, definitivamente necesita configurarlo con la --retrybandera con un valor de 3-5. Porque los errores como el que usted mostró son perfectamente normales... y deben tenerse en cuenta.

2. ¿Por qué la confiabilidad de su servidor de producción es peor que la de su computadora local?

En un mundo perfectoun servidor de producción siempre tendrá una conexión más confiable a los recursos basados ​​en Internet que cualquier conexión a Internet del hogar o la oficina. Como ese no es el caso aquí, tienes razón al interesarte por la causa. Sin embargo, esto no significa necesariamente que debas preocuparte porque, nuevamente, esto no es necesariamente un problema causado por tu servidor.

Comprenda que es casi seguro que su computadora local y su servidor no comparten la misma ruta hacia los recursos en cuestión. Por ejemplo. Si realizo un análisis traceroutedesde mi servidor doméstico local para decir... superuser.comobtengo esto:

user@home ~ $ sudo traceroute -I superuser.com
traceroute to superuser.com (151.101.1.69), 30 hops max, 60 byte packets
 1  rtr.scrapyard.local (10.5.0.1)
 2  96.120.58.37 (96.120.58.37)
 3  po94-sr22.dothan.al.pancity.comcast.net (68.85.202.165)
 4  162.151.221.209 (162.151.221.209)
 5  be-3666-cr02.56marietta.ga.ibone.comcast.net (68.86.90.209)
 6  * * *
 7  50.242.151.138 (50.242.151.138)
 8  151.101.1.69 (151.101.1.69)

Pero si hago el mismo comando desde uno de mis servidores de producción obtengo esto:

user@production ~ $ sudo traceroute -I superuser.com
traceroute to superuser.com (151.101.1.69), 30 hops max, 60 byte packets
 1  * * *
 2  ae-20-202.gw-distp-a.slr.lxa.us.oneandone.net (74.208.138.130)
 3  ae-10-0.bb-a.ga.mkc.us.oneandone.net (74.208.1.237)
 4  kanc-b1-link.telia.net (80.239.196.109)
 5  dls-b22-link.telia.net (62.115.125.159)
 6  fastly-ic-340339-dls-b22.c.telia.net (62.115.166.191)
 7  151.101.1.69 (151.101.1.69)

El único salto que esas dos rutas tienen en común es el destino. Todas las demás máquinas por las que pasan son diferentes. Entonces, si, digamos, dls-b22-link.telia.netse comportara mal, afectaría los intentos de mi servidor de comunicarse con superuser.com... pero no los intentos de mi computadora personal de hacer lo mismo.

Desafortunadamente, si hayeraSi tuviera un problema, dls-b22-link.telia.netno habría mucho que pudiera hacer al respecto. Y dada la naturaleza intermitente del problema, no sería particularmente fácil determinar cuál dls-b22-link.telia.netfue la fuente del problema para empezar.

Entonces...

2b. ¿Es realmente un problema?

Lo primero que debe hacer es confirmar que esto está causando un problema real que simplemente volver a intentar las conexiones fallidas no se solucionará. Lo que significa que su servidor de producción no puede realizar su trabajo de alguna manera. Supongo que tenías un objetivo en mente cuando configuraste esto.¿Ese objetivo todavía se está logrando de tal manera que no es necesario tomar medidas?Ésa es la pregunta clave.

Volviendo a lo que dije antes, problemas intermitentes como este simplemente son parte de Internet. En un mundo perfecto, esto no sucedería, pero no vivimos en un mundo perfecto... razón por la cual la redundancia es un principio fundamental en todas las tecnologías sobre las que se basa Internet. Es por eso que volver a intentarlo después de este tipo de fallas de conexión es un procedimiento operativo estándar. Y por qué no debería preocuparse demasiado por este tipo de fallos a menos que afecten activamente a su servidor.

2c. ¿Está bajo su control?

Es necesario delimitar la posible fuente del problema. Para hacer eso, simplemente haga las mismas pruebas que ya hizo (contando el número de fallas en un período de tiempo determinado), pero esta vez haga que el servidor solicite recursos desde un lugar radicalmente diferente. Sugeriría configurar un servidor web simple en la computadora de su hogar con un par de archivos similares a los que ha estado trabajando y usar curlen su servidor.

Si el servidor no experimenta fallas al hacer esto, entonces es muy poco probable que el problema esté en su servidor o en el proveedor de alojamiento de su servidor. Y sus pruebas existentes ya han eliminado su red local y su ISP, así como el lugar donde se alojan los recursos, como posibles fuentes del problema. Eso deja los nodos entre su proveedor de alojamiento y el proveedor de alojamiento de los recursos y cae directamente en "cosas sobre las que no tiene control".

Si el servidorhaceSi experimenta problemas durante la prueba anterior, debido a que ya ha eliminado el problema de su red/ISP local, puede estar casi seguro de que el problema está en su servidor o en el proveedor de alojamiento del servidor. Esto significa que está bajo tu control arreglarlo. También significa que tienes más problemas que solucionar.

2do. ¿Qué sigue?

Si el problema no está en su servidor, en el proveedor de alojamiento de su servidor o en los recursos que está consultando... entonces la causa en sí no está bajo su control. Lo mejor que puede hacer, en ese caso, es reubicar el servidor (comuníquese con su proveedor de hosting y vea qué opciones puede ofrecerle). Elesperanzaes que al hacerlo ya no necesitarás usar la ruta que tiene el nodo defectuoso. Sin embargo, es toda una prueba y no se garantiza que funcione. Incluso podría generar nuevos problemas. Por lo tanto, esto definitivamente debe ser un problema serio antes de dar ese paso.

Por otro lado, si ha reducido el problema a su servidor o al proveedor de alojamiento de su servidor, entonces probablemente pueda solucionarlo. Si tiene un acuerdo de alojamiento administrado, llame a su proveedor de alojamiento y pídale que lo solucione. Si no tiene un acuerdo de hosting administrado, entonces necesita eliminar la configuración de su servidor como posible culpable. Y ahí, desgraciadamente, es donde me bajo del tren. Estamos alcanzando los límites de mi experiencia.

Generalmente, para que sea un problema intermitente causado por su servidor, es probable que tenga algo que ver con el almacenamiento en búfer de la red o sea el resultado de algún tipo de automatización. Algunas conjeturas informadas:

  • ¿Ha tomado alguna medida para proteger su servidor contra sondeos y ataques maliciosos?
  • ¿Te has metido con tus /etc/sysctl.confarchivos o con los de /etc/sysctl.d/?
  • ¿Ha configurado algún tipo de software de inspección de paquetes o detección de intrusos (firewalls basados ​​en iptables/netfilter, snort, etc.)?

De todos modos, si se encuentra en el punto en el que está solucionando problemas del servidor, mi consejo sería tomar la información que ha recopilado y hacer una nueva pregunta sobreFallo del servidor. La gente de allí tiene mucha más experiencia con problemas de servidores que la gente de SuperUser y es más probable que sepan qué probar a continuación.

3. Respecto a la aparente coherencia de los errores

Ahora bien, ¿por qué recibe el mismo error específico una y otra vez? Es difícil de decir. Suponiendo que realmente esté sucediendo como un reloj cada 5 minutos... todavía podría ser cualquier cosa. Estos dispositivos tienen relojes y temporizadores para una amplia variedad de propósitos. Podría ser que algo que uno de ellos está configurado para hacer cada cinco minutos esté causando este pequeño problema.

Es posible que sea un problema con su servidor. O es un problema con tu proveedor de hosting. O es un problema con el ISP de su proveedor de alojamiento. O es un problema con el ISP de su casa/oficina. O en cualquier punto intermedio. Si no es su servidor, y probablemente no se base en lo que me ha dicho, entonces la conclusión es que no puede hacer mucho al respecto... excepto asegurarse de que está configurado para volver a intentar conexiones fallidas. Todos los navegadores web modernos, por ejemplo, lo vuelven a intentar varias veces antes de desistir de recuperar un recurso de un servidor web.

EDICIONES

  1. Se agregaron la segunda y tercera sección en respuesta a un comentario que solicitaba más aclaraciones.
  2. Se reescribió la segunda sección para tener en cuenta las correcciones.

información relacionada