Apache Foundation 에 속하는 Tomcat 은 오픈 소스 경량 웹 어플리케이션 서버로 널리 사용되고 있습니다. Server.xml 은 Tomcat 에서 가장 중요한 구성 파일이며 server.xml 의 각 요소는 Tomcat 의 구성 요소에 해당합니다. Xml 파일의 요소를 구성하여 Tomcat 의 구성 요소를 제어할 수 있습니다. 따라서 Tomcat 을 이해하고 사용하려면 server.xml 파일의 구성을 배우는 것이 중요합니다.
이 문서에서는 예를 통해 server.xml 의 구성 요소 구성, Tomcat 의 핵심 구성 요소 기능 및 구성 요소 간의 관계에 대해 자세히 설명합니다.
참고: server.xml 파일의 요소와 Tomcat 의 구성 요소 간의 대응 관계로 인해 설명 편의를 위해 "요소" 와 "구성 요소" 사용을 엄격하게 구분하지 않았습니다.
먼저 server.xml 구성 예제를 시작합니다
Server.xml 은 $TOMCAT_HOME/conf 디렉토리에 있습니다. 다음은 server.xml 의 예입니다. 이 예는 server.xml 에 있는 각 요소의 의미와 기능을 설명하는 데 사용됩니다. 다음 장을 읽는 과정에서 쉽게 이해할 수 있도록 이 XML 문서를 참조할 수 있습니다.
둘째, server.xml 문서의 요소 분류 및 전체 구조
1, 전체 구조
Server.xml 의 전체 구조는 다음과 같습니다.
이 구조에서는 Tomcat 의 핵심 구성 요소만 제공됩니다. 핵심 구성 요소 외에도 Tomcat 에는 몇 가지 다른 구성 요소가 있습니다. 다음은 구성 요소 분류에 대한 설명입니다.
2. 요소 분류
Server.xml 파일의 요소는 다음 네 가지 범주로 나눌 수 있습니다.
(1) 맨 위 요소: 및
요소는 엔진 요소와 연결된 커넥터 요소 세트를 나타내는 전체 구성 파일의 루트 요소입니다.
(2) 커넥터:
외부 클라이언트가 특정 서비스에 요청을 보내는 인터페이스를 나타냅니다. 외부 클라이언트가 특정 서비스로부터 응답을 받는 인터페이스이기도 합니다.
(3) 용기:
컨테이너의 기능은 커넥터에서 수신한 수신 요청을 처리하고 적절한 응답을 생성하는 것입니다. 엔진, 호스트, 컨텍스트는 모두 컨테이너이지만 평행이 아니라 상위-하위 관계입니다. 엔진에는 호스트가 포함되고 호스트에는 컨텍스트가 포함됩니다. 엔진 구성 요소는 서비스의 모든 요청을 처리할 수 있고, 호스트 구성 요소는 특정 가상 호스트로 전송된 모든 요청을 처리할 수 있으며, 컨텍스트 구성 요소는 특정 웹 응용 프로그램에 대한 모든 요청을 처리할 수 있습니다.
(4) 임베디드 구성 요소: 컨테이너에 포함 할 수있는 구성 요소. 실제로 서버, 서비스, 커넥터, 엔진, 호스트 및 컨텍스트는 가장 중요하고 핵심 Tomcat 구성 요소이며 다른 구성 요소는 임베디드 구성 요소로 분류할 수 있습니다.
다음은 Tomcat 의 핵심 구성 요소 기능과 그 관계에 대해 자세히 설명합니다.
셋째, 핵심 구성 요소
이 섹션에서는 각 핵심 구성 요소의 기능, 특징 및 구성 방법에 대해 설명합니다.
1, 서버
Server 요소는 최상위 수준에 있으며 전체 Tomcat 컨테이너를 나타내므로 server.xml 에서 유일하게 가장 바깥쪽 요소여야 합니다.
첫 번째 부분의 예에서 가장 바깥쪽에 요소가 있으며, shutdown 속성은 서버를 종료하는 명령을 나타냅니다. Port 속성은 서버가 종료 명령을 받는 포트 번호를 나타냅니다. 이 포트를 비활성화하려면-1 으로 설정합니다.
서버의 주요 임무는 클라이언트에 이 서비스 컬렉션에 액세스할 수 있는 인터페이스를 제공하는 동시에, 포함된 모든 서비스에 대한 선언 기간 (초기화 방법, 서비스 종료 방법, 클라이언트가 액세스할 서비스를 찾는 방법 등) 을 유지하는 것입니다.
2, 서비스
서비스의 기능은 커넥터와 엔진 주위에 한 층을 싸서 함께 조립하고 외부에 서비스를 제공하는 것이다. 서비스에는 여러 커넥터가 포함될 수 있지만 엔진은 하나만 포함될 수 있습니다. 을 눌러 섹션을 인쇄할 수도 있습니다 커넥터의 역할은 클라이언트로부터 요청을 수신하는 것이고 엔진은 들어오는 요청을 처리하는 것입니다.
첫 번째 부분의 예에서 서버에는 "Catalina" 라는 서비스가 포함되어 있습니다. 사실, Tomcat 은 다양한 서비스를 제공 할 수 있으며, 다른 서비스는 다른 포트에서 수신 할 수 있습니다. 나중에 설명합니다.
3, 커넥터
커넥터의 주요 기능은 접속 요청을 수신하고 요청자와 데이터를 교환하는 요청 및 응답 객체를 생성하는 것입니다. 그런 다음 스레드를 할당하여 엔진에서 이 요청을 처리하고 생성된 요청 및 응답 객체를 엔진에 전달하도록 합니다.
커넥터를 구성하면 서비스를 요청하는 프로토콜 및 포트 번호를 제어할 수 있습니다. 첫 번째 섹션의 예에서는 서비스에 다음과 같은 두 개의 커넥터가 포함되어 있습니다.
이 예에서 Tomcat 는 공식 포트 80 대신 포트 8080 을 사용하여 HTTP 요청을 수신합니다. 실제로 공식적인 프로덕션 환경에서 Tomcat 는 포트 80 이 아닌 포트 8080 을 자주 수신합니다. 그 이유는 운영 환경에서 Tomcat 가 직접 외부에 요청을 받는 경우는 거의 없고, Tomcat 와 클라이언트 사이에 nginx 와 같은 프록시 서버를 추가하여 요청 전달, 로드 밸런싱, 정적 파일 처리 등을 하기 때문입니다. 프록시 서버를 통해 Tomcat 에 액세스할 때 LAN 내에 있으므로 일반적으로 8080 포트를 사용합니다.
(2) 두 번째 커넥터를 구성하면 클라이언트는 포트 번호 8009 를 통해 AJP 프로토콜의 Tomcat 에 액세스할 수 있습니다. AJP 프로토콜은 Apache 와 같은 다른 HTTP 서버와의 연결을 담당합니다. 이 커넥터는 Tomcat 가 다른 HTTP 서버와 통합될 때 필요합니다. Tomcat 이 다른 서버와 통합되는 이유는 Tomcat 이 서블릿/JSP 컨테이너로 사용될 수 있지만 정적 리소스는 Apache, IIS 등의 HTTP 서버보다 처리 속도가 느리기 때문입니다. 따라서 Tomcat 은 종종 서블릿 컨테이너, 정적 리소스 처리, AJP 프로토콜이 Tomcat 과 Apache 의 연결을 담당하는 Apache 와 통합됩니다. Tomcat 과 Apache 의 통합 원리는 다음과 같습니다 (사진 출처).
4, 엔진
엔진 구성 요소는 서비스 구성 요소에 있으며 하나만 있습니다. 엔진은 서비스 구성 요소의 요청 처리 구성 요소입니다. 엔진 구성요소는 하나 이상의 커넥터에서 요청을 수신하고 처리하고, 완료된 응답을 커넥터로 반환하고, 최종적으로 클라이언트에 전달합니다.
앞서 언급했듯이 엔진, 호스트, 컨텍스트는 모두 컨테이너이지만 평행이 아니라 상위-하위 관계입니다. 즉, 엔진에는 호스트가 포함되고 호스트에는 컨텍스트가 포함됩니다.
첫 번째 부분의 예에서 엔진의 구성 문은 다음과 같습니다.
여기서 name 속성은 로그 및 오류 메시지에 사용되며 서버 전체에서 고유해야 합니다. DefaultHost 속성은 기본 호스트 이름을 지정합니다. DefaultHost 로 지정된 호스트는 이 컴퓨터로 보낸 요청에 지정된 호스트 이름이 없을 때 처리됩니다. 따라서 defaultHost 의 값은 엔진에 있는 호스트 구성 요소의 name 속성 값과 일치해야 합니다.
5, 호스트
엔진 및 호스트 (1)
호스트는 엔진의 하위 컨테이너입니다. 엔진 구성 요소는 1 이상의 호스트 구성 요소를 내장할 수 있으며, 각 호스트 구성 요소는 엔진 내의 가상 호스트를 나타냅니다. 호스트 구성 요소가 하나 이상 있어야 하며 구성 요소 중 하나의 이름이 엔진 구성 요소의 defaultHost 속성과 일치해야 합니다.
(2)2) 사회자의 역할
호스트 가상 호스트의 역할은 여러 웹 응용 프로그램 (하나의 컨텍스트가 하나의 웹 응용 프로그램을 나타냄) 을 실행하고 각 웹 응용 프로그램을 설치, 확장, 시작 및 종료하는 것입니다.
호스트 구성 요소가 나타내는 가상 호스트는 서버의 네트워크 이름 엔티티 (예: "www.test.com" 또는 IP 주소 "116.25.25.25") 에 해당합니다 사용자가 네트워크 이름을 통해 Tomcat 서버에 연결할 수 있도록 하려면 DNS 서버에 이 이름을 등록해야 합니다.
클라이언트는 일반적으로 호스트 이름을 사용하여 연결할 서버를 식별합니다. 호스트 이름은 HTTP 요청 헤더에도 포함됩니다. Tomcat 은 HTTP 헤더에서 호스트 이름을 추출하고 이름이 일치하는 호스트를 찾습니다. 일치하지 않으면 요청이 기본 호스트로 전송됩니다. 따라서 모든 호스트 이름과 일치하지 않는 요청은 기본 호스트로 라우팅되므로 기본 호스트는 DNS 서버에 등록된 네트워크 이름이 아니어도 됩니다.
(3)3) 호스트 구성
첫 번째 섹션의 예에서 호스트는 다음과 같이 구성됩니다.
구성된 속성은 다음과 같습니다.
Name 속성은 엔진 구성 요소의 defaultHost 속성과 일치하는 하나의 엔진에 있는 하나의 호스트 구성 요소의 name 속성과 일치하는 가상 호스트의 호스트 이름을 지정합니다. 일반적으로 호스트 이름은 DNS 서버에 등록된 네트워크 이름이어야 하지만 엔진이 지정한 defaultHost 는 위에서 설명한 대로 필요하지 않습니다.
UnpackWARs 웹 응용 프로그램을 나타내는 WAR 파일의 압축을 풀 것인지 여부를 지정합니다. 참이면 압축을 푼 파일 구조를 통해 웹 애플리케이션을 실행합니다. False 이면 WAR 파일을 사용하여 웹 응용 프로그램을 직접 실행합니다.
호스트의 autoDeploy 및 appBase 속성은 호스트의 웹 애플리케이션 자동 배포와 관련이 있습니다. 또한 이 예제에 나타나지 않는 xmlBase 및 deployOnStartup 속성은 웹 응용 프로그램의 자동 배포와 관련이 있습니다. 다음 섹션 (컨텍스트) 에서 설명합니다.
6, 문맥
(1) 컨텍스트의 역할
Context 요소는 특정 가상 호스트에서 실행되는 웹 응용 프로그램을 나타냅니다. 아래에서 컨텍스트, 응용 프로그램 또는 웹 응용 프로그램을 언급하며 모두 웹 응용 프로그램을 나타냅니다. 각 웹 응용 프로그램은 WAR 파일 또는 추출된 WAR 파일에 해당하는 디렉토리 (이 경우 응용 프로그램 디렉토리라고 함) 를 기반으로 합니다.
Context 는 Host 의 하위 컨테이너이며 각 Host 에서 원하는 수의 Context 요소를 정의할 수 있습니다.
예제의 첫 번째 부분에서는 Context 요소의 구성이 server.xml 구성 파일에 나타나지 않음을 알 수 있습니다. 이는 Tomcat 이 이미 자동 배포를 시작했고, 웹 응용 프로그램은 server.xml 에 정적 배포를 구성하지 않고, Tomcat 이 특정 규칙을 통해 자동으로 배포되기 때문입니다. 다음은 Tomcat 이 웹 어플리케이션을 자동으로 배포하는 메커니즘에 대해 설명합니다.
(2) 웹 응용 프로그램 자동 배포
호스트 구성
웹 응용 프로그램의 자동 배포를 시작하려면 가상 호스트를 구성해야 합니다. 구성 방법은 앞서 언급한 호스트 요소의 deployOnStartup 및 autoDeploy 속성입니다. DeployOnStartup 및 autoDeploy 가 true 로 설정된 경우 Tomcat 은 자동 배포를 시작합니다. 즉, 새 웹 어플리케이션 또는 웹 어플리케이션에 대한 업데이트가 감지되면 어플리케이션 배포 (또는 재배포) 가 트리거됩니다. 두 가지의 주요 차이점은 deployOnStartup 이 true 일 때 Tomcat 이 시작 시 웹 응용 프로그램을 검사하고 감지된 모든 웹 응용 프로그램이 새 응용 프로그램으로 간주된다는 것입니다. AutoDeploy 가 true 이면 Tomcat 은 런타임 시 정기적으로 새 웹 어플리케이션 또는 웹 어플리케이션의 업데이트를 확인합니다. 그렇지 않으면 비슷한 방식으로 처리됩니다.
DeployOnStartup 및 autoDeploy 를 구성하여 가상 호스트를 시작하여 웹 응용 프로그램을 자동으로 배포할 수 있습니다. 실제로 자동 배포는 새 웹 응용 프로그램이나 변경된 웹 응용 프로그램이 있는지 확인하는 데 따라 달라집니다. Host 요소의 appBase 및 xmlBase 설정은 웹 응용 프로그램 업데이트를 확인하는 데 사용되는 디렉토리를 설정합니다.
AppBase 등록 정보는 웹 응용 프로그램이 있는 디렉토리를 지정합니다. 기본값은 webapps 입니다. 이는 Tomcat 루트 아래의 webapps 폴더를 나타내는 상대 경로입니다.
XMLBase 속성은 웹 응용 프로그램의 XML 구성 파일이 있는 디렉토리를 지정합니다. 기본값은 conf// 입니다. 예를 들어, 예제의 첫 번째 부분에서 호스트 localhost 의 xmlBase 에 대한 기본값은 $ Tomcat _ home/conf/catalina/localhost 입니다.
웹 응용 프로그램 업데이트 확인
웹 응용 프로그램에는 XML 프로파일, WAR 패키지, 응용 프로그램 디렉토리 (웹 응용 프로그램을 포함하는 파일 구조) 파일이 포함될 수 있습니다. XML 구성 파일은 xmlBase 에서 지정한 디렉토리에 있고 WAR 패키지 및 응용 프로그램 디렉토리는 appBase 에서 지정한 디렉토리에 있습니다.
Tomcat 은 다음 순서로 스캔하여 어플리케이션 업데이트를 확인합니다.
A. 가상 호스트에 지정된 XMLBase 에서 XML 구성 파일을 검색합니다.
B. 가상 호스트에 지정된 appBase 에서 WAR 파일을 검색합니다.
C. 가상 호스트에 지정된 appBase 아래의 응용 프로그램 디렉토리를 검색합니다.
요소의 구성입니다
Context 요소의 가장 중요한 속성은 docBase 와 path 이며 reloadable 속성도 자주 사용됩니다.
DocBase 는 웹 응용 프로그램에서 사용하는 WAR 패키지의 경로나 응용 프로그램 디렉토리를 지정합니다. 자동 배포 시나리오 (프로파일은 xmlBase 에 있음) 에서는 문서 데이터베이스가 appBase 디렉토리에 없으므로 지정해야 합니다. 문서 데이터베이스에 지정된 WAR 패키지 또는 응용 프로그램 디렉토리가 문서 데이터베이스에 있는 경우 지정할 필요가 없습니다. Tomcat 은 docBase 에서 WAR 패키지 및 응용 프로그램 디렉토리를 자동으로 검색하지만 지정에 문제가 있기 때문입니다.
Path 는 웹 응용 프로그램에 액세스하는 데 사용되는 컨텍스트 경로를 지정합니다. 요청이 도착하면 Tomcat 은 웹 응용 프로그램의 path 속성이 URI 와 일치하는 정도에 따라 웹 응용 프로그램을 선택하여 해당 요청을 처리합니다. 예를 들어 웹 응용 프로그램 app 1 의 path 속성이 "/app 1" 이고 웹 응용 프로그램 app2 의 path 속성이 "/app2" 인 경우/app/를 요청합니다 요청 /app2/index.html 은 app2 에 의해 처리됩니다. Context 요소의 path 속성이 \ "\" 인 경우 이 컨텍스트는 가상 호스트의 기본 웹 응용 프로그램입니다. 요청된 uri 가 모든 경로와 일치하지 않으면 기본 웹 응용 프로그램을 사용하여 처리됩니다.
그러나 자동 배포 장면 (프로파일은 XML 베이스에 있음) 에서는 path 속성을 지정할 수 없습니다. path 속성은 프로파일의 파일 이름, WAR 파일의 파일 이름 또는 응용 프로그램 디렉토리의 이름에서 자동으로 파생됩니다. XmlBase 디렉토리에서 app 1.xml 또는 app 1 을 찾은 경우. AppBase 디렉토리의 WAR 또는 app 1 application directory 가 웹 응용 프로그램을 검색하는 경우 웹 응용 프로그램의 path 등록 정보는' app 1' 입니다. 이름이 app 1 이 아닌 ROOT 인 경우 웹 응용 프로그램은 가상 호스트에 대한 기본 웹 응용 프로그램이며 path 속성은 ""로 파생됩니다.
Reloadable 속성은 Tomcat 이 런타임 시 WEB-INF/classes 및 WEB-INF/lib 디렉토리에 있는 클래스 파일의 변경 사항을 모니터링할지 여부를 나타냅니다. True 로 설정하면 클래스 파일이 변경될 때 웹 응용 프로그램 재로드가 트리거됩니다. 개발 환경에서 디버깅을 용이하게 하기 위해 reloadable 을 true 로 설정합니다. 그러나 프로덕션 환경에서 true 로 설정하면 서버에 성능 스트레스가 발생하므로 reloadable 매개 변수의 기본값은 false 입니다.
자동 배포 시 XMLBase 아래에 있는 XML 구성 파일 app 1.xml 의 예를 살펴보겠습니다.
이 경우 docBase 는 호스트의 appBase 디렉토리 외부에 있습니다. Path 속성이 지정되지 않았지만 app 1.xml 에 따라 "app1"으로 자동 도출됩니다. 개발 환경이기 때문에 true 로 설정되어 있어 개발 디버깅이 편리하다.
자동 배포의 예
가장 일반적인 자동 배포는 Tomcat 을 설치한 후 $ Tomcat _ home/webapps 디렉토리에 다음 폴더가 있는 것입니다.
Tomcat 을 시작할 때 STAT-AON | Findstr "808 1 "을 사용하여 포트 808 1 이 PID 가 2064 인 프로세스, tasklist 에 의해 점유된다는 것을 알 수 있습니다
(3) 서비스 및 엔진의 이름 속성을 수정합니다.
(4) 호스트의 appBase 등록 정보 (예: webapps2) 를 수정합니다.
(5) 웹 애플리케이션은 여전히 자동 배포를 사용합니다.
(6) 웹 응용 프로그램 (WAR 패키지 또는 응용 프로그램 디렉토리) 을 새 appBase 에 복사합니다.
첫 번째 섹션의 server.xml 을 예로 들면 다중 서비스는 다음과 같이 구성됩니다.
Http://localhost:8080/docs/
Http://localhost:8084/docs/
동사 (verb 의 약어) 기타 구성 요소
핵심 구성 요소 외에도 server.xml 에서 여러 가지 다른 구성 요소를 구성할 수 있습니다. 자세한 내용은 Tomcat 공식 문서를 참조하십시오.
1, 리스너
특정 이벤트가 발생할 때 특정 작업을 수행할 수 있는 리스너 정의 구성 요소입니다. 모니터링되는 이벤트는 일반적으로 Tomcat 의 시작 및 중지입니다.
리스너는 서버, 엔진, 호스트 또는 컨텍스트에 있을 수 있습니다. 이 경우 리스너는 서버에 있습니다. 실제로 이 예제에 정의된 6 개의 리스너는 서버 구성 요소에만 존재할 수 있습니다. 리스너가 다른 구성 요소에 포함될 수 없습니다.
리스너가 구성해야 하는 가장 중요한 속성은 className 입니다. classname 은 org 인터페이스를 구현해야 하는 리스너의 특정 구현 클래스를 지정합니다. 아파치. 수명 주기 리스너.
다음은 예제에 구성된 리스너에 대한 설명입니다.
VersionLoggerListener: 이 리스너는 Tomcat 이 시작될 때 Tomcat, Java 및 운영 체제에 대한 정보를 기록합니다. 이 리스너는 구성의 첫 번째 리스너여야 합니다.
AprlifecycleListener: Tomcat 이 시작될 때 APR 라이브러리를 확인하고 있는 경우 로드합니다. APR, Apache portable runtime, Apache Portable Runtime 은 뛰어난 확장성, 성능 및 로컬 서버 기술과의 통합을 가능하게 하는 Apache portable runtime 입니다.
JasperListener: 웹 응용 프로그램이 시작되기 전에 Jasper 를 초기화합니다. Jasper 는 JVM 에서 알 수 없는 JSP 파일을 Java 파일로 구문 분석하고 JVM 에서 사용할 수 있도록 클래스 파일로 컴파일하는 JSP 엔진입니다.
Jrememoryleakpreventionlistener: 클래스 로더로 인한 메모리 누수와 관련이 있습니다.
이 리스너를 통해 초기화하십시오.
Threadlocaleakrevelationlistener: 이 리스너는 thread-local 로 인한 메모리 누수로 웹 응용 프로그램이 중지되면 스레드 풀의 스레드 업데이트를 트리거합니다. 작업이 실행된 후 스레드가 스레드 풀에서 회수되면 활성 스레드가 하나씩 업데이트됩니다. 리스너는 웹 응용 프로그램, 즉 컨텍스트 요소의 속성이 true 로 설정된 경우에만 유효합니다.
2. 글로벌 명명 자원 및 영역
예제의 첫 번째 부분에서는 영역 구성 요소가 엔진 구성 요소 아래에 정의됩니다.
영역은 "도메인" 으로 이해 될 수 있습니다. Realm 은 사용자 암호와 웹 응용 프로그램 간의 매핑 관계를 제공하여 역할 보안 관리의 역할을 수행합니다. 이 예에서는 자원 이름 UserDatabase 를 사용하여 Realm 을 구성했습니다. 또한 GlobalNamingResources 를 사용하여 서버 요소에 자원을 구성합니다.
GlobalNamingResources 요소는 글로벌 자원을 정의하며, 구성에서 볼 수 있듯이 구성은 $ Tomcat _ home/conf/Tomcat-users.xml 을 읽어 수행됩니다.
Tomcat 도메인 관리에 대한 자세한 내용은 영역 도메인 관리를 참조하십시오.
3, 밸브
첫 번째 부분의 예에서 밸브 구성요소는 호스트 요소에 정의됩니다.
Valve 라는 단어는 "밸브" 를 의미하며, Tomcat 에서 파이프 처리를 요청하는 구성 요소를 나타냅니다. 밸브는 Tomcat 컨테이너 (엔진, 호스트 또는 컨텍스트) 와 연관될 수 있습니다.
밸브마다 특성이 다르다. 이 예제에 나타난 AccessLogValve 를 소개하겠습니다.
AccessLogValve 는 상주하는 컨테이너에서 처리된 모든 요청을 로깅하는 데 사용됩니다. 이 경우 밸브를 호스트 아래에 놓고 호스트가 처리하는 모든 요청을 기록할 수 있습니다. AccessLogValve 에 기록된 로그는 액세스 로그이며, 매일 요청이 로그 파일에 기록됩니다. 입구 밸브는 엔진과 연관될 수 있습니다. 호스트 또는 컨텍스트 이 예에서는 엔진이 하나만 있고, 엔진 아래에는 호스트가 하나만 있고, 호스트 아래에는 하나의 컨텍스트만 있습니다. 그래서 세 개의 용기 아래에 있는 AccessLogValve 의 기능은 사실 비슷하다.
이 예에서 AccessLogValve 등록 정보 구성은 기본 구성을 사용합니다. 다음은 AccessLogValve 의 각 등록 정보 기능에 대한 설명입니다.
(1)className: 밸브 유형을 지정합니다. 가장 중요한 속성입니다. 이 예에서 이 속성은 AccessLogValve 임을 지정합니다.
(2) 디렉토리: 로그가 저장되는 위치를 지정합니다. 이 경우 로그는 $ ＄TOMCAT _ HOME/logs 디렉토리에 저장됩니다.
(3) 접두어: 로그 파일의 접두어를 지정합니다.
(4) 접미어: 로그 파일의 접미어를 지정합니다. 디렉토리, 접두어 및 접미어 구성을 통해 $TOMCAT_HOME/logs 디렉토리에서 다음과 같은 로그 파일을 볼 수 있습니다.
(5) 모드: 로그의 형식을 지정합니다. 이 예에서 각 항목의 의미는 다음과 같습니다.
%h: 원격 호스트 이름 또는 IP 주소 ： Nginx 와 같은 역방향 프록시 서버가 배포를 요청하는 경우 호스트 이름 /IP 주소는 nginx 를 나타내고, 그렇지 않은 경우 클라이언트를 나타냅니다. 원격의 의미도 비슷해서 더 이상 설명하지 않는다.
%l: 원격 논리 사용자 이름, 항상'-'입니다. 무시할 수 있습니다.
%u: 승인된 원격 사용자 이름, 그렇지 않으면'-'입니다.
%t: 방문 시간.
%r: 요청의 첫 번째 줄, 요청 메서드 (get/post 등). ), uri 및 프로토콜.
%s: 응답 상태, 200, 404 등.
%b: 응답한 데이터의 양 (요청 헤더 제외). 0 이면 "-"입니다.
예를 들어, 다음은 액세스 로그의 레코드입니다.
Pattern 구성에서는 위의 몇 가지 옵션 외에도 요청 처리 시간 (밀리초) 을 나타내는 매우 일반적인 옵션 %D 가 있어 통계 분석 요청 처리 속도에 도움이 됩니다.
개발자는 액세스 로그를 최대한 활용하여 문제를 분석하고 응용 프로그램을 최적화할 수 있습니다. 예를 들어, 액세스 로그의 각 인터페이스에 대한 액세스 비율을 분석하면 요구 사항 및 운영자에게 데이터 지원을 제공할 뿐만 아니라 자체 최적화를 목표로 할 수 있습니다. 액세스 로그의 각 요청에 대한 응답 상태 코드를 분석하여 서버 요청의 성공률을 파악하고 문제가 있는 요청을 파악할 수 있습니다. 액세스 로그의 각 요청에 대한 응답 시간을 분석하여 느린 요청을 식별하고 필요에 따라 응답 시간을 최적화할 수 있습니다.