Depuis hier soir, le site répond très mal

Désolé par avance si c’est la mauvaise catégorie, le mauvais emplacement, etc.

Je fais tourner un site Discourse depuis environ 6 mois via un VPS DigitalOcean, sans trop de problèmes. La page d’administration indique que je suis sur la version 2.5.0.beta4. Depuis hier soir, la plupart du contenu des pages refuse de se charger ou met un temps déraisonnable. Par exemple, je peux naviguer vers des pages comme la page d’accueil ou /admin, mais aucun de leur contenu réel (publications, graphiques de l’administration ou autres onglets) ne semble se charger. J’ai vérifié les indicateurs système : l’utilisation du CPU tourne autour de 2 % en idle, et il y a un trafic ou une utilisation du disque minimale. L’ensemble d’utilisateurs compte peut-être une dizaine de personnes, car je suis simplement en train de tester/configurer le site. Compte tenu de cela, ce comportement semble très étrange.

Les seuls plugins que j’ai, selon app.yml, sont docker_manager et discourse-signatures. Je suis le seul administrateur, donc je peux confirmer qu’aucun changement n’a été apporté aux paramètres du site depuis un moment.

Ma première idée a été de redémarrer la machine elle-même. J’ai aussi essayé de mettre à jour manuellement avec git pull et ./launcher rebuild app. Je ne sais pas trop quoi surveiller pendant ce processus pour détecter d’éventuelles erreurs, mais la reconstruction semble se terminer et le site devient accessible à nouveau, bien qu’il reste sur la version 2.5.0.beta4. De même, essayer d’accéder à la page /admin/update finit par un simple délai d’attente.

Tout cela semble assez bizarre car le site est en quelque sorte « fonctionnel » — je ne connais tout simplement pas assez son fonctionnement pour vraiment diagnostiquer quoi que ce soit. J’ai trouvé et pu exécuter discourse-doctor, mais je ne suis pas sûr de ce qu’il accomplit — il m’envoie un e-mail avec succès, etc.

La seule chose qui pourrait indiquer un problème est que, hier soir, j’ai reçu un e-mail du forum concernant une réponse à un message. Quand je navigue vers la catégorie « derniers messages » (après qu’elle ait fini de charger), il ne semble y avoir aucune indication que le message existe, car l’aperçu du fil dans « derniers messages » ne l’indique pas comme ayant été publié en dernier par cet utilisateur. Je ne parviens pas à charger le contenu d’aucun message, donc je ne peux pas vérifier avec certitude. Il pourrait donc y avoir une erreur ou un décalage dans la base de données ? Je ne sais pas comment un tel problème pourrait se propager et provoquer l’échec du chargement de grandes parties du site, ou si cela vaut la peine de s’engager dans cette voie.

Quelles que soient vos idées sur par où commencer pour dépanner un problème comme celui-ci ? Merci beaucoup d’avoir pris le temps de lire : )

Salut tuckie ! Bienvenue !

Il semble que tu fasses tout ce qu’il faut.

Je te recommande vivement de mettre à jour si tu le peux — tu es assez loin de la dernière version. Mais assure-toi de télécharger une sauvegarde au préalable pour ne rien perdre.

Peux-tu te connecter via SSH et vérifier si tu manques d’espace de stockage ?

df -h

Quoi qu’il en soit, l’espace de stockage est un bon premier point à vérifier, et cette commande est utile pour supprimer les conteneurs obsolètes qui occupent de l’espace :

./launcher cleanup app

Ensuite, je te conseillerais de reconstruire l’application vers la dernière version. Fais-nous savoir si cela fonctionne cette fois et n’affiche aucune erreur dans la console.

./launcher rebuild app

Merci pour cette réactivité rapide.

Il reste environ 7,9 Go d’espace libre sur le disque monté sur /dev/vda1, qui est monté sur /. Je ne connais pas vraiment comment les autres partitions sont utilisées sous Ubuntu ni comment elles pourraient affecter le fonctionnement (Discourse est dans un conteneur, n’est-ce pas ?). Le reste semble correspondre à la partition de démarrage, etc. Il n’y a que 30 à 40 publications au total sur le forum, car je le teste, donc il ne semble pas être en danger de ce côté-là. Le nettoyage a permis de libérer environ 4 Go supplémentaires.

En ce qui concerne la reconstruction de l’application, je l’ai déjà exécutée plusieurs fois. Je ne vois aucun message d’avertissement flagrant pendant le processus, mais en même temps, une fois terminé, rien n’indique « succès » non plus — je ne saurais pas quelles lignes d’erreur ou d’avertissement rechercher. Cela supprime l’ancien conteneur, lance ensuite le conteneur Docker, puis c’est terminé. Je viens de le relancer une dernière fois, et lorsque je me connecte au site, il indique toujours que des mises à jour sont disponibles, mais cela prend un temps incroyablement long pour afficher la version actuelle (2.5.0.beta4) et la version vers laquelle mettre à jour.

Une partie du problème est que je ne parviens pas vraiment à utiliser les outils d’administration non plus, en raison de temps de réponse excessifs ou d’échecs de chargement. Par exemple, naviguer vers l’onglet des sauvegardes affiche indéfiniment l’animation de chargement. Par curiosité, j’ai ouvert la console sur l’onglet des sauvegardes, et le navigateur semble tenter de récupérer des fichiers JavaScript, mais échoue sur tous d’eux, lentement, un par un.

S’il existe un moyen de travailler avec les sauvegardes via SSH, cela semblerait très utile ici.

Cela ressemble à un problème réseau. Utilisez-vous Cloudflare ? (Dans ce cas, désactivez le nuage orange).

Vous pourriez avoir un « voisin bruyant » chez DigitalOcean, il serait donc judicieux d’ouvrir un ticket auprès de leur support.

Il n’a aucun sens que vous affirmiez avoir effectué une reconstruction sans que la version ait changé. Je pense que vous auriez dû procéder à la mise à niveau vers PostgreSQL 12. N’avez-vous rien remarqué à ce sujet lors de la reconstruction ?

Je suis sur DigitalOcean. Je suppose qu’un phénomène similaire pourrait se produire, bien que je ne sache pas si cela provoquerait ce problème de manière aussi constante ou aussi longtemps. Je pense qu’une meilleure façon de décrire le problème avec le site est que, généralement, la page parvient à charger le modèle ou la « coquille » de la page, mais au-delà de cela, la récupération de tout contenu réel semble rester bloquée indéfiniment.

En ce qui concerne la reconstruction ou le changement de version, il est possible qu’une erreur de ce type se produise, mais je ne connais pas de bonne méthode pour l’analyser, ni ce que je devrais rechercher. J’ai bien vu une ligne du type « postgres installé » défiler dans la sortie lorsque j’ai relancé la reconstruction tout à l’heure. Je ne sais pas si cela est dû aux opérations se déroulant à l’intérieur d’un conteneur, mais par exemple, ./launcher rebuild app | grep 'postgres' ne semble filtrer aucun résultat, tout comme ./launcher rebuild app > output.txt && grep 'postgres' output.txt. Le fichier output.txt contient bien des informations, mais apparemment pas tout ? Il ne se termine du moins pas de la même manière que la sortie réelle de la console.

Bonjour, j’espère que je ne viole aucune règle concernant les relances, etc., mais j’aimerais quand même obtenir de l’aide à ce sujet. Au cours de la semaine dernière, la situation semble s’être aggravée ? Je ne peux pas dire avec certitude quand cela s’est produit, car je n’ai pas travaillé là-dessus pendant les vacances la semaine dernière, mais je ne parviens plus du tout à me connecter à mon site. Je peux toujours faire un ping vers l’adresse IP avec succès, et cette même IP redirige vers le bon domaine, donc il ne semble pas s’agir d’un problème de serveur de noms.

L’accès au site via Firefox produit maintenant :

Le site https://aregames.art/ a rencontré une violation de protocole réseau qui ne peut pas être réparée.

La page que vous essayez d'afficher ne peut pas être affichée car une erreur de transmission de données a été détectée.

Je ne parviens pas à trouver beaucoup d’informations utiles dans l’inspecteur du navigateur, car il ne semble pas y avoir de réponse à la requête GET.

Depuis la découverte de ce nouveau problème, j’ai :

  • exécuté la reconstruction plusieurs fois,
  • mis à jour Ubuntu vers la version 20.04,
  • reconstruit à nouveau.

Le site lui-même n’a été utilisé que pour tester la plateforme pendant environ un mois, et je suis prêt à admettre qu’il n’était probablement pas judicieux de ne pas avoir maintenu le logiciel à jour. Je suis également prêt à réinstaller Discourse à partir de zéro. Bien sûr, ce serait idéal de trouver un moyen de résoudre ce problème en conservant la configuration du site, les utilisateurs et les publications, mais la seule chose dont j’ai vraiment besoin est une copie du CSS personnalisé que j’ai écrit dans l’éditeur de thème. S’il existe un emplacement où il est stocké et que je peux le copier vers une nouvelle installation, cela serait très utile. J’ai (de manière irresponsable) aucune version à jour stockée localement.

Et concernant le processus de reconstruction, je ne sais toujours pas exactement comment l’analyser pour détecter d’éventuels problèmes. À ma connaissance, il s’exécute et se termine sans demander aucune saisie, et les dernières lignes après son achèvement concernent le démarrage du conteneur Docker avec les configurations issues du fichier YAML. Je comprends qu’il y a une différence entre la fin de la reconstruction et sa réussite, mais je ne suis pas sûr de ce que je devrais rechercher ou où diagnostiquer un éventuel problème durant ce processus.

Le serveur est-il en ligne ? Pouvez-vous vous y connecter via SSH ?

Si oui, redémarrez le serveur, puis reconstruisez Discourse.

S’il n’est toujours pas en ligne après tout cela, copiez-collez ici la sortie de la reconstruction et nous pourrons vous aider.

Oui, je peux me connecter en SSH correctement et c’est ainsi que j’ai lancé le rebuild à chaque fois. Et non, toujours inaccessible après un rebuild. Je constate (même après un rebuild) que ifconfig affiche le conteneur Docker avec une adresse IP différente de celle du serveur, que je ne peux pas atteindre depuis le navigateur web de mes systèmes. Je ne sais pas si c’est prévu ou non. ./launcher rebuild app > output.txt ne semble afficher qu’une partie de la sortie console réelle, mais je peux également la fournir.

Ubuntu Pastebin (fichier de sortie court)
Ubuntu Pastebin (sortie complète collée depuis le terminal)
Je remarque quelques messages d’erreur de la part de postgres indiquant que la base de données ‘discourse’ existe déjà ; vaut-il la peine d’investiguer cela ?

Votre DNS est-il correct ?

host aregames.art 
aregames.art a pour adresse 198.54.117.200
aregames.art a pour adresse 198.54.117.199
aregames.art a pour adresse 198.54.117.198
aregames.art a pour adresse 198.54.117.197

Pourquoi tant d’adresses IP ? Quelle est l’adresse IP de votre serveur ?

Wow, c’était vraiment éclairant : j’avais laissé mon nom de domaine expirer, et coïncidemment, cela s’est produit le jour où j’ai commencé à rencontrer ces problèmes… Je comptais changer de fournisseur, alors j’avais désactivé les paiements automatiques de mon côté, et la date est passée, je suppose. Il semble donc que ces adresses IP soient liées à un service de stationnement pour le domaine. Je viens de le renouveler, donc peut-être que les bons enregistrements seront réappliqués — je ne sais pas combien de temps cela prend habituellement, l’hébergeur indique toujours ces IP. Selon la documentation, je ne devrais pas pouvoir me connecter directement via l’IP, donc je ne pourrai pas vérifier si cela a fonctionné avant un certain temps, je suppose. Merci de l’avoir signalé.

Cela dit, je suis toujours un peu confus quant aux problèmes que je rencontrais initialement : est-ce que j’accédais à une version mise en cache de la page, et à cause des problèmes de serveurs de noms, les requêtes de contenu n’arrivaient pas à passer ? Certaines choses, comme même les messages dans un fil de discussion, ou la liste des messages lorsque vous ouvrez les « derniers messages », finissaient par se charger, mais après un long délai.

Mise à jour : host aregames.art, comme vous l’avez mentionné ci-dessus, semble à nouveau résoudre vers la bonne IP et le bon serveur de messagerie. J’ai pu confirmer avec le script discourse-setup qu’il accepte le DNS pointant vers l’IP. Il semble que le script de configuration ait également lancé la reconstruction. Cependant, la navigation vers l’URL produit une erreur « serveur introuvable ». L’accès direct à l’IP sur le port 443 produit une erreur nginx 400 Bad Request, ce qui ressemble un peu à une avancée.

Nouvelle modification : j’ai dû vider le cache de mon navigateur — le site s’est chargé parfaitement dans un onglet de navigation privée. Les choses semblent à nouveau fonctionnelles ! Je suppose… payer pour mon site web a été la solution pour le réparer ici.

Oui, vous utilisiez la vue mise en cache.

Nous avons ajouté une nouvelle fonctionnalité dans Discourse 2.6 pour ajouter une classe CSS spécifique au document lorsque vous êtes sur cette vue, mais nous n’avons pas encore d’élément d’interface utilisateur par défaut pour cela.

Vous pouvez en savoir plus à ce sujet sur Offline Indicator