오늘 아침 2개 컨테이너 설치 환경에서 업그레이드를 진행했는데 문제가 발생했습니다. 새 컨테이너를 부트스트랩하는 과정에서 데이터베이스가 깨진 상태로 마이그레이션되었습니다(SKIP_POST_DEPLOYMENT_MIGRATIONS=1을 사용했으면 이런 일이 일어나지 않았을 수도 있지만, 그것은 별개의 문제입니다). 그 결과 실행 중인 컨테이너에서 "사이트가 깨졌습니다"라는 오류 메시지가 표시되었습니다.
이 정도는 예상했던 부분입니다. 하지만 제 모니터링 시스템은 /srv/status를 확인하는데, 레일즈(Rails)가 상당히 깨진 상태여도 여전히 OK를 반환합니다.
이것이 버그인가요? 문제가 있을 때 모니터링 시스템이 이를 감지하길 원하는데, 로그인 없이 접근할 수 있는 사이트의 경우 /about.json 같은 다른 엔드포인트를 확인하는 것이 더 나은 방법일까요?
정확히 어떻게 깨졌나요? 좀 더 구체적으로 말씀해 주시겠어요? 홈페이지는 어떤 모습이었나요?
그래, “ok”는 “유니코르노가 정상 작동 중”이라는 뜻이야. 기억이 맞다면, Postgres와 Redis를 내려놔도 여전히 “ok”라고 표시되거든.
그게 맞을 것 같아요. 논리적으로는 맞는데, 내가 생각했던 것과는 좀 달라요.
@sam @eviltrout 이 이슈의 현재 상태가 뭔지 잘 모르겠어요. 과거에 이 주제에 대해 논의한 적이 있었던 것 같기도 하고요.
네, redis나 PG를 확인하지 않아요. 대신 User.find(1)과 $redis.get를 사용하는 플러그인을 사용하는 것 같습니다. 그래도 @pfaffman 님의 경우는 잡아내지 못하지만, 그것만으로도 좀 과할 수 있어요. 완전한 DB 무결성 검사까지 기대할 수는 없으니까요.
discourse/app/controllers/forums_controller.rb at main · discourse/discourse · GitHub
/srv/status 엔드포인트는 종속성이 아닌 로컬 프로세스만 확인합니다. “HTTP 스택이 막혔는가?” 그리고 "나는 lame-duck 상태인가?"를 묻는 것이죠. Kubernetes 용어로 말하면, 이것은 readinessProbe가 아니라 livenessProbe입니다.
readinessProbe를 도입하고 싶다면, 다른 URL에 위치해야 합니다.
1 대신 Discourse.system_user.id를 사용하는 것이 좋을 것입니다.