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

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

.net agent name include PID or USER

bhalsey
Inactive

Is there a way to include the PID or USER of a process in the agent name? We have several instances of the same process running and as a result they all get myAppName[#]. It would be a huge value if we could to myAppName[user] or myAppName[PID]. All of the instances are running the same executable for the app. Each user is logged in as themselves and the data appears in the list of connected agents. Just need a way to use it when binding the agentName. Any help would be greatly appreciated!

5 REPLIES 5

bhalsey
Inactive

Please advise if I can provide any clarity or screenshots for this. We've tried a handful of ideas to include environment variables and such, but so far we've had no luck. Thanks!

bhalsey
Inactive

Ok... so I felt like I had searched pretty well on this issue but just came across this https://answers.dynatrace.com/questions/106561/using-regex-or-in-net-agent-configuration-command.html which worked. I was thinking I needed to use the .net configuration tool to reference the variables, but it seems the DT_AGENTNAME set for user/system on the OS will actually override the value set in configuration tool. Tested this and it worked. Will tinker some more but I guess this is the correct answer based on initial tests.

Joe_Hoffman
Dynatrace Leader
Dynatrace Leader

Brent, Using ENV VARS will certainly let you define the agent name programatically at process startup time. However I'm not sure that's what you really want. The PID is already part of every agent name, just look in the AgentOverview and you'll notice the PID and every purepath node contains the Agent which generated that node, which includes the PID of the agent at the time the data was collected. So it seems trying to add the PID to the agent name is redundantly redundant.

As for the Username, unless your architecture spins up a new process for every authenticated user, the user can change for any given process/agent invocation. And you can't change the agent name once the agent has connected. So a better approach is to capture the username as part of the transaction itself, ideally as part of UEM and set it as the Visit Tag for that transaction (Purepath), or simply capture it as a transaction variable as a method parameter, request parameters, session variable, etc. This approach allows a given agent to process multiple user transactions during the lifetime of the monitored process.

HTH

joe hoffman

bhalsey
Inactive

Thanks Joseph- you are spot on PID is 'redundantly redundant' 😉 The PID was more an example of data that I was hoping we could reference by variable in the agentName field for the .net configuration tool. Ultimately, username is exactly what we want because as you pointed out, 'unless your architecture spins up a new process for every authenticated user, the user can change for any given process/agent invocation'. Our architecture for this application is exactly that. Previously, when using the static agent name of 'myApp', 5 users would log into the terminal server and we would see this for processes on the host; myApp, myApp[1], myApp[2], myApp[3], myApp[4]. With the the use of the DT_AGENTNAME set to myApp_%username% under the user variables, I now get myApp_bhalsey, myApp_otherUser, etc. The other challenge with our architecture is that this .net executable hasn't really allowed us to retain username tied to transactions from each client. We can capture the username at login, but after that ponit it isn't available (not a web app type of setup). At least this way, we can see what agent captured the data which will tell us what user it was easily. Let me know if you have more thoughts on this. Really appreciate the support!

Joe_Hoffman
Dynatrace Leader
Dynatrace Leader

Brent, Given your architecture, I think you're using the right approach. The one challenge to your approach is when you try to use 'split by agent' features, you'll likely end up with a mess, because you're really splitting by username. So you might just want to avoid that feature. By default, splitting measures by agent is not enabled for measures so you should be fine.

If the username is available at login, and you're using UEM (I'm not sure), then you could assign that username to the visit as the visitTag. But as you stated, this might not work for your architecture.

Glad you're getting what you need.