In the process of migrating our monitoring from AppMon to Dynatrace I just found out the hard way that setting the env variable DT_STORAGE in the context of an application process (Java in this case) will have an impact on where the Deep Monitoring Agent (which monitors the process) will write its logs and memory dumps, namely:
Although this seems to be an undocumented feature (probably a remnant of sorts from the AppMon agent "DNA") it is quite neat as we would want to keep all process-specific logs (incl. memdumps) to a process-specific location. This was actually the whole point of defining DT_STORAGE during the AppMon days.
The only problem is that this seems to break memdump uploads to the ActiveGate and therefore they will never appear for download via the UI. Unfortunately "unsetting" DT_STORAGE is not easily possible for the apps we're trying to migrate.
I'm curious if anyone made a similar experience and if perhaps any "insiders" can comment/confirm the current usage of DT_STORAGE and the impact on memory dump storage.
Thanks in advance.
Solved! Go to Solution.
Hi @Chad T.,
This was "resolved" via a support case where it was stated that setting DT_STORAGE is not supported and that it "changes the directory where agent stores data like dumps, log files, downloaded config and so on"...
Unfortunately support could not provide me with any additional insights regarding possible issues associated with setting the variable in the context of a monitored process - other than what I had established myself through trial and error. The reason given was:
Once a variable is set to be restricted, as in this case, not all the ways it impacts the environment are fully known.
We've learned to live with this issue by manually retrieving and purging memdumps from the file system after we trigger them via the UI. Thankfully this only affects one of our legacy J2EE platforms of diminishing criticality and whose remaining days are already counted...