question

Wouter C. avatar image
Wouter C. asked ·

Collectors at a different minor version as a control mechanism for release upgrades?

Hi,

As the administrator of just our dynaTrace APM solution and not of the environments themselves, I'm trying to find an manageable upgrade strategy for new dynaTrace releases in our very heterogenous environments (preferably without getting shot by the admins of those environments).

For more than a year now, I had set my hopes on the development of a fixpack-like (now update-like, I guess) upgrade mechanism that would allow for controllable roll-out of new releases, so the possibility to determine which agents (environments) are allowed to upgrade at what time.

We really need a mechanism like that because upgrading our 5 different environments at the same time implies a synchronized maintenance window for those environments in which all 'dynatraced' application processes can restart, which is near impossible to find (yes, I know, there's always the option to upgrade dynaTrace and let the agents upgrade -and introduce new code in production- as a side-effect of a random process restart, but for that case, I'd like to refer again to the environment admins shooting me).

Recently I read in the 6.2 dt online documentation that it's possible to connect collectors with the same major release number but with a lower minor release number to an upgraded dt server. So I was wondering, would it be a bad idea to use this (within the same major release of course) as a mechanism to control what environments are upgraded at what time, provided we put each environment (agents) on their separate collector(s)?

Ideally it should not matter there's a month or more between the dt server upgrade and the upgrade of the last collector (environment) to the same minor version.

Does anybody already have experience with this?

Is there a reason why it's not recommended to try to work like that?

Thanks in advance for any feedback.

Wouter

2 comments
10 |2000000 characters needed characters left characters exceeded

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

have you thought about using the libdtagentcore ? more and more of my clients are using that as a way to control when they update their agent binaries. It becomes a manual distribution at that point instead of using the bootstrap, but it allows them to follow controlled change management process(es)

0 Likes 0 · ·

Thanks for the suggestion David. We're already using that method for some of our environments but it's a bit tricky and very cumbersome (see also this post), more so because I have to ask the admins of the different environments to do it.

0 Likes 0 · ·

1 Answer

Sreerag M. avatar image
Sreerag M. answered ·

Here is an RFE that you could support by adding your case and vote up.

Synced bootstrapped Agent migration

Share
10 |2000000 characters needed characters left characters exceeded

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