Il est plus que probable que les causes de ces erreurs puissent être classées dans la catégorie "SNAFU"... Situation normale, tout est foutu.
L'internet est un vaste réseau d'ordinateurs et d'appareils de mise en réseau interconnectés. Ces autres machines, sur lesquelles vous n'avez aucun contrôle, ne font pas toujours ce qu'elles devraient faire. Elles subissent des pannes de courant. Elles ont des défaillances matérielles. Elles sont touchées par des radiations cosmiques. Des choses arrivent.
Les technologies de mise en réseau qui sous-tendent l'internet sont conçues dans cette optique. Si l'internet fonctionne, c'est grâce à un énorme niveau de redondance. Si une tentative de connexion à une destination via une route échoue... le dernier "saut" de la chaîne qui a fonctionné se souviendra de l'échec et essaiera un autre "saut suivant" pour les communications futures. C'est en fait beaucoup plus compliqué que ça... mais vous avez compris l'essentiel.
La plupart des applications web relancent les connexions qui ont échoué afin de tirer parti de cette redondance. Mais pas toutes. Plus l'application est simple, plus elle risque d'échouer tout simplement. Cela est particulièrement vrai pour les applications terminales qui appliquent les principes *nix de petits outils à tâche unique. La relance est le travail d'un autre outil. curl est une de ces applications. D'après le site curl page d'accueil :
--retry
Si une erreur transitoire est renvoyée lorsque curl tente d'effectuer un transfert, il réessayera ce nombre de fois avant d'abandonner. Réglage de le nombre à 0 fait que curl ne fait pas de tentatives ( qui est la valeur par défaut ). Une erreur transitoire signifie soit : un dépassement de délai, un code de réponse FTP 4xx ou un code de réponse HTTP 408 ou 5xx.
Je ne suis pas sûr de savoir exactement quel est votre cas d'utilisation pour utiliser curl pour récupérer des ressources, mais si vous utilisez curl pour fournir des ressources de manière automatisée, vous devez absolument le configurer avec la directive --retry avec une valeur de 3-5. Parce que des erreurs comme celles que vous avez montrées sont parfaitement normales... et doivent être prises en compte.
2. Pourquoi la fiabilité de votre serveur de production est-elle moins bonne que celle de votre ordinateur local ?
Dans un monde parfait un serveur de production aura toujours une connexion plus fiable aux ressources Internet que n'importe quelle connexion Internet à domicile ou au bureau. Comme ce n'est pas le cas ici, vous avez raison de vous intéresser à la cause. Cependant, cela ne signifie pas nécessairement que vous devez vous inquiéter car, encore une fois, ce n'est pas nécessairement un problème causé par votre serveur.
Comprenez que votre ordinateur local et votre serveur ne partagent presque certainement pas la même route vers les ressources en question. Par exemple. Si j'effectue un traceroute de mon serveur domestique local pour dire... superuser.com Je comprends :
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)
Mais si je fais la même commande depuis un de mes serveurs de production, j'obtiens ceci :
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)
Le seul saut que ces deux routes ont en commun est la destination. Toutes les autres machines par lesquelles ils passent sont différentes. Donc si, disons, dls-b22-link.telia.net se comportait mal, cela affecterait les tentatives de mon serveur de communiquer avec superuser.com... mais pas les tentatives de mon ordinateur personnel de faire de même.
Malheureusement, s'il y a était un problème avec dls-b22-link.telia.net il n'y aurait pas grand chose que je puisse faire à ce sujet. Et étant donné la nature intermittente du problème, il ne serait pas particulièrement facile de déterminer que dls-b22-link.telia.net était la source du problème au départ.
Alors...
2b. Est-ce vraiment un problème ?
La première chose à faire est de confirmer que cela cause un problème réel que le simple fait de réessayer les connexions échouées ne pourra pas résoudre. Cela signifie que votre serveur de production est gêné dans son travail d'une manière ou d'une autre. Je suppose que vous aviez un objectif en tête lorsque vous avez mis en place ce système. Cet objectif est-il toujours atteint de telle sorte que vous n'avez pas besoin d'agir ? C'est la question clé.
Pour en revenir à ce que j'ai dit avant, les problèmes intermittents comme celui-ci font simplement partie d'Internet. Dans un monde parfait, ils n'arriveraient pas, mais nous ne vivons pas dans un monde parfait... c'est pourquoi la redondance est un principe fondamental dans toutes les technologies sur lesquelles Internet est construit. C'est pourquoi réessayer après ce type d'échec de connexion est une procédure opérationnelle standard. Et c'est pourquoi vous ne devriez pas trop vous inquiéter de ces pannes, à moins qu'elles ne nuisent activement à votre serveur.
2c. Est-ce sous votre contrôle ?
Vous devez réduire la source potentielle du problème. Pour cela, il suffit de faire les mêmes tests que ceux que vous avez déjà effectués (compter le nombre d'échecs dans un laps de temps donné) mais cette fois-ci, demandez au serveur de demander des ressources d'un endroit radicalement différent. Je vous suggère de configurer un simple serveur Web sur votre ordinateur personnel avec quelques fichiers similaires à ceux que vous avez utilisés et d'utiliser les éléments suivants curl sur votre serveur, prenez-les.
Si le serveur ne connaît aucune défaillance, il est très peu probable que le problème vienne de votre serveur ou de votre fournisseur d'hébergement. Et vos tests existants ont déjà éliminé votre réseau local et votre fournisseur d'accès Internet ainsi que l'endroit où les ressources elles-mêmes sont hébergées comme sources potentielles du problème. Il ne reste donc que les nœuds situés entre votre fournisseur d'hébergement et le fournisseur d'hébergement des ressources, ce qui relève carrément de la catégorie des "choses sur lesquelles vous n'avez aucun contrôle".
Si le serveur fait Si vous rencontrez des problèmes pendant le test ci-dessus, vous pouvez être quasiment certain que le problème vient de votre serveur ou de l'hébergeur, puisque vous avez déjà éliminé le problème de votre réseau local/isp. Cela signifie qu'il est sous votre contrôle pour le résoudre. Cela signifie également que vous avez plus de dépannage à faire.
2d. Quelle est la suite ?
Si le problème ne vient pas de votre serveur, de l'hébergeur de votre serveur ou des ressources que vous interrogez... alors la cause elle-même n'est pas sous votre contrôle. Dans ce cas, votre meilleure chance est de relocaliser le serveur (contactez votre hébergeur et voyez quelles options il peut vous proposer). Le site espoir est qu'en faisant cela, vous n'aurez plus besoin d'utiliser la route sur laquelle se trouve le nœud défectueux. Mais c'est une véritable épreuve et il n'est pas garanti que cela fonctionne. Cela pourrait même conduire à de nouveaux problèmes. C'est pourquoi il faut absolument que ce problème soit sérieux avant de prendre une telle mesure.
En revanche, si vous avez déterminé que le problème est dû à votre serveur ou à son hébergeur, vous pouvez probablement le résoudre. Si vous avez un contrat d'hébergement géré, appelez votre fournisseur d'hébergement et demandez-lui de résoudre le problème. Si vous n'avez pas de contrat d'hébergement géré, vous devez éliminer la configuration de votre serveur comme coupable potentiel. Et c'est là, malheureusement, que je m'égare. Nous atteignons les limites de mon expertise.
En général, s'il s'agit d'un problème intermittent causé par votre serveur, il a probablement quelque chose à voir avec la mise en mémoire tampon du réseau ou est le résultat d'une sorte d'automatisation. Quelques suppositions éclairées :
- Avez-vous pris des mesures pour renforcer votre serveur contre les sondages et les attaques malveillantes ?
- As-tu modifié ton
/etc/sysctl.conf ou les fichiers dans /etc/sysctl.d/ ?
- Avez-vous installé un logiciel d'inspection des paquets ou de détection des intrusions (pare-feu basé sur iptables/netfilter, snort, etc.) ?
Quoi qu'il en soit, si vous en êtes au point de dépanner le serveur lui-même, je vous conseille de prendre les informations que vous avez collectées et de poser une nouvelle question sur ServerFault . Les gens là-bas ont beaucoup plus d'expérience avec les problèmes de serveur que les gens ici sur SuperUser et sont plus susceptibles de savoir ce qu'il faut essayer ensuite.
3. Concernant l'apparente cohérence des erreurs
Maintenant, pour savoir pourquoi vous obtenez la même erreur spécifique encore et encore et encore ? C'est difficile à dire. En supposant que ça se passe vraiment comme une horloge toutes les 5 minutes... ça peut toujours être n'importe quoi. Ces appareils sont équipés d'horloges et de minuteries pour une grande variété de raisons. Il se pourrait que quelque chose que l'un d'entre eux est configuré pour faire toutes les cinq minutes cause ce petit problème.
Il est possible qu'il s'agisse d'un problème avec votre serveur. Ou qu'il s'agisse d'un problème avec votre fournisseur d'hébergement. Ou un problème avec le fournisseur d'accès à Internet de votre hébergeur. Ou un problème avec le FAI de votre domicile/bureau. Ou n'importe où entre les deux. Si ce n'est pas votre serveur, et ce n'est probablement pas le cas d'après ce que vous m'avez dit, vous ne pouvez pas y faire grand-chose... sauf vous assurer que vous êtes configuré pour réessayer les connexions qui échouent. Tous les navigateurs web modernes, par exemple, tentent plusieurs fois avant d'abandonner la récupération d'une ressource sur un serveur web.
EDITS
- Ajout de la deuxième et de la troisième section en réponse à un commentaire demandant une clarification supplémentaire
- Réécriture de la deuxième section pour tenir compte des corrections.
