We have a generic method sensor with a class name "SimpleJobBean" for capturing quartz jobs.
Sensor works fine but it creates same entrypoint names for all applications so we can not split them by applications. They are all under "Default Application".
As you see the purepath tree, SimpleJobBean line is at the top and the application specific job (which is DataTransferJobMuhBek in this case) is coming next. If we add DataTransferJobMuhBek class as a new definition to an application, it doos not match(since it is not an entrypoint).
Creating an new method sensor for DataTransferJobMuhBek class does not produce new entrypoints as expected.
Additional note: We can see DataTransferJobMuhBek and other job classes in method dashlets individually.
Do you know any solution to split these purepaths into applications according to the implementation classes of generic SimpleJobBean class sensor.
1) You could create sensors for each job as you tried on DataTransferJobMuhBek. Make sure to review the priority of the sensors, make sure they start PurePaths in the configuration and eventually disable/exclude the sensor on SimpleJobBean. Then you should be able to complete the configuration of application, noting that the SimpleJobBean method would not be included in the PurePaths anymore.
2) Another solution would be to check if the job name is in the code, as a parameter or attribute. You would then configure 1 application for SimpleJobBean and a business transaction splitting by job name. The Monitoring dashboard would then display 1 application and each job as transaction. AppMon would also start baselining and alert on each job performance.
I think both solutions are pretty much equivalent in term of configuration. Then, it depends if you will define other applications which have nothing to do with the jobs or if you would like to create a business transaction for all jobs on another parameter. Also accessing the data would differ with different filters to use in dashboards or API, both solutions having its pros and cons.
Using first solution is not applicable since we want to capture all SimpleJobBean purepaths all time. There are lots of application having multiple jobs and developing new ones. So we need a common solution.
Actually, second solution is not what I want to have but I want to try. And application has both web requests and quartz jobs, so when I filter by application it would be nice to see all of them together.
And I did not get how should be the splitting. Lets say I create an application for generic SimpleJobBean. Which splitting for business transaction should I create to see jobs?
As you see the changing part is the second line on purepath tree.
Each purepath starts with SimpleJobBean and it call another job class, DataTransferJobonBek in this case.
Is there a way to create a generic splitting option for this case?
As an option, can I split DataTransferJobAonBek and others by changing API name for each of them.
My idea was to eventually find the class name or job name in the JobExecutionContext object. If that is possible, you could create a sensor to capture that value and use a measure to configure the splitting in the business transaction.
For the second question, you could create a 'Classname value' measure and use it as a splitting (if you found a generic regex or package that includes all the classes) or use it as a filter (not generic, as you would need to create a measure and a BT for each class).