Eu tenho um servidor web executando o Centos7 que faz solicitações de curl para outros recursos. Com a taxa de 5 a 10 solicitações por segundo, tudo funciona bem, exceto que recebo diferentes erros de curl a cada 2 a 10 minutos. Acho que começou a acontecer com o tempo, à medida que o número de solicitações aumentava, o que me faz pensar que tem algo a ver com a rede, mas sou totalmente novato nisso. Como descobrir o que causa esses erros e o que posso fazer sobre isso?
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
Mais do que provável, o que causa esses erros pode ser geralmente classificado como "SNAFU"... Situação Normal, Tudo Effed Up.
A internet é uma vasta rede de computadores interconectados e dispositivos de rede. Essas outras máquinas, sobre as quais você não tem controle, nem sempre fazem o que deveriam. Eles sofrem falhas de energia. Eles têm falhas de hardware. Eles são atingidos pela radiação cósmica. Coisas acontecem.
As tecnologias de rede que sustentam a Internet são projetadas com isso em mente. A razão pela qual a internet funciona é um enorme nível de redundância. Se uma tentativa de se conectar a um destino por meio de uma rota falhar ... o último "salto" nessa cadeia que funcionou se lembrará da falha e tentará um "próximo salto" diferente para comunicação futura. Na verdade, é muito mais complicado do que isso... mas você entendeu.
A maioria dos aplicativos da Web tentará novamente as conexões com falha especificamente para aproveitar essa redundância. Nem todos eles, no entanto. Quanto mais simples for o aplicativo, maior a probabilidade de ele simplesmente falhar. Isso se torna especialmente verdadeiro para aplicações de terminal que aplicam os princípios *nix de ferramentas pequenas e de trabalho único. Tentar novamente é trabalho de outra ferramenta.
curlé um desses aplicativos. Conforme a página decurlmanual :Não sei exatamente qual é o seu caso de uso
curlpara recuperar recursos, mas se você estiver usando curl para fornecer recursos de maneira automatizada, definitivamente precisará configurá-lo com o--retrysinalizador com um valor de 3-5. Porque erros como você mostrou são perfeitamente normais... e precisam ser contabilizados.2. Por que a confiabilidade é pior para seu servidor de produção do que para seu computador local?
Em um mundo perfeito, um servidor de produção sempre terá uma conexão mais confiável com recursos baseados na Internet do que qualquer conexão doméstica ou de escritório. Como esse não é o caso aqui, você está certo em se interessar pela causa. No entanto, isso não significa necessariamente que você deva se preocupar porque, novamente, isso não é necessariamente um problema causado pelo seu servidor.
Entenda que seu computador local e seu servidor quase certamente não compartilham a mesma rota para os recursos em questão. Por exemplo. Se eu executar um
traceroutedo meu servidor doméstico local para dizer ...superuser.comrecebo isto:Mas se eu fizer o mesmo comando de um dos meus servidores de produção, recebo isto:
O único salto que essas duas rotas têm em comum é o destino. Todas as outras máquinas pelas quais eles passam são diferentes. Portanto, se, digamos,
dls-b22-link.telia.netestivesse se comportando mal, isso afetaria as tentativas do meu servidor de se comunicar com superuser.com ... mas não as tentativas do meu computador doméstico de fazer o mesmo.Infelizmente, se houvesse um problema
dls-b22-link.telia.net, não haveria muito que eu pudesse fazer. E, dada a natureza intermitente do problema, não seria particularmente fácil determinar qualdls-b22-link.telia.netera a origem do problema para começar.Então...
2b. É realmente um problema?
A primeira coisa que você deve fazer é confirmar se isso está causando um problema real que simplesmente tentar novamente as conexões com falha não resolverá. O que significa que seu servidor de produção está sendo prejudicado em fazer seu trabalho de alguma forma. Presumo que você tenha um objetivo em mente quando configurou isso. Esse objetivo ainda está sendo alcançado de tal forma que você não precisa agir? Essa é a questão chave.
Voltando ao que eu disse antes, problemas intermitentes como esse simplesmente fazem parte da Internet. Em um mundo perfeito, eles não aconteceriam, mas não vivemos em um mundo perfeito... e é por isso que a redundância é um princípio fundamental em todas as tecnologias nas quais a Internet é construída. É por isso que tentar novamente após esses tipos de falhas de conexão é o procedimento operacional padrão. E por que você não deve se preocupar muito com essas falhas, a menos que elas prejudiquem ativamente seu servidor.
2c. Está sob seu controle?
Você precisa restringir a fonte potencial do problema. Para fazer isso, basta fazer os mesmos testes que você já fez (contando o número de falhas em um determinado período de tempo), mas desta vez fazer com que o servidor solicite recursos de algum lugar radicalmente diferente. Eu sugeriria configurar um servidor web simples em seu computador doméstico com alguns arquivos semelhantes aos que você está trabalhando e usar
curlem seu servidor para pegá-los.Se o servidor não apresentar falhas ao fazer isso, é muito improvável que o problema esteja no servidor ou no provedor de hospedagem do servidor. E seus testes existentes já eliminaram sua rede local e provedor, bem como onde quer que os próprios recursos estejam hospedados como fontes potenciais do problema. Isso deixa os nós entre seu provedor de hospedagem e o provedor de hospedagem dos recursos e se enquadra diretamente em "coisas sobre as quais você não tem controle".
Se o servidor tiver problemas durante o teste acima, porque você já eliminou sua rede local/provedor como o problema, você pode ter quase certeza de que o problema está no seu servidor ou no provedor de hospedagem do servidor. Isso significa que está sob seu controle consertar. Isso também significa que você tem mais solução de problemas para fazer.
2d. Qual o proximo?
Se o problema não estiver no seu servidor, no provedor de hospedagem do seu servidor ou nos recursos que você está consultando... então a causa em si não está sob seu controle. Sua melhor aposta, nesse caso, é realocar o servidor (entre em contato com seu provedor de hospedagem e veja quais opções eles podem oferecer a você). A esperança é que, ao fazer isso, você não precise mais usar a rota que contém o nó defeituoso. É uma provação e tanto, e não é garantido que funcione. Pode até levar a novos problemas. Portanto, isso definitivamente precisa ser um problema sério antes de você dar esse passo.
Por outro lado, se você restringiu o problema ao seu servidor ou ao provedor de hospedagem do seu servidor, provavelmente poderá consertá-lo. Se você tiver um contrato de hospedagem gerenciada, ligue para o seu provedor de hospedagem e peça que ele o corrija. Se você não tiver um contrato de hospedagem gerenciada, precisará eliminar a configuração do seu servidor como um possível culpado. E aí, infelizmente, é onde eu desço do trem. Estamos atingindo os limites da minha especialidade.
Geralmente, para que seja um problema intermitente causado pelo seu servidor, provavelmente tem algo a ver com o buffer de rede ou é resultado de algum tipo de automação. Algumas suposições informadas:
/etc/sysctl.confou os arquivos em/etc/sysctl.d/?Independentemente disso, se você estiver no ponto em que está solucionando problemas do próprio servidor, meu conselho seria pegar as informações que você coletou e fazer uma nova pergunta em ServerFault . As pessoas lá têm muito mais experiência com problemas de servidor do que as pessoas aqui no SuperUser e são mais propensas a saber o que tentar a seguir.
3. Sobre a consistência aparente dos erros
Agora, por que você está recebendo o mesmo erro específico repetidamente? É difícil dizer. Supondo que realmente esteja acontecendo como um relógio a cada 5 minutos ... ainda pode ser qualquer coisa. Esses dispositivos possuem relógios e temporizadores para uma ampla variedade de propósitos. Pode ser que algo que um deles está configurado para fazer a cada cinco minutos esteja causando esse pequeno soluço.
É possível que seja um problema com o seu servidor. Ou é um problema com seu provedor de hospedagem. Ou é um problema com o ISP do seu provedor de hospedagem. Ou é um problema com o ISP de sua casa/escritório. Ou em qualquer lugar no meio. Se não é o seu servidor e provavelmente não é baseado no que você me disse, o resultado final é que você não pode fazer muito sobre isso ... exceto certificar-se de que está configurado para tentar novamente as conexões com falha. Todos os navegadores da Web modernos, por exemplo, tentam várias vezes antes de desistir de recuperar um recurso de um servidor da Web.
EDITAR% S