Vine aquí esperando encontrar un diagnóstico paso a paso para cuando un sitio de Discourse se encuentra en una condición de 502 Bad Gateway. Parece que las únicas opciones son del tipo:\n\n1) La actualización de Discourse podría haber fallado, usa ./launcher rebuild app.\n2) Actualiza y reinicia el servidor.\n\nEstas son el tipo de respuestas que obtenemos de un técnico de soporte de nivel 1, o de un bot de correo electrónico.\n\n¿Qué más podemos hacer para revisar los registros y ver exactamente por qué murió el entorno? Con esa información podríamos aprender a prevenir el problema en el futuro.\n\nPor ejemplo, ¿sería apropiado programar un proceso cron para hacer ping ocasionalmente a Discourse y, si la respuesta es un código de retorno 502 o similar, reconstruir automáticamente?\n\nReconstruir parece una forma bastante brutal de resolver un problema. No es un diagnóstico.\n\nRealmente espero que alguien pueda indicarnos un documento popular de "Diagnóstico de problemas de Discourse" que los tontos como yo se hayan perdido. 
\n\n¡Gracias!
Por leer muchas publicaciones aquí, normalmente los administradores del foro no son la causa de los 502, y es un error de plugin/núcleo. Así que no habría mucho que pudieras hacer para evitar esos problemas.
Los registros de la consola siempre ayudan, a menudo pueden señalar el plugin problemático.
Puedo abrir la consola en este VPS pero la ventana de texto es limitada.
¿Hay registros específicos que se puedan revisar en el contenedor o en el sistema operativo?
¿Ya existe algún tipo de proceso de ping en el sistema operativo anfitrión o en el contenedor que detecte cuándo los procesos están inactivos?
¿Podría un simple reinicio del servidor dentro del contenedor ser una buena manera de abordar esto en lugar de una reconstrucción completa?
Por cierto, estoy ejecutando la última versión beta/dev, por lo que es totalmente posible que una actualización reciente haya caído el servidor, como hemos visto en el pasado. No recuerdo en este momento si hay algún plugin no predeterminado instalado.
Tengo la libertad de ayudar con el diagnóstico de esto sin que nuestra comunidad se moleste, aunque dentro de unos meses necesitaremos pasar a versiones más estables solo para mantener cómodos a nuestros usuarios. Así que si esto es algo en la compilación, estaré feliz de ayudar a encontrarlo.
¡Gracias!
Me refería a los registros del navegador, de las herramientas de desarrollador o el equivalente en tu navegador.
No lo creo, pero siempre puedes intentarlo.
¿Está lleno el disco?
¿Sucede esto con frecuencia?
Mira /var/discourse/logs/rails/production.log
Disculpa por tardar tanto en responder…
El disco está en uso <50%.
La RAM tiende a permanecer en el rango 80-90%, el Swap <40%. Supongo que aquí es donde se origina el problema.
Los registros están en /var/discourse/shared/standalone/log/rails.
production.log y los archivos comprimidos relacionados tienen muchos detalles de transacciones. ¿Qué podría buscar?
No hay ninguna entrada en production_error.log.
¿“Frecuentemente”? No. Pero lo suficientemente a menudo como para ser un poco molesto y animarme a publicar aquí.
Revisé syslog y no vi nada; no estoy seguro de que hubiera algo allí si el problema está restringido al contenedor, como debería ser.
Soy un novato en Docker, así que lamento no tener información del contenedor, pero estaré feliz de seguir las instrucciones.
¡Gracias!
Esto no ayudará. El problema está en el backend. Ni siquiera llega a recibir una respuesta del servidor (de ahí lo de “bad gateway”).
Son los registros de rails del backend los que necesitas revisar.
Prueba las acciones:
-
/var/discourse/shared/standalone/log/rails# tail -n 200 production.logpara ver si hay errores obvios de inicio. -
en el contenedor (primero
./launcher enter app):curl 0.0.0.0:3000para ver si el servidor de rails está respondiendo.
Por lo demás, elimina todos los plugins, reconstruye y luego añádelos de nuevo iterativamente.
El error 502 ocurre cuando Rails no devuelve una respuesta, generalmente cuando el sistema se está iniciando o algo está mal configurado.
Podrías revisar los registros de nginx.
Creo que casi todos los hilos aquí sobre errores 502 ocurren cuando Discourse ha sido actualizado y no ha vuelto a la vida. La actualización falló, o el administrador no esperó el tiempo suficiente para que el servicio se iniciara.
¿Estás diciendo que tienes un Discourse funcionando, no realizas ninguna acción administrativa, pero empieza a devolver 502 espontáneamente?
Y cuando lo hace, ¿siempre devuelve 502 hasta que se reinicia o funciona intermitentemente de nuevo?