현재 우리 프로젝트 개발 환경에서 젠킨스에서 새로운 PR에 대해 Build 하고 배포를 하도록 구성되어 있으며 AWS 클라우드를 활용 중이다.
하지만 여러 사람이 프로젝트에 관여하다 보니 가끔 빌드 후 톰캣에서 에러가 발생하곤 한다..(개발 단계이고, 실제 Production에선 절! 대! 발생해선 안 되는 상황이다)
이번에 정리해보고자 하는 내용은 Tomcat 구동 시 에러로그를 확인하고, 추적하는 방법이다.
일반적인 로컬에서의 상황이 아니고 클라우드 cli에서 로그 파일을 확인해야 하므로 기록을 남겨보고자 한다.
1. Build가 성공하고 새롭게 Reload되었더니 시원하게 502 Bad Gateway를 뿌려주고 있었다.
2. Tomcat을 구동하는 AWS EC2 서버에 ssh 접속하여 확인을 해보기 시작
ps -ef | grep tomcat // tomcat이 구동되고 있는지 확인
위의 명령어를 쳐 본다, 하지만 다른 tomcat으로 구동되는 여러 프로세스가 나오기 때문에 이해하기 어려울 수 있다.
netstat -ntpl // 사용중인 포트 확인
사용 중인 포트를 확인하여 tomcat이 구동되는 포트가 LISTEN 상태인지 확인해 본다.
-> 예를 들어 8080 포트를 Tomcat 포트로 사용 중인데 LISTEN 상태가 아니라면 Tomcat 서버가 뜨지 않았다는 의미
3. 에러 로그를 확인해 보자.
cat /usr/local/apache-tomcat-9.0.65/logs/catalina-date.log // 당시 날짜로 생성된 catalina 로그파일 확인
...
01-Feb-2023 06:46:49.547 SEVERE [main] org.apache.catalina.loader.WebappClassLoaderBase.checkThreadLocalMapForLeaks The web application [ROOT] created a ThreadLocal with key of type [org.springframework.boot.SpringBootExceptionHandler.LoggedExceptionHandlerThreadLocal] (value [org.springframework.boot.SpringBootExceptionHandler$LoggedExceptionHandlerThreadLocal@2d5b28bd]) and a value of type [org.springframework.boot.SpringBootExceptionHandler] (value [org.springframework.boot.SpringBootExceptionHandler@73e825d1]) but failed to remove it when the web application was stopped. Threads are going to be renewed over time to try and avoid a probable memory leak.
...
생각보다 길게 알아보기 힘든 형태로 나타날 수 있지만 핵심 word를 찾아보면
jdbc 커넥션으로 인한 Memory Leak 문제가 발생했다
Memory Leak이라니? 내가 무슨 죄를 지었나.. 잘 되던 녀석이 안되니까 Memory Leak 문제는 아니라고 생각하면서도 에러가 그러하니 막 Memory Leak에 대한 에러를 찾아보았다.
https://rumor1993.tistory.com/76
고질적인 플로우 메모리 누수 원인 (Memory Leak)
메모리 누수로 인한 문제점 JVM의 힙영역에 GC에 관리 대상에서 제외 된 객체들이 메모리를 차지하면서 GC가 자주 발생하고 이를 해소하는 과정을 거치는데 이 과정에서 플로우 서비스는 동작하
rumor1993.tistory.com
4. 메모리 누수가 일어난다고? 그렇다면 메모리를 확인해 보자!
ps -eo user, pid, ppid, rss, size, vsize, pmem, pcpu, time, cmd --sort --rss | head -n 11 // 필요 없는 옵션은 제외해도 좋다
확인해 보니 잡아먹는 메모리의 문제라기보다, 어느 순간에 그냥 Tomcat이 종료되는 것이었다.
따라서, 메모리 누수의 문제는 아니구나 라는 생각을 하게 되었다.
5. 톰캣이 구동되면서 뜨는 로그를 봐보자, cli 환경이지만 Spring Boot가 뜨는 과정을 볼 수 있기 때문에 로컬에서 실행하는 것처럼 에러가 보기 쉽게 나오지 않을까?라는 생각을 했다.
/usr/local/apache-tomcat-9.0.65/bin/catalina.sh // 디렉토리는 환경에 맞게 수정
로컬에서 처럼 SpringBoot가 뜨면서 에러를 뱉어냈고, 확인해 보니, 이전 Build에서 application.yml을 업데이트하지 않아 환경변수 값을 못 불러와 Tomcat이 제대로 구동하지 않았다.
해결
클라우드에 직접 서비스를 배포하고 관리하는 과정에서 부득이하게 CLI 화면에서 에러로그를 찾아봐야 하는 상황이 자주 있었다. 그때마다 여기저기 찾아보느라고 시간을 많이 썼는데, 이번에 또 에러를 만나고 역시 기억보단 기록을 하는 것이 맞는 것 같다.
다른 사람들도 에러 확인을 못해서 삽질하는 일이 없었으면 좋겠다..
제일 중요한 건 에러로 인한 서버가 떨어지는 것을 쉽게 생각하면 안 된다.. 잘 확인하고 올리도록 하자!!
'트러블슈팅' 카테고리의 다른 글
SSL/TLS 설정 시 Cipher Suites 설정 (0) | 2023.04.20 |
---|---|
3-cert-chain 인증서 만들기 (0) | 2023.04.18 |
Spring Security와 CORS 에러 대응 (0) | 2023.01.03 |
Spring Security 환경에서 테스트 통과하는 방법 (0) | 2022.11.24 |
Swagger에서 CORS에러 해결 (0) | 2022.11.13 |