[Web Application Server] 상황별 로그

본 포스팅은 장애 상황 별 로그에 대한 분석 가이드입니다.

---

JEUS 로그에 발생되는 상황 별 로그를 살펴 봄으로써 장애 발생 시 즉각 또는 선조치가 가능하도록 대응 할 수 있도록 하는데 목적이 있습니다.

다양한 Exception Case가 존재 하지만 본 포스팅에서는 자주 발생되는 이슈들만 우선적으로 다뤄보도록 하겠습니다.

먼저 BindException입니다.

Address already in use라는 메시지와 함께 발생한 경우를 살펴보겠습니다.

발생하는 주요 원인은 기동하려는 node의 das 또는 ms의 PORT가 이미 사용 중일 경우 발생합니다.

해결 방법은 다음과 같습니다.

먼저 netstat 명령어로 해당 포트가 사용 중인지 확인하고 사용 중인 해당 프로세스 강제 종료한 후 재 기동을 수행합니다.
또는 같은 Node에 여러대의 WAS가 설치되어 있지는 않은지 확인합니다. 다른 계정에서 기동 중인 WAS Process가 있을 경우 사용해야

할 Port를 변경하고 반영합니다. 일반적으로 JEUS를 기동할 경우 아래와 같은 Port를 사용합니다.

JEUS Manager Base Port는 9736이고, Webadmin Port는 9744며, Http-Listener는 일반적으로 8080을 사용합니다. 그밖에 JMS Port, Container Port등 다수가 있을 수 있으며, 설정파일을 수정하여 반영합니다.

다음으로 Cannot assign requested address 메시지가 나왔을 경우입니다.

발생하는 주요 원인은 기동하려는 node, das 또는 ms의  IP가 다를 경우 발생합니다.

해당 서버 IP와  설정 IP 확인 후 설정 수정 후 재 기동을 수행합니다. 일반적으로 본 이슈는 JEUS이관 설치 시에 발생할 수 있습니다.

JEUS DAS와 MS의 Listen IP를 확인하고 이전 서버의 설정으로 반영되어 있지는 않은지 검토를 수행합니다.

 

두번째로 Server authentication failed입니다.

The user name or password is not correct라는 메시지와 함께 발생합니다.

발생하는 주요 원인은 설정의 UserName 혹은 Password가 기동 스크립트 내용과 상이할 경우 발생합니다.

해결 방법은 다음과 같습니다.

accounts.xml 파일과 $JEUS_HOME/bin 의 기동 스크립트를 확인하고 수정 후 재 기동을 수행합니다. 인코딩 방식이 복호화가 불가능한 DES / AES 수준 이상으로 되어 있을 경우 재생성이 필요하지만, BASE64로 되어 있을 경우 encryption script를 사용하여 password를 확인 할 수 있습니다.

 

세번째로 Permission denied입니다.

발생하는 주요 원인은 로그 디렉터리 권한이나 설정 파일 권한등이 제한되어 있을 경우 발생 할 수 있습니다.

해결 방법은 다음과 같습니다.

로그 디렉터리 및 JEUS Engine 설치 디렉토리에 JEUS 설치 계정으로 read와 write권한을 추가한 후 재기동을 수행합니다.

네번째로 already has the context Path입니다. 

발생하는 주요 원인은 한 개의 MS에서 동일 Context Path 사용 시 발생합니다.  
해결 방법은 다음과 같습니다.

먼저 MS를 분리하여 application을 Deploy하는 방법입니다. Context Path가 동일한 Application 2개를 Deploy 할 경우 일반적인 방법입니다.

다음으로 동일 MS에 Deploy해야 할 경우, Vhost를 반영하여 인식할 수 있도록 설정합니다. 이는 JEUS6 버전 이하의 context-group과 비슷한 기능이라고 생각하면 됩니다. Vhost를 통해 전달 받는 Domain을 선택하여 Context 분기 처리를 할 수 있도록 반영하는 방법입니다. 

다섯번째로 기동 시 SAXParseExcetpion 에러가 발생하는 경우입니다.

발생하는 주요 원인은 설정 xml 파일에 오타가 있거나 인식할 수 없는 Tag가 들어가 있을 경우 정상 기동이 되지 않습니다. xml 파서는 일반적으로 SAX Parser 또는 DOM Parser를 사용하나 JEUS에서는 SAX Parser를 사용합니다.

해결 방법은 다음과 같습니다.

xml 수정 전 백업은 필수이며, 로그를 참고하여 문제된 부분을 수정합니다. 다만 마이너 업그레이드를 수행하는 도중 위 에러가 발생하였을 경우 설정 Tag가 변경되었거나 없어졌을 경우가 있으니 Reference Book을 참고하여 변경사항에 맞게 수정을 진행합니다.  

 

여섯번째로 HTTP 404 에러입니다. 

발생하는 주요 원인은 파일 또는 디렉터리 부재이거나 Context-path가 맞지 않을 경우 또는 application이 정상 디플로이가 안되었을 경우 등 다양한 케이스에서 발생할 수 있습니다. 일반적으로 가장 많이 보게되는 Exception 중 하나입니다.
해결 방법은 다음과 같습니다.

파일, 디렉터리 확인 및 Context-path 및 application deploy 상태 등을 확인합니다.

 

일곱번째로 HTTP 500 에러입니다.

발생하는 주요 원인은 Application이나 서버 내부의 문제일 경우입니다. application 비즈니스 로직 수행 시 또는 jeus의 비정상 동작 시 발생할 수 있습니다.

해결 방법은 다음과 같습니다.

JEUS log 파일 내용을 참조하여 원인 파악 필요합니다. application 또는 jeus engine 문제는 다양한 케이스가 있기 때문에 해결하지 위해서는 Exception을 통해 문제 발생 위치를 파악하고 예외처리를 통해 디버깅을 수행해야 합니다.

 

여덟번째로 HTTP 503 에러입니다.

발생하는 주요 원인은 JEUS가 다운되었거나 기동은 되어있으나 WebtoB와 연동이 안된 상태에 발생합니다.

해당 에러는 WebtoB에서 발생하는 Exception입니다.

해결 방법은 다음과 같습니다.

먼저 thread 상태를 확인해야 합니다. JEUS이 경우 연결이 실패하였을 경우 reconnection 상태로 빠지게 되며 기존에 운영중인 서버의 경우 방화벽확인이 필요하고 신규 구축 중인 사이트의 경우 설정 검토 및 방화벽 확인이 필요합니다. 

아홉번째로 DB 연동 실패 에러입니다.

WAS와 Database 간 ConnectionPool을 생성하기 위해 필요한 정보는 다음과 같습니다.
IP, Port, ID, Passwd, SID, JNDI 6가지 정보가 필요하며 특시 연동간 필요한 JDBC Driver가 역시 필요합니다.

먼저 ClassNotFoundException이 발생한 경우입니다.

발생하는 주요 원인은 jdbc driver가 없을 경우 발생합니다. 또는 JDBC Driver Version이 잘못되었거나, 설정 상 Driver Class Name을 잘못 입력하였을 경우 발생 가능합니다.
해결 방법은 다음과 같습니다.
JDBC Driver는 연결을 시도하는 DB Server에서 직접 다운받아 해당 Driver를 사용합니다. 물론 설정 상의 검토는 병행해서 수행해야 합니다.

두번째로 NamingException입니다.

먼저 NoRouteToHostException과 함께 발생한 경우입니다.

발생하는 주요 원인은 DB IP를 잘못 입력할 경우 또는 방화벽이 막혀 있을 경우 발생합니다.
해결방법은 다음과 같습니다.
DB IP 재 입력 후 재기동 또는 방화벽을 확인합니다.
NamingException이 Connection refused와 함께 발생한 경우입니다.
발생하는 주요 원인은 DB PORT를 잘못 입력할 경우 또는 방화벽이 막혀 있을 경우 발생합니다.
해결방법은 다음과 같습니다.
DB PORT 재 입력 후 재기동 또는 방화벽을 확인합니다.
NamingException이 Listener refused the connection와 함께 발생한 경우입니다.
발생하는 주요 원인은 DB SID 잘못 입력하였을 경우 발생합니다.
해결방법은 다음과 같습니다.
DB SID 재 입력 후 재기동을 수행합니다.

마지막으로  NameNotFoundException입니다.

발생하는 주요 원인은 export name을 잘못 입력하였을 경우 발생합니다.
해결방법은 다음과 같습니다.
export name 재 입력 후 재기동을 수행합니다. export name은 application에서 JEUS의 Naming Server에 등록되어 있는 JNDI정보를 lookup 하기 위해 사용하는 정보이므로 개발자와 함께 옳바른 JNDI Name을 선정하고 설정에 반영해야 합니다.

열번째로 Thread hang입니다.

Monitoring에서 Thread에서 MS를 선택하면 해당 MS의 thread 모니터링이 가능합니다.

active시간 확인이 가능하며, hang 의심되는 thread의 tid를 선택하면 해당 요청의 trace 정보를 확인할 수 있습니다.

MS의 Pid를 확인하고, kill -3 [MS Pid] 입력하면 thread dump가 생성됩니다.
dump 분석하여 원인 파악을 수행합니다.

열한번째로 OutOfMemory입니다.

발생하는 주요 원인은 JVM Heap영역으로 설정한 메모리 사이즈가 부족하거나 GC가 정상적으로 일어나지 않을 때 발생합니다.

해결 방법은 다음과 같습니다.

원인분석을 위해 OutOfMemory 발생시 자동으로 HeapDump가 발생하도록 Managed Server의 JVM옵션에 Dump 및 GC log 옵션을 설정합니다. 발생된 HeapDump는 MemoryAnalyzer, IBM HeapAnalyzer 등의 툴로 분석이 가능합니다. 

열두번째로 UnsupportedClassVersionError입니다.

발생하는 주요 원인은 JEUS에서 지원하는 JDK Version과 Application build java version이 다를때 발생합니다.
해결방법은 다음과 같습니다.

상위 jdk 로 build된 Application을 하위버전 jdk 에서 수행하고자 할때 발생 됩니다. WAS의 Version을 업그레이드 하거나 혹은 application Compile을 was에 맞게 변경하여 수행합니다. 현실적으로 WAS의 Version을 수정하는 경우가 일반적입니다. 

열세번째로 ClassNotFoundException입니다.

발생하는 주요 원인은 해당 클래스가 실제 Application 경로에 없을 경우에 발생(class path)할 수 있습니다.

해결방법은 다음과 같습니다.

ClassNotFound가 발생한 클래스의 위치를 찾습니다. 이후 해당 클래스가 WAS에서 로딩할 수 있는 위치에 있는지를 확인합니다. 클래스 파일이 위치할 수 있는 경로를 점검하고 설정에서 인식할 수 있는 위치가 아니라면 해당 클래스를 해당 위치로 변경하여 재기동을 수행합니다. 

열네번째로 NoClassDefFoundError입니다.

발생하는 주요 원인은 클래스는 존재하나 해당 클래스가 Compile 시점과 다를 경우 발생합니다.

해결 방법은 다음과 같습니다.

일반적으로는 다양한 Library가 서로 다른 위치에 업로드 되어 있고, 이로 인해 WAS에서 인식하는 ClassLoader의 우선순위에 따라 Compile 시점의 클래스가 아닌 다른 클래스가 로딩될 경우 발생하게 됩니다. 동일한 클래스가 서로다른 위치에 존재하지 않도록 버전관리를 수행하고 재기동을 수행합니다.

이상으로 본 포스팅을 마치도록 하겠습니다. 다양한 로그 상태를 확인하여 선조치 및 대응할 수 있도록 활용을 부탁드립니다.

고맙습니다.