[Java, WLS, FMW] Using Diagnostic Context for Correlation

原文はこちら。
https://blogs.oracle.com/WebLogicServer/entry/using_diagnostic_context_for_correlation
WebLogic診断フレームワーク（WLDF）とFusion Middleware Diagnostics Monitoring System（DMS）はログやJava Flight Recorder（JFR）といった診断成果物に関連する相関情報を提供します。
Oracle® Fusion Middleware Configuring and Using the Diagnostics Framework for Oracle WebLogic Server 12c (12.2.1)
Introduction and Roadmap
WebLogic Diagnostics Framework (WLDF)
http://docs.oracle.com/middleware/1221/wls/WLDFC/intro.htm#WLDFC107
Oracle® Fusion Middleware Tuning Performance Guide 12c (12.2.1)
DMS Execution Context
http://docs.oracle.com/middleware/1221/core/ASPER/dms.htm#ASPER310
Oracle® Fusion Middleware Configuring and Using the Diagnostics Framework for Oracle WebLogic Server 12c (12.2.1)
Using WLDF with Java Flight Recorder
http://docs.oracle.com/middleware/1221/wls/WLDFC/using_flightrecorder.htm#WLDFC423
相関情報はWebLogic Serverプロセス内のスレッド間でリクエストとともに流れます。また、（OTDからDatabaseというような）他のOracle製品とのプロセス境界間も流れます。この相関情報は一意のIDの形で公開され、システムを流れる特定のリクエストを識別、相関付けするために利用できます。この情報はフローの順序の詳細も提供します。

相関IDは以下のようなものです。
  • 診断コンテキストID (DCID) と 実行コンテキストID (ECID)
    これはシステムを流れるリクエストを識別する一意の識別子です。利用しているのがWLDFかDMSかでIDの名前が異なりますが、実体は同じIDです。Oracle製品で幅広く使われている名前がECIDなので、ここでもECIDという名前を使います。
  • リレーションシップID (RID)
    このIDはフロー（やツリー）でリクエストが現在どこにいるかを示すために使うものです。このID自体はタスクツリーで各タスクの場所を示す順序セット順序付けされた数値の集合で、先頭の数字は通常はゼロです。先頭の数値の1は、全体のサブタスク・ツリー内でサブタスクの場所を追跡できないことを示します。
Oracle® Fusion Middlewareパフォーマンスのチューニング・ガイド 12c (12.1.3)
DMS実行リクエストおよびサブタスク
http://docs.oracle.com/cd/E57014_01/core/ASPER/dms.htm#ASPER311
Oracle® Fusion Middleware Tuning Performance Guide 12c (12.2.1)
DMS Execution Requests and Sub-Tasks
http://docs.oracle.com/middleware/1221/core/ASPER/dms.htm#ASPER311 
これらの相関IDはかなりの長期間にわたって存在します。12.2.1での新規事項は、WLDFがDMSのいくつかの機能をカバーするようになっています。
  1. DMSのRelationshipID (RID)機能をサポート
  2. HTTPに載って流入する相関情報のハンドリングが可能
  3. WebLogic HTTPクライアント利用時、相関をHTTPに載せて伝播可能
  4. 非継承Contextのコンセプト（今回は説明しませんが、このブログの別のエントリで取り上げられることでしょう）
このエントリでは、シンプルなシナリオを通じて、管理者がこの相関情報を使って迅速に特定のリクエスト・フローに関連する利用可能なデータを見つける方法をご紹介します。下図は基本的なシナリオを示しています。

図中のそれぞれの矢印は、コンテキスト伝播が発生し得る箇所を示していますが、この例では、伝播は青の矢印の箇所でのみ発生しています。この理由は、今回の例ではコンテキストを供給しないブラウザのクライアントを使っているためで、今回の場合はコンテキストはMySimpleServletが呼ばれた時点で生成されます。注意いただきたいのは、コンテキストを伝播できるクライアントが呼んだ場合、コンテキストはMySimpleServletを伝播することができる、ということです（例えばDMSが有効化されているHTTPクライアント、12.2.1以後のWebLogic HTTPクライアント、OTDなど）

今回のアプリケーションでは、DiagnosticContextHelper APIを使用して、ECID/RIDの値を各レベルで問い合わせ、サーブレットがこれらの値を返します。実際のアプリケーションではこんなことはしません。あくまでもサンプルの目的であり、サーブレットは値を表示することができます。
Oracle Fusion Middleware Java API Reference for Oracle WebLogic Server 12c (12.2.1)
Class DiagnosticContextHelper
http://docs.oracle.com/middleware/1221/wls/WLAPI/weblogic/diagnostics/context/DiagnosticContextHelper.html 
EJBをハードコーディングし、サーブレットへのリクエストにクエリ文字列が含まれている場合に例外をスローするようにしています。アプリケーションはクエリ文字列を含むリクエストを検知した場合、警告をログに書き込みます。この警告ログメッセージは自動的にECID/RIDの値を含めるようになっています。アプリケーションは、ECID/RID取得のために特別なことをする必要はありません。
ここでつかっているアプリケーションと基本的な使い方を含めてここから入手できます。

まず、失敗しないURL (http://myhost:7003/MySimpleServlet/MySimpleServlet) でサーブレットを呼び出してみましょう。

上図から、すべてのアプリケーションコンポーネントが同じECID(f7cf87c6-9ef3-42c8-80fa-e6007c56c21f-0000022f)をレポートしていることがわかります。また、各コンポーネントが報告しているRIDは異なっており、各コンポーネントの関係は以下のようになっていることがわかります。

続いて、失敗するURL (http://myhost:7003/MySimpleServlet/MySimpleServlet?fail) でサーブレットを呼び出してみます。

EJBが失敗をレポートしていることがわかります。このサンプルアプリケーションでは、ECIDが障害が発生したフロー全体で"f7cf87c6-9ef3-42c8-80fa-e6007c56c21f-00000231"です。実際のアプリケーションでは、そうではないでしょう。管理者はおそらくほとんど最初に様々なサーバーログで報告されている警告を見るはずで、そこでこうした警告とともにECIDを見るはずです。この例ではECIDを知っているので、grepを使って、これらの警告がどういうものか、そうした警告にはECID/RIDがログで報告されていることを調べることができます。

障害があったことを確認すると、管理者は、関係しているすべてのサーバーからJFRデータをキャプチャします。実際のシナリオでは、管理者はログの警告や、自動通知やデータをキャプチャするように構成されたポリシーおよびアクション（以前はWatch（監視）およびNotification（通知）として知られていました）があるかもしれません。今回の例では、WLSTスクリプトには、JFRデータのキャプチャが含まれています。
Oracle® Fusion Middleware Configuring and Using the Diagnostics Framework for Oracle WebLogic Server 12c (12.2.1)
Configuring Policies and Actions
http://docs.oracle.com/middleware/1221/wls/WLDFC/config_watch_notif.htm#WLDFC188
ここで、みなさんがJFRとJava Mission Control（JMC）に精通されており、WebLogic Plugin for JMCをインストール済みであることを前提とします。



我々は障害に関連したECID（実際の場合にはこれはログの警告からになるでしょう）を持っているので、JMCでJFRのデータを読み出し、直接WebLogicタブグループのECIDタブに移動します。このタブには、初期状態で管理サーバのJFRからのフィルタリングされていないビューが表示されています。これにはこのJFR記録に存在するすべてのECIDが含まれています。

つづいて、"f7cf87c6-9ef3-42c8-80fa-e6007c56c21f-00000231"というECIDをコピーし、"Filter Column"にペーストします。

特定のECIDのみを表示して、当該ECIDに関連するJFR記録に存在するJFRイベントを選択することができます。
右クリックしてこれらの関連するイベントをJMCの「操作セット」機能に追加することができます。一度「操作セット」で実施すれば、JMCの他のビューも操作セットのみを表示するよう設定できます。詳しくは以下のドキュメントをご覧ください。
Oracle® Fusion Middleware Configuring and Using the Diagnostics Framework for Oracle WebLogic Server 12c (12.2.1)
Using WLDF with Java Flight Recorder
http://docs.oracle.com/middleware/1221/wls/WLDFC/using_flightrecorder.htm#WLDFC423
以下は、ejbServerとwebappServer JFRデータに対して同じフィルタ・ビューを示すスクリーンショットです。



今回の例では、意図的に発生させた失敗がアプリケーションコードにありました。結果として、ここで参照したJFRのデータからサンプル目的で全体のフローがわかりますが、この特定のケース自体での障害に対し、多くの洞察を与えるものではありません。障害で発生したJFRイベントは、何が失敗の原因になったのか、障害までの間に何が起こったのかを知るよい方法です。

詳細情報は以下のドキュメントをご覧ください。
-
カテゴリ ,

0 件のコメント:

コメントを投稿

登録: コメントの投稿 (Atom)