Discourse 사이트에서 502 Bad Gateway 오류가 발생했을 때 단계별 진단 방법이 있나요?

Discourse 사이트가 502 Bad Gateway 상태에 놓였을 때를 위한 단계별 진단 방법을 찾아보려고 여기에 왔습니다. 현재 제시되는 유일한 옵션은 다음과 같은 수준인 것 같습니다:

  1. Discourse 업데이트가 실패했을 수 있으니 ./launcher rebuild app을 사용하세요.
  2. 서버를 업데이트하고 재시작하세요.

이런 식의 답변은 1차 지원 기술자나 이메일 봇이 주는 전형적인 응답입니다.

환경이 왜 죽었는지 정확히 파악하기 위해 로그를 확인하는 등 다른 방법은 없을까요? 그런 정보가 있다면 향후 문제를 예방하는 방법을 배울 수 있을지도 모릅니다.

예를 들어, cron 프로세스를 스크립트로 작성해서 가끔씩 Discourse에 ping을 보내고, 응답이 502 또는 유사한 반환 코드인 경우 자동으로 재빌드하는 것이 적절할까요?

재빌드는 문제를 해결하는 방식으로는 다소 무리가 있어 보입니다. 진단 방법이 아니기 때문입니다.

제 같은 초보자가 놓치고 있을 만한 인기 있는 “Discourse 문제 진단” 문서를 알려주시는 분이 있을까 정말 기대하고 있습니다. :slight_smile:

감사합니다!

여기서 많은 게시물을 읽어본 결과, 보통 포럼 관리자가 502 오류의 원인이 되는 경우는 드물며, 플러그인 또는 코어 오류가 원인인 경우가 많습니다. 따라서 이러한 문제를 피하기 위해 특별히 할 수 있는 일은 많지 않습니다.

콘솔 로그는 항상 도움이 되며, 많은 경우 문제의 원인이 되는 플러그인을 정확히 찾아낼 수 있습니다.

이 VPS에서 콘솔은 열 수 있지만 텍스트 창이 제한되어 있습니다.
컨테이너나 OS에서 확인해 볼 수 있는 특정 로그가 있을까요?
호스트 OS나 컨테이너에서 프로세스가 다운되었을 때 감지하는 형태의 ping 프로세스가 이미 존재합니까?
전체 재빌드보다는 컨테이너 내에서 서버를 단순히 재시작하는 방식이 더 나은 접근 방법이 될 수 있을까요?

참고로, 저는 최신 베타/개발 버전을 실행 중이므로, 과거에도 그랬듯이 최근 업데이트로 인해 서버가 다운되었을 가능성이 충분히 있습니다. 현재 비기본 플러그인이 설치되어 있는지 기억이 나지 않습니다.

커뮤니티가 불편해하지 않도록 몇 달 내에는 더 안정적인 버전으로 전환해야 하지만, 그 전까지는 커뮤니티가 화내지 않는 선에서 진단을 돕는 데 자유가 있습니다. 따라서 이것이 빌드 관련 문제라면 찾아내는 데 기꺼이 도움을 주겠습니다.

감사합니다!

브라우저 로그, 즉 개발자 도구 또는 브라우저의 동등한 기능을 통한 로그를 말씀하신 것입니다.

그렇지 않다고 생각하지만, 시도해 볼 수는 있습니다.

디스크가 가득 찬 것일까요?

이 문제가 자주 발생하나요?

/var/discourse/logs/rails/production.log 파일을 확인해 보세요.

답변이 늦어서 죄송합니다…

디스크 사용량은 50% 미만입니다.
RAM은 80~90% 범위를 유지하는 경향이 있고, 스왑 사용량은 40% 미만입니다. 문제가 여기서 발생한다고 추측하고 있습니다.
로그는 /var/discourse/shared/standalone/log/rails에 있습니다.
production.log와 관련 압축 파일에는 트랜잭션 세부 정보가 많이 포함되어 있습니다. 무엇을 찾아봐야 할까요?
production_error.log에는 항목이 전혀 없습니다.
“자주” 발생하나요? 아니요. 하지만 은근히 짜증을 내고 여기에 글을 쓰게 만들 정도로 자주 발생합니다. :slight_smile:
syslog를 확인해 보았지만 아무것도 보이지 않았습니다 - 문제가 컨테이너에 국한되어 있다면(그렇게 되어야 하지만) syslog에 무언가가 있을 것 같지 않거든요.

저는 Docker 초보자라서 컨테이너 관련 정보를 제공하지 못해 죄송합니다. 지시해 주시면 기꺼이 확인해 보겠습니다.

감사합니다!

이것은 도움이 되지 않습니다. 문제는 백엔드에 있습니다. 서버로부터 응답을 받는 단계까지 도달하지 못하고 있습니다(그래서 “bad gateway” 오류가 발생하는 것입니다).

확인해야 할 것은 백엔드 레일즈(rails) 로그입니다.

다음과 같은 작업을 시도해 보세요:

  • /var/discourse/shared/standalone/log/rails# tail -n 200 production.log 명령을 실행하여 명백한 시작 오류가 있는지 확인합니다.

  • 컨테이너 내부에서 (먼저 ./launcher enter app 실행): curl 0.0.0.0:3000 명령을 실행하여 레일즈 서버가 응답하는지 확인합니다.

그 외에는 모든 플러그인을 제거한 후 다시 빌드하고, 하나씩 다시 추가해 보세요.

502 에러는 Rails가 응답을 반환하지 않을 때 발생하며, 보통 시스템이 부팅 중이거나 구성에 문제가 있을 때 나타납니다.

nginx 로그를 확인해 볼 수 있습니다.

여기서 502 에러에 대한 거의 모든 스레드는 Discourse가 업그레이드된 후 다시 시작되지 않았을 때 발생하는 경우입니다. 업그레이드가 실패했거나, 관리자가 서비스가 시작될 때까지 충분히 기다리지 않은 것이죠.

작동 중인 Discourse에서 관리자 작업을 수행하지 않았는데도 502 에러가 자발적으로 발생하기 시작한다는 말씀이신가요?

그리고 그렇게 될 때, 재시작할 때까지 항상 502 에러를 반환하는 건가요, 아니면 간헐적으로 다시 정상 작동하나요?