| Oracle® Fusion Middleware Oracle WebLogic Server診断フレームワークの構成と使用 12c (12.2.1.2.0) E82864-01 |
|
 前 |
 次 |
この章には次の項が含まれます:
WebLogic Server管理コンソールを使用してアクションを作成する方法の詳細は、Oracle WebLogic Server管理コンソール・オンライン・ヘルプの診断システム・モジュールのポリシー用のアクションの作成に関する項を参照してください。
次の項には、WLDFアクションに関するバックグラウンド情報が含まれます。
アクションは、ポリシー式がtrueに評価されたときに実行される操作です。WLDFでは、配信メカニズムに従って、次の種類の診断アクションがサポートされます。
Java Management Extensions (JMX)
Java Message Service (JMS)
Simple Network Management Protocol (SNMP)
簡易メール転送プロトコル(SMTP)
診断イメージ・キャプチャ
拡張度フレームワーク
REST
WebLogicロギング・システム
WebLogic Scripting Tool(WLST)
ヒープ・ダンプ
スレッド・ダンプ
診断モジュールの構成ファイルでは、ドメインのconfig.xmlファイル内の次の要素によって、種類の異なるアクションが識別されます。
<jmx-notification>
<jms-notification>
<snmp-notification>
<smtp-notification>
<image-notification>
<scale-up-action>
<scale-down-action>
<rest-notification>
<log-action>
<script-action>
<heap-dump-action>
<thread-dump-action>
前述のいずれのアクション・タイプにも、<name>および<enabled>構成オプションがあります。<name>の値は、ポリシーを対応するアクションにマップするためにポリシーの<notification>要素の値として使用されます。<enabled>要素をtrueに設定すると、そのアクションが有効になります。つまり、関連するポリシーがtrueに評価されると、アクションが実行されます。<name>および<enabled>を除き、各アクション・タイプは一意です。
ログ、SMTPおよびRESTアクション・タイプでは、このトピックで示されている1つ以上の変数を含むカスタマイズされた文字列の生成がサポートされています。
トリガーされたポリシーによってこれらのアクション・タイプのいずれかが呼び出されると、アクションによって生成されるカスタマイズ済の文字列で使用される各変数が、次の表に示されている値に置き換えられます。
表11-1 置換変数
| 変数名 | 値 |
|---|---|
|
アクションに対応するポリシーの名前 |
|
ポリシー・タイプ( |
|
ポリシー式 |
|
対応するポリシーがトリガーされた日時を識別するタイムスタンプ |
|
ポリシー重大度オプション |
|
ログ・メッセージ |
|
ポリシー・アラーム・タイプの指定( |
|
|
|
WebLogicドメイン名 |
|
サーバー・インスタンス名 |
ログ、RESTおよびSMTPアクションは、実行時に様々な種類のメッセージを送信します。これらのアクションは、それぞれ異なりますが、定義された1つ以上の変数の使用をサポートする1つ以上のプロパティを持ちます。たとえば、SMTPメッセージ本文は、次のようにポリシー名、式、およびポリシーのトリガー日時を示すタイムスタンプを含むように指定できます。
"Test ${WatchName} with policy ${WatchRule} fired at ${WatchTime}."
これらの置換変数の使用方法の詳細は、次の項を参照してください。
すべてのWLDFアクションで、アクションが実行を完了するための時間を秒単位で指定するタイムアウトがサポートされます。デフォルトでは、タイムアウトは0で、アクション・タイムアウトは無効です。
アクション・タイムアウトを指定するには、WLDFNotificationBean.Timeout属性を使用します。
また、WebLogic Server管理コンソールまたはFusion Middleware Controlでアクションを構成する際にタイムアウトを設定できます。詳細は、以下のトピックを参照してください。
Oracle WebLogic Server管理コンソール・オンライン・ヘルプの診断システム・モジュールのポリシー用のアクションの作成に関する項
『Fusion Middleware ControlによるOracle WebLogic Serverの管理』のアクションの構成に関する項
関連するポリシーがトリガーされると、WLDFは、定義されたJMXアクションごとにJMXイベント(通知)を発行します。すべてのJMX通知を受信し、指定した出力をフィルタするために、各アプリケーションは、アクション・リスナーをサーバーのWLDFWatchNotificationSourceRuntimeMBeanに登録できます。JMXクライアントがフィルタとして使用できるJMX「通知タイプ」の文字列を指定することもできます。
例11-1では、JMXアクションの構成のサンプルを示します。
例11-1 JMXアクションの構成のサンプル
<wldf-resource xmlns="http://xmlns.oracle.com/weblogic/weblogic-diagnostics"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://xmlns.oracle.com/weblogic/weblogic-diagnostics/1.0/weblogic-diagnostics.xsd">
<name>mywldf1</name>
<watch-notification>
<!-- One or more policy configurations -->
<jmx-notification>
<name>myJMXNotif</name>
<enabled>true</enabled>
</jmx-notification>
<!-- Other action configurations -->
</watch-notification>
</wldf-resource>
次に、JMXアクションの例を示します。
Notification name: myjmx called. Count= 42.
Watch severity: Notice
Watch time: Jul 19, 2005 3:40:38 PM EDT
Watch ServerName: myserver
Watch RuleType: Harvester
Watch Rule: ${com.bea:Name=myserver,Type=ServerRuntime//OpenSocketsCurrentCount} > 1
Watch Name: mywatch
Watch DomainName: mydomain
Watch AlarmType: None
Watch AlarmResetPeriod: 10000
JMSアクションは、関連するポリシーのトリガーに応答してJMSトピックまたはキューに通知を送信するために使用します。システム・リソース構成ファイルの<destination-jndi-name>要素と<connection-factory-jndi-name>要素で、通知の配信方法を定義します。
例11-2に、指定した接続ファクトリを使用して、指定トピックおよびキューからJMS通知を送信する2つのJMSアクションを示します。この処理を適切に行うためには、ドメインのconfig.xmlファイルでJMSが適切に構成されている必要があります。また、JMSリソースがこのサーバーに対象指定されている必要があります。
例11-2 JMSアクションのサンプル
<wldf-resource xmlns="http://xmlns.oracle.com/weblogic/weblogic-diagnostics"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://xmlns.oracle.com/weblogic/weblogic-diagnostics/1.0/weblogic-diagnostics.xsd">
<name>mywldf1</name>
<watch-notification>
<!-- One or more policy configurations -->
<jms-notification>
<name>myJMSTopicNotif</name>
<destination-jndi-name>MyJMSTopic</destination-jndi-name>
<connection-factory-jndi-name>weblogic.jms.ConnectionFactory
</connection-factory-jndi-name>
</jms-notification>
<jms-notification>
<name>myJMSQueueNotif</name>
<destination-jndi-name>MyJMSQueue</destination-jndi-name>
<connection-factory-jndi-name>weblogic.jms.ConnectionFactory
</connection-factory-jndi-name>
</jms-notification>
<!-- Other action configurations -->
</watch-notification>
</wldf-resource>
ポリシーおよびアクションの詳細は、アクション・メッセージの内容で示されます。
簡易ネットワーク管理プロトコル(SNMP)アクションは、関連ポリシーのトリガーに応答してSNMPトラップを送信するために使用されます。SNMPアクションを定義するには、例11-3に示すように、アクション名を指定するだけで済みます。生成されたトラップには、トラップが生成される原因になったポリシーおよびアクションの両方の名前が含まれます。SNMPトラップを適切に行うためには、ドメインのconfig.xml構成ファイルでSNMPが適切に構成されている必要があります。
例11-3 SNMPアクションの構成のサンプル
<wldf-resource xmlns="http://xmlns.oracle.com/weblogic/weblogic-diagnostics"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://xmlns.oracle.com/weblogic/weblogic-diagnostics/1.0/weblogic-diagnostics.xsd">
<name>mywldf1</name>
<watch-notification>
<!-- One or more policy configurations -->
<snmp-notification>
<name>mySNMPNotif</name>
</snmp-notification>
<!-- Other action configurations -->
</watch-notification>
</wldf-resource>
例11-3のSNMPアクションの構成によって生成されるトラップの型は85です。ここには、以下の値が含まれます(構成された値は山カッコ「<>」で示します)。
.1.3.6.1.4.1.140.625.100.5 timestamp (e.g. Dec 9, 2004 6:46:37 PM EST
.1.3.6.1.4.1.140.625.100.145 domainName (e.g. mydomain")
.1.3.6.1.4.1.140.625.100.10 serverName (e.g. myserver)
.1.3.6.1.4.1.140.625.100.120 <severity> (e.g. Notice)
.1.3.6.1.4.1.140.625.100.105 <name> [of watch] (e.g.
simpleWebLogicMBeanWatchRepeatingAfterWait)
.1.3.6.1.4.1.140.625.100.110 <rule-type> (e.g. HarvesterRule)
.1.3.6.1.4.1.140.625.100.115 <rule-expression>
.1.3.6.1.4.1.140.625.100.125 values which caused rule to
fire (e.g..State =
null,weblogic.management.runtime.WLDFHarvesterRuntimeMBean.
TotalSamplingTime = 886,.Enabled =
null,weblogic.management.runtime.ServerRuntimeMBean.
OpenSocketsCurrentCount = 1,)
.1.3.6.1.4.1.140.625.100.130 <alarm-type> (e.g. None)
.1.3.6.1.4.1.140.625.100.135 <alarm-reset-period> (e.g. 10000)
.1.3.6.1.4.1.140.625.100.140 <name> [of notification]
(e.g.mySNMPNotif)
ログ・アクションを作成して、カスタマイズされたメッセージをサーバー・ログに送信できます。
カスタマイズされたメッセージには、「カスタマイズ可能なアクションの変数」で説明されている任意の変数をオプションで含めることができます。次のWLSTの例は、ログ・アクションの構成を示しています。
wn=res.getWatchNotification()
actionName="myaction"
action = wn.lookupLogAction(actionName);
if action is None:
action = wn.createScriptAction(actionName);
action.setMessage("Message with substitution on server ${WatchServerName} in domain ${WatchDomainName}");
action.setSubsystemName("SpecialLogAction);
action.setSeverity("Info");
前述のログ・アクションが実行されると、太字で示されているカスタム・メッセージは、次の項目を識別する変数を使用します。
WebLogic Serverインスタンス名(${WatchServerName}変数で表現)
WebLogicドメイン名(${WatchDomainName}変数で表現)
RESTアクションを使用して、通知ペイロードにカスタマイズされたメッセージを含むRESTエンドポイントに通知を送信できます。認証なしまたはBasic認証では、RESTエンドポイント呼出しを構成できます。
RESTアクションを構成する場合、「カスタマイズ可能なアクションの変数」で説明されている任意の変数をオプションで使用できる通知プロパティのカスタマイズされたセットを作成できます。たとえば、次のWLSTの例は、カスタマイズされたメッセージを送信するRESTアクションの構成を示しています。
wn = res.getWatchNotification();
#No Auth REST invocation
rest1 = wn.createRESTNotification('r1')
rest1.setEndpointURL("http://localhost:7001/rest-no-auth/resources/watch-listener")
customNotif = java.util.Properties()
customNotif.put('message','Policy ${WatchName} with rule ${WatchRule} fired.')
rest1.setCustomNotificationProperties(customNotif)
rest1.setEnabled(true)
#Basic Auth REST invocation
rest2 = wn.createRESTNotification('r2')
rest2.setEndpointURL("http://localhost:7001/rest-basic-auth/resources/watch-listener")
rest2.setHttpAuthenticationMode('Basic')
rest2.setHttpAuthenticationUserName('restuser1')
rest2.setHttpAuthenticationPassword('restuser1')
rest2.setEnabled(true)
前述のRESTアクションが実行されると、次の項目を識別する太字で示されているメッセージを使用してRESTエンドポイントが呼び出されます。
対応するRESTアクションを実行したトリガー済ポリシーの名前(${WatchName}変数で表現)
ポリシー式(${WatchRule}変数で表現)
簡易メール転送プロトコル(SMTP)アクションは、関連ポリシーのトリガーに応答してSMTPプロトコルを介してメッセージ(電子メール)を送信するために使用されます。SMTPアクションを定義するには、最初にSMTPセッションを構成します。その構成は、ドメインのconfig.xml構成ファイルで永続化されます。DIAG_MODULE.xmlで、下位要素<mail-session-jndi-name>を使用して構成済SMTPセッションを指定し、下位要素<recipients>を使用して宛先(少なくとも1つ)のリストを指定します。下位要素<subject>では件名、<body>では本文を指定できます(いずれも省略可能)。これらを指定しない場合、デフォルトが使用されます。
例11-4に、構成されたSMTPセッションから構成された宛先にSMTP (電子メール)メッセージを配信するSMTPアクションを示します。このアクションの構成では、カスタムの件名および本文が記述されています。件名または本文を指定しなかった場合は、デフォルト設定(ポリシーおよびアクションの詳細表示)が使用されます。
例11-4 SMTPアクションの構成のサンプル(DIAG_MODULE.xml内)
<wldf-resource xmlns="http://xmlns.oracle.com/weblogic/weblogic-diagnostics"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://xmlns.oracle.com/weblogic/weblogic-diagnostics/1.0/weblogic-diagnostics.xsd">
<name>mywldf1</name>
<watch-notification>
<!-- One or more policy configurations -->
<smtp-notification>
<name>mySMTPNotif</name>
<mail-session-jndi-name>MyMailSession</mail-session-jndi-name>
<subject>Critical Problem!</subject>
<body>A system issue occurred. Call Winston ASAP.
Reference number 81767366662AG-USA23.</body>
<recipients>administrator@myCompany.com</recipients>
</smtp-notification>
<!-- Other action configurations -->
</watch-notification>
</wldf-resource>
ポリシーおよびアクションの詳細は、アクション・メッセージの内容で示されます。
WLDFでは、「カスタマイズ可能なアクションの変数」で説明されている任意の変数を使用して、送信される電子メールのsubjectおよびbody要素をカスタマイズすることもできます。
次のWLSTの例は、カスタマイズされた件名および本文テキストを含むSMTPアクションの構成を示しています。メッセージの件名および本文では、ポリシー名と、ポリシーのトリガー日時を示すタイムスタンプを指定する変数を使用しています。
smtp=wn.lookupSMTPNotification('smtp1')
if smtp is None:
smtp=wn.createSMTPNotification('smtp1')
smtp.setMailSessionJNDIName('test.MailSession')
smtp.setSubject("WatchRule ${WatchName} alert")
smtp.setBody("Test ${WatchName} with rule ${WatchRule} fired at ${WatchTime}.")
smtp.setRecipients(["john.smith@foo.com"])
前述のSMTPアクションが実行されると、次の項目を識別する太字で示されているカスタムの件名および本文を使用して電子メールが生成されます。
SMTPアクションを実行したポリシーの名前(${WatchName}変数で表現)。この変数は、件名と本文の両方で使用されます。
ポリシー式(${WatchRule}変数で表現)
対応するポリシーのトリガー日時を識別するタイムスタンプ(${WatchTime}変数で表現)
イメージ・アクションによって、関連ポリシーのトリガーに応答して診断イメージが生成されます。イメージ・アクションには、ディレクトリとロックアウト期間の2つのオプションを構成できます。
ディレクトリ名はイメージの生成先を示します。ロックアウト期間には、最後にイメージが生成されてから新しいイメージが生成されるまでに経過する必要のある秒数を指定します。サーバーの障害と回復が繰り返される場合に、生成されるイメージの数を制限するのに便利です。
DOMAIN_HOME\servers\SERVER_NAMEを基準にした相対パスでディレクトリ名を指定できます。デフォルト・ディレクトリはDOMAIN_HOME\servers\SERVER_NAME\logs\diagnostic-imagesです。
イメージ・ファイル名は、その時点のタイムスタンプを基に生成されます(たとえば、diagnostic_image_myserver_2005_08_09_13_40_34.zip)。このアクションは、実行されるたびに別個のイメージ・ファイルを生成するので、何度でも実行可能です。
構成はDIAG_MODULE.xml構成ファイルに保存されます。例11-5に、ロックアウト期間が2分間で、イメージがDOMAIN_HOME\servers\SERVER_NAME\imagesディレクトリに生成されるように指定したイメージ・アクションの構成を示します。
例11-5 イメージ・アクションの構成のサンプル(DIAG_MODULE.xml内)
<wldf-resource xmlns="http://xmlns.oracle.com/weblogic/weblogic-diagnostics"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://xmlns.oracle.com/weblogic/weblogic-diagnostics/1.0/weblogic-diagnostics.xsd">
<name>mywldf1</name>
<watch-notification>
<!-- One or more policy configurations -->
<image-notification>
<name>myImageNotif</name>
<enabled>true</enabled>
<image-lockout>2</image-lockout>
<image-directory>images</image-directory>
</image-notification>
<!-- Other action configurations -->
</watch-notification>
</wldf-resource>
診断イメージの詳細は、「診断イメージの構成とキャプチャ」参照してください。
WLDFでは、動的クラスタで実行できる次のエラスティック・アクションが提供されます。
スケール・アップ - WLDFScaleUpActionBeanを使用して構成
スケール・ダウン - WLDFScaleDownActionBeanを使用して構成
各アクションBeanには、次の構成属性があります。
clusterName - スケーリングの必要がある動的クラスタの名前
scalingSize - 動的クラスタをスケール・アップまたはスケール・ダウンする必要がある管理対象サーバー・インスタンスの数
スケール・アップおよびスケール・ダウン・アクションでは、clusterNameパラメータで指定された動的クラスタを、scalingSizeの値で指定されたサーバーの数だけスケーリングしようと試みます。WLDFは、拡張度フレームワークと対話して、それに基づいて動的クラスタをスケーリングします。
注意:
次に注意してください:動的クラスタの自動拡張度を構成するには、スケーリング・ポリシーおよびそれに対応するエラスティック・アクションを定義するドメイン・スコープ診断システム・モジュールを作成してから、その診断モジュールのターゲットを管理サーバーにする必要があります。
スケール・アップまたはスケール・ダウンのアクションを呼び出した後に、そのスケーリング・アクションを取り消すことはできません。
次のWLSTスニペットは、スケール・アップ・アクションを構成するためのコマンドを示しています。この例で、動的クラスタmyClusterは、1つの管理対象サーバー・インスタンスの分だけスケール・アップされます。
wn=res.getWatchNotification()
scaleUp=wn.lookupScaleUpAction('scaleUp')
if scaleUp == None:
print "Creating scale up action”
scaleUp=wn.createScaleUpAction('scaleUp')
scaleUp.setScalingSize(1)
scaleUp.setClusterName(myCluster)
次の例は、myClusterでスケール・ダウン・アクションを構成するためのWLSTコマンドを示しています。
wn=res.getWatchNotification()
scaleDown=wn.lookupScaleDownAction('scaleDown')
if scaleDown == None:
print "Creating scale down action”
scaleDown=wn.createScaleDownAction('scaleDown')
scaleDown.setScalingSize(1)
scaleDown.setClusterName(myCluster)
これらのエラスティック・アクションの使用方法の詳細は、次を参照してください。
『Oracle WebLogic Server動的クラスタの拡張度の構成』のエラスティック・アクションに関する項
『Oracle WebLogic Serverクラスタの管理』の動的クラスタの拡張または縮減に関する項
スケーリング操作の開始時にはスケール・アップ操作かスケール・ダウン操作かを問わず取り消すことができないということに注意してください。カレンダ・ベースまたはポリシー・ベースのスケーリングなど、動的クラスタで自動拡張度を構成する場合、拡張度フレームワークでは、スケーリング操作の開始後にそれを取り消す方法は用意されていません。
そのため、ポストプロセッサ・スクリプト(スクリプト・インターセプタによって呼び出される)が失敗した場合には、完了したスケーリング操作の一部を元に戻すことができません。スクリプト・インターセプタおよびポストプロセッサ・スクリプトの詳細は、Oracle WebLogic Server動的クラスタの拡張度の構成のスクリプト・インターセプタの構成を参照してください。
スケール・ダウン操作中にサーバーを停止すると長い時間がかかることがあり、特に、レプリケートされていないセッションがある場合はそのようになります。長い時間がかかる可能性がある、レプリケートされていないセッションがタイムアウトになるまで、サーバーは停止されません。
スケール・ダウン操作を完了するために必要な時間の長さを制限するには、DynamicServersMBeanの次の属性を構成します。
| 属性 | 説明 |
|---|---|
タイムアウト周期(単位は秒)、動的サーバーのインスタンスを正常に停止する間に使用します。動的サーバーのインスタンスは、指定されたタイムアウト期間が経過するまでに停止しなかった場合、強制的に停止されます。 デフォルト値は0です。 |
|
動的サーバーのインスタンスを停止する間に処理中HTTPリクエストを無視するかどうかを指定します。 |
|
動的サーバーのインスタンスの停止前に永続および非永続のすべての処理中HTTPセッションが完了するまで待機するかどうかを指定します。 |
タイムアウトを指定するか、停止時に処理中HTTPセッションを無視することによって、停止時間を制限できます。ただし、処理中の残りのHTTPセッションが失われる場合があることを覚えておいてください。
スクリプト・アクションを使用して、任意の言語で記述できる外部コマンドライン・スクリプトを実行できます。
スクリプトが実行される実行環境を設定するには、WLDFScriptActionBeanの次の属性を構成します。
PathToScript - スクリプトへのフルパス(DOMAIN_HOME/bin/scriptsディレクトリに存在する必要があります)
WorkingDirectory - WebLogic Serverプロセスの実行元のディレクトリ(通常はドメイン・ルート・ディレクトリです)。
Environment - 子プロセスに設定する環境変数のマップ
Parameters - スクリプトに渡すパラメータまたはコマンド・オプションの配列
Timeout - スクリプト・アクションが実行を完了するための時間(秒単位)。デフォルトでは、タイムアウトは0で、スクリプト・アクション・タイムアウトは無効です。
トリガーされたポリシーによってスクリプト・アクションが実行されると、WLDFによって構成済のスクリプトが呼び出され、構成済のスクリプトのIDで実行されます。スクリプト・プロセスは、それを生成したWebLogic Serverプロセスの子プロセスとして実行されます。そのため、スクリプト・プロセスは、WebLogic Serverプロセスと同じオペレーティング・システムIDを持ちますが、どの親プロセス環境も継承しません。
次の例では、WLSTを使用したスクリプト・アクションの構成を示します。
wn=res.getWatchNotification()
actionName="myaction"
action = wn.lookupScriptAction(actionName);
if action is None:
action = wn.createScriptAction(actionName);
action.setWorkingDirectory("somedir");
action.setPathToScript("myScript.sh");
action.setParameters(["param1", "param2"]);
action.setTimeout(300);
ヒープ・ダンプ・アクションを使用して、ポリシー式で定義された特定の実行時条件を満たした場合にヒープ・ダンプを取得できます。各ヒープ・ダンプはHPROF形式で生成されます。これは、JDKで利用可能なjmapユーティリティなどのツールで分析できます。
ドメイン・スコープの診断システム・モジュール、つまり、ドメイン・パーティションにデプロイされた診断システム・モジュールで、WLDFHeapDumpActionBeanとWLDFServerDiagnosticMBeanを構成することで、ヒープ・ダンプ・アクションを作成します。パーティションを対象とする診断システム・モジュールではこのアクションは使用できません。ヒープ・ダンプ・アクションを構成する場合は、次のことを指定できます。
参照されないオブジェクト(つまり、ガベージが収集されていないか、ガベージ・コレクションを待機している)のみを含めるかどうか。WLDFHeapDumpActionBeanのLiveSetOnly属性で指定します。デフォルト値はtrue。
ヒープ・ダンプを格納する、各サーバーの診断ダンプ・ディレクトリの場所。このディレクトリは、WLDFServerDiagnosticMBeanのDiagnosticDumpsDir属性で指定できます。
保持するヒープ・ダンプ・ファイルの数。生成されたヒープ・ダンプでファイル・システムがいっぱいにならないようにします。この数は、WLDFServerDiagnosticMBeanのMaxHeapDumpCount属性で指定できます。デフォルト値は8です。
生成されたヒープ・ダンプ・ファイルには、次の構文を使用して名前が付けられます。
HeapDump_$SERVER_$MODULE_$POLICY_$ACTION_$timestamp.hprof
前の構文では:
$SERVERは、ヒープ・ダンプを生成したWebLogic Serverインスタンスの名前を表します。
$MODULEは、アクション構成を含む診断システム・モジュールの名前を表します。
$POLICYは、ヒープ・ダンプ・アクションを実行したポリシーの名前を表します。
$ACTIONは、WLDFHeapDumpActionBeanの名前を表します。
$timestampは、ヒープ・ダンプが生成された時刻を表します。形式はyyyy_mm_dd_HH_MM_SSのようになります。
注意:
次に注意してください:
ヒープ・ダンプには機密データが含まれる場合があります。そのため、ヒープ・ダンプが生成されるディレクトリに必ず適切なアクセス保護を設定するようにしてください。
ヒープ・ダンプ・アクションが進行中の場合は、別のヒープ・ダンプ・アクションによるヒープ・ダンプ生成の試みは拒否され、サーバー・ログにメッセージが生成されます。
WebLogic Server管理コンソールの使用によるヒープ・ダンプ・アクションの作成方法と構成方法の詳細は、Oracle WebLogic Server管理コンソール・オンライン・ヘルプのヒープ・ダンプ・アクションの作成とヒープ・ダンプ・アクションの構成を参照してください。
jmapユーティリティについては、http://docs.oracle.com/javase/8/で入手可能なJava SE 8ドキュメントで説明されています。
例11-6 ヒープ・ダンプ・アクションの構成のサンプル
次のWLSTの例は、ヒープ・ダンプ・アクションの構成を示しています。
# Start an edit session in edit tree
edit()
startEdit()
cd("/")
if cmo.lookupWLDFSystemResource("mywldf") == None:
print "Creating WLDF resource"
cmo.createWLDFSystemResource("mywldf")
cd("/WLDFSystemResources/mywldf/WLDFResource/mywldf/WatchNotification/mywldf")
# Create a heap dump action
cmo.createHeapDumpAction('myHeapDump')
cd("HeapDumpActions/myHeapDump")
# Set it to capture a full heap, not just the live setLiveSetOnly - default is "true"
cmo.setLiveSetOnly(false)
save()
activate()
スレッド・ダンプ・アクションを使用して、対応するポリシーで指定されている実行時条件を満たしたときに、構成された時間間隔で区切り、特定の数のスレッド・ダンプを取得できます。各スレッド・ダンプ・ファイルは個別のテキスト・ファイルで生成されます。
ドメイン・スコープの診断システム・モジュール、つまり、ドメイン・パーティションにデプロイされた診断システム・モジュールで、WLDFThreadDumpActionBeanとWLDFServerDiagnosticMBeanを構成することで、スレッド・ダンプ・アクションを作成します。パーティションを対象とする診断システム・モジュールではこのアクションは使用できません。スレッド・ダンプ・アクションを構成する場合は、次のことを指定します。
取得するスレッド・ダンプの数。WLDFThreadDumpActionBeanのThreadDumpCount属性で指定します。デフォルト値は3です。
連続するスレッド・ダンプ間の間隔。WLDFThreadDumpActionBeanのThreadDumpDelaySeconds属性で指定します。デフォルト値は10秒。
スレッド・ダンプが格納される、各サーバーの診断ダンプ・ディレクトリの場所。WLDFServerDiagnosticMBeanのDiagnosticDumpsDir属性で指定できます。
保持するスレッド・ダンプ・ファイルの数。生成されたスレッド・ダンプでファイル・システムがいっぱいにならないようにします。この数は、WLDFServerDiagnosticMBeanのMaxThreadDumpCount属性を使用して指定します。デフォルト値は100です。
生成されたスレッド・ダンプ・ファイルには、次の構文を使用して名前が付けられます。
HeapDump_$SERVER_$MODULE_$POLICY_$ACTION_$timestamp.hprof
前の構文では:
$SERVERは、スレッド・ダンプを生成したWebLogic Serverインスタンスの名前を表します。
$MODULEは、アクション構成を含む診断システム・モジュールの名前を表します。
$POLICYは、スレッド・ダンプ・アクションを実行したポリシーの名前を表します。
$ACTIONは、WLDFThreadDumpActionBeanの名前を表します。
$timestampは、スレッド・ダンプが生成された時刻を表します。形式はyyyy_mm_dd_HH_MM_SSのようになります。
注意:
次に注意してください:
スレッド・ダンプには機密データが含まれる場合があります。そのため、スレッド・ダンプが生成されるディレクトリに必ず適切なアクセス保護を設定するようにしてください。
スレッド・ダンプ・アクションが進行中の場合は、別のスレッド・ダンプ・アクションによるスレッド・ダンプ生成の試みは拒否され、サーバー・ログにメッセージが生成されます。
WebLogic Server管理コンソールの使用によるスレッド・ダンプ・アクションの作成方法と構成方法の詳細は、Oracle WebLogic Server管理コンソール・オンライン・ヘルプのスレッド・ダンプ・アクションの作成とスレッド・ダンプ・アクションの構成を参照してください。
例11-7 スレッド・ダンプ・アクションの構成のサンプル
次のWLSTの例は、スレッド・ダンプ・アクションの構成を示しています。
# Start an edit session in edit tree
edit()
startEdit()
cd("/")
if cmo.lookupWLDFSystemResource("mywldf") == None:
print "Creating WLDF resource"
cmo.createWLDFSystemResource("mywldf")
cd("WLDFSystemResources/mywldf/WLDFResource/mywldf/WatchNotification/mywldf")
# Create a Thread Dump action
cmo.createThreadDumpAction('myThreadDump')
cd("ThreadDumpActions/myThreadDump")
# set it to capture 5 dumps at 30 second intervals
cmo.setThreadDumpCount(5)
cmo.setThreadDumpDelaySeconds(30)
save()
activate()
