• Forums
    • Public Forums
      • Community Connect
      • Dynatrace
        • Dynatrace Open Q&A
      • Application Monitoring & UEM
        • AppMon & UEM Open Q&A
      • Network Application Monitoring
        • NAM Open Q&A
  • Home /
  • Public Forums /
  • Application Monitoring & UEM /
  • AppMon & UEM Open Q&A /
avatar image
Question by Erik H. · Jun 27, 2012 at 01:46 AM ·

Question about v4.x agent upgrades

Hello,

We are currently upgrading to 4.1 from 3.5.2 on Solaris equipment. In doing so, we are trying to better organize our DynaTrace layout to make it easier in the future. Currently we are at ~70 JVM agents with more growth to come. Our current installation process is to install the agent on each individual server and we use a symlink to point at the active version for that application (this allows us to pre-install new versions without turning them on yet). Obviously, installing the agent 70+ times is tedious and it will be getting worse as we grow. So we are thinking about making a shared mount that we have the different DynaTrace installs in. Thus when upgrading in the future, we just need a single install to be performed.

Ex:

/dynatrace
  |=> dynatrace-3.5.2
  |=> dynatrace-4.0  |=> dynatrace-4.1

We do this with other shared software libraries and it works well. But with Dynatrace, I have a few questions about this approach.

1) By default, DynaTrace wants to log to ?$<DT_HOME>/log directory. Can we control that path at the agent level with a parameter? Otherwise in the above scenario, all agents would try to log to the same log directory which I assume would be bad.

2) In the v4.x releases, when doing the maintenance releases, it seems that the the release is loaded to the server and that is pushed down to the client which updates the binary on the next application restart. Is that correct? If so, how would that affect things if a single JVM was restarted which updated the binary that is shared by 70 other JVMs that have not yet restarted?

Also, is there any other gotchas around this?

Finally, how are any other groups who are at 50+ agent doing their installation processing to make it as painless as possible?

Comment

People who like this

0 Show 0
10 |2000000 characters needed characters left characters exceeded
  • Viewable by all users
  • Viewable by moderators
  • Viewable by moderators and the original poster
  • Advanced visibility
Toggle Comment visibility. Current Visibility: Viewable by all users

Up to 10 attachments (including images) can be used with a maximum of 50.0 MiB each and 250.0 MiB total.

3 Replies

  • Sort: 
  • Most voted
  • Newest
  • Oldest
avatar image

Answer by Erik H. · Jun 27, 2012 at 10:16 PM

Thank you for the replies.  That clarifies a bunch of items.

So here is our plan for our migration.  

1) Apps all point to DT collectors using VIPs which are currently pointing to the 3.5.2 collectors.

2) Repoint the VIPs to new 4.1 collectors.

3) Repoint the symlink on each app to point to 4.1 install and bounce app to pick up and use the 4.1 binaries.

Does anyone know if that plan should work. We know we will lose our 3.5 history but we are okay with that.  Our worry is when we point the VIPs to 4.1 collectors how the 3.5.2 agents will react between that point and when the app is bounced to use the 4.1 binary.  

Note, we plan to try and test this out in the next week or so.  Just seeing if anyone has good/bad experience around this that we can learn from ahead of time.  

Thanks in advance. 

- Erik

Comment

People who like this

0 Show 0 · Share
10 |2000000 characters needed characters left characters exceeded
  • Viewable by all users
  • Viewable by moderators
  • Viewable by moderators and the original poster
  • Advanced visibility
Toggle Comment visibility. Current Visibility: Viewable by all users

Up to 10 attachments (including images) can be used with a maximum of 50.0 MiB each and 250.0 MiB total.

avatar image

Answer by Roman S. · Jun 27, 2012 at 03:37 PM

Hi Erik,

ad 1) Changing the log folder is possible through the agent option logpath, a full list of all the options with examples can be found in the documentation at https://apmcommunity.compuware.com/community/display/DOCDT41/Java+Agent+Configuration.

ad 2) The agent is not replaced but the newest version is downloaded and stored in a seperate folder (e.g. on my Windows system this is C:\Program Files (x86)\dynaTrace\dynaTrace 4.1.0\agent\downloads where I have sub folders for the various releases/patches). When the agent starts up it connects to the server, checks for the current version and then uses the appropriate binaries (+ downloads them if necessary). It means that user that the JVM is running under needs write access to the agent folder. If that behavior is not desirable in your specific environment you can prevent this by using the dtagentcore.dll/.so files (-agentpath:/path/agent/dtagentcore.so=name=test,server=localhost). In that case you have the behavior as before and would need to manually update the agent libraries.

Best, Roman

Comment

People who like this

0 Show 0 · Share
10 |2000000 characters needed characters left characters exceeded
  • Viewable by all users
  • Viewable by moderators
  • Viewable by moderators and the original poster
  • Advanced visibility
Toggle Comment visibility. Current Visibility: Viewable by all users

Up to 10 attachments (including images) can be used with a maximum of 50.0 MiB each and 250.0 MiB total.

avatar image

Answer by James M. · Jun 27, 2012 at 09:53 AM

We have about 500 agents deployed so far, and about 70 collectors or so. Here's how we do it, and how dynaTrace 4.1 both facilitates and makes our lives more challenging. We're running 4.1 and focus primarily on Java in the middle-tier. We use the same symlink model you are proposing. Our agent file system is read-only, so we don't preserve logs at all.

We use rsync to push out agents across our infrastructure, largely because we don't use shared drives since that introduces single points of failure. We do the same approach for our collectors. With dynaTrace 4.1, agent upgrades for Java aren't required since it auto-upgrades itself after your process is restarted. Same for the collectors. Upgrades can be done even while running processes are touching the agent code, as long as your upgrade process doesn't change the file ids. SSH commands are used to auto-start or auto-shutdown/restart the collectors, although you can also use the dynaTrace console as long as the collector process is running. 

The downside, and a real problem for us, is that it auto-updates everything after an upgrade. This violates our change management processes, where we may not want everything upgraded just because the central server is updated. We''ve put in an RFE to help manage that more intelligently and risk-appropriate way. 

Comment

People who like this

0 Show 0 · Share
10 |2000000 characters needed characters left characters exceeded
  • Viewable by all users
  • Viewable by moderators
  • Viewable by moderators and the original poster
  • Advanced visibility
Toggle Comment visibility. Current Visibility: Viewable by all users

Up to 10 attachments (including images) can be used with a maximum of 50.0 MiB each and 250.0 MiB total.

How to get started

First steps in the forum
Read Community User Guide
Best practices of using forum

NAM 2019 SP5 is available


Check the RHEL support added in the latest NAM service pack.

Learn more

LIVE WEBINAR

"Performance Clinic - Monitoring as a Self Service with Dynatrace"


JANUARY 15, 3:00 PM GMT / 10:00 AM ET

Register here

Follow this Question

Answers Answers and Comments

2 People are following this question.

avatar image avatar image

Forum Tags

dotnet mobile monitoring load iis 6.5 kubernetes mainframe rest api dashboard framework 7.0 appmon 7 health monitoring adk log monitoring services auto-detection uem webserver test automation license web performance monitoring ios nam probe collector migration mq web services knowledge sharing reports window java hybris javascript appmon sensors good to know extensions search 6.3+ server documentation easytravel web dashboard kibana system profile purelytics docker splunk 6.1 process groups account 7.2 rest dynatrace saas spa guardian appmon administration production user actions postgresql upgrade oneagent measures security Dynatrace Managed transactionflow technologies diagnostics user session monitoring unique users continuous delivery sharing configuration alerting NGINX splitting business transaction client 6.3 installation database scheduler apache mobileapp RUM php dashlet azure purepath agent 7.1 appmonsaas messagebroker nodejs 6.2 android sensor performance warehouse
  • Forums
  • Public Forums
    • Community Connect
    • Dynatrace
      • Dynatrace Open Q&A
    • Application Monitoring & UEM
      • AppMon & UEM Open Q&A
    • Network Application Monitoring
      • NAM Open Q&A