第15章 JBoss EAP での Web サーバー (Undertow) の設定
この章では、JBoss EAP に組み込まれているデフォルトサーバーである Undertow Web サーバーの設定に焦点を当てます。ここでは、安全な通信のために SSL/TLS を有効にする方法、パフォーマンスを向上させるために HTTP/2 を活用する方法、運用要件に合わせてサーバー設定を微調整する方法について詳しく説明します。
15.1. Undertow サブシステムの概要 リンクのコピーリンクがクリップボードにコピーされました!
JBoss EAP 8.0 では、Undertow サブシステムはアプリケーションサーバー内の Web レイヤーとして機能します。コア Web サーバーおよびサーブレットコンテナー機能を提供し、Jakarta Servlet 6.0 仕様、Web ソケット、HTTP アップグレードなどの高度な機能をサポートします。Undertow は、mod_cluster をサポートする高性能リバースプロキシーとしても機能し、Web トラフィックの処理におけるスケーラビリティー、効率、柔軟性の向上に貢献します。
undertow サブシステムは、Web サーバーおよびサーブレットコンテナーの設定を可能にします。Jakarta Servlet 6.0 Specification や websocket を実装します。HTTP のアップグレードや、サーブレットデプロイメントでの高パフォーマンスな非ブロッキングハンドラーの使用もサポートします。undertow サブシステムは、mod_cluster をサポートする高パフォーマンスなリバースプロキシーとして動作することも可能です。
undertow サブシステム内で設定する主なコンポーネントは 5 つあります。
- Buffer caches
- Server
- Servlet container
- Handlers
- Filters
JBoss EAP には、これらの各コンポーネントの設定を更新する機能がありますが、デフォルト設定は妥当なパフォーマンスの設定を提供し、ほとんどのユースケースに適しています。
デフォルトの Undertow サブシステムの設定
undertow サブシステムは、XNIO ワーカーとバッファープールを提供するために io サブシステムにも依存します。io サブシステムは個別に設定され、ほとんどの場合で最適なパフォーマンスを得られるデフォルト設定を提供します。
15.1.1. Undertow サブシステムでの Elytron の使用 リンクのコピーリンクがクリップボードにコピーされました!
web アプリケーションがデプロイされると、そのアプリケーションが必要なセキュリティードメインの名前が特定されます。これは、デプロイメント内からで、デプロイメントにセキュリティードメインがない場合は undertow サブシステムで定義された default-security-domain が仮定されます。デフォルトでは、default-security-domain は ApplicationDomain です。アプリケーションに必要なセキュリティードメインの名前から適切な Elytron 設定への適切なマッピングを確実に行うために、application-security-domain リソースを undertow サブシステムに追加できます。
例: マッピングの追加
/subsystem=undertow/application-security-domain=ApplicationDomain:add(security-domain=ApplicationDomain)
/subsystem=undertow/application-security-domain=ApplicationDomain:add(security-domain=ApplicationDomain)
マッピングの追加に成功すると、以下のような結果が出力されます。
- この時点でデプロイメントがすでにデプロイされている場合は、アプリケーションサーバーをリロードして、アプリケーションセキュリティードメインマッピングを有効にする必要があります。
- 現在の Web サービス/Elytron 統合では、Web サービスエンドポイントと Elytron セキュリティードメイン名をセキュアにするために指定されたセキュリティードメインの名前が同じである必要があります。
この簡単な例は、BASIC、CLIENT_CERT、DIGEST、FORM など、デプロイメントがサーブレット仕様内で定義された標準の HTTP メカニズムを使用する場合に適しています。この場合、認証は ApplicationDomain セキュリティードメインに対して実行されます。このフォームは、アプリケーションが認証メカニズムを使用せず、代わりにプログラムによる認証を使用したり、デプロイメントに関連する SecurityDomain を取得して直接使用したりする場合にも適しています。
例: 高度なマッピング
/subsystem=undertow/application-security-domain=MyAppSecurity:add(http-authentication-factory=application-http-authentication)
/subsystem=undertow/application-security-domain=MyAppSecurity:add(http-authentication-factory=application-http-authentication)
高度なマッピングに成功すると、以下のような結果が出力されます。
このような設定では、セキュリティードメインを参照する代わりに、http-authentication-factory が参照されます。これは、認証メカニズムのインスタンスの取得に使用されるファクトリーで、セキュリティードメインと関連付けられます。
カスタム HTTP 認証メカニズムを使用する場合や、プリンシパルトランスフォーマー、認証情報ファクトリー、メカニズムレルムなどのメカニズムに追加の設定を定義する必要がある場合など、http-authentication-factory 属性を参照する必要があります。また、Servlet 仕様に記載されている 4 つのメカニズム以外を使用する場合は、http-authentication-factory 属性を参照した方がよいでしょう。
高度なマッピングが使用される場合、別の設定オプション override-deployment-config を使用できます。参照された http-authentication-factory は認証メカニズムの完全セットを返すことができます。デフォルトでは、アプリケーションによってリクエストされたメカニズムと一致するするためにフィルターされます。このオプションが true に設定された場合、ファクトリーによって提供されたメカニズムは、アプリケーションによってリクエストされたメカニズムをオーバーライドします。
application-security-domain リソースには追加のオプション enable-jacc もあります。これを true に設定すると、このマッピングに一致するデプロイメントに対して Java Authorization Contract for Containers が有効になります。
15.1.1.1. ランタイム情報 リンクのコピーリンクがクリップボードにコピーされました!
application-security-domain マッピングが使用されている場合、このマッピングに対してデプロイメントが想定どおり一致していることを再度確認すると便利です。リソースが include-runtime=true で読み取りされた場合、マッピングに関連するデプロイメントは以下のように表示されます。
この出力の referencing-deployments 属性は、simple-webapp.war デプロイメントがマッピングを使用してデプロイされたことを示しています。
15.1.2. バッファーキャッシュの設定 リンクのコピーリンクがクリップボードにコピーされました!
この手順では、静的リソースをキャッシュしてパフォーマンスを向上させる 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>
<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)
/subsystem=undertow/buffer-cache=default/:write-attribute(name=buffer-size,value=2048)Copy to Clipboard Copied! Toggle word wrap Toggle overflow reload
reloadCopy to Clipboard Copied! Toggle word wrap Toggle overflow
新しいバッファーキャッシュを作成します。
新しいバッファーキャッシュを追加します。
/subsystem=undertow/buffer-cache=new-buffer:add
/subsystem=undertow/buffer-cache=new-buffer:addCopy to Clipboard Copied! Toggle word wrap Toggle overflow
バッファーキャッシュを削除します。
既存のバッファーキャッシュを削除します。
/subsystem=undertow/buffer-cache=new-buffer:remove
/subsystem=undertow/buffer-cache=new-buffer:removeCopy to Clipboard Copied! Toggle word wrap Toggle overflow reload
reloadCopy to Clipboard Copied! Toggle word wrap Toggle overflow
15.1.3. バイトバッファープールの設定 リンクのコピーリンクがクリップボードにコピーされました!
Undertow バイトバッファープールは、プールされた NIO ByteBuffer インスタンスの割り当てに使用されます。すべてのリスナーにバイトバッファープールがあり、各リスナーに異なるバッファープールおよびワーカーを使用できます。バイトバッファープールは異なるサーバーインスタンス間で共有できます。
これらのバッファーは IO 操作に使用され、バッファーサイズはアプリケーションのパフォーマンスに大きく影響します。通常、ほとんどのサーバーでは 16 K が理想のサイズになります。
前提条件
- JBoss EAP がインストールされており、管理 CLI への管理アクセス権があることを確認します。
手順
既存のバイトバッファープールを更新します。
バッファーサイズ属性を変更します。
/subsystem=undertow/byte-buffer-pool=myByteBufferPool:write-attribute(name=buffer-size,value=1024)
/subsystem=undertow/byte-buffer-pool=myByteBufferPool:write-attribute(name=buffer-size,value=1024)Copy to Clipboard Copied! Toggle word wrap Toggle overflow reload
reloadCopy to Clipboard Copied! Toggle word wrap Toggle overflow
新しいバイトバッファープールを作成します。
新しいバイトバッファープールを追加します。
/subsystem=undertow/byte-buffer-pool=newByteBufferPool:add
/subsystem=undertow/byte-buffer-pool=newByteBufferPool:addCopy to Clipboard Copied! Toggle word wrap Toggle overflow
バイトバッファープールを削除します。
既存のバイトバッファープールを削除します。
/subsystem=undertow/byte-buffer-pool=newByteBufferPool:remove
/subsystem=undertow/byte-buffer-pool=newByteBufferPool:removeCopy to Clipboard Copied! Toggle word wrap Toggle overflow reload
reloadCopy to Clipboard Copied! Toggle word wrap Toggle overflow
検証
- 管理コンソールでバッファープールの設定を確認して、変更を確認します。
関連情報
- バイトバッファープールの詳細な属性については、バイトバッファープールの属性の項 を参照してください。
15.1.4. Undertow でのサーバー設定について リンクのコピーリンクがクリップボードにコピーされました!
サーバーは Undertow のインスタンスを表し、次のいくつかの要素で構成されます。
-
host -
http-listener -
https-listener -
ajp-listener
host 要素は仮想ホスト設定を提供し、3 つのリスナーはそのタイプの接続を Undertow インスタンスに提供します。
サーバーのデフォルトの動作では、サーバーの起動中にリクエストをキューに置きます。このデフォルトの動作は、ホストの queue-requests-on-start 属性を使用して変更できます。この属性が true (デフォルト) に設定されている場合、サーバーの起動時に到着した要求は、サーバーの準備が整うまで保留されます。この属性が false に設定された場合、サーバーが完全に起動する前に到達したリクエストは、デフォルトの応答コードで拒否されます。
属性の値に関わらず、サーバーが完全に起動するまでリクエストの処理は開始されません。
管理コンソールを使用して queue-requests-on-start 属性を設定するには、Configuration
複数のサーバーを設定できるため、デプロイメントやサーバーを完全に分離できます。これは、マルチテナント環境などで便利です。
JBoss EAP はデフォルトでサーバーを提供します。
15.1.5. デフォルトの Undertow サブシステムの設定 リンクのコピーリンクがクリップボードにコピーされました!
このリファレンスでは、Undertow サブシステムのデフォルト設定について説明します。
15.1.6. 管理 CLI を使用したサーバーの設定 リンクのコピーリンクがクリップボードにコピーされました!
この手順では、管理 CLI を使用して Undertow サブシステム内のサーバーを管理する方法について説明します。必要に応じて、既存のサーバーを更新したり、新しいサーバーを作成したり、サーバーを削除したりできます。
管理コンソールを使用してサーバーを設定する場合は、Configuration
前提条件
- 管理 CLI にアクセスできる。
- サーバー設定を変更する権限がある。
手順
既存のサーバーを更新します。
/subsystem=undertow/server=default-server:write-attribute(name=default-host,value=default-host)
/subsystem=undertow/server=default-server:write-attribute(name=default-host,value=default-host)Copy to Clipboard Copied! Toggle word wrap Toggle overflow reload
reloadCopy to Clipboard Copied! Toggle word wrap Toggle overflow 新しいサーバーを作成します。
/subsystem=undertow/server=new-server:add
/subsystem=undertow/server=new-server:addCopy to Clipboard Copied! Toggle word wrap Toggle overflow reload
reloadCopy to Clipboard Copied! Toggle word wrap Toggle overflow サーバーを削除します。
/subsystem=undertow/server=new-server:remove
/subsystem=undertow/server=new-server:removeCopy to Clipboard Copied! Toggle word wrap Toggle overflow reload
reloadCopy to Clipboard Copied! Toggle word wrap Toggle overflow
15.1.7. アクセスロギング リンクのコピーリンクがクリップボードにコピーされました!
定義する各ホストにアクセスロギングを設定できます。
利用できるアクセスロギングオプションは、標準のアクセスロギングとコンソールアクセスロギングの 2 つです。
アクセスロギングに必要な追加の処理はシステムパフォーマンスに影響を与える可能性があることに注意してください。
15.1.7.1. 標準のアクセスロギング リンクのコピーリンクがクリップボードにコピーされました!
標準のアクセスログは、ログエントリーをログファイルに書き込みます。
デフォルトでは、ログファイルは standalone/log/access_log.log ディレクトリーに保存されます。
標準のアクセスログを有効にするには、アクセスログデータを取得するホストに access-log 設定を追加します。以下の CLI コマンドは、デフォルトの JBoss EAP サーバーのデフォルトのホストの設定を示しています。
/subsystem=undertow/server=default-server/host=default-host/setting=access-log:add
/subsystem=undertow/server=default-server/host=default-host/setting=access-log:add
標準のアクセスログを有効にしたら、サーバーをリロードする必要があります。
デフォルトでは、アクセスログレコードには以下のデータが含まれます。
- リモートホスト名
- リモート論理ユーザー名 (常に -)
- 認証されたリモートユーザー
- Common Log Format 形式のリクエストの日時
- 要求の最初の行
- 応答の HTTP ステータスコード
- HTTP ヘッダーを除く、送信済みバイト数。
この一連のデータは共通のパターンとして定義されます。組み合わせた別のパターンも使用できます。一般的なパターンでログ記録されているデータのほかに、組み合わせたパターンには、受信ヘッダーからの閲覧元およびユーザーエージェントが含まれます。
ログに記録されるデータは、pattern 属性を使用して変更できます。以下の CLI コマンドは、組み合わせたパターンを使用ための pattern 属性の更新を示しています。
/subsystem=undertow/server=default-server/host=default-host/setting=access-log:write-attribute(name=pattern,value="combined"
/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 | Common Log Format 形式の日時 |
| %u | 認証されたリモートユーザー |
| %U | 要求された URL パス |
| %v | ローカルサーバー名 |
| %D | 要求を処理するのにかかった時間 (ミリ秒単位) |
| %T | 要求を処理するのにかかった時間 (秒単位) |
| %I | 現在の要求スレッド名 (後でスタックトレースと比較できます) |
| common |
|
| combined |
|
cookie、受信ヘッダーおよび応答ヘッダー、またはセッションから情報を書き込むこともできます。これは、Apache 構文に基づきます。
-
%{i,xxx}(受信ヘッダーの場合) -
%{o,xxx}(送信応答ヘッダーの場合) -
%{c,xxx}(特定のクッキーの場合) -
%{r,xxx}(xxxはServletRequestの属性) -
%{s,xxx}(xxxはHttpSessionの属性)
このログには、追加の設定オプションも利用できます。詳細は、付録の "access-log 属性" を参照してください。
15.1.7.2. コンソールアクセスロギング リンクのコピーリンクがクリップボードにコピーされました!
コンソールのアクセスログは、JSON データとして構造化された標準出力 (stdout) にデータを書き込みます。
各アクセスログレコードは、1 行のデータです。ログ集約システムにより、このデータを取得して処理できます。
コンソールアクセスロギングを設定するには、アクセスログデータをキャプチャーしたいホストに console-access-log 設定を追加します。以下の CLI コマンドは、デフォルトの JBoss EAP サーバーのデフォルトのホストの設定を示しています。
/subsystem=undertow/server=default-server/host=default-host/setting=console-access-log:add
/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={key="@timestamp", date-format="yyyy-MM-dd’T’HH:mm:ssSSS"} |
| host-and-port | リクエストによってクエリーされたホストおよびポート。デフォルトラベル: hostAndPort。このキーオプションを使用して、このプロパティーのラベルを変更します。 | host-and-port{} host-and-port={key="port-host"} |
| local-ip | ローカル接続の IP アドレス。このキーオプションを使用して、このプロパティーのラベルを変更します。デフォルトラベル: localIp。このキーオプションを使用して、このプロパティーのラベルを変更します。 | local-ip{} local-ip{key="localIP"} |
| local-port | ローカル接続のポート。デフォルトラベル: localPort。このキーオプションを使用して、このプロパティーのラベルを変更します。 | local-port{} local-port{key="LocalPort"} |
| local-server-name | 要求を処理したローカルサーバー名。デフォルトラベル: localServerName。このキーオプションを使用して、このプロパティーのラベルを変更します。 | local-server-name {} local-server-name {key=LocalServerName} |
| path-parameter | リクエストに含まれる 1 つ以上のパスまたは 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}} predicate{names={store,section}, key-prefix="my-"} |
| query-parameter | リクエストに含まれる 1 つ以上のパラメーターまたはクエリーパラメーター。names プロパティーは、交換値を解決するために使用される名前のコンマ区切りリストです。key-prefix プロパティーを使用してキーを一意にします。key-prefix が指定されている場合は、出力の各 path パラメーター名の前に接頭辞が追加されます。 | query-parameter{names={store,section}} query-parameter{names={store,section}, key-prefix="my-"} |
| query-string | リクエストのクエリー文字列。デフォルトラベル: queryString。このキーオプションを起用して、このプロパティーのラベルを変更します。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 プロパティーを使用してキーを一意にします。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 | リクエストの相対パス。デフォルトラベル: 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。クライアントで指定した場合、ホスト名、プロトコルなどが含まれます。デフォルトラベル: requestUrl。このキーオプションを使用して、このプロパティーのラベルを変更します。 | request-url{} request-url{key="RequestURL"} |
| resolved-path | 解決したパス。デフォルトラベル: resolvedPath。このキーオプションを使用して、このプロパティーのラベルを変更します。 | resolved-path{} resolved-path{key="ResolvedPath"} |
| response-code | 応答コード。デフォルトラベル: responseCode。このキーオプションを使用して、このプロパティーのラベルを変更します。 | response-code{} response-code{key="ResponseCode"} |
| response-header | 応答ヘッダーの名前。構造化されたデータのキーはヘッダーの名前です。その値は名前付きヘッダーの値になります。names プロパティーは、交換値を解決するために使用される名前のコンマ区切りリストです。key-prefix プロパティーを使用してキーを一意にします。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"} |
| response-time | リクエストの処理に使われる時間。デフォルトラベル: 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 |
| 要求に対する、保存した応答。デフォルトラベル: storedResponse。このキーオプションを使用して、このプロパティーのラベルを変更します。 | stored-response{} stored-response{key="StoredResponse"} | thread-name |
| 現在のスレッドのスレッド名。デフォルトラベル: threadName。このキーオプションを使用して、このプロパティーのラベルを変更します。 | thread-name{} thread-name{key="ThreadName"} | transport-protocol |
metadata 属性を使用して、アクセスログレコードに追加する追加の任意のデータを設定できます。metadata 属性の値は、アクセスログレコードに追加するデータを定義する key:value ペアのセットです。ペアのこの値は管理モデルの式になります。管理モデル式は、サーバーの起動またはリロード時に解決されます。キーと値のペアはコンマで区切られます。
以下の 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={}})
/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 データに類似しています (注意: 以下の出力例は、読みやすさを考慮してフォーマットされています。実際の記録では、すべてのデータが単一の行として出力されます)。
以下のコマンドは、コンソールアクセスログを有効にした後にのログデータへの更新を示しています。
/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=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}})
/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}})