Je suis venu ici dans l’espoir de trouver un diagnostic étape par étape pour lorsqu’un site Discourse se retrouve dans un état 502 Bad Gateway. Il semble que les seules options soient les suivantes :
La mise à jour de Discourse a peut-être échoué, utilisez ./launcher rebuild app.
Mettre à jour et redémarrer le serveur.
Ce sont le genre de réponses que nous obtenons d’un technicien de support de niveau 1, ou d’un bot par e-mail.
Que pouvons-nous faire d’autre pour examiner les journaux et voir exactement pourquoi l’environnement est tombé en panne ? Avec ces informations, nous pourrions apprendre à prévenir le problème à l’avenir.
Par exemple, serait-il approprié de scripter un processus cron pour interroger Discourse occasionnellement, et si la réponse est un code de retour 502 ou similaire, reconstruire automatiquement ?
La reconstruction semble être une manière plutôt brutale de résoudre un problème. Ce n’est pas un diagnostic.
J’espère vraiment que quelqu’un pourra nous indiquer un document populaire sur le « Diagnostic des problèmes de Discourse » que des idiots comme moi ont manqué.
D’après la lecture de nombreux messages ici, typiquement les administrateurs de forum ne sont pas la cause des erreurs 502, et il s’agit d’une erreur de plugin/noyau. Donc, il n’y aurait pas grand-chose que vous puissiez faire pour éviter ces problèmes.
Les journaux de la console aident toujours, ils peuvent souvent identifier le plugin problématique.
Je peux ouvrir la console sur ce VPS mais la fenêtre de texte est limitée.
Existe-t-il des journaux spécifiques à vérifier dans le conteneur ou dans le système d’exploitation ?
Existe-t-il déjà une forme de processus de ping dans le système d’exploitation hôte ou dans le conteneur qui détecte lorsque les processus sont arrêtés ?
Un simple redémarrage du serveur dans le conteneur pourrait-il être une bonne approche plutôt qu’une reconstruction complète ?
Au fait, j’utilise la dernière version bêta/dev, il est donc tout à fait possible qu’une mise à jour récente ait arrêté le serveur, comme nous l’avons déjà vu. Je ne me souviens pas pour le moment s’il y a des plugins non par défaut installés.
J’ai la liberté d’aider au diagnostic de cela sans que notre communauté ne s’énerve, bien que dans quelques mois, nous devrons passer à des versions plus stables juste pour que nos utilisateurs soient à l’aise. Donc, si c’est quelque chose dans la construction, je suis heureux de vous aider à le trouver.
Le disque est utilisé à moins de 50 %.
La RAM a tendance à rester dans la plage 80-90 %, le Swap est inférieur à 40 %. Je suppose que c’est là que le problème est causé.
Les logs se trouvent dans /var/discourse/shared/standalone/log/rails.
production.log et les fichiers compressés associés contiennent beaucoup de détails sur les transactions. Que pourrais-je rechercher ?
Il n’y a aucune entrée dans production_error.log.
« Fréquemment » ? Non. Mais assez souvent pour être légèrement ennuyeux et justifier un message ici.
J’ai parcouru syslog et je n’ai rien vu - je ne suis pas sûr qu’il y ait quoi que ce soit là si le problème est limité au conteneur, comme il se doit.
Je suis un noob de Docker, donc je suis désolé de ne pas avoir d’informations du conteneur, mais je serai heureux de suivre vos instructions.
Je pense que la quasi-totalité des fils de discussion ici concernant les erreurs 502 surviennent lorsque Discourse a été mis à niveau et qu’il n’est pas revenu à la vie. La mise à niveau a échoué, ou l’administrateur n’a pas attendu assez longtemps que le service démarre.
Dites-vous que vous avez un Discourse fonctionnel, que vous n’effectuez aucune action d’administration, mais qu’il commence à renvoyer des 502 spontanément ?
Et quand cela se produit, renvoie-t-il toujours 502 jusqu’au redémarrage ou fonctionne-t-il de manière intermittente ?
