Solved: Re: OneAgent: remove previous versions

yury_kostsik · ‎03 Dec 2020

We have the oneagent installed with the autoupdate enabled. Just found that the oneagent keeps all previous versions for ever. Are there any solution, key, flag that could help to avoid a such behavior and remove them automatically after the update is finished

JamesKitson · ‎03 Dec 2020

Where exactly are you seeing that? If we kept every version on the monitored hosts everyone would quickly be running out of space.

https://www.dynatrace.com/support/help/setup-and-configuration/dynatrace-oneagent/oneagent-aging-mec...

Do you mean on the Managed cluster side?

yury_kostsik · ‎03 Dec 2020

In the AWS EC2 instances, that we use

For instance:

[root]# ls -lah /opt/dynatrace/oneagent/agent/bin/
drwxr-xr-x. 6 root user 82 Jun  3  2020 1.193.159.20200602-190835
drwxr-xr-x. 6 root user 82 Jun 30 23:10 1.195.139.20200701-001924
drwxr-xr-x. 6 root user 82 Jul  7 15:31 1.195.148.20200707-160955
drwxr-xr-x. 6 root user 82 Jul 20 14:55 1.195.161.20200720-160625
drwxr-xr-x. 6 root user 82 Jul 23 13:27 1.197.134.20200723-143315
drwxr-xr-x. 6 root user 82 Aug 21 15:42 1.199.101.20200821-165422
lrwxrwxrwx. 1 root root   25 Aug 26 08:17 current -> 1.199.101.20200821-165422

JamesKitson · ‎03 Dec 2020

So what is in those directories is described here:

https://www.dynatrace.com/support/help/shortlink/oneagent-aging-mechanism#installation-bin-directory

It is not the full agent just some of the small pieces that are used for injection into processes. The only item of note in their is under the 'any' subdirectory of each of the versions. It shows we keep the 10 most recent (plus the current) versions of that so it is not forever.

I'll update if I find any way to control this behavior but at this time I don't think that is possible.

yury_kostsik · ‎04 Dec 2020

Hi James, not sure that's correct

du -sh /opt/dynatrace/oneagent/agent/bin/
4.1G    /opt/dynatrace/oneagent/agent/bin/

And moreover, there were much many versions, but I just deleted them

drwxr-xr-x. 3 root user 17 Mar 18  2019 1.163.277.20190318-125829
drwxr-xr-x. 3 root user 17 Apr  2  2019 1.165.211.20190402-143336
drwxr-xr-x. 3 root user 17 Apr  8  2019 1.165.227.20190408-130003
drwxr-xr-x. 3 root user 17 Apr 17  2019 1.165.238.20190417-081639
drwxr-xr-x. 3 root user 17 May  2  2019 1.167.159.20190502-150150
drwxr-xr-x. 3 root user 17 May  8  2019 1.167.176.20190508-104947
drwxr-xr-x. 3 root user 17 May 29  2019 1.169.172.20190529-101847
drwxr-xr-x. 3 root user 17 Jun 25  2019 1.171.180.20190625-172111
drwxr-xr-x. 3 root user 17 Jul 19  2019 1.171.252.20190719-134816
drwxr-xr-x. 3 root user 17 Aug  2  2019 1.173.295.20190802-111637
drwxr-xr-x. 3 root user 17 Aug  9  2019 1.173.314.20190809-152259
drwxr-xr-x. 3 root user 17 Aug 26  2019 1.173.358.20190826-182424
drwxr-xr-x. 3 root user 17 Sep 10  2019 1.175.240.20190910-170422
drwxr-xr-x. 3 root user 17 Sep 20  2019 1.175.270.20190920-173335
drwxr-xr-x. 3 root user 17 Oct 10  2019 1.177.204.20191010-030448
drwxr-xr-x. 3 root user 17 Oct 11  2019 1.177.216.20191011-134546
drwxr-xr-x. 3 root user 17 Nov  6  2019 1.179.177.20191106-102431
drwxr-xr-x. 3 root user 17 Nov 13  2019 1.179.187.20191113-095744
drwxr-xr-x. 3 root user 17 Dec 11  2019 1.181.154.20191211-083443
drwxr-xr-x. 6 root user 82 Apr 23 09:12 1.189.205.20200423-102214
drwxr-xr-x. 6 root user 82 May 14 09:35 1.191.217.20200514-103405
drwxr-xr-x. 6 root user 82 May 26 13:44 1.191.239.20200526-145639
drwxr-xr-x. 6 root user 82 Jun  3 07:30 1.193.159.20200602-190835
drwxr-xr-x. 6 root user 82 Jun 30 23:10 1.195.139.20200701-001924
drwxr-xr-x. 6 root user 82 Jul  7 15:31 1.195.148.20200707-160955
drwxr-xr-x. 6 root user 82 Jul 20 14:55 1.195.161.20200720-160625
drwxr-xr-x. 6 root user 82 Jul 23 13:27 1.197.134.20200723-143315
drwxr-xr-x. 6 root user 82 Aug 21 15:42 1.199.101.20200821-165422
lrwxrwxrwx. 1 root root   25 Aug 26 08:17 current -> 1.199.101.20200821-165422

JamesKitson · ‎04 Dec 2020

After checking internally, it seems this behavior is most often attributed to monitoring being deactivated on the host in which case the aging operations do not occur.

If you do have monitoring active on this host (or others) and still see this a support case would be best so they can take a closer look at what is happening.

Tomasz_Gajger · ‎14 Dec 2020

Hi, the problem you're experiencing is being tracked in the following product idea: https://community.dynatrace.com/idea/243195/oneagent-update-cleanup.html

You will also find the explanation of the behavior there - as James mentioned, it's caused by agent being deactivated and having auto-updates enabled at the same time.

yury_kostsik · ‎14 Dec 2020

Could you clarify please, what it means enabled?
If I can see my machine in the DT dashboard?
and if I can see that process on my machine?

ps -ef | grep dynatracroot     18076     1  0 Aug26 ?        00:35:47 /opt/dynatrace/oneagent/agent/lib64/oneagentwatchdog -bg -config=/opt/dynatrace/oneagent/agent/conf/watchdog.conf

If that's right, I don't see any difference between machines that are added into the monitoring pool and don't.

all of them have kept all the versions since the first installation

Tomasz_Gajger · ‎14 Dec 2020

"enabled" pertains to whether the monitoring of the host is enabled or not, in the Web UI: "Host settings > General > Monitor this host"

OneAgent processes will be running regardless if monitoring is enabled or not.

ThatiSrikanth · ‎28 Dec 2021

Is your issue solved?
i am curious know if so what the solution they have provided to clean up the old oneagent softwares which is lying on the instances