15장. JBoss EAP에서 웹 서버(Undertow) 구성
이 장에서는 JBoss EAP에 내장된 기본 서버인 Cryostat 웹 서버 구성에 대해 중점적으로 설명합니다. 여기에서 보안 통신을 위해 SSL/TLS 활성화, 향상된 성능을 위해 HTTP/2 활용, 운영 요구 사항에 맞게 서버 설정을 미세 조정하는 방법에 대한 자세한 지침을 확인할 수 있습니다.
15.1. Cryostat 하위 시스템 개요 링크 복사링크가 클립보드에 복사되었습니다!
JBoss EAP 8.1에서 Cryostat 하위 시스템은 애플리케이션 서버 내의 웹 계층 역할을 합니다. 핵심 웹 서버 및 서블릿 컨테이너 기능을 제공하여 Jakarta Servlet 6.0 사양, websockets 및 HTTP 업그레이드와 같은 고급 기능을 지원합니다. 또한 Cryostat는 mod_cluster 지원을 통해 고성능 역방향 프록시 역할을 하여 웹 트래픽 처리의 확장성, 효율성 및 유연성을 향상시킵니다.
undertow 하위 시스템을 사용하면 웹 서버 및 서블릿 컨테이너 설정을 구성할 수 있습니다. Jakarta Servlet 6.0 사양 과 웹 소켓을 구현합니다. 또한 HTTP 업그레이드 및 서블릿 배포에서 고성능 비차단 처리기 사용을 지원합니다. undertow 하위 시스템에는 mod_cluster를 지원하는 고성능 역방향 프록시 역할을 할 수 있습니다.
undertow 하위 시스템 내에는 다음과 같은 5가지 기본 구성 요소가 있습니다.
- 버퍼 캐시
- 서버
- 서블릿 컨테이너
- 처리기
- 필터
JBoss EAP는 이러한 각 구성 요소에 대한 구성을 업데이트하는 기능을 제공하지만 기본 구성은 대부분의 사용 사례에 적합하며 적절한 성능 설정을 제공합니다.
15.1.1. 기본 undertow 하위 시스템 구성 링크 복사링크가 클립보드에 복사되었습니다!
<subsystem xmlns="{UndertowSubsystemNamespace}" default-server="default-server" default-virtual-host="default-host" default-servlet-container="default" default-security-domain="other">
<buffer-cache name="default"/>
<server name="default-server">
<http-listener name="default" socket-binding="http" redirect-socket="https" enable-http2="true"/>
<https-listener name="https" socket-binding="https" security-realm="ApplicationRealm" enable-http2="true"/>
<host name="default-host" alias="localhost">
<location name="/" handler="welcome-content"/>
<http-invoker security-realm="ApplicationRealm"/>
</host>
</server>
<servlet-container name="default">
<jsp-config/>
<websockets/>
</servlet-container>
<handlers>
<file name="welcome-content" path="${jboss.home.dir}/welcome-content"/>
</handlers>
</subsystem>
undertow 하위 시스템은 io 하위 시스템을 사용하여 XNIO 작업자 및 버퍼 풀을 제공합니다. io 하위 시스템은 별도로 구성되며 대부분의 경우 최적의 성능을 제공해야 하는 기본 구성을 제공합니다.
15.1.2. undertow 하위 시스템에서 Elytron 사용 링크 복사링크가 클립보드에 복사되었습니다!
웹 애플리케이션이 배포되면 해당 애플리케이션에 필요한 보안 도메인의 이름이 식별됩니다. 이는 배포 내에서 또는 배포에 보안 도메인이 없는 경우 undertow 하위 시스템에 정의된 대로 default-security-domain 으로 가정합니다. 기본적으로 default-security-domain 은 ApplicationDomain 입니다. 애플리케이션에 필요한 보안 도메인 이름에서 적절한 Elytron 구성으로의 매핑을 보장하기 위해 application-security-domain 리소스를 undertow 하위 시스템에 추가할 수 있습니다.
예: 매핑 추가
/subsystem=undertow/application-security-domain=ApplicationDomain:add(security-domain=ApplicationDomain)
결과가 표시되면 매핑이 성공적으로 추가됩니다.
<subsystem xmlns="{UndertowSubsystemNamespace}" ... default-security-domain="other">
...
<application-security-domains>
<application-security-domain name="ApplicationDomain" security-domain="ApplicationDomain"/>
</application-security-domains>
...
</subsystem>
- 이 시점에 배포를 이미 배포한 경우 애플리케이션 보안 도메인 매핑을 적용하려면 애플리케이션 서버를 다시 로드해야 합니다.
- 현재 웹 서비스-Elytron 통합에서는 웹 서비스 엔드포인트를 보호하기 위해 지정된 보안 도메인의 이름이 동일해야 하며 Elytron 보안 도메인 이름은 동일해야 합니다.
이 간단한 형식은 배포가 BASIC,CLIENT_CERT, hieradataGEST,FORM 과 같은 서블릿 사양에 정의된 표준 HTTP 메커니즘을 사용하는 경우에 적합합니다. 여기에서 인증은 ApplicationDomain 보안 도메인에 대해 수행됩니다. 이 양식은 애플리케이션에서 인증 메커니즘을 사용하지 않고 프로그래밍 방식으로 인증을 사용하거나 배포와 연결된 SecurityDomain 을 직접 가져오려는 경우에도 적합합니다.
예: 매핑의 고급 양식
/subsystem=undertow/application-security-domain=MyAppSecurity:add(http-authentication-factory=application-http-authentication)
결과가 표시되면 고급 매핑이 성공합니다.
<subsystem xmlns="{UndertowSubsystemNamespace}" ... default-security-domain="other">
...
<application-security-domains>
<application-security-domain name="MyAppSecurity" http-authentication-factory="application-http-authentication"/>
</application-security-domains>
...
</subsystem>
이 형태의 구성에서는 보안 도메인을 참조하는 대신 http-authentication-factory 를 참조합니다. 이는 인증 메커니즘의 인스턴스를 가져오는 데 사용할 팩토리이며 보안 도메인과 연결됩니다.
사용자 정의 HTTP 인증 메커니즘을 사용하거나 주요 변환기, 인증 정보 팩토리 및 메커니즘 영역과 같은 메커니즘에 대해 추가 구성을 정의해야 하는 경우 http-authentication-factory 속성을 참조해야 합니다. 또한 서블릿 사양에 설명된 4개 이외의 메커니즘을 사용할 때 http-authentication-factory 특성을 참조하는 것이 좋습니다.
고급 매핑 형식이 사용되는 경우 다른 구성 옵션을 사용할 수 있습니다. override-deployment-config. 참조된 http-authentication-factory 는 전체 인증 메커니즘 세트를 반환할 수 있습니다. 기본적으로 이러한 항목은 애플리케이션에서 요청한 메커니즘과 일치하도록 필터링됩니다. 이 옵션이 true 로 설정된 경우 팩토리에서 제공하는 메커니즘은 애플리케이션에서 요청한 메커니즘을 재정의합니다.
application-security-domain 리소스에는 하나의 추가 옵션 enable-jacc 도 있습니다. 이 값이 true 로 설정되면 이 매핑과 일치하는 배포에 대해 Java Authorization Contract for Containers가 활성화됩니다.
15.1.2.1. 런타임 정보 링크 복사링크가 클립보드에 복사되었습니다!
application-security-domain 매핑이 사용 중인 경우 배포가 예상대로 일치하는지 확인하는 것이 유용할 수 있습니다. include-runtime=true 를 사용하여 리소스를 읽는 경우 매핑과 연결된 배포도 다음과 같이 표시됩니다.
/subsystem=undertow/application-security-domain=MyAppSecurity:read-resource(include-runtime=true)
{
"outcome" => "success",
"result" => {
"enable-jacc" => false,
"http-authentication-factory" => undefined,
"override-deployment-config" => false,
"referencing-deployments" => ["simple-webapp.war"],
"security-domain" => "ApplicationDomain",
"setting" => undefined
}
}
이 출력에서 referencing-deployments 속성은 매핑을 사용하여 배포 simple-webapp.war 가 배포되었음을 보여줍니다.
15.1.3. 버퍼 캐시 구성 링크 복사링크가 클립보드에 복사되었습니다!
이 절차에서는 정적 리소스를 캐시하여 성능을 개선하는 데 도움이 되는 JBoss EAP에서 버퍼 캐시를 구성하는 방법을 안내합니다. 다른 배포에서는 다른 캐시 크기를 사용하여 리소스 관리를 최적화할 수 있습니다. 사용된 총 공간 크기는 버퍼 크기와 영역당 버퍼 수와 최대 영역 수를 곱하여 계산할 수 있습니다. 버퍼 캐시의 기본 크기는 10MB입니다.
JBoss EAP는 기본적으로 단일 캐시를 제공합니다.
<subsystem xmlns="{UndertowSubsystemNamespace}" default-server="default-server" default-virtual-host="default-host" default-servlet-container="default" default-security-domain="other">
<buffer-cache name="default"/>
...
</subsystem>
사전 요구 사항
- JBoss EAP가 설치되어 있고 관리 CLI에 대한 관리 액세스 권한이 있는지 확인합니다.
프로세스
기존 버퍼 캐시를 업데이트합니다.
버퍼 크기 특성을 수정합니다.
/subsystem=undertow/buffer-cache=default/:write-attribute(name=buffer-size,value=2048)reload
새 버퍼 캐시를 생성합니다.
새 버퍼 캐시를 추가합니다.
/subsystem=undertow/buffer-cache=new-buffer:add
버퍼 캐시를 삭제합니다.
기존 버퍼 캐시를 제거합니다.
/subsystem=undertow/buffer-cache=new-buffer:removereload
15.1.4. 바이트 버퍼 풀 구성 링크 복사링크가 클립보드에 복사되었습니다!
Cryostat 바이트 버퍼 풀은 풀링된 NIO Cryostat Buffer 인스턴스를 할당하는 데 사용됩니다. 모든 리스너에는 바이트 버퍼 풀이 있으며 각 리스너에 서로 다른 버퍼 풀과 작업자를 사용할 수 있습니다. 바이트 버퍼 풀은 서로 다른 서버 인스턴스 간에 공유할 수 있습니다.
이러한 버퍼는 IO 작업에 사용되며 버퍼 크기는 애플리케이션 성능에 큰 영향을 미칩니다. 대부분의 서버에서 이상적인 크기는 일반적으로 16k입니다.
사전 요구 사항
- JBoss EAP가 설치되어 있고 관리 CLI에 대한 관리 액세스 권한이 있는지 확인합니다.
프로세스
기존의 버퍼 풀을 업데이트합니다.
버퍼 크기 특성을 수정합니다.
/subsystem=undertow/byte-buffer-pool=myByteBufferPool:write-attribute(name=buffer-size,value=1024)reload
새 Cryostat 버퍼 풀을 만듭니다.
새 바이트 버퍼 풀을 추가합니다.
/subsystem=undertow/byte-buffer-pool=newByteBufferPool:add
Cryostat 버퍼 풀을 삭제합니다.
기존 바이트 버퍼 풀을 제거합니다.
/subsystem=undertow/byte-buffer-pool=newByteBufferPool:removereload
검증
- 관리 콘솔에서 버퍼 풀 설정을 확인하여 변경 사항을 확인합니다.
추가 리소스
- 바이트 버퍼 풀에 대한 자세한 속성은 Cryostat 버퍼 풀 속성 섹션을 참조하십시오.
15.1.5. undertow에서 서버 구성 이해 링크 복사링크가 클립보드에 복사되었습니다!
서버는 Cryostat의 인스턴스를 나타내며 다음과 같은 여러 요소로 구성됩니다.
-
host -
http-listener -
https-listener -
ajp-listener
host 요소는 가상 호스트 구성을 제공하는 반면 3개의 리스너는 해당 유형의 연결을 Cryostat 인스턴스에 제공합니다.
서버의 기본 동작은 서버가 시작되는 동안 요청을 대기열에 추가하는 것입니다. 호스트의 queue-requests-on-start 특성을 사용하여 이 기본 동작을 변경할 수 있습니다. 이 속성이 true (기본값)로 설정된 경우 서버를 시작할 때 도달하는 요청이 서버가 준비될 때까지 유지됩니다. 이 속성이 false 로 설정된 경우 서버가 완전히 시작되기 전에 도착한 요청은 기본 응답 코드로 거부됩니다.
특성 값에 관계없이 서버가 완전히 시작될 때까지 요청 처리가 시작되지 않습니다.
구성 queue-requests-on-start 속성을 구성할 수 있습니다. 관리형 도메인의 경우 구성할 프로필을 지정해야 합니다.
배포 및 서버를 완전히 분리할 수 있도록 여러 서버를 구성할 수 있습니다. 이는 다중 테넌트 환경과 같은 특정 시나리오에서 유용할 수 있습니다.
JBoss EAP는 기본적으로 서버를 제공합니다.
15.1.6. 기본 undertow 하위 시스템 구성 링크 복사링크가 클립보드에 복사되었습니다!
이 참조는 Cryostat 하위 시스템의 기본 구성을 제공합니다.
<subsystem xmlns="{UndertowSubsystemNamespace}" default-server="default-server" default-virtual-host="default-host" default-servlet-container="default" default-security-domain="other">
<buffer-cache name="default"/>
<server name="default-server">
<http-listener name="default" socket-binding="http" redirect-socket="https" enable-http2="true"/>
<https-listener name="https" socket-binding="https" security-realm="ApplicationRealm" enable-http2="true"/>
<host name="default-host" alias="localhost">
<location name="/" handler="welcome-content"/>
<http-invoker security-realm="ApplicationRealm"/>
</host>
</server>
...
</subsystem>
15.1.7. 관리 CLI를 사용하여 서버 구성 링크 복사링크가 클립보드에 복사되었습니다!
다음 절차에서는 관리 CLI를 사용하여 Cryostat 하위 시스템에서 서버를 관리하는 방법을 설명합니다. 필요에 따라 기존 서버를 업데이트하거나 새 서버를 생성하거나 서버를 삭제할 수 있습니다.
구성
사전 요구 사항
- 관리 CLI에 액세스할 수 있습니다.
- 서버 구성을 수정할 수 있는 권한이 있습니다.
프로세스
기존 서버 업데이트
/subsystem=undertow/server=default-server:write-attribute(name=default-host,value=default-host)reload새 서버 만들기
/subsystem=undertow/server=new-server:addreload서버 삭제
/subsystem=undertow/server=new-server:removereload
15.1.8. 액세스 로깅 링크 복사링크가 클립보드에 복사되었습니다!
정의한 각 호스트에서 액세스 로깅을 구성할 수 있습니다.
표준 액세스 로깅 및 콘솔 액세스 로깅의 두 가지 액세스 로깅 옵션을 사용할 수 있습니다.
액세스 로깅에 필요한 추가 처리는 시스템 성능에 영향을 미칠 수 있습니다.
15.1.8.1. 표준 액세스 로깅 링크 복사링크가 클립보드에 복사되었습니다!
표준 액세스 로깅은 로그 항목을 로그 파일에 작성합니다.
기본적으로 로그 파일은 standalone/log/access_log.log 디렉터리에 저장됩니다.
표준 액세스 로깅을 활성화하려면 액세스 로그 데이터를 캡처할 호스트에 access-log 설정을 추가합니다. 다음 CLI 명령은 기본 JBoss EAP 서버의 기본 호스트의 구성을 보여줍니다.
/subsystem=undertow/server=default-server/host=default-host/setting=access-log:add
표준 액세스 로깅을 활성화한 후 서버를 다시 로드해야 합니다.
기본적으로 액세스 로그 레코드에는 다음 데이터가 포함됩니다.
- 원격 호스트 이름
- 원격 논리 사용자 이름(항상 -)
- 인증된 원격 사용자
- 요청의 날짜 및 시간 (Common Log Format)
- 요청의 첫 번째 줄
- 응답의 HTTP 상태 코드
- HTTP 헤더를 제외하고 전송된 바이트 수
이 데이터 세트는 공통 패턴으로 정의됩니다. 다른 패턴( combined)도 사용할 수 있습니다. 공통 패턴에 기록된 데이터 외에도 결합된 패턴에는 들어오는 헤더의 참조자 및 사용자 에이전트가 포함됩니다.
pattern 특성을 사용하여 기록된 데이터를 변경할 수 있습니다. 다음 CLI 명령은 결합된 패턴을 사용하도록 pattern 특성을 업데이트하는 방법을 보여줍니다.
/subsystem=undertow/server=default-server/host=default-host/setting=access-log:write-attribute(name=pattern,value="combined"
pattern 속성을 업데이트한 후 서버를 다시 로드해야 합니다.
| 패턴 | 설명 |
|---|---|
| %a | 원격 IP 주소 |
| %A | 로컬 IP 주소 |
| %b |
HTTP 헤더를 제외하고 전송된 바이트 또는 바이트가 없는 경우 |
| %B | HTTP 헤더를 제외하고 전송된 바이트 |
| %h | 원격 호스트 이름 |
| %H | 요청 프로토콜 |
| %l |
|
| %m | 요청 방법 |
| %p | 로컬 포트 |
| %q |
쿼리 문자열 ( |
| %r | 요청의 첫 번째 줄 |
| %s | 응답의 HTTP 상태 코드 |
| %t | 날짜 및 시간, 일반적인 로그 형식의 형식 |
| %u | 인증된 원격 사용자 |
| %U | 요청된 URL 경로 |
| %v | 로컬 서버 이름 |
| %D | 요청을 처리하는 데 걸린 시간(밀리초) |
| %T | 요청을 처리하는 데 걸린 시간(초) |
| %I | 현재 요청 스레드 이름(나중에 스택 추적과 비교 가능) |
| 공통 |
|
| combined |
|
쿠키, 들어오는 헤더 및 응답 헤더 또는 세션에서 정보를 작성할 수도 있습니다. 구문은 Apache 구문 후에 모델링됩니다.
-
%{I,xxx}들어오는 헤더의 경우 -
%{O,xxx}발신 응답 헤더의 경우 -
%{C,xxx}특정 쿠키의 경우 -
%{R,xxx}여기서xxx는ServletRequest의 속성입니다. -
%{s,xxx}여기서xxx는 CryostatSession의 속성입니다.
이 로그에 추가 구성 옵션을 사용할 수 있습니다. 자세한 내용은 부록의 "access-log Attributes"를 참조하십시오.
15.1.8.2. 콘솔 액세스 로깅 링크 복사링크가 클립보드에 복사되었습니다!
콘솔 액세스 로깅은 JSON 데이터로 구성된 stdout에 데이터를 씁니다.
각 액세스 로그 레코드는 단일 데이터 행입니다. 로그 집계 시스템에서 처리하기 위해 이 데이터를 캡처할 수 있습니다.
콘솔 액세스 로깅을 구성하려면 로그 데이터를 캡처할 호스트에 console-access-log 설정을 추가합니다. 다음 CLI 명령은 기본 JBoss EAP 서버의 기본 호스트의 구성을 보여줍니다.
/subsystem=undertow/server=default-server/host=default-host/setting=console-access-log:add
기본적으로 콘솔 액세스 로그 레코드에는 다음 데이터가 포함됩니다.
| 로그 데이터 필드 이름 | 설명 |
|---|---|
| eventSource | 요청의 이벤트 소스 |
| hostName | 요청을 처리하는 JBoss EAP 호스트 |
| bytesSent | 요청에 대한 응답으로 전송된 JBoss EAP 서버의 바이트 수 |
| dateTime | JBoss EAP 서버에서 요청을 처리한 날짜 및 시간 |
| remoteHost | 요청이 시작된 시스템의 IP 주소입니다. |
| remoteUser | 원격 요청과 연결된 사용자 이름 |
| requestLine | 요청 제출 |
| responseCode | JBoss EAP 서버에서 반환한 HTTP 응답 코드 |
기본 속성은 항상 로그 출력에 포함됩니다. attributes 속성을 사용하여 기본 로그 데이터의 레이블을 변경하고 경우에 따라 데이터 구성을 변경할 수 있습니다. attributes 속성을 사용하여 출력에 로그 데이터를 추가할 수도 있습니다.
| 로그 데이터 필드 이름 | 설명 | 형식 |
|---|---|---|
| authentication-type | 요청과 연결된 사용자를 인증하는 데 사용되는 인증 유형입니다. 기본 레이블: authenticationType 키 옵션을 사용하여 이 속성의 레이블을 변경합니다. | authentication-type{} authentication-type={key="authType"} |
| bytes-sent | HTTP 헤더를 제외하고 요청에 반환되는 바이트 수입니다. 기본 레이블: bytesSent 키 옵션을 사용하여 이 속성의 레이블을 변경합니다. | bytes-sent={} bytes-sent={key="sent-bytes"} |
| date-time | 요청이 수신 및 처리된 날짜 및 시간입니다. 기본 레이블: dateTime 키 옵션을 사용하여 이 속성의 레이블을 변경합니다. date-format을 사용하여 날짜 시간 레코드를 포맷하는 데 사용되는 패턴을 정의합니다. 패턴은 Java SimpleDateFormatter 패턴이어야 합니다. date-format 옵션이 정의된 경우 time-zone 옵션을 사용하여 날짜 및/또는 시간 데이터를 포맷하는 데 사용되는 시간대를 지정합니다. 이 값은 유효한 java.util.TimeZone이어야 합니다. | date-time={key="<keyname>", date-format="<date-time format>"} date-time="@timestamp", date-format="yyyy-MM-dd'T'HH:mm:sSSS"} |
| host-and-port | 요청에서 쿼리한 호스트 및 포트입니다. Default label: hostAndPort key 옵션을 사용하여 이 속성의 레이블을 변경합니다. | host-and-port{} host-and-port={key="port-host"} |
| local-ip | 로컬 연결의 IP 주소입니다. 키 옵션을 사용하여 이 속성의 레이블을 변경합니다. 기본 레이블: localIp 키 옵션을 사용하여 이 속성의 레이블을 변경합니다. | local-ip{} local-ip{key=”localIP”} |
| local-port | 로컬 연결의 포트입니다. Default label: localPort key 옵션을 사용하여 이 속성의 레이블을 변경합니다. | local-port{} local-port{key=”LocalPort”} |
| local-server-name | 요청을 처리하는 로컬 서버의 이름입니다. 기본 레이블: localServerName 키 옵션을 사용하여 이 속성의 레이블을 변경합니다. | local-server-name {} local-server-name {key=LocalServerName} |
| path-parameter | 요청에 포함된 하나 이상의 경로 또는 URI 매개변수입니다. names 속성은 교환 값을 확인하는 데 사용되는 쉼표로 구분된 이름 목록입니다. key-prefix 속성을 사용하여 키를 고유하게 만듭니다. key-prefix가 지정되면 출력의 각 path 매개변수 이름에 접두사가 추가됩니다. | path-parameter{names={store,section}} path-parameter{names={store,section}, key-prefix=”my-”} |
| predicate | 서술자 컨텍스트의 이름입니다. names 속성은 교환 값을 확인하는 데 사용되는 쉼표로 구분된 이름 목록입니다. key-prefix 속성을 사용하여 키를 고유하게 만듭니다. key-prefix가 지정되면 출력의 각 path 매개변수 이름에 접두사가 추가됩니다. | predicate{names={store,section}} 서술자{names={store,section}, key-prefix="my-"} |
| query-parameter | 요청에 포함된 하나 또는 쿼리 매개변수입니다. names 속성은 교환 값을 확인하는 데 사용되는 쉼표로 구분된 이름 목록입니다. key-prefix 속성을 사용하여 키를 고유하게 만듭니다. key-prefix가 지정되면 출력의 각 path 매개변수 이름에 접두사가 추가됩니다. | query-parameter{names={store,section}} query-parameter{names={store,section}, key-prefix=”my-”} |
| 쿼리 문자열 | 요청의 쿼리 문자열입니다. Default label: queryString key 옵션을 사용하여 이 속성의 레이블을 변경합니다. include-question-mark 속성을 사용하여 쿼리 문자열에 물음표를 포함해야 하는지 여부를 지정합니다. 기본적으로 물음표는 포함되지 않습니다. | query-string{} query-string{key=”QueryString”, include-question-mark=”true”} |
| relative-path | 요청의 상대 경로입니다. 기본 레이블: relativePath 키 옵션을 사용하여 이 속성의 레이블을 변경합니다. | relative-path{} relative-path{key=”RelativePath”} |
| remote-host | 원격 호스트 이름입니다. 기본 레이블: remoteHost 키 옵션을 사용하여 이 속성의 레이블을 변경합니다. | remote-host{} remote-host{key=”RemoteHost”} |
| remote-ip | 원격 IP 주소입니다. 기본 레이블: remoteIp 키 옵션을 사용하여 이 속성의 레이블을 변경합니다. 난독 처리된 속성을 사용하여 출력 로그 레코드의 IP 주소를 난독화합니다. 기본값은 false입니다. | remote-ip{} remote-ip{key=”RemoteIP”, obfuscated=”true”} |
| remote-user | 인증된 원격 사용자입니다. 기본 레이블: remoteUser 키 옵션을 사용하여 이 속성의 레이블을 변경합니다. | remote-user{} remote-user{key=”RemoteUser”} |
| request-header | 요청 헤더의 이름입니다. 구조화된 데이터의 키는 헤더의 이름입니다. 값은 이름이 지정된 헤더의 값입니다. names 속성은 교환 값을 확인하는 데 사용되는 쉼표로 구분된 이름 목록입니다. key-prefix 속성을 사용하여 키를 고유하게 만듭니다. 키 접두사가 지정된 경우 로그 출력의 요청 헤더 이름에 접두사가 추가됩니다. | request-header{names={store,section}} request-header{names={store,section}, key-prefix=”my-”} |
| request-line | 요청 행입니다. 기본 레이블: requestLine 키 옵션을 사용하여 이 속성의 레이블을 변경합니다. | request-line{} request-line{key=”Request-Line”} |
| request-method | 요청 방법입니다. 기본 레이블: requestMethod 키 옵션을 사용하여 이 속성의 레이블을 변경합니다. | request-method{} request-method{key=”RequestMethod”} |
| request-path | 요청의 상대 경로입니다. 기본 label: requestPath 키 옵션을 사용하여 이 속성의 레이블을 변경합니다. | request-path{} request-path{key=”RequestPath”} |
| request-protocol | 요청에 대한 프로토콜입니다. 기본 레이블: requestProtocol 키 옵션을 사용하여 이 속성의 레이블을 변경합니다. | request-protocol{} request-protocol{key=”RequestProtocol”} |
| request-scheme | 요청의 URI 스키마입니다. 기본 레이블: requestScheme 키 옵션을 사용하여 이 속성의 레이블을 변경합니다. | request-scheme{} request-scheme{key=”RequestScheme”} |
| request-url | 원래 요청 URI입니다. 클라이언트에서 지정한 경우 호스트 이름, 프로토콜 등을 포함합니다. Default label: requestUrl 키 옵션을 사용하여 이 속성의 레이블을 변경합니다. | request-url{} request-url{key=”RequestURL”} |
| resolved-path | 해결된 경로입니다. Default Label: resolvedPath key 옵션을 사용하여 이 속성의 레이블을 변경합니다. | resolved-path{} resolved-path{key=”ResolvedPath”} |
| response-code | 응답 코드입니다. 기본 레이블: responseCode 키 옵션을 사용하여 이 속성의 레이블을 변경합니다. | response-code{} response-code{key=”ResponseCode”} |
| response-header | 응답 헤더의 이름입니다. 구조화된 데이터의 키는 헤더의 이름입니다. 값은 이름이 지정된 헤더의 값입니다. names 속성은 교환 값을 확인하는 데 사용되는 쉼표로 구분된 이름 목록입니다. key-prefix 속성을 사용하여 키를 고유하게 만듭니다. 키 접두사가 지정된 경우 로그 출력의 요청 헤더 이름에 접두사가 추가됩니다. | response-header{names={store,section}} response-header{names={store,section}, key-prefix=”my-”} |
| response-reason-phrase | 응답 코드의 텍스트 이유입니다. 기본 레이블: responseReasonPhrase 키 옵션을 사용하여 이 속성의 레이블을 변경합니다. | response-reason-phrase{} response-reason-phrase{key=”ResponseReasonPhrase”} |
| 응답 시간 | 요청을 처리하는 데 사용되는 시간입니다. 기본 레이블: responseTime 키 옵션을 사용하여 이 속성의 레이블을 변경합니다. 기본 시간 단위는 MiLLISECONDS입니다. 사용 가능한 시간 단위는 다음과 같습니다. * NANOSECONDS *MICROSECONDS *MILLISECONDS * SECONDS | response-time{} response-time{key=”ResponseTime”, time-unit=SECONDS} |
| secure-exchange | 교환이 안전한지 여부를 나타냅니다. 기본 레이블: secureExchange 키 옵션을 사용하여 이 속성의 레이블을 변경합니다. | secure-exchange{} secure-exchange{key=”SecureExchange”} |
| ssl-cipher | 요청에 대한 SSL 암호입니다. 기본 레이블: sslCipher 키 옵션을 사용하여 이 속성의 레이블을 변경합니다. | ssl-cipher{} ssl-cipher{key=”SSLCipher”} |
| ssl-client-cert | 요청에 대한 SSL 클라이언트 인증서입니다. 기본 레이블: sslClientCert 키 옵션을 사용하여 이 속성의 레이블을 변경합니다. | ssl-client-cert{} ssl-client-cert{key=”SSLClientCert”} |
| ssl-session-id | 요청의 SSL 세션 ID입니다. 기본 레이블: sslSessionId 키 옵션을 사용하여 이 속성의 레이블을 변경합니다. | SSL-session-id{} stored-response |
| 요청에 저장된 응답입니다. Default label: storedResponse key 옵션을 사용하여 이 속성의 레이블을 변경합니다. | stored-response{} stored-response{key=”StoredResponse”} | thread-name |
| 현재 스레드의 스레드 이름입니다. Default label: threadName key 옵션을 사용하여 이 속성의 레이블을 변경합니다. | thread-name{} thread-name{key="ThreadName"} | transport-protocol |
metadata 속성을 사용하여 액세스 로그 레코드에 포함하도록 추가 임의의 데이터를 구성할 수 있습니다. metadata 속성 값은 액세스 로그 레코드에 포함할 데이터를 정의하는 키:값 쌍 집합입니다. 한 쌍의 값은 관리 모델 표현식일 수 있습니다. 관리 모델 표현식은 서버가 시작되거나 다시 로드될 때 해결됩니다. 키-값 쌍은 쉼표로 구분됩니다.
다음 CLI 명령은 추가 로그 데이터, 로그 데이터 사용자 지정 및 추가 메타데이터를 포함하여 복잡한 콘솔 로그 구성의 예를 보여줍니다.
/subsystem=undertow/server=default-server/host=default-host/setting=console-access-log:add(metadata={"@version"="1", "qualifiedHostName"=${jboss.qualified.host.name:unknown}}, attributes={bytes-sent={}, date-time={key="@timestamp", date-format="yyyy-MM-dd'T'HH:mm:ssSSS"}, remote-host={}, request-line={}, response-header={key-prefix="responseHeader", names=["Content-Type"]}, response-code={}, remote-user={}})
결과 액세스 로그 레코드는 다음과 같은 추가 JSON 데이터와 유사합니다(참고: 아래 예제 출력은 가독성을 위해 포맷됩니다. 실제 레코드에서는 모든 데이터가 한 줄로 출력됩니다.).
{
"eventSource":"web-access",
"hostName":"default-host",
"@version":"1",
"qualifiedHostName":"localhost.localdomain",
"bytesSent":1504,
"@timestamp":"2019-05-02T11:57:37123",
"remoteHost":"127.0.0.1",
"remoteUser":null,
"requestLine":"GET / HTTP/2.0",
"responseCode":200,
"responseHeaderContent-Type":"text/html"
}
다음 명령은 콘솔 액세스 로그를 활성화한 후 로그 데이터 업데이트를 보여줍니다.
/subsystem=undertow/server=default-server/host=default-host/setting=console-access-log:write-attribute(name=attributes,value={bytes-sent={}, date-time={key="@timestamp", date-format="yyyy-MM-dd'T'HH:mm:ssSSS"}, remote-host={}, request-line={}, response-header={key-prefix="responseHeader", names=["Content-Type"]}, response-code={}, remote-user={}})
다음 명령은 콘솔 액세스 로그를 활성화한 후 사용자 지정 메타데이터 업데이트를 보여줍니다.
/subsystem=undertow/server=default-server/host=default-host/setting=console-access-log:write-attribute(name=metadata,value={"@version"="1", "qualifiedHostName"=${jboss.qualified.host.name:unknown}})