This content has been marked as final. Show 6 replies
When I put this file into my MEAT-INF EAR, the deploying is OK but I'cant see nothing into WLDF console extension ?Are there events in the WLDF Archive for the deployed monitor? Have you enabled Instrumentation through a WLDF System Resource targeted to the server?
In order to view instrumentation data through the console extension,
- the WLDF DyeInjection monitor needs to be deployed through the WLDF SystemResouce at server scope as well.
- the application monitors must be of the "Around" type with the TraceElapsedTimeAction assigned to them
Then the console extension can build a call-tree of known requests that have passed through the server, based on each request's Diagnostic Context ID.
If you truly want to view information from the DisplayArgumentsAction, you will need to view the data stored in the WLDF Archive using the WLS Console, or WLST. In the Console, you can view the data by navigating to Diagnostic Modules -> Logs and selecting the EventsDataArchive "log". On the resulting page you can customize your views (the default view only shows you the last 5 minutes of data in the archive, I believe).
Using WLST you can use the exportDiagnosticData (offline) or exportDiagnosticDataFromServer (online) functions. See the WLST help on these functions for details on how to use them.
Thank you for your answer, it was very helpfull !
I was able to instrument my methods using the around type and the TraceElapsedTimeAction action.
My Server was corectly configured to show the request into the wldf console extension.
But I have still some questions about WLDF:
Is it possible to get the information of "request" tab of the WLDF console extension from MBeans ? In my company we used an internal tool for JMX platform monitoring, when I would like to have the instrumentation data as standard JMX.
Moreover, I tried to export data using WLST, it works ! but I can't see nothing ito my console.
Another question, is there any XSL document to beautiful the export data xml file ?
Thank you for your help,
Thank you for your answer, it was very helpfull !Glad to be of help.
But I have still some questions about WLDF:That's an interesting proposal...I'll bring it up with my teammates and see if we can enter it as an enhancement request. You can programmatically access the data from the instrumentation archive, but you would still have to build the call tree yourself. I can see how providing this kind of correlation data would be helpful for building custom visualizations and analytics.
Is it possible to get the information of "request" tab of the WLDF console extension from MBeans ? In my company we used an internal tool for JMX platform monitoring, when I would
like to have the instrumentation data as standard JMX.
There is also a great article posted by Phil Aston at http://www.oracle.com/technology/pub/articles/dev2arch/2007/09/mining-wldf-xslt.html, which shows how to build a call tree using the WLST extractDiagnosticData() functions and XSL transforms. It might give you an option to extract call trees for programmatic use.
Another question, is there any XSL document to beautiful the export data xml file ?No, we provide a schema, but no XSL transforms. Most people would have their own styles that they would prefer to apply.
No problem...I should also mention that all the information that Phil uses in his article also is available programmatically via the WLDF Accessor API. The Accessor API is available through the WLS ServerRuntime MBeanServer, and provides programmatic access to Instrumentation and Harvested MBean data. So, you could reverse-engineer what Phil is doing to cull and correlate the data and apply it to the raw data retrieved through the Accessor API. The algorithm would be the same, but the implementation would be different.
The Accessor returns data as tabular data (i.e., like rows from a database). You can perform SQL-like queries to identify what data you are interested in, etc. It is the same mechanism we use both to implement the exportDiagnosticDataFromServer() WLST functions as well as Dashboard's Request Browser functionality. As with other Runtime MBeans, the API is available through WLST in the serverRuntime tree, so you could also script access in Jython if you wanted to.
See http://edocs.bea.com/wls/docs103/wldf_configuring/access_diag_data.html for details on the Accessor API.
It sounds like you have an interesting use case. Would you mind sending me a paragraph or so on the the overall goal and and architecture you are implementing? We are always looking for new ways to enhance the feature set and make the services easier to use.