cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

This product reached the end of support date on March 31, 2021.

Data calling different system profile

tthat
Inactive

I'm having issues withData calling different system profile. The one marked in circle are system profile which are being called from PAG01 and all these system profiles are from different servers/JVMs. pago1.png

18 REPLIES 18

JamesKitson
Dynatrace Leader
Dynatrace Leader

I'm not sure if I'm answering your question, but in cases where a transaction spans system profiles, by default the PurePath will be associated only with the system profile where it started (the entry point). You will still see data from the other system profiles within that PurePath (sensor rules etc...) but it will all be in that original profile.

Is that what you're asking or is there something else?

James

tthat
Inactive

@James K. But is it correct that in transaction flow of one system profile we can see other profiles also being called? and when I am checking PP also its showing other profiles JVM .

Is this correct ?

Yes. You still see the JVMs from the other system profiles show up on your Transaction Flow.

yes we still see the Jvm's from other system profile as its coding by app team

andreas_grabner
Dynatrace Guru
Dynatrace Guru

The bigger question is why you have multiple system profiles. Cross System Profile PurePaths is a big topic and there are many challenges that come with it, e.g: the PurePath will show up in the Profile where it starts -but what if it calls services in another profile -> people that look into that profile wont see these calls.

We promote having a single System Profile and using "Appilcations" to differentiate between logical applications. We know this is not covering all use cases and probably you have reasons why you separate into separate profiles. fill us in and maybe we find a better solution for you rather than splitting purepaths that belong to "your core system" into different profiles

andi

Hi Andreas,

with all applications in the same system profile you cannot manage the permissions. What if you want the developpers from one application only seeing the data from their application and not the others?

We have the exact same situation because the permissions are defined at system profile level. And we also have purepath which goes over multiple system profiles (CICS is a common part used by most of the applications)

Regards

Olivier

@Oliver W.

you can talk to your app team regarding this as we got the answer
its because its defined at application layer that one system profile and different ones also.

Hi Oliver,

If this is a concern for you, there is a RFE for this application permission functionality. Please take a look at vote if you think it it is something you would like to see in the product.

https://answers.dynatrace.com/idea/134117/rfe-user-access-at-application-level.html

Andrew

Babar_Qayyum
DynaMight Leader
DynaMight Leader

Hello Taneshaa,

As @Ari P. said when we have multiple system profiles and the transaction flow in moving around in other system profiles then you will see the agent groups / tiers on the selected system profile but you will not see the process and host information of those agent groups except the transactions.

Regards,

Babar

germanmv
Contributor

Hi All,

I'm trying to see all the purepaths which go through an specific JVM (say 'JVM_A') from an specific System Profile ('SP_A').

To do that, I open the Transaction Flow of the desired System Profile ('SP_A'), and it is true that I can see JVMs from other System Profiles but seems to happen as long as the purepaths start on JVMs from SP_A.

Is this the expected behavior?

What if some purepaths come from JVMs from other System Profiles before reaching JVM_A?

Regards,

Germán

PurePaths will be stored in the System Profile that they originated from (i.e where they hit the first entry point). So if a PurePath starts on a server in SP_A it will be stored in that profile regardless of if it travels through agents in other system profiles, and you'll be able to see the data from those profiles in SP_A.

germanmv
Contributor

Then, If there are purepaths starting in a JVM_B (SP_B) which go through JVM_A (SP_A), they will be plotted only in SP_B's transaction flow (where I could also see JVM_A) even if they pass through JVM_A, Is that right?

Correct, in that scenario everything will be in SP_B, you can tell when they are agents in different system profiles when the little circle in the flow is clearly an agent but only has a color in the 'transactions' piece as opposed to all host and process health data.

oscarata
Guide

you should think in better thing for this ..... so people is better done with this .... at least purepaths that are from profile 2 when i search for purepaths in profile 2 although they start in profile 1 we should have them in profile 2, if not looking for this is difficult

There's ups and downs to both options. Ideally any system that communicates with each other should be in the same profile. I believe there is also a configuration that can be made that will cause PurePaths to end and begin when they would enter a new system profile so a 'piece' of each PurePath would be in each profile. Then you have to worry about configuring the right entry points for each segment though.

I think if it's not a technical reason that PurePaths are duplicated across each profile they touch it is because it would involve possibly duplicating large amounts of data arguably unecesarily.

If permissions can only be defined at System Profile level and you follow a microservices strategy with full JVM coverage, then all the purepaths will belong to the first service called, what means that developers with no permissions over that first System Profile won't see any information on dynatrace.

Besides, purepath length will became easily bigger than 10.000 in this first System Profile since all the nodes of the purepaths belongs to this System Profile.

I think that, even if you want to see nodes of every System Profile as part of purepaths of the first System Profile, that should be only something "visual", keeping the nodes on their real System Profile.

Regars,

Germán

No argument from me, I would appreciate the flexibility. See the following RFE:

https://answers.dynatrace.com/idea/134232/rfe-cross-system-profiles-purepath-csppp-or-xsppp.html

i was thinking in separated purepaths one by each profile but with link as follow ..... if each purepath has an id it is as easy as correlate them with follow this .... so when painting purepath from profile 2 if user has permissions in profile 1 it can paint if not it can not.

And for the business transactions they should have a tick to follow purepaths in another profiles (or mark the profiles we waant to choose) that is the use case i am thinking in, just to have the profiles and their security ok. if not users from profile 2 can see things in purepaths from profile 1 and they shouldnt ... and if we split without the follow up link we loose the possibility of having full transaction . This is something that needs improvement