Tracking Storage Requirements with Continous Transaction Storage
What metric can we monitor to provide us with a leading indicator that we need to add more storage for our continuous transaction storage area?
We are currently adding about 100Gb of storage a month to accomodate our current ramp, but we have no idea if this is too much, not enough, etc. We will have an SLA to keep around 15 days or more of detail for our production applications.
Hi Andi! Thanks for the quick response.
I don't think it does; we use some of those metrics to raise incidents in our non-prod server, where disk space usage comes and goes. In prod, with continuous transaction storage turned on, the Total Session Size metric always shows very close to the amount of storage available at that point in time. If I gave it 2TB, it would ramp up to 2Tb within a few days, so not particularly interesting. The PurePath Buffer Size is likely the most potentially interesting, but it isn't enough to tease out the oldest event/oldest purepath being persisted.
And I suspect that there are no useful heuristics on purepath buffer size that will translate to a data retention SLA.
Hi James,
unfortunately there is currently no measure that allows monitoring of the timerange for which transactions are persisted.
You can see the time of the oldest PurePath in the storage for a certain system profile by looking at the system profile details (from the cockpit). The entry "Recording" tells you where the recorded data starts for this system. So if you check how much disk space is used and how much days are currently in the storage you should get a good feeling how much storage you have to configure to get your minimum of 15 days.
A measure that allows monitoring, defining incidents etc. is a good idea that will be considered for future releases.
Welcome the
Dynatrace Community Forums
Check out the Forum User Guide and Forum Guidelines to learn how to get started.Community Member of the Month
August 2017
Announcing Dynatrace's Community Member of the Month for August 2017, Rick B.! Click here to read more! 
