고객사는 당연히 윈도우 서버이고 배포했을때 디버깅에 상당한 에로가 많습니다.
너무 거대한 db 라 떠올수도 없고 ?
무슨 환경변수가 있을지 모르겠고
로그를 남기는것도 어느정도고 어느줄에서 발생하는지 감 잡기도 어렵고요
제일 좋은것 visual studio 설치되서 프로세스 attach 시켜서 디버깅 하는것데 ?
vs 를 설치하기 어려운 상황에서 뭐 좋은 방법이 없을까요?
linqpad 이걸로 가능하다는것 같긴 한데 가부만 알려주시면 한번 연구해보겠습니다.
1개의 좋아요
Visual Studio 디버거를 프로덕션 서버에 배포해서 붙이는 시도, 혹은 LINQPad 같은 도구를 프로덕션 서버에 배포할 경우 많은 취약점을 야기할 수 있어서 절대 하면 안되는 일입니다. 추후 보안 사고가 발생할 경우 디버거를 프로덕션 서버에 붙이려 시도했다는 행위 자체가 감사 대상이 될 수 있어서 위험하다고 봅니다.
대신, 예외가 발생하면 수집되는 Exception과 Stack Trace를 수집하는 Sentry (sentry.io)같은 서비스를 이용해서 오류의 원인을 추적하시는 것이 좋고, 구체적인 정보가 필요하다면 릴리즈 빌드 대신 디버그 빌드를 배포하면서 PDB 파일을 함께 배포하시는 것이 도움이 됩니다.
그리고 배포되는 애플리케이션을 포렌식이나 진단 목적으로 일시 격리를 할 수 있는 조건이나 상황이 된다면 (이 경우는 서버 애플리케이션의 경우 보통 컨테이너화를 한 경우에 해당되며, 데스크톱 애플리케이션이라면 사용자의 협조를 얻어 작업 관리자에서 덤프 생성 기능으로 문제가 발생했을 당시에 덤프를 떠달라고 요청하시면 도움이 됩니다.), 문제가 발생한 후 해당 서버 인스턴스를 격리하시고, 프로세스 메모리 덤프를 뜬 다음 배포했던 PDB 파일, Git 리비전, 그리고 DMP 파일을 함께 수집하여 Visual Studio에서 해당 소스 리비전으로 되돌린 후 덤프 파일을 열어서 당시 상황을 시뮬레이션할 수 있습니다. 이를 통해 문제가 발생했을 당시의 상황을 역추적하고, 메모리에 들어있는 값도 대입해볼 수 있어서 문제 해결이 조금 더 쉬워집니다.
4개의 좋아요