The Threads in Use metrics are mapped by the ResourceMetricMap.properties file in the config folder of the Enterprise Manager
threads.used.path.2=WebLogic|JMX Aggregate|Thread Pool:Waiting Request Count
As per documentation, the JMX Aggregate metrics are generated by an extension that would have been present in the Enterprise Manager - .\ext\PPWebLogicExtensionPlugins.jar
https://docops.ca.com/ca-apm/10-2/en/implementing-agents/java-agent/java-agent-extensions/oracle-weblogic-server/installing-and-configuring-the-oracle-weblogic-server-extension/install-apm-for-oracle-weblogic-server/
this was part of the PowerPack for Weblogic which does not exist as a separate entity nowadays.
If you can find any other metric already reporting that could be relevant for you, you can update the ResourceMetricMap.properties file with reference to that file - most probably this would want to be sourced from JMX data, as the existing configuration indicates
This is just to point you hopefully towards the right direction, the only other thing I can say from our side is that we should review if there is any alternative default metric that could work.
Somewhat related, you can do thread tracing by using weblogic-full.pbl or if you have a typical pbl to uncomment ThreadTracing in toggles-typical.pbd by removing the #
# TurnOn: ThreadTracing
But ThreadTracing is the sort of thing that can cause performance and functionality issues in the app (which is why it goes in full instrumentation instead of typical) so it should be tested to see that it does not cause issues and also to review if it gives you something you really would need to have.
It would create a Threads node under the agent, I think you get a Current Threads In Use value out of there, you could then consider putting that metric in ResourceMetricMap.properties