2 Webサーバー機能の構成
『Oracle WebLogic Server Webアプリケーション、サーブレット、JSPの開発』を参照してください。
- Webサーバー・コンポーネントの構成の概要
WebLogic Serverは、動的なJavaベース分散アプリケーションをホストする他にも、大容量Webサイトを処理する高機能Webサーバーとして、HTMLファイルや画像ファイルなどの静的ファイル、およびサーブレットとJavaServer Pages (JSP)を提供します。 - サーバーの構成
各WebLogic ServerがHTTPリクエストをリスニングするポートを指定できます。任意の有効なポート番号を指定できますが、ポート80を指定した場合、HTTPを介してリソースにアクセスするために使用するHTTPリクエストからポート番号を省略できます。たとえば、リスニング・ポートとしてポート80を定義した場合、http://hostname:portnumber/myfile.htmlではなく、http://hostname/myfile.htmlという形式を使用できます。 - Webアプリケーション
HTTPアプリケーションとWebアプリケーションは、Jakarta Servlet 4.0およびJSP 2.3の仕様に従ってデプロイされます。これらの仕様では、WebアプリケーションがWebベース・アプリケーションのコンポーネントをグループ化するための標準として定義されています。これらのコンポーネントには、JSPページ、HTTPサーブレット静的リソース(HTMLページや画像ファイルなど)が含まれます。またWebアプリケーションは、エンタープライズEJBやJSPタグ・ライブラリなどの外部リソースにアクセスすることもできます。各サーバーは、任意の数のWebアプリケーションのホストになることができます。通常、Webアプリケーションの名前は、そのWebアプリケーションからリソースをリクエストするために使用するURIの一部として使用します。 - 仮想ホスティングの構成
仮想ホスティングを使用すると、サーバーまたはクラスタが応答するホスト名を定義できます。仮想ホスティングを使用するときは、WebLogic ServerインスタンスまたはクラスタのIPアドレスにマップする1つまたは複数のホスト名を、DNSを使用して指定します。また、仮想ホストによって提供されるWebアプリケーションを指定します。仮想ホスティングをクラスタ内で使用する場合、ロード・バランシング機能により、DNSホスト名の1つが他のホスト名より多くのリクエストを処理する場合でもハードウェアを最も効率的に使用できます。 - WebLogic ServerによるHTTPリクエストの解決方法
WebLogic ServerがHTTPリクエストを受信すると、WebLogic Serverは、URLの様々な部分を解析し、その情報を利用してどのWebアプリケーションとサーバーがそのリクエストを処理すべきかを決定することによって、そのリクエストを解決します。 - ヘルス・スコアベースのインテリジェント・ルーティング
ヘルス・スコアベースのインテリジェント・ルーティングを使用すると、システムの最適化の管理、過負荷の回避、異常のあるサーバーへの対処を行うことができます。 - HTTPアクセス・ログの設定
WebLogic Serverは、HTTPトランザクションのログを、共通ログ・フォーマットまたは拡張ログ・フォーマットのいずれかのフォーマットでテキスト・ファイルに保存します。 - POSTサービス拒否攻撃の防止
サービス拒否攻撃とは、偽りのリクエストによってサーバーを過負荷状態にしようとする悪意ある試みです。一般的な攻撃の1つは、HTTP POSTメソッドで膨大な量のデータを送信するというものです。WebLogic Serverでは、3つの属性を設定して、この種の攻撃を防くことができます。これらの属性は、リモート・コンソールの「サーバー」: 「プロトコル」: 「HTTP」または「仮想ホスト」: 「HTTP」で設定します。これらの属性を仮想ホストに対して設定した場合、その値は「サーバー」で設定した値をオーバーライドします。 - HTTPトンネリングのためのWebLogic Serverの設定
HTTPトンネリングは、HTTPプロトコルしか使用できないときに、WebLogic ServerとJakartaクライアントの間にステートフルなソケット接続をシミュレートするための手段を提供します。 - ネイティブI/Oを使用した静的ファイルの提供(Windowsのみ)
WebLogic ServerをWindows NT/2000/XPで実行している場合は、HTMLファイル、テキスト・ファイル、画像ファイルなどの静的ファイルを提供する際に、Javaメソッドではなくネイティブ・オペレーティング・システム・コールTransmitFileを使用するように指定できます。ネイティブI/Oを使用することで、サイズの大きい静的ファイルを提供する際のパフォーマンスが向上します。
Webサーバー・コンポーネントの構成の概要
WebLogic Serverは、動的なJavaベース分散アプリケーションをホストする他にも、大容量Webサイトを処理する高機能Webサーバーとして、HTMLファイルや画像ファイルなどの静的ファイル、およびサーブレットとJavaServer Pages (JSP)を提供します。
WebLogic Serverでは、HTTP 1.1規格をサポートしています。
親トピック: Webサーバー機能の構成
サーバーの構成
各WebLogic ServerがHTTPリクエストをリスニングするポートを指定できます。任意の有効なポート番号を指定できますが、ポート80を指定した場合、HTTPを介してリソースにアクセスするために使用するHTTPリクエストからポート番号を省略できます。たとえば、リスニング・ポートとしてポート80を定義した場合、http://hostname:portnumber/myfile.htmlではなく、http://hostname/myfile.htmlという形式を使用できます。
UNIXシステムでは、プロセスを1025より小さいポートにバインドする場合は、権限があるユーザー(通常はroot)で行う必要があります。したがって、WebLogic Serverがポート80をリスニングするようにするには、権限があるユーザーとしてWebLogic Serverを起動しなければなりません。しかし、セキュリティの観点からすると、WebLogic Serverのように長時間にわたって実行するプロセスを、必要以上の権限で実行するのは望ましくありません。WebLogic Serverにroot権限が必要なのは、ポートがバインドされるまでです。
WebLogic Serverでは、ポート80にバインドした後、そのUNIXユーザーID (UID)またはUNIXグループID (GID)、あるいはその両方を切り替えることができます。UID(またはGID)は、WebLogicリモート・コンソールを介して(「リスニング・ポートの構成」を参照)、またはWLSTを使用してUnixMachineMBeanにアクセスすることにより変更できます。UnixMachineMBbean.setPostBindUID()を使用してUIDを設定し、UnixMachineMBean.setPostBindUIDEnabled()をtrueに設定してスイッチを有効にします。同様に、GIDはメソッドUnixMachineMBean.setPostBindGID()およびUnixMachineMBean.setPostBindGIDEnabled()を使用して変更できます。
UNIXアカウントは、ほとんどのUNIXシステムで権限が最も低い「nobody」に切り替えることができます。必要な場合は、WebLogic Serverの実行専用のUNIXユーザー・アカウントを作成します。権限のないユーザーは、WebLogic Serverで必要になるファイル(ログ・ファイル、WebLogicクラスなど)にアクセスできるように設定してください。WebLogicプロセスの所有権が権限のないユーザーに切り替わると、WebLogicの読み込み、書き込み、および実行の許可がそのユーザーと同じになります。
リスニング・ポートは、非SSLのリクエストとセキュアな(SSLを使用した)リクエストで別個に定義します。リスニング・ポートの構成の詳細は、「ネットワーク・チャネルの理解」を参照してください。
親トピック: Webサーバー機能の構成
リスニング・ポートの構成
- WebLogicリモート・コンソールを使用して、リスニング・ポートをポート80に設定します。リスニング・ポートの指定に関する項を参照してください。
- WebLogic ServerをホストしているマシンでWindowsが動作している場合、ステップ8へ進みます。
- WebLogicリモート・コンソールを使用して、新しいUnixマシンを作成します。「マシンの作成と構成」を参照してください。
- 「バインド後UIDの有効化」フィールドを選択します。
- 「バインド後UIDの有効化」フィールドに、WebLogic Serverを実行するユーザー名を入力します。
- 「バインド後GIDの有効化」フィールドを選択します。
- 「バインド後GIDの有効化」フィールドに、WebLogic Serverを実行するグループ名を入力します。
- 「保存」をクリックします。
親トピック: サーバーの構成
Webアプリケーション
HTTPアプリケーションとWebアプリケーションは、Jakarta Servlet 4.0およびJSP 2.3の仕様に従ってデプロイされます。これらの仕様では、WebアプリケーションがWebベース・アプリケーションのコンポーネントをグループ化するための標準として定義されています。これらのコンポーネントには、JSPページ、HTTPサーブレット静的リソース(HTMLページや画像ファイルなど)が含まれます。またWebアプリケーションは、エンタープライズEJBやJSPタグ・ライブラリなどの外部リソースにアクセスすることもできます。各サーバーは、任意の数のWebアプリケーションのホストになることができます。通常、Webアプリケーションの名前は、そのWebアプリケーションからリソースをリクエストするために使用するURIの一部として使用します。
『Oracle WebLogic Server Webアプリケーション、サーブレット、JSPの開発』を参照してください。
親トピック: Webサーバー機能の構成
Webアプリケーションとクラスタリング
Webアプリケーションは、WebLogic Serverクラスタにデプロイできます。ユーザーがWebアプリケーションのリソースをリクエストすると、そのリクエストはそのWebアプリケーションがホストするクラスタ内のサーバーの1つに転送されます。アプリケーションがセッション・オブジェクトを使用する場合、そのセッションはクラスタ内の全ノードにレプリケートする必要があります。セッションのレプリケートにはいくつかの方法があります。
『Oracle WebLogic Serverクラスタの管理』を参照してください。
親トピック: Webアプリケーション
仮想ホスティングの構成
仮想ホスティングを使用すると、サーバーまたはクラスタが応答するホスト名を定義できます。仮想ホスティングを使用するときは、WebLogic ServerインスタンスまたはクラスタのIPアドレスにマップする1つまたは複数のホスト名を、DNSを使用して指定します。また、仮想ホストによって提供されるWebアプリケーションを指定します。仮想ホスティングをクラスタ内で使用する場合、ロード・バランシング機能により、DNSホスト名の1つが他のホスト名より多くのリクエストを処理する場合でもハードウェアを最も効率的に使用できます。
たとえば、booksというWebアプリケーションが仮想ホスト名www.books.comのリクエストに応答し、これらのリクエストがWebLogic Server A、B、およびCに向けられるよう指定し、一方、carsというWebアプリケーションが仮想ホスト名www.autos.com に応答し、これらのリクエストがWebLogic Server DおよびEに向けられるよう指定できます。アプリケーションとWebサーバーの要件に合わせて、仮想ホスト、WebLogic Serverインスタンス、クラスタ、およびWebアプリケーションの様々な組合せを構成できます。
また、定義した各仮想ホストに対して、個別にHTTPパラメータとHTTPアクセス・ログを定義できます。仮想ホストに対して設定されたHTTPパラメータとアクセス・ログは、サーバーに対して設定されたHTTPパラメータとアクセス・ログをオーバーライドします。指定できる仮想ホストの数に制限はありません。
仮想ホスティングをアクティブ化するには、仮想ホストをサーバーまたはサーバー・クラスタに割り当てます。クラスタに割り当てられた仮想ホスティングは、そのクラスタ内のすべてのサーバーに適用されます。
仮想ホスティングとデフォルトWebアプリケーション
各仮想ホストに対して、デフォルトWebアプリケーションを指定することもできます。仮想ホストのデフォルトWebアプリケーションは、同じサーバーまたはクラスタで仮想ホストとしてデプロイされている別のWebアプリケーションで解決できないすべてのリクエストに応答します。
他のWebアプリケーションとは異なり、デフォルトWebアプリケーションの名前(コンテキスト・パスともいう)は、そのデフォルトWebアプリケーションのリソースにアクセスするために使うURIの一部として使用されません。
たとえば、www.mystore.comという仮想ホスト名を定義し、shoppingというWebアプリケーションをデプロイしたサーバーにその仮想ホストを割り当てた場合、shoppingのcart.jspというJSPにアクセスするには、次のURIを使用します。
http://www.mystore.com/shopping/cart.jsp
しかし、shoppingをこの仮想ホストwww.mystore.comのデフォルトWebアプリケーションとして宣言した場合は、次のURIを使用してcart.jspにアクセスします。
http://www.mystore.com/cart.jsp
「WebLogic ServerによるHTTPリクエストの解決方法」を参照してください。
複数の仮想ホストを別々のデフォルトWebアプリケーションで使用する場合は、シングル・サインオンは使用できません。それぞれのWebアプリケーションが、以前のWebアプリケーションに設定されたJSESSIONID Cookieを上書きしてしまうためです。これは、すべてのデフォルトWebアプリケーションでCookieName、CookiePath、およびCookieDomainをまったく同じにしても発生します。
親トピック: 仮想ホスティングの構成
仮想ホストの設定
- リモート・コンソールを使用して、「ツリーの編集」の「環境」: 「仮想ホスト」で仮想ホストを定義します。
- 新しい仮想ホストを作成します。
- 「一般」仮想ホスト・プロパティを構成します。
- 仮想ホストのHTTPロギング設定を構成します。
- 仮想ホストのHTTPを構成します。
- 仮想ホストのターゲットをサーバーに設定します。
- 仮想ホスト名を確実に解決できるように、サーバー上の
etc/hostsファイルに仮想ホストのネーミングの行を追加します。
親トピック: 仮想ホスティングの構成
WebLogic ServerによるHTTPリクエストの解決方法
WebLogic ServerがHTTPリクエストを受信すると、WebLogic Serverは、URLの様々な部分を解析し、その情報を利用してどのWebアプリケーションとサーバーがそのリクエストを処理すべきかを決定することによって、そのリクエストを解決します。
表2-1では、Webアプリケーション、仮想ホスト、サーブレット、JSP、および静的ファイルのリクエストの様々な組合せとそのレスポンスについて説明します。
ノート:
Webアプリケーションをエンタープライズ・アプリケーションの一部としてパッケージ化する場合は、Webアプリケーションへのリクエストの解決に使用するために、Webアプリケーションに別の名前を指定できます。『Oracle WebLogic Server Webアプリケーション、サーブレット、JSPの開発』を参照してください。
表2-1に、WebLogic Serverによって提供されるURLとファイルのサンプルを示します。「索引ディレクトリはチェックされているか」の列は、特定のファイルがリクエストされなかった場合にディレクトリ・リストを提供するかどうかを制御する索引ディレクトリ属性の設定を示します。
表2-1 WebLogic ServerによるURLの解決例
| URL | 索引ディレクトリはチェックされているか | レスポンスで提供されるファイル |
|---|---|---|
http://host:port/apples |
いいえ |
|
http://host:port/apples |
はい |
|
http://host:port/oranges/naval |
どちらでもよい |
サーブレット・マッピングには、いくつかの考慮事項があります。『Oracle WebLogic Server Webアプリケーション、サーブレット、JSPの開発』のサーブレットの構成に関する項を参照してください。 |
http://host:port/naval |
どちらでもよい |
『Oracle WebLogic Server Webアプリケーション、サーブレット、JSPの開発』のサーブレットの構成に関する項を参照してください。 |
http://host:port/apples/pie.jsp |
どちらでもよい |
|
http://host:port |
はい |
デフォルトWebアプリケーションの最上位レベルのディレクトリのリスト |
http://host:port |
いいえ |
デフォルトWebアプリケーションのウェルカム・ファイル* |
http://host:port/apples/myfile.html |
どちらでもよい |
|
http://host:port/myfile.html |
どちらでもよい |
|
http://host:port/apples/images/red.gif |
どちらでもよい |
|
http://host:port/myFile.html
|
どちらでもよい |
エラー404 |
http://www.fruit.com/ |
いいえ |
|
http://www.fruit.com/ |
はい |
|
http://www.fruit.com/oranges/myfile.html |
どちらでもよい |
|
親トピック: Webサーバー機能の構成
ヘルス・スコアベースのインテリジェント・ルーティング
ヘルス・スコアベースのインテリジェント・ルーティングを使用すると、システムの最適化の管理、過負荷の回避、異常のあるサーバーへの対処を行うことができます。
WebLogic Serverは、インテリジェントなロード・バランシングをサポートしています。これにより、Oracle HTTP Server (OHS)は、実際の容量に応じて、サーバーのプール間でトラフィックをより均等に分散できます。クラスタ内の管理対象サーバーごとに、WebLogic Serverはデフォルトのヘルス・スコアの計算を提供します。このヘルス・スコアは、ローカルに使用可能なメトリックとMBeanに基づいて、各管理対象サーバーによって個別に計算され、その後リクエストされたときにOHSに返されます。OHSは、最も健全なサーバー・インスタンスにリクエストをルーティングします。詳細なOHS情報は、『Oracle WebLogic Serverプロキシ・プラグインの使用』のインテリジェントなロード・バランシングのサポートに関する項を参照してください。
仕組み
各WebLogic Serverインスタンスは、サービス・プロバイダ・プラグインを使用して自身のヘルスを計算します。WebLogicヘルス・サービスは、プラグインを定期的に起動して、定義済の問合せ間隔(たとえば、5秒ごと)で最新のヘルス値を取得します。OHSは、ヘルス・スコアをリクエストしている個々の管理対象サーバー・インスタンスにリクエスト・ヘッダーX-WebLogic-Request-Server-Health-Scoreを送信します。各サーバーのヘルス・スコアは、定義済のHTTPレスポンス・ヘッダーX-WebLogic-Server-Health-Scoreを使用してOHSプラグインに送信されます。
- デフォルトのヘルス・スコア・プラグイン
WebLogic Serverは、カスタム・プラグインが定義されていない場合に使用されるデフォルトのプラグイン実装を提供します。 - カスタム・プラグインの実装
WebLogic Serverでは、サービス・プロバイダが、クラスタ化された管理対象サーバー・インスタンスのヘルス・スコアを計算するためのカスタム・プラグイン実装を定義できる次のインタフェースが定義されています。
親トピック: Webサーバー機能の構成
デフォルトのヘルス・スコア・プラグイン
WebLogic Serverは、カスタム・プラグインが定義されていない場合に使用されるデフォルトのプラグイン実装を提供します。
- CPU負荷
- ヒープ使用量
- ワーク・マネージャ・スタック・スレッド数
- データ・ソース保留接続リクエスト数
- ヘルス状態
デフォルトのヘルス・スコアの計算では、最初にサーバーのヘルス状態がチェックされます。その後、アルゴリズムは一連のメトリックを検討します。メトリックごとに、アルゴリズムは"ヘルス・スコア減数"を計算します。これは、このメトリックが原因でヘルスが減少する量です。ヘルス・スコアは、100からヘルス・スコア減数を差し引いたものです。1つの最大ヘルス・スコア減数の原因となるメトリックが使用されて、最終的なヘルス・スコアに到達します。これは、このヘルス・スコア減数値を100から引いた値になります。
ヘルス状態
- サーバーのヘルス状態が
HEALTH_FAILEDの場合、ヘルス・スコアは0です。 - サーバーのヘルス状態が
HEALTH_OVERLOADEDの場合、ヘルス・スコア減数は50です。 - その他のヘルス状態の場合、ヘルス状態の値はヘルス・スコアに影響しません。
親トピック: ヘルス・スコアベースのインテリジェント・ルーティング
カスタム・プラグインの実装
WebLogic Serverでは、サービス・プロバイダが、クラスタ化された管理対象サーバー・インスタンスのヘルス・スコアを計算するためのカスタム・プラグイン実装を定義できる次のインタフェースが定義されています。
クラスタ内の管理対象サーバーごとに、ヘルス・サービス・プロバイダ・インタフェース(SPI)を使用してヘルス・スコアを計算します。ヘルス・サービス・プロバイダ・インタフェースを使用すると、管理対象サーバー・インスタンスの全体的なヘルスに関連するメトリックに基づいて、カスタム・アルゴリズムを実装できます。プラグインの実装は、OHSがヘルス・スコアに基づいてリクエストをルーティングする対象となるすべてのクラスタ化された管理対象サーバー・インスタンスで構成する必要があります。
/**
* Plugin interface for calculating health score.
*/
public interface HealthScore {
int calculateHealthScore();
}カスタム・ヘルス・スコア・プラグイン実装の例
- JNDIを介したローカルMBeanServerへの参照の検索。
- 関連するランタイムMBeanの取得。
- 関連するメトリックに基づいたヘルス・スコアの計算。
package com.oracle.weblogic;
public class HealthScorePlugin implements HealthScore {
// public default constructor needed for instantiation
public HealthScorePlugin() { }
@Override
public int calculateHealthScore() {
try {
// Lookup local MBeanServer from JNDI.
InitialContext ctx = new InitialContext();
MBeanServer mbeanServer = (MBeanServer) ctx.lookup("java:comp/jmx/runtime");
// Example of how to retrieve runtime mbeans.
ObjectName objectName = new ObjectName("com.bea:Name=RuntimeService,Type=weblogic.management.mbeanservers.runtime.RuntimeServiceMBean");
ObjectName serverRuntime = (ObjectName) mbeanServer.getAttribute(objectName, "ServerRuntime");
ObjectName jvmRuntime = (ObjectName) mbeanServer.getAttribute(serverRuntime, "JVMRuntime");
ObjectName threadPoolRuntime = (ObjectName) mbeanServer.getAttribute(serverRuntime, "ThreadPoolRuntime");
ObjectName jdbcServiceRuntime = (ObjectName) mbeanServer.getAttribute(serverRuntime, "JDBCServiceRuntime");
return getHeapFreeHealthScore(mbeanServer, jvmRuntime);
} catch (Exception e) {
throw new RuntimeException(e);
}
}
/**
* Example of how to retrieve "HeapFreePercent" attribute from JVMRuntime MBean and calculate related health score.
*/
private int getHeapFreeHealthScore(MBeanServer mbeanServer, ObjectName jvmRuntime) throws ReflectionException, AttributeNotFoundException,
InstanceNotFoundException, MBeanException {
int heapFreePercent = (int) mbeanServer.getAttribute(jvmRuntime, "HeapFreePercent");
System.out.println("heapFreePercent: " + heapFreePercent);
return 100 - heapFreePercent;
}
}親トピック: カスタム・プラグインの実装
ヘルス・スコアの構成
ノート:
WebLogicヘルス・スコア・サービスは、デフォルトで無効です。- ドメイン・レベルでのヘルス・スコアの構成(DomainMBeanを使用)は、WebLogicドメインに定義されているすべての管理対象サーバーに適用されます。
- サーバー・レベルで個々のヘルス・スコアを構成でき、これによりドメイン・レベルの構成がオーバーライドされます。
- サービス・プロバイダ・プラグイン・クラスの実装を使用可能にするには、それをWebLogic Serverシステム・クラスパスに追加します。
WebLogicドメイン・レベルでの次のヘルス・スコア構成例を参照してください。
<domain>
...
<health-score>
<enabled>true</enabled>
<plugin-class-name>com.oracle.weblogic.HealthScorePlugin</plugin-class-name>
<calculate-interval-secs>10</calculate-interval-secs>
</health-score>
</domain>WLSTの例
次のWLSTの例は、ヘルス・スコア・サービスを有効にする方法と、ドメイン・レベルでヘルス・スコア構成を定義する方法を示しています。ドメイン・レベルで構成した場合、HealthScoreMBean構成はドメイン内のすべての管理対象サーバーに適用されます。
この例では、ヘルス・スコア・サービスを有効にします。
# Connect to the AdminServer.
connect(adminUsername, adminPassword, adminURL)
edit()
startEdit()
# Navigate to Health Score at Domain.
cd('HealthScore/your_domain')
cmo.setEnabled(true)
save()
activate()
disconnect()PluginClassName- サーバーのヘルス・スコアを計算するためにヘルス・スコア・サービスでインスタンス化され、使用されるカスタム・ヘルス・スコア・プラグインのクラス名。CalculateIntervalSecs- WebLogic Serverがサーバーのヘルス・スコアを計算するためにヘルス・スコア・プラグインをコールする間隔(秒単位の時間)。
# Connect to the AdminServer.
connect(adminUsername, adminPassword, adminURL)
edit()
startEdit()
# Navigate to Health Score at Domain.
cd('HealthScore/your_domain')
cmo.setPluginClassName('weblogic.health.HealthScorePlugin')
com.setCalculateIntervalSecs(10)
save()
activate()
disconnect()親トピック: カスタム・プラグインの実装
HTTPアクセス・ログの設定
WebLogic Serverは、HTTPトランザクションのログを、共通ログ・フォーマットまたは拡張ログ・フォーマットのいずれかのフォーマットでテキスト・ファイルに保存します。
デフォルトは共通ログ・フォーマットです。拡張ログ・フォーマットでは、記録されている情報をカスタマイズできます。定義した各サーバー・インスタンスまたは各仮想ホストに対して、HTTPアクセス・ログの動作を定義する属性を設定できます。
サーバーまたは仮想ホストのHTTPロギングを設定するには、リモート・コンソールの「ツリーの編集」で次のようにします:
- サーバーの場合は、「環境」: 「サーバー」: myServerに移動します。「ロギング」: 「HTTP」サブタブで、HTTPアクセス・ログを有効にして構成します。
- 仮想ホストの場合は、「環境」: 「仮想ホスト」: myVirtualHostに移動します。「ロギング」ページでHTTPログ・ファイル設定を指定します。
ログ・ローテーション
ログ・ファイルは、そのファイルのサイズ、または指定した時間のいずれかに基づいてローテーションさせることができます。どちらかの条件が満たされると、現在のアクセス・ログ・ファイルが閉鎖され、新しいログ・ファイルが開始されます。ログ・ローテーションを設定しないと、HTTPアクセス・ログ・ファイルは無限に大きくなります。アクセス・ログ・ファイルの名前は、いつファイルがローテーションされたのかを示す日付と時刻のスタンプが含まれるように構成できます。タイムスタンプを構成しない場合、ローテーションされた各ファイルの名前にはローテーションごとにインクリメントされる数値が含まれます。HTTPアクセス・ログは、定義した仮想ホストごとに保存されます。
親トピック: HTTPアクセス・ログの設定
共通ログ・フォーマット
ログに記録されるHTTP情報のデフォルトのフォーマットは、共通ログ・フォーマットです。http://www.w3.org/Daemon/User/Config/Logging.html#common-logfile-formatを参照してください。
この標準フォーマットのパターンは以下のとおりです。
host RFC931 auth_user [day/month/year:hour:minute:second
UTC_offset] "request" status bytes
説明:
- host
-
リモート・クライアントのDNS名またはIP番号。
- RFC931
-
リモート・クライアントのIDENTDによって戻された情報。WebLogic Serverでは、ユーザー識別はサポート対象外。
- auth_user
-
リモート・クライアントのユーザーが認証用にユーザーIDを送信した場合、そのユーザー名。それ以外の場合は「-」。
- day/month/year:hour:minute:second UTC_offset
-
日、月、年、時間(24時間形式)、および現地時間とGMTの時差(大カッコで囲まれて示されます)。
- "リクエスト"
-
リモート・クライアントによって送信されたHTTPリクエストの最初の行(二重引用符で囲まれて示されます)。
- status
-
使用可能な場合、サーバーによって戻されたHTTPステータス・コード。それ以外の場合は「-」。
- bytes
-
既知の場合、HTTPヘッダーでコンテンツ長として示されるバイト数(HTTPヘッダーは含まない)。それ以外の場合は「-」
親トピック: HTTPアクセス・ログの設定
拡張ログ・フォーマットを使用したHTTPアクセス・ログの設定
WebLogic Serverは、拡張ログ・ファイル・フォーマットのバージョン1.0もサポートしています。これはW3C (http://www.w3.org/TR/WD-logfile.html)の仕様草案で定義された新しく拡大しつつある標準です。この件について現在、最も信頼性のある参照先は「W3C Technical Reports and Publications」ページ(http://www.w3.org/TR/)です。
拡張ログ・フォーマットを使用すると、各HTTP通信に関する記録情報のタイプと順序を指定できます。WebLogicリモート・コンソールでこのフォーマットを有効化するには:
- 「ツリーの編集」で、「環境」: 「サーバー」: myServerに移動します。
- 次に、「ロギング」: 「HTTP」サブタブに移動します。
- 「HTTPアクセス・ログ・ファイルの有効化」オプションがオンになっていることを確認します。
- 「拡張フィールドの表示」をクリックします。
- 「フォーマット」フィールドで、「拡張」を選択します。
「拡張ロギング・フォーマットのフィールド」フィールドでは、「サポートされるフィールド識別子」に記載されている1つ以上のフィールドを選択できます。HTTPアクセス・ログ・ファイルにカスタム・フィールドを追加する場合は、「カスタム・フィールド識別子の作成」を参照してください。
このフォーマットでは、ログ・ファイルに記録される情報のタイプをディレクティブによって指定します。ディレクティブは、実際のログ・ファイルに組み込まれます。ディレクティブは、新しい行からポンド記号(#)で始まります。ログファイルが存在しない場合、デフォルト・ディレクティブが記述された新しいログ・ファイルが作成されます。しかし、サーバーの起動時にログ・ファイルがすでに存在する場合、そのファイルの先頭には有効なディレクティブが記述されている必要があります。
Fieldsディレクティブの作成
ログ・ファイルの最初の行には、そのログ・ファイル・フォーマットのバージョン番号を示すディレクティブが存在しなければなりません。また、ファイルの先頭の近くには、Fieldsディレクティブが存在しなければなりません。
#Version: 1.0 #Fields: xxxx xxxx xxxx ...
ここで各xxxxは、記録されるデータ・フィールドを表します。フィールド・タイプは、W3C仕様に定義されているとおり、単純な識別子として指定されるか、または接頭辞-識別子というフォーマットを取ります。たとえば:
#Fields: date time cs-method cs-uri
この識別子は、HTTPアクセスごとにトランザクションの日付と時間、クライアントが使用したリクエスト・メソッド、およびリクエストのURIを記録するようサーバーに指示します。各フィールドはスペースによって区切られ、各レコードは新しい行に書き込まれてログ・ファイルに追加されます。
ノート:
ログ・ファイル内の#Fieldsディレクティブの後には新しい行が続かなければなりません。これは、最初のログ・メッセージがディレクティブと同じ行に追加されないようにするためです。
サポートされるフィールド識別子
以下の識別子がサポートされています。接頭辞は必要ありません。
- date
-
トランザクションが完了した日付。W3C仕様で定義されているフィールド・タイプは
<date>。 - time
-
トランザクションが完了した時間。W3C仕様で定義されているフィールド・タイプは
<time>。 - time-taken
-
トランザクションが完了するまでの時間(秒)。W3C仕様で定義されているフィールド・タイプは
<fixed>。 - bytes
-
転送されたバイト数。フィールド・タイプは
<integer>。W3C仕様で定義されているcachedフィールドは、WebLogic Serverではサポートされていません。
以下の識別子は接頭辞を必要とし、単独では使用できません。ここでは、サポートされている個々の接頭辞の組み合わせについて説明します。
IPアドレス関連フィールド
これらのフィールドには、リクエストを行ったクライアントまたは応答したサーバーのいずれかのIPアドレスとポートが記録されます。W3C仕様で定義されているフィールド・タイプは<address>です。サポートされるフィールドは、次のとおりです。
親トピック: サポートされるフィールド識別子
DNS関連フィールド
これらのフィールドには、クライアントまたはサーバーのドメイン名が記録されます。W3C仕様で定義されているフィールド・タイプは<name>です。サポートされるフィールドは、次のとおりです。
- c-dns
-
リクエストを送信したクライアントのドメイン名。
- s-dns
-
リクエストを受信したサーバーのドメイン名。
- sc-status
-
レスポンスのステータス・コード。たとえば、(404)は「File not found」というステータスを表します。W3C仕様で定義されているフィールド・タイプは
<integer>です。 - sc-comment
-
ステータス・コードと一緒に戻されるコメント(「File not found」など)。このフィールド・タイプは
<text>です。 - cs-method
-
リクエスト・メソッド(GETやPOSTなど)。W3C仕様で定義されているフィールド・タイプは
<name>です。 - cs-uri
-
完全なリクエストURI。W3C仕様で定義されているフィールド・タイプは
<uri>です。ノート:
拡張ログ・フォーマットが有効な場合、記録されたURIの長さがデフォルト制限の256文字を超えた場合は切り捨てられます。WebLogic Serverを起動するコマンドに次の引数を指定することにより、URIの最大長を拡大できます。
-Dweblogic.servlet.maxLoggingURILength=length - cs-uri-stem
-
URIの基本部分のみ(問合せを省略)。W3C仕様で定義されているフィールド・タイプは
<uri>です。 - cs-uri-query
-
URIの問合せ部分のみ。W3C仕様で定義されているフィールド・タイプは
<uri>です。
親トピック: サポートされるフィールド識別子
診断メッセージ相関フィールド
これらのフィールドには、診断メッセージのメッセージ相関情報が記録されます。これは、コンポーネント全体のメッセージ間の関係を判断する際に役立ちます。これらのフィールドは、診断コンテキストが存在する場合、および実行されたリクエストに対して作成される場合に記録されます。診断コンテキストは、受信リクエストでサーバーに伝搬された場合には存在する可能性があり、診断コンテキストが有効な場合にWebLogic Serverによってリクエストに対して作成される可能性があります。サポートされるフィールドは、次のとおりです。
- ctx-ecid
-
実行コンテキストID (ECID)。ECIDは、特定のリクエストの実行に関連付けられたグローバル一意識別子です。
- ctx-rid
-
関係ID (RID)。RIDは、あるプロセスのあるスレッドで行われた作業と、同じリクエストを受けて同じプロセスおよび別のプロセスの別のスレッドで行われた作業を区別します。
診断コンテキストが存在しない場合、またはECIDとRIDの値が診断コンテキストで使用できない場合、その値としてハイフン(-)が記録されます。ECIDおよびRIDの詳細は、Oracle Fusion Middlewareの管理のログ・ファイルおよびコンポーネント全体におけるメッセージの相関関係に関する項を参照してください。
親トピック: サポートされるフィールド識別子
カスタム・フィールド識別子の作成
拡張ログ・フォーマット(ELF)を使用するHTTPアクセス・ログ・ファイルに追加するために、ユーザー定義のフィールドを作成することもできます。カスタム・フィールドを作成するには、ELFログ・ファイルでFieldsディレクティブを使用してフィールドを指定します。次に、そのフィールドに対応し、必要な出力が生成されるJavaクラスを作成します。フィールドごとに別々のJavaクラスを作成することも、複数のフィールドを出力するJavaクラスを作成することもできます。このようなクラスのJavaソースの例については、例2-1を参照してください。
カスタム・フィールドを作成するには:
HttpAccountingInfoオブジェクトのgetメソッド
次のメソッドはHTTPリクエストに関する様々なデータを戻します。これらのメソッドは、javax.servlet.ServletRequest、javax.servlet.http.Http.ServletRequest、およびjavax.servlet.http.HttpServletResponseの様々なメソッドと似ています。
これらのインタフェースのJavadocは、次の場所で入手できます。
-
https://javaee.github.io/javaee-spec/javadocs/javax/servlet/ServletRequest.html
-
https://javaee.github.io/javaee-spec/javadocs/javax/servlet/ServletResponse.html
-
https://javaee.github.io/javaee-spec/javadocs/javax/servlet/http/HttpServletRequest.html
これらのメソッドの詳細は、次の表に示すJavaインタフェースの対応するメソッドを参照するか、表内の特定の情報を参照してください。
表2-2 HttpAccountingInfoのゲッター・メソッド
| HttpAccountingInfoのメソッド | メソッドに関する情報 |
|---|---|
Object getAttribute(String name); |
javax.servlet.ServletRequest |
Enumeration getAttributeNames(); |
javax.servlet.ServletRequest |
String getCharacterEncoding(); |
javax.servlet.ServletRequest |
int getResponseContentLength(); |
javax.servlet.ServletResponse.setContentLength()このメソッドはレスポンスのコンテンツ長を取得し、 |
String getContentType(); |
javax.servlet.ServletRequest |
Locale getLocale(); |
javax.servlet.ServletRequest |
Enumeration getLocales(); |
javax.servlet.ServletRequest |
String getParameter(String name); |
javax.servlet.ServletRequest |
Enumeration getParameterNames(); |
javax.servlet.ServletRequest |
String[] getParameterValues(String name); |
javax.servlet.ServletRequest |
String getProtocol(); |
javax.servlet.ServletRequest |
String getRemoteAddr(); |
javax.servlet.ServletRequest |
String getRemoteHost(); |
javax.servlet.ServletRequest |
String getScheme(); |
javax.servlet.ServletRequest |
String getServerName(); |
javax.servlet.ServletRequest |
int getServerPort(); |
javax.servlet.ServletRequest |
boolean isSecure(); |
javax.servlet.ServletRequest |
String getAuthType(); |
javax.servlet.http.HttpServletRequest |
String getContextPath(); |
javax.servlet.http.HttpServletRequest |
Cookie[] getCookies(); |
javax.servlet.http.HttpServletRequest |
long getDateHeader(String name); |
javax.servlet.http.HttpServletRequest |
String getHeader(String name); |
javax.servlet.http.HttpServletRequest |
Enumeration getHeaderNames(); |
javax.servlet.http.HttpServletRequest |
Enumeration getHeaders(String name); |
javax.servlet.http.HttpServletRequest |
int getIntHeader(String name); |
javax.servlet.http.HttpServletRequest |
String getMethod(); |
javax.servlet.http.HttpServletRequest |
String getPathInfo(); |
javax.servlet.http.HttpServletRequest |
String getPathTranslated(); |
javax.servlet.http.HttpServletRequest |
String getQueryString(); |
javax.servlet.http.HttpServletRequest |
String getRemoteUser(); |
javax.servlet.http.HttpServletRequest |
String getRequestURI(); |
javax.servlet.http.HttpServletRequest |
String getRequestedSessionId(); |
javax.servlet.http.HttpServletRequest |
String getServletPath(); |
javax.servlet.http.HttpServletRequest |
Principal getUserPrincipal(); |
javax.servlet.http.HttpServletRequest |
boolean isRequestedSessionIdFromCookie(); |
javax.servlet.http.HttpServletRequest |
boolean isRequestedSessionIdFromURL(); |
javax.servlet.http.HttpServletRequest |
boolean isRequestedSessionIdFromUrl(); |
javax.servlet.http.HttpServletRequest |
boolean isRequestedSessionIdValid(); |
javax.servlet.http.HttpServletRequest |
byte[] getURIAsBytes(); |
HTTPリクエストのURIをバイト配列として返します。たとえば、 |
long getInvokeTime(); |
サーブレットがクライアントにレスポンスを送信するときにかかる時間の長さを取得するには、次のコードを使用します。
|
int getResponseStatusCode(); |
javax.servlet.http.HttpServletResponse |
String getResponseHeader(String name); |
javax.servlet.http.HttpServletResponse |
例2-1 カスタムELFフィールドを作成するJavaクラス
import weblogic.servlet.logging.CustomELFLogger;
import weblogic.servlet.logging.FormatStringBuffer;
import weblogic.servlet.logging.HttpAccountingInfo;
/* This example outputs the User-Agent field into a
custom field called MyCustomField
*/
public class MyCustomField implements CustomELFLogger{
public void logField(HttpAccountingInfo metrics,
FormatStringBuffer buff) {
buff.appendValueOrDash(metrics.getHeader("User-Agent"));
}
}
親トピック: カスタム・フィールド識別子の作成
POSTサービス拒否攻撃の防止
サービス拒否攻撃とは、偽りのリクエストによってサーバーを過負荷状態にしようとする悪意ある試みです。一般的な攻撃の1つは、HTTP POSTメソッドで膨大な量のデータを送信するというものです。WebLogic Serverでは、3つの属性を設定して、この種の攻撃を防くことができます。これらの属性は、リモート・コンソールの「サーバー」: 「プロトコル」: 「HTTP」または「仮想ホスト」: 「HTTP」で設定します。これらの属性を仮想ホストに対して設定した場合、その値は「サーバー」で設定した値をオーバーライドします。
- PostTimeout
-
HTTP POSTに含まれる大量のデータをWebLogic Serverが受信する間隔。
PostTimeoutのデフォルト値は30秒です。 - MaxPostTime
-
WebLogic ServerがPOSTデータを受信するために費やす最長時間。この制限を超えた場合、
PostTimeoutExceptionがスローされ、次のメッセージがサーバー・ログに記録されます。Post time exceeded MaxPostTime.MaxPostTimeのデフォルト値は30秒です。 - MaxPostSize
-
単一のリクエストで受領するデータの最大バイト数。構成では、POSTリクエストとPUTリクエストの両方が制御されます。リクエストされたデータが
MaxPostSizeを超えた場合は、MaxPostSizeExceeded例外がスローされ、次のメッセージがサーバー・ログに送信されます。POST size exceeded the parameter MaxPostSize.-
リクエストにチャンク転送エンコーディングが含まれており、リクエストされたデータが
MaxPostSizeを超えた場合は、MaxPostSizeExceptionがスローされます。 -
リクエストがコンテンツ長のセットで構成されており、リクエストされたデータが
MaxPostSizeを超えた場合は、メッセージPOST size exceeded the parameter MaxPostSize.がサーバー・ログに書き込まれ、HTTPエラー・コード413 (Request Entity Too Large)がクライアントに返されます。
MaxPostSizeのデフォルト値は -1です。 -
親トピック: Webサーバー機能の構成
HTTPトンネリングのためのWebLogic Serverの設定
ノート:
ファイアウォールの外部で使用可能なチャネルでトンネリングを有効にすることはお薦めしません。HTTPトンネリング接続の設定
HTTPプロトコルでは、クライアントはリクエストを送信し、サーバーから応答を受信することしかできません。サーバーは自主的にクライアントと通信できず、プロトコルはステートレスです - これは、連続的な双方向接続ができないことを意味します。
WebLogic HTTPトンネリングは、HTTPプロトコル経由でT3Connectionをシミュレートすることによって、こうした制限を打開します。WebLogicリモート・コンソールには、トンネリング接続を調整してパフォーマンスを向上させるために構成できる属性があります。接続に関する問題が発生しないかぎり、これらの制限を克服します。サーバーは、これらのプロパティを使用して、クライアント接続が有効であるかどうか、またはクライアントが有効であるかを判断します。
- トンネリングを有効化
-
HTTPトンネリングを有効または無効にします。HTTPトンネリングはデフォルトでは無効です。
HTTPトンネリングを使用するには、サーバーでHTTPプロトコルとT3プロトコルの両方がサポートされている必要があります。
- トンネリング・クライアントPing
-
トンネリング・クライアントがまだアライブかどうかを確認するためにチェックする間隔(単位: 秒)。
デフォルトは45秒で、有効な範囲は20 - 900秒です。
- トンネリング・クライアント・タイムアウト
-
クライアントがサーバーに対して(レスポンスに対する)リクエストを最後に送信してから、この属性で設定された秒数が経過した場合、サーバーはクライアントを応答なしと見なしてHTTPトンネル接続を終了します。サーバーはこの属性によって指定された間隔で経過時間をチェックし、それまでにクライアントからリクエストがあればそれにレスポンスします。
デフォルトは40秒で、有効な範囲は10 - 900秒です。
クライアントからのWebLogic Serverへの接続
クライアントがWebLogic Serverへの接続をリクエストする場合、HTTPトンネリングを使用するために必要なことはURLにHTTPプロトコルを指定することだけです。たとえば:
Hashtable env = new Hashtable(); env.put(Context.PROVIDER_URL, "http://wlhost:80"); Context ctx = new InitialContext(env);
クライアント側では、特殊なタグがhttpプロトコルに付加されます。このためWebLogic Serverは、これが通常のHTTPリクエストではなくトンネリング接続であることを認識します。この処理では、アプリケーション・コードを変更する必要はありません。
クライアントは、ポートが80の場合でもURLにポートを指定しなければなりません。WebLogic ServerインスタンスはHTTPリクエストを任意のポートでリスニングするように設定できますが、ファイアウォールを介したポート80へのリクエストは許可されるのが通例であるため、ポート80を使用するのが最も一般的です。
Oracle WebLogicリモート・コンソール・オンライン・ヘルプのリスニング・ポートの指定に関する項を参照してください。
ネイティブI/Oを使用した静的ファイルの提供(Windowsのみ)
WebLogic ServerをWindows NT/2000/XPで実行している場合は、HTMLファイル、テキスト・ファイル、画像ファイルなどの静的ファイルを提供する際に、Javaメソッドではなくネイティブ・オペレーティング・システム・コールTransmitFileを使用するように指定できます。ネイティブI/Oを使用することで、サイズの大きい静的ファイルを提供する際のパフォーマンスが向上します。
ネイティブI/Oを使用するには、ネイティブI/Oを使用して提供するファイルを含むWebアプリケーションのweb.xmlデプロイメント記述子に2つのパラメータを追加します。1つめのパラメータはweblogic.http.nativeIOEnabledです。これをTRUEに設定することで、ネイティブI/Oによるファイル提供が有効になります。2つめのパラメータは、weblogic.http.minimumNativeFileSizeです。このパラメータには、ネイティブI/Oを使用する際の最小ファイル・サイズを指定します。提供するファイルのサイズがこの値より大きいと、ネイティブI/Oが使用されます。このパラメータを指定しない場合、デフォルトで値4Kが使用されます。
通常、ネイティブI/Oを使用することで、サイズの大きいファイルを提供する際のパフォーマンスが向上します。ただし、WebLogic Serverインスタンスを実行しているマシンの負荷が大きくなるにつれて、この向上の度合いは小さくなります。weblogic.http.minimumNativeFileSizeの値を調節して、適切な値を見つける必要があります。
web.xmlデプロイメント記述子に追加する必要のあるすべてのエントリの例を示します。これらのエントリは、web.xmlファイルの<distributable>要素の後、<servlet>要素の前に追加する必要があります。
<context-param> <param-name>weblogic.http.nativeIOEnabled</param-name> <param-value>TRUE</param-value> </context-param> <context-param> <param-name>weblogic.http.minimumNativeFileSize</param-name> <param-value>500</param-value> </context-param>
weblogic.http.nativeIOEnabledも、FileServletのコンテキスト・パラメータとして設定できます。
親トピック: Webサーバー機能の構成