We figured out that adding the next 2 lines (enabling jmx instrumentation) in the IntroscopeAgent.profile solve the issue.
introscope.agent.jmx.enable=true
introscope.agent.jmx.name.filter=ThreadPoolRuntime:ExecuteThreadIdleCount,ThreadPoolRuntime:ExecuteThreadTotalCount,ThreadPoolRuntime:HoggingThreadCount,ThreadPoolRuntime:PendingUserRequestCount,ThreadPoolRuntime:QueueLength,ThreadPoolRuntime:StandbyThreadCount,ThreadPoolRuntime:Throughput,JDBCDataSourceRuntime*:ActiveConnectionsCurrentCount,JDBCDataSourceRuntime*:ActiveConnectionsHighCount,JDBCDataSourceRuntime*:ConnectionDelayTime,JDBCDataSourceRuntime*:ConnectionsTotalCount,JDBCDataSourceRuntime*:CurrCapacity,JDBCDataSourceRuntime*:CurrCapacityHighCount,JDBCDataSourceRuntime*:FailedReserveRequestCount,JDBCDataSourceRuntime*:FailuresToReconnectCount,JDBCDataSourceRuntime*:HighestNumAvailable,JDBCDataSourceRuntime*:HighestNumUnavailable,JDBCDataSourceRuntime*:LeakedConnectionCount,JDBCDataSourceRuntime*:NumAvailable,JDBCDataSourceRuntime*:NumUnavailable,JDBCDataSourceRuntime*:WaitingForConnectionCurrentCount,JDBCDataSourceRuntime*:WaitingForConnectionFailureTotal,JDBCDataSourceRuntime*:WaitingForConnectionHighCount,JDBCDataSourceRuntime*:WaitingForConnectionSuccessTotal,JDBCDataSourceRuntime*:WaitingForConnectionTotal,JDBCDataSourceRuntime*:WaitSecondsHighCount,JMSDestinationRuntime*:MessagesCurrentCount,JDBCOracleDataSourceRuntime:ActiveConnectionsCurrentCount,JDBCOracleDataSourceRuntime:ActiveConnectionsHighCount,JDBCOracleDataSourceRuntime:ConnectionDelayTime,JDBCOracleDataSourceRuntime:ConnectionsTotalCount,JDBCOracleDataSourceRuntime:CurrCapacity,JDBCOracleDataSourceRuntime:CurrCapacityHighCount,JDBCOracleDataSourceRuntime:FailedReserveRequestCount,JDBCOracleDataSourceRuntime:FailuresToReconnectCount,JDBCOracleDataSourceRuntime:HighestNumAvailable,JDBCOracleDataSourceRuntime:HighestNumUnavailable,JDBCOracleDataSourceRuntime:LeakedConnectionCount,JDBCOracleDataSourceRuntime:NumAvailable,JDBCOracleDataSourceRuntime:NumUnavailable,JDBCOracleDataSourceRuntime:WaitingForConnectionCurrentCount,JDBCOracleDataSourceRuntime:WaitingForConnectionFailureTotal,JDBCOracleDataSourceRuntime:WaitingForConnectionHighCount,JDBCOracleDataSourceRuntime:WaitingForConnectionSuccessTotal,JDBCOracleDataSourceRuntime:WaitingForConnectionTotal,JDBCOracleDataSourceRuntime:WaitSecondsHighCount
So, the JMX metrics appears in the workstation again as they used to appear with the APM 10.5 agent.
However, if we use the remote jmx extension, no com.bea JMX metrics are displayed.
We tried
introscope.agent.remotejmx.system.s1.mbeanPatternsWhiteList=*:* and many more.
Q1. Is this method of using the traditional JMX filters supported?
A1. Yes
Q2 Not seeing if we use the remote jmx extension, no com.bea JMX metrics are displayed.
A2. Please see https://knowledge.broadcom.com/external/article?articleId=244011
It appears that something changed between 20.6 and later.
Copying over the 20.6.0.49/10.x traditional JMX properties to later release IntroscopeAgent.profile (such as introscope.agent.jmx.enable) and removing remotejmx extension from bundle.properties , the JMX metrics of com.bea beans on WebLogic applications hosted on RHEL appears.
Other option: Adjust the remotejmx configuration to get desired the JMX metrics.
Start with: introscope.agent.remotejmx.system.s1.mbeanPatternsWhiteList=com.bea*:*