Own Sensor via Sensorpacks
We want to remove our list with doFilters.
We removed the javax.servlet.Filter, the javax.servlet.ServletRequest sensor was used.
Even when we added our own JBoss class.
We added it in the sensor pack of servlets and our own sensor, but it failed to work.
The javax.servlet.ServletRequest always got priority.
The idea was to get our own Filter as entry point.
Hi Danny,
you are talking about the javax.servlet.Filter.doFilter(...) method? Have you restarted the JBoss && double checked the deployed sensors (from agent overview). If you take a look there you should see a sensor column that tells you which sensor pack is used. In my case (using EasyTravel and changed nothing form standard it shows: Sevlet and EndUser Tagging). Double check here also if your placed Filter is in place and shown as first in the list.
Hope that helps
Herwig
Thank you for you quick response.
We tried it but without effect.
Thanks you, but will not look in to this further.
hi Danny,
I did not fully understand what you tried, but from what I understand, you want to get rid of the many doFilter() nodes in the PurePath, correct?
simplest way to do so would be to go into client debug mode and enable delegation suppression on the Filter class rule of the Servlet Sensor (if unclear, I could give you more detailed steps).
but just FYI, this will also be default behavior starting with the upcoming dynaTrace 6.0.
best, Christian
Hi Christian,
Please provide the detailed steps. If I understand correctly it will make this tree look pretty in the PurePath :
| Level | Method | Error Type | Argument | Exec Total [ms] |
| 1 | doFilter(ServletRequest request, ServletResponse response, FilterChain filterChain) | /URL/ | 193,6123 | |
| 2 | doFilter(ServletRequest request, ServletResponse response, FilterChain chain) | 193,5513 | ||
| 3 | doFilter(ServletRequest servletRequest, ServletResponse servletResponse, FilterChain chain) | 193,5144 | ||
| 4 | doFilterHttp(HttpServletRequest, HttpServletResponse, FilterChain) | 193,1558 | ||
| 5 | doFilter(ServletRequest, ServletResponse) | 193,1558 | ||
| 6 | doFilter(ServletRequest servletRequest, ServletResponse servletResponse, FilterChain chain) | 193,1558 | ||
| 7 | doFilterHttp(HttpServletRequest, HttpServletResponse, FilterChain) | 192,5357 | ||
| 8 | doFilter(ServletRequest, ServletResponse) | 192,5357 | ||
| 9 | doFilter(ServletRequest servletRequest, ServletResponse servletResponse, FilterChain chain) | 192,5357 | ||
| 10 | doFilterHttp(HttpServletRequest, HttpServletResponse, FilterChain) | 192,5118 | ||
| 11 | doFilter(ServletRequest, ServletResponse) | 192,5118 | ||
| 12 | doFilter(ServletRequest servletRequest, ServletResponse servletResponse, FilterChain chain) | 192,5118 | ||
| 13 | doFilterHttp(HttpServletRequest, HttpServletResponse, FilterChain) | 192,4833 | ||
| 14 | doFilter(ServletRequest, ServletResponse) | 192,4833 | ||
| 15 | doFilter(ServletRequest servletRequest, ServletResponse servletResponse, FilterChain chain) | 192,4833 | ||
| 16 | doFilterHttp(HttpServletRequest, HttpServletResponse, FilterChain) | 192,4592 | ||
| 17 | doFilter(ServletRequest, ServletResponse) | 192,4592 | ||
| 18 | doFilter(ServletRequest servletRequest, ServletResponse servletResponse, FilterChain chain) | 192,4592 | ||
| 19 | doFilterHttp(HttpServletRequest, HttpServletResponse, FilterChain) | 192,4084 | ||
| 20 | doFilter(ServletRequest, ServletResponse) | 192,4084 | ||
| 21 | doFilter(ServletRequest request, ServletResponse response, FilterChain filterChain) | 192,4084 | ||
| 22 | doFilter(ServletRequest servletRequest, ServletResponse servletResponse, FilterChain chain) | 192,3838 | ||
| 23 | doFilterHttp(HttpServletRequest, HttpServletResponse, FilterChain) | 192,3534 | ||
| 24 | doFilter(ServletRequest, ServletResponse) | 192,3534 | ||
| 25 | doFilter(ServletRequest servletRequest, ServletResponse servletResponse, FilterChain chain) | 192,3534 | ||
| 26 | doFilterHttp(HttpServletRequest, HttpServletResponse, FilterChain) | 192,2819 | ||
| 27 | doFilter(ServletRequest, ServletResponse) | 192,2819 | ||
| 28 | doGet(HttpServletRequest request, HttpServletResponse response) | 192,2819 |
Edit: removed the link to avoid confusion, thx Andi.
detailed steps:
- go into dynaTrace Client debug mode (Ctrl-Shift-F9), you should see "[DEBUG]" in the bottom right of the Client
- go to dynaTrace Server settings -> Sensor Packs
- edit the Servlet Sensor
- edit the class rule for javax.servlet.Filter
- check "Use Delegation Suppression"
- hit OK multiple times
- restart the agents (= applications) or do a Hot Sensor Placement on them
with this change you should get rid of the doFilter() calls. the doFilterHttp() calls should be auto-sensor nodes, right?
please let us know if this worked for you. anyway, this will be default behavior in dynaTrace 6.0.
best, Christian
Hi Christian - FYI - Patrick might not be able to see that linked page because it references a forum entry on our internal forum
Andi
Hi Christian,
Out of curiosity does enabling delegation suppression keep the root (1st) dofilter() and then gets rid of other invocations or is it as good as performing a global exclude? Also are there any advantages/disadvantages of doing this? This is just for my learning 
Thanks,
Srikar
hi Srikar,
right, delegation suppression will suppress the subsequent (child) nodes (which are also instrumented by the same class rule) after the first call until the next instrumented method is called. global exclude is something completely different as it excludes specific methods globally.
advantages:
- you get less nodes in such call chains
disadvantages:
- you get less nodes in such call chains
hope this helps,
Christian
Since we're in "nerd mode": isn't it also the case that delegate suppression analysis is done at the agent level, meaning that this can cause a tiny bit more overhead on the agent since we are in fact doing "data processing" on the agent (which we say we never do)? This is as opposed to processing during PP assembly, tossing out those nodes that are to be suppressed.
Comments Christian?
hi Rob,
no, delegation suppression does not increase overhead, on the contrary.
<nerd_mode>
delegation suppression is just based on ID comparisons, which are done anyway, so there's not more code executed because of delegation suppression.
on the contrary, because delegation suppression will not collect data for nodes which are suppressed, it will reduce the executed code and also the overhead.
</nerd_mode>
best, Christian
Sweet! That's great to know. I always hesitated a bit before using it as an option. The reduced data was always appealing, but I didn't realize how efficient it was to process. Thanks Christian!!
Thank you all for your responses. We tried to this, but our own filter which we wanted to see, was no longer being picked up. Even when we redeclared it in the sensor back.
I think we'll just wait until 6. Thank you for all your help.
Kind regards,
Danny
Danny,
I still don't understand what you really want to achieve. however, if you followed my steps and are not satisfied with the result, chances are pretty high that you will get the exact same result with dynaTrace 6.0.
so if you can show us what you want to achieve by providing us some exported PurePaths or an explanatory example, we may help you here.
best, Christian
Hello Christian,
I deleted my changes and tried your step by step tutorial and everything worked.
Thank you.
Kind regards,
Danny
Welcome the
Dynatrace Community Forums
Check out the Forum User Guide and Forum Guidelines to learn how to get started.Community Member of the Month
August 2017
Announcing Dynatrace's Community Member of the Month for August 2017, Rick B.! Click here to read more! 