I don't think that will work because the system property value can be an arbitrary string (it may even contain blanks etc.) and therefore can't be matched with 100% confidence.
The whole point is to avoid having to create manual mappings for each expected value and instead use the system property value directly as identified by the system property's name.
Please consider this aproach:
You can define environment variable DT_TAGS and use it to create automatic tagging. After that you can use those tags to build own tagging rules base on them. You can also use DT_CUSTOM_PROP (https://www.dynatrace.com/support/help/monitor/processes/how-do-i-define-my-own-process-group-metadata/), you will get custom properties on process groups and than use them to build tags.
I'm well aware of the usage of custom environment variables for tagging purposes. Unfortunately this is currently not an option for us as we are not allowed to modify the monitored runtimes in this respect.
It seems a bit odd that Java system properties can be used for process group detection but not for tagging... Seems like the feature that evaluates them is already there but just not enabled for creating tagging rules... Would this be a good candidate for an RFE?
You can always try to make RFE because of that but if you have process groups that containes multiple different (ex. Tomcat) processes, I recommend you to use custome process detection to split those process groups because of role they have, and than you will have no problem with add proper tags to them.
Thanks - I will consider raising an RFE. Our process groups are already auto-detected correctly and adding tags to them is not really the problem but rather using dynamic values according to system properties....
We've used the existing values of a system property called "deploymentPurpose" as an additional criterion for splitting process groups more granularly i.e. "deploymentPurpose=nextrel". Now it would be great if we could use the same property for tagging as it can have the same value throughout different process groups (due to multiple detection rules being evaluated as an "OR" condition) and it would be useful to filter it.