Struggle with easyTravel out of the box setup.

Did you install dynaTrace in a non-default location? That would explain much of that behavior such as the Java and C++ agents not being found. The demo tries to inject the agents on start up, making some assumptions about where the actual agents live. If it's installed in some non-standard location those assumptions will fail and it won't find the agents.

If this is the case, there are ways you can specify the agent location in the easyTravel properties file. But if this is a training/demo system you may be happier in the long run if you uninstall dT and reinstall it accepting the default location. If it's not a training/demo system, you'll need to work through editing the easyTravel properties

For the .NET symptom: is it possible that you had a previous version of dynaTrace installed at some point? What are the .NET agent names that you see in the Agent Overview?

Rob

Thanks Rob for your quick response and great input.  I'm new with Dynatrace and new with the team, but I can see that we do use a non-default location.  So you are saying that if this was not the easyTravel application, but instead a regular company application, normally an agent would be given to the app owner and he would put it in the place he/she needs to apply it which is not normally a DT server.  But because this is easyTravel, easyTravel uses the agents that live with Dynatrace and therefore those agents that are needed are in the Dynatrace install directory.  That makes a ton of sense.  I can certainly change the easyTravel property files.  Thank you!

Yes this is our DEV server and we have had previous versions of dynatrace installed and also different version at the same time installed (unfortunetly as you can see definitly not the default DT install)..  But how would this throw the mapping off?   I'm not following.  The easyTravel was installed and started after the latest version of DT was installed. 

The names of those .NET agents are dotNetFrontend_easyTravel and dotNetBackend_easyTravel.

Yep, you've got it on the agent process. In fact, there are agent installer files (.MSI for Windows, and JAR files for Linux/Unix). You'd give those files to your app owner s/he would copy to their app server, run the installer, and poof there would be agents on those machines. Then in the startup script for your JVMs (for example), you'd add an option of "-agentpath <path-to-agent>=name=yourAgentName,server=dTCollector:9998"

And you're right that for easyTravel, it's making the assumption that there's a dT installation in one of a couple of particular places (could be the full install, or it could just be the agent install mentioned above) and it will grab the agent from there.

As for my .NET comment: I was asking about the previous install since you had the version difference, and because the .NET agents were connecting. Our agent gets registered as a "profiler" on Windows so I was assuming that you were still picking up the old version of that agent. And that's why you were seeing the .NET agents connecting, but not the Java and C++ (because the original agent was still registered).

As to why the mapping doesn't work: I don't know without seeing exactly what you're seeing. Those agent names are what I would expect to see for an OOTB easyTravel, and if you haven't changed the mappings in the demo easyTravel profile that you installed I'd expect that to work just fine. What's the exact error that you see? Does it start off with "Skipped by license check..."? And what do your dotNet agent mapping definitions look like?

Hi Rob, Those .NET agent match misses seemed to have cleared up.   As I was reworking the DT agents locations, I decided to just remove the easyTravel SystemProfile and start from scratch.  and that seems to have fixed it, there are now mapping matches in the agent overview.  

 I did change where the agents are looked for but I'm sure I edited the wrong place within the easyTravelConfig.properties.   This time the check marks in the Blue Boxes didn't even come up when I started easyTravel up. 

I've made the changes here (see below) within the easyTravelConfig.properties file (originally config.agent, config.frontendAgent and config.backendAgent all equalled "auto") :

# When set to auto, easyTravel will search well known directory locations and use the most recent version of the agent that is found.
config.agent=none

# Note: this is a Java-style property, you need to use double-backslashes, i.e. C:\\Program Files\\....\\dtagent.dll
config.frontendAgent=E:\\dynaTrace\\easyTravel dynaTrace 5.5.0\\agent\\lib64\\dtagent.dll

Like I said that did not work well at all.   I guess we pay for doing things different than the default.   If you know where the change would be made in this property file could you let me know.  But np if you don't you have been awesome Rob.  Thanks for all your help on this.  I appreciate it a ton! 

I do know, and I'm glad to help. 

For Java, it's config.frontendJavaopts,  and config.backendJavaopts. For C++ it's config.creditCardAuthorizationEnvArgs. Since your DotNet stuff is connecting, it seems like you're OK on that.

Details (obviously use your own path info):

config.frontendJavaopts=-Xmx160m,-agentpath:"C:\\Program Files\\dynaTrace\\dynaTrace 5.5.0\\agent\\lib\\dtagent.dll"=name=CustomerFrontend_easyTravel,,server=yourServer:9998

config.backendJavaopts=-Xmx64m,-agentpath:"C:\\Program Files\\dynaTrace\\dynaTrace 5.5.0\\agent\\lib\\dtagent.dll"=name=BusinessBackend_easyTravel,,server=yourServer:9998
 
config.creditCardAuthorizationEnvArgs=DT_AGENTLIBRARY="C:\\Program Files\\dynaTrace\\dynaTrace 5.5.0\\agent\\lib\\dtagent.dll",DT_AGENTNAME=CreditCardAuthorization_easyTravel,DT_SERVER=yourServer:9998

Let me know if this works for you.

Rob

That was gold Rob!!  I was having a problem for a while with it because I was trying to use the \\lib64 path for the agent.  I think in the back my head I was trying to use the agent the video demo had shown.  Finally it dawned on me that just maaaaybe I need to go with the 32 bit.  And Both Java agents lit up after that.   I still am wrestling with the CreditCardAuthorization agent.  It does get a check mark in the blue box upon startup but still comes up with a "slash Operations" status.  I'll look at the logs closer tomorrow and see what I can find.   Thanks so much for your help with this.  I've learned a lot and I haven't even started using easyTravel yet thanks to you.  Hope you have a good night!  Thanks again!  

David

My pleasure! Glad to see you going to bed happy instead of frustrated at easyTravel! 

One more thing: In my creditCardAuthorization line above: try doubling up the commas on that line like I did on the Java lines. I think I may have made a typo there and I don't have time to test it. But that might just fix your C++ problem.

Update: Above was incorrect. See below.

Rob

More on this: I did get to test the C++ part, and the syntax I have above for that (single commas) is correct. I noticed on mine, in the easyTravel Demo Console (the one with all the blue checkmarks saying that components are running), I also get a red slash through the agent next to the word "operating", indicating that it can't find the agent. 

But if you check in the dynaTrace client, it shows that it's connecting fine, and I double-checked to make sure it's collecting PurePath data on that agent.

I suspect that the red-slash is just a bad interaction with the demo, since we're manually setting the agent path. I'm guessing that at the time it decides to paint that red slash, that it hasn't processed those environment arguments yet.

Give it a try and look in the dT client itself, in the Agent Overview, and see if it's connecting for you.

Oh - and one more last thing. If  you want to have the Apache webserver running and monitored properly, you'll also need to update the agent path in its "httpd.conf" file, which you can find here:

C:\Users\YourUserID\.dynaTrace\easyTravel 2.0.0\easyTravel\config\httpd.conf\

It should be near the top of the file. Search for "dtagent.dll"

Are you SURE it's not easier to just reinstall dT in the default location? 

Rob

Hi Rob! hard to tell about the CreditCardAuthorization agent.   But it's great to have gotten past that point with your discovery.   Why I cannot visibly see what you are seeing is that the mapping issue is happening again and the end result of that problem is the agents are not being instrumented. 

Actually where the mappings fail the message reads "5.5.0.5226: The Agent version is outdated. Restart your application in order to get the most recent version injected. Instrumentation disabled since the agent was not mapped into an agent group". 

 Our DT version is 5.5.0.5668.  As we talked about last night, the agents are coming from the DT server install location.  So to me it does not make sense that the agents are 5.5.0.5226.  And they should be upgrading automatically.   Yes to some degree I would love to put this all on a default location.  Then from that state it would be clean and troubleshooting would be a lot easier for my level of knowledge.  But unfortunetely, they architects on the team have a method to their maddness, and I need to go where the licenses are.

On another note, are you familiar with the easyTravel license - specific to just the use of easyTravel on DT?  Do you know if  that can be used in parallel with real licenses.   That is; as we discussed we don't have a default location and it appears that I am short a few licenses (license exhausted on the .NET agents) on the DEV.    So If I could use the easyTravel license without clobbering the real licenses that would be great.  On the other hand if the easyTravel license is flexiable enough, I could possibly install my own default location DT (even if it means on my own Laptop) which would be the best solution.