Agent matching several system profiles

Hi Matthias

An Agent must always map to a single System Profile. The System Profile and the definitions in the Agent Group defines what level of information is captured (e.g: which sensors are active).

If you have multiple System Profiles with overlapping agent name mappings then you will eventually end up in a situation where an agent first connects to Profile A and upon the next restart connects to Profile B. Why? Because the dT Server iterates through all Sys Profiles + Mappings and picks the first match it finds. As there is no guarantee about the order in which the dT Server checks this mapping there is no guarantee that the same agent will always connect to the same profile

FOLLOW BEST PRACTICES:

The best way is to follow the best practice which is to make sure you have something unique in your agent mapping names, e.g: append the System Profile Name to the agent name. Thats also how our wizards create agent mappings. If you create the tier "Tomcat" in profile "ABC" the mapping will be defined as "Tomcat_ABC". That ensures that this agent always maps to that system profile

Nothing really has changed in that behavior over the last couple of years - so - if you see a difference now than it was before it is probably a coincidents

Andi

Hi Matthias, I can not provide greater value than Andreas on my reply =)

But, you could also evaluate if going for a "single system profile" containing several app is not the best approach, based on your comment: "...All 3 System profiles have several Agent groupes with agents on several jvms calling each other.."

If they are calling each other and is hard to distinguish for which app/agent group etc...by using a larger System Profile you make sure all the agents are there, the purepaths are consistent and they are not breaking up (based on my experience).

Then you can split the info by Application, passed transactions, filter etc...to narrow down to specific applications.

Sometimes agent mapping solve the problem, but if they do not, it may be time to group them together on fewer system profiles based on my experience (i.e. there is a JVM sharing resources/calls/executions for application A and application B)

Just my 2 cents!

Carlos.

Hi Andi and Carlos

The Situation is, that we have quite some more then 3 appservers and they almost all call each other

We would like to have System profiles for our main applications Then there are some appservers hit by several of this applications It would be convenient, defining on this appservers sensors for all the applications (this sensors should be the same in all profiles) but separating the others (together with this specail ones) in different System profiles

As far as I see, we now have some sessions where we can see Agent-groups and sensors coming from other System profiles, but they are also defined in the currently analyzed Profile So the Situation is not quite clear here but when the behaviour would be clearly defined, one could use this

Regrads

Matthias

I understand the confusion.

The problem is that we do not support PurePaths that cross System PRofiles - even though it seems to work and these PurePaths show up in your dynaTrace Client. This has been a topic of discussion over the last couple of years. Fact is that dynaTrace does not officially support PurePaths from Agents where the Agents are distributed across different Profiles. There are many implications that come with this. Therefore - even though we don't break PurePaths in that scenario - you need to get to a configuration where you can move those agents into one system profile that actually belong to the same "System". Here are additional discussions on the forum about this topic: PurePath Behavior When Crossing System Profiles and Purepaths crossing System Profile

Thanks Andreas for the linked discussions. This summed it up pretty well for me. I do have one additional question, I can clearly see now when and why to break up application groups into profiles, but what effect would this have on host monitoring?

I've proposed that we break up or implementation into three profiles, each do not intersect pure paths but do share hosts. Should this be avoided as it would break up a complete host view of our system?

Thanks!