Using the Inspection View and options to help debugging VSE transactions.
Article ID: 43193
Updated On:
Products
Issue/Introduction
How to use the Inspection View and options to help debugging transactions.
Is there a way to see the standard properties and custom properties set by the VS in VSE on the server.
Environment
All supported DevTest releases.
Cause
N/A
Resolution
When opening the Inspection View there are two options:
. Matching View
. Request Event Details
The information shown in these tabs is impacted by the log level set in the logging.properties file with the property below:
log4j.logger.VSE
This property keeps a separate log for VSE transaction match/no-match events. Having a separate log makes debugging much easier. Change INFO to WARN for production/performance systems. Do not simply comment out the following line. Explicitly set the log level to OFF or WARN instead of INFO.
Note that if there are no transactions against the VS, then there will be no Inspection View details either.
Matching View
The Matching View lists recent requests that the virtual services processed. When you select a request, the dialog shows a description of how the request was or was not matched.
The same information is recorded in the vse_matches.log file. If any events were associated with the selected request, they display at the bottom of the panel.
As mentioned before, the information displayed in the Matching view depends on how VSE logger is set.
If the property log4j.logger.VSE is set to DEBUG:
log4j.logger.VSE=DEBUG, VSEAPP
We will see all the events in the “Events” panel, like in the image below:
The “Long Info” column shows the source request details and what matched or didn’t match.
The "Timestamp" column can be used to troubleshoot performance issues.
If the property log4j.logger.VSE is set to INFO:
log4j.logger.VSE=INFO, VSEAPP
DevTest won’t generate as much log as in DEBUG mode and we won’t have information to be displayed in the Events panel. See image:
If the property log4j.logger.VSE is set to WARN or ERROR:
log4j.logger.VSE=WARN, VSEAPP
log4j.logger.VSE=ERROR, VSEAPP
DevTest will only generate log when there is a WARN or ERROR scenario. In this level we won’t see any transactions in the Inspection View/Matching tab.
There is a property that controls how many VSE matching related events are buffered. These events are the source for the "Matching" tab of the VS model inspection page in the VSE dashboard.
lisa.vse.match.event.buffer.size
The default value is 100, but it is possible to increase this number – with caution, it can impact memory usage. To increase its value you can add this property to the local.properties file and set it to 200.
The number of events is per VS model so if you have 2 VS models deployed with the default event buffer size of 100, then a total of 200 events will be buffered.
If the number of events per VS is higher than the value specified with this property then we won’t be able to see some events in the matching tab.
This can happen when a VSI has too many transactions. When a request is sent to the VSM the VSE checks each transaction until it finds one that matches. For every check performed the VSE generates events. If the request that was sent doesn't match one of the first transactions in the VSI, we are going to get several events. If there is no match, it will go through the whole VSI and generate events for every check. In DEBUG mode, DevTest logs every analysis the VSE performs until it finds the right transaction to match. These events are stored in the vse_matches and VS_<VSMName> log files.
If a request is being forwarded to the live system we won’t be able to see the transaction in the matching tab – that happens because the VSI is not verified, the request goes directly to the live system.
Request Event Details View
The Request Event Details view shows the list of inbound requests, the ones that caused the virtual service to error out and the good requests. When you select a request, the list of VSM steps that was executed is shown. To see the events that occurred during processing for that step (similar to the ITR), select a step.
The information displayed on this tab is also impacted by the log level set in the logging.properties file – DEBUG, INFO or WARN.
Sometimes we won’t see the remaining VSM steps executed in the “Execution Step Events” panel or we will see the steps as “(unknown)”, as highlighted in the image.
When that happens we can add the property below to the local.properties file and increase its value:
lisa.vse.request.event.set.buffer.size
This property controls how many inbound VSE requests for which a full set of DevTest events is buffered. The default value is 50.
If we increase this property value – with caution, we will be able to get the whole list of steps executed. You can increase it from 50 to 200.
lisa.vse.request.event.set.buffer.size=200
If you are still having problems to see the step required, try to increase it to 500.
lisa.vse.request.event.set.buffer.size=500
It also depends on how many events your virtual service is generating, if there are too many assertions and filters in the VSM, it could be that you need to increase this buffer a little more.
The image below shows what happened after the value of the property above was increased.
Depending on the request size, we will see the transactions body as “_TRUNCATED_” in the Inspection View/Request Event Details:
To change this behavior add the property below to the VirtualServiceEnvironmentService.vmoptions or VirtualServiceEnvironment.vmoptions file:
-Dlisa.testexec.lite.longMsgLen=10000
Save the vmoptions file and restart the VSE Service.
Additional Information
The steps on this document is for debugging purpose only. The content of this document is not recommended for performance environment. The logging can slow down systems with high transaction rates.
There is no need to restart DevTest components after modifying the logging.properties file.
The lisa.properties file should never be modified.
The properties referenced here should be added to the local.properties and vmoptions file only.
After editing local.properties and vmoptions file, DevTest components should be restarted.
Feedback
