로그 레벨 설정

이 주제를 사용하여 로그 레벨 설정을 구성 및 관리하십시오.

이 관리 콘솔 페이지를 보려면 문제점 해결 > 로그 및 추적 > server_name > 로그 세부사항 수준 변경을 클릭하십시오.

로그 레벨을 사용하면 Java 로깅에서 처리하는 이벤트를 제어할 수 있습니다. 로거의 레벨을 변경할 경우 변경사항은 로거의 하위로 전달됩니다.

참고: 이 주제에서는 하나 이상의 애플리케이션 서버 로그 파일을 참조합니다. 권장되는 대안으로 분산 IBM® 시스템에서 SystemOut.log, SystemErr.log, trace.log 및 activity.log 파일을 사용하는 대신 HPEL(High Performance Extensible Logging) 로그 및 추적 인프라를 사용하도록 서버를 구성할 수 있습니다. 기본 z/OS® 로깅 기능과 함께 HPEL을 사용할 수도 있습니다. HPEL을 사용할 경우 서버 프로파일 바이너리 디렉토리에서 LogViewer 명령행 도구를 사용하여 모든 로그 및 추적 정보에 액세스할 수 있습니다. HPEL 사용에 대한 자세한 정보는 HPEL을 사용한 애플리케이션 문제 해결 정보를 참조하십시오.

잠재적으로 민감한 데이터의 로깅 및 추적 사용 안함

애플리케이션 서버에는 사용 가능한 경우 잠재적으로 쓰기에 민감한 정보로 알려진 로거 목록이 있습니다. 예를 들어, 특정 HTTP 관련 로거를 FINEST 레벨로 사용하는 경우, HTTP 요청의 사용자 지정 기밀 정보가 추적 파일에 저장될 수 있습니다. 서버에서 잠재적으로 민감한 정보에 사용하도록 알려진 레벨의 로거를 사용하지 않도록 하려면, 잠재적으로 민감한 데이터의 로깅 및 추적 사용 안함 선택란을 선택하십시오. 서버가 시작되거나 런타임 시 로그 세부사항 레벨 스펙이 수정되면, 서버는 로그 세부사항 레벨 스펙에서 지정된 로거 및 레벨의 목록을 민감한 로거 목록에 있는 로거 및 레벨 목록과 비교하고 필요한 경우 로그 세부사항 레벨 스펙을 업데이트합니다.

로그 세부사항 레벨 변경

추적할 컴포넌트, 패키지 또는 구룹을 지정하는 로그 세부사항 레벨을 입력하십시오. 로그 세부사항 레벨 문자열은 이 주제에 설명된 특정 문법을 준수해야 합니다. 로그 세부사항 레벨 문자열을 직접 입력하거나 그래픽 추적 인터페이스를 사용하여 생성할 수 있습니다.

구성 탭을 선택하고 컴포넌트 및 그룹을 펼치면, 잘 알려진 컴포넌트, 패키지 및 그룹의 정적 목록이 표시됩니다. 이 목록은 포괄적이지 않을 수 있습니다.

런타임 탭을 선택하고 컴포넌트 및 그룹을 펼치면, 실행 중인 애플리케이션 서버 및 정적 목록에 등록된 모든 컴포넌트와 함께 컴포넌트, 패키지 및 그룹 목록이 표시됩니다.

로그 세부사항 레벨 스펙의 형식은 다음과 같습니다.

<component> = <level>

여기서 <component>는 로그 세부사항 레벨을 설정할 컴포넌트이고, <level>은 유효한 로거 레벨(off, fatal, severe, warning, audit, info, config, detail, fine, finer, finest, all) 중 하나입니다. 복수 로그 세부사항 레벨 스펙은 콜론(:)으로 구분하십시오.

문제점 방지:

추적 스펙에 포함된 절은 문자열에 나타나는 순서대로 읽습니다. 따라서 *=info 절의 다중 변형이 추적 스펙에 포함된 경우 마지막으로 지정된 값은 시스템이 로그의 추적 레벨을 결정하는 값입니다. *=info를 마지막 절로 지정한 경우 추적은 추적 문자열에 지정된 다른 절과 관계없이 info 레벨에서 발생합니다. 예를 들어, 다음 추적 문자열을 지정한 경우:

*=info:PMGR=all:*=info:com.ibm.ws.sm.*=all

은 다음과 같이 단순히 지정하는 것과 같습니다.

*=all

마지막 절은 문자열의 절에 앞서 지정된 모든 절을 대체하기 때문입니다. [업데이트 됨- 2013년 6월]

gotcha

컴포넌트는 Java 패키지 및 클래스에 해당하거나 Java 패키지의 콜렉션에 해당합니다.지정된 컴포넌트에 들어 있는 모든 패키지의 모든 클래스를 포함하는 컴포넌트를 표시하려면 별표(*)를 와일드 카드로 사용하십시오. 예를 들어, 다음과 같습니다.

*: 제품 시스템 코드 및 고객 코드를 포함하여 애플리케이션 서버에서 실행 중인 모든 추적 가능한 코드를 지정합니다.
com.ibm.ws.*: 패키지 이름이 com.ibm.ws로 시작하는 모든 클래스를 지정합니다.
com.ibm.ws.classloader.JarClassLoader: JarClassLoader 클래스만을 지정합니다.

그룹 및 컴포넌트 목록 모두에서 선택할 경우 관리 콘솔에서 로그 세부사항 레벨 스펙을 설정할 때 오류가 발생할 수 있습니다. 경우에 따라, 어떤 목록에서의 선택을 추가할 때 다른 목록에서의 선택이 소실되는 경우가 있습니다. 이 문제점을 해결하려면 로그 세부사항 레벨 스펙을 직접 로그 세부사항 레벨 입력 필드에 입력하십시오.

로그 세부사항 레벨을 설정할 컴포넌트 또는 그룹을 선택하십시오. 다음 표에는 WebSphere® Application Server 버전 6 이상에서 Application Server에 유효한 레벨이 나열되어 있습니다.

문제점 방지: 로깅 레벨 값은 대소문자를 구분하며 소문자로 시작합니다.gotcha

표 1. 유효한 로깅 레벨. 다음 표에는 WebSphere Application Server 버전 6 이상에서 Application Server에 유효한 레벨이 나열되어 있습니다.
버전 6 이상 로깅 레벨	내용 / 중요도
off	로깅이 꺼져 있습니다.
fatal	태스크를 계속할 수 없고 컴포넌트, 애플리케이션 및 서버를 작동할 수 없습니다.
severe	태스크를 계속할 수 없지만 컴포넌트, 애플리케이션 및 서버를 계속 작동할 수 있습니다. 또한 이 레벨은 임박한 복구할 수 없는 오류를 표시할 수도 있습니다.
warning	잠재적 오류 또는 임박한 오류. 이 레벨은 진행형의 장애를 표시하기도 합니다(예: 자원의 잠재적 누출).
audit	서버 상태나 자원에 영향을 미치는 중요한 이벤트
info	전체 작업 진행을 요약하는 일반 정보
config	구성 변경 또는 상태
detail	하위 작업 진행의 세부사항에 대한 일반 정보
fine	추적 정보 - 일반 추적 + 메소드 입력, 종료 및 리턴 값
finer	추적 정보 - 자세한 추적
finest	추적 정보 - 문제점을 디버그하는 데 필요한 모든 세부사항을 포함하는 자세한 추적.
모두	모든 이벤트가 로그됩니다. 사용자 정의 레벨을 작성하면, 이들 레벨은 모두 레벨에 포함되며, 모두 레벨에서는 가장 정밀한 레벨보다 더 자세한 추적을 제공할 수 있습니다.

버전 6.0 이상에서 로깅 레벨을 사용 가능으로 설정한 경우에는 그보다 높은 심각도의 레벨도 모두 사용 가능합니다. 예를 들어, Application Server 버전 6.x에서 로깅 레벨을 경고로 설정한 경우에는 경고, 심각한 및 치명적 이벤트가 처리됩니다.

[기본 모드 로깅] 정밀(Fine), 더 정밀한(Finer) 및 가장 정밀한(Finest) 레벨의 이벤트 추적 정보는 추적 로그에만 기록할 수 있습니다. 따라서 진단 추적을 사용 가능으로 설정하지 않을 경우, 로그 세부사항 레벨을 정밀(Fine), 더 정밀한(Finer) 또는 가장 정밀한(Finest) 레벨로 설정해도 로그된 데이터에 영향을 주지 않습니다.

상관: 사용 가능하게 할 상관 설정을 지정하십시오. 애플리케이션 서버에 대한 상관을 사용 가능하게 하려면 로그 및 추적 상관 사용 선택란을 선택하십시오. 애플리케이션 서버에 대한 상관을 사용 불가능하게 하려면 로그 및 추적 상관 사용 선택란을 선택 취소하십시오. 로그 및 추적 레코드에 요청 ID 포함, 로그 및 추적 레코드와 상관 로그 레코드에 요청 ID 포함 또는 로그 및 추적 레코드에 요청 ID 포함, 상관 로그 레코드 작성 및 데이터 스냅샷 캡처를 적절하게 선택하십시오.
우수 사례: 모든 스레드 및 애플리케이션 서버 프로세스에서 동일한 요청에 관련되어 있는 로그 및 추적 항목을 표시할 경우 로그 및 추적 파일에 요청 ID를 포함하도록 XCT를 사용 가능하게 하십시오. HPEL 로그 및 추적 모드를 사용할 경우에만 레코드 ID가 기록되고 logViewer 명령을 사용하여 요청 ID를 표시하거나 필터링에 사용할 수 있습니다. bprac

우수 사례: 스레드와 프로세스 간에 요청이 분기되는 방식을 로그할 경우 상관 로그 레코드를 작성하도록 XCT를 활성화하고, 각 요청에 대한 추가 정보를 표시할 수 있습니다. 상관 로그 레코드를 작성하도록 XCT를 활성화하면 시스템에 상당한 성능 영향을 미칠 수 있으므로 테스트 및 개발 환경에 가장 적합합니다. bprac

우수 사례: 전체 요청 및 응답 본문을 파일 시스템에 저장할 경우 데이터 스냅샷을 캡처하도록 XCT를 활성화합니다. 데이터 스냅샷을 캡처하도록 XCT를 활성화하면 시스템에 상당한 성능 영향을 미칠 수 있으므로 테스트 및 개발 환경에 가장 적합합니다. XCT는 SIBus에서 처리하는 메시지 요청 및 응답에 대해서 데이터 스냅샷을 캡처합니다. bprac

문제점 방지: 캡처된 데이터 스냅샷은 $SERVER_LOG_ROOT/snapdata 디렉토리에 기록됩니다. Application Server는 이 디렉토리에서 파일을 자동으로 정리하지 않습니다. 데이터 스냅샷 캡처를 사용하는 경우 이 디렉토리에서 파일을 정기적으로 삭제해야 합니다. 데이터 스냅샷의 경우 전체 요청 및 응답 컨텐츠를 저장하고 중요한 정보를 포함할 수 있습니다. 이 옵션은 프로덕션 환경에서 사용하는 데 적합하지 않을 수 있습니다. gotcha

구성에 런타임 변경사항도 저장: 실행 중인 서버와 서버 구성의 동적 상태 둘 다를 변경하도록 지정합니다. 이러한 변경사항은 다음 다시 시작 시 적용됩니다. 이 선택란을 선택하지 않으면 서버는 해당 설정을 서버 구성에 복사하지 않습니다.

파일 이름: utrb_loglevel.html