BrowserAgent extention in Jboss Agent for Wildfly does not import snippet to browser pages

Products

• DX Application Performance Management

Issue/Introduction

Experience Collector 2.5

APM 10.8

Jboss Agent 2023.3

Wildfly 24.1

Jboss Agent with BrowserAgent extension configured in Wildfly standalone.conf and loaded with standalone.sh

We can see Performance Metrics coming from Jboss Agent into APM Enterprise Manager, but the Metric Group Business Service is missing which will have the BrowserAgent Metrics. In the Browser Developer Tools (F12) we do not see the browserAgent snippet added. 

 

Environment

Release : 23.1

Resolution

The snippet auto-injection works by now.

Only not  for the WildFly start pagehttp://address:port  (URL pattern “.*”) where we have starting the tests. On the application for examplehttp://address:port/MathClient it works fine, probably

It is per design, so it is OK.

***

I saw your note last night but wanted to answer this internally before closing. I asked internally but no response. So, I dug deeper.

 

My guess is that you are using this parameter https://techdocs.broadcom.com/us/en/ca-enterprise-software/it-operations-management/dx-apm-agents/SaaS/java-agent/configure-the-browser-agent/browser-agent-advanced-configuration/browser-agent-properties.html/

introscope.agent.browseragent.response.decoration.includeURLsRegex

Two of the three KBs have examples showing wildcards. So it is supported. These are older KBs but should still be good. Try these steps out and failing that, please open a new case.

https://knowledge.broadcom.com/external/article?articleId=91899
https://knowledge.broadcom.com/external/article?articleId=91903  has example
https://knowledge.broadcom.com/external/article?articleId=91917  has example

***

Unfortunately we still don’t see browser metrics on the DXC logstash sub-tree, but this is another story which we need to clarify yet.

***

the BA metrics problem is solved now too

in our test environment after changed to HTTP instead of HTTPS for the WildFly sites. The reason was protocol mismatch: HTTPS on the WildFly, but HTTP on the DxC. Of course in the end-customer environment must be both changed to HTTPS so usage of self-signed certificates on DxC would be impossible from my point of view, but this is via CORS, etc. restrictions.