Showing results for 
Show  only  | Search instead for 
Did you mean: 

What are best practices regarding dockerized collectors and persistent storage?


I would like to deploy dockerized collectors on our OpenShift cluster and I was wondering about the best practices regarding persistent storage attached to such a container/pod. We are currently on AppMon 6.5.

I'm aware of the Dynatrace-Docker/Dynatrace-Collector community subproject on GitHub but it appears the current approach there is to have a completely ephemeral container i.e. no persistent storage attached whatsoever.

The reason I'm questioning this is mainly because of log file retention, class cache and the automatic roll-out of updates, which I see as 3 areas where it would potentially be beneficial to use persistent storage.

At first glance it would seem reasonable to attach persistent storage to the file systems in ./collector/log and ./collector/cache in order to provide persistent logs and class cache, but how about updates received from the server? Would it be possible to attach a persistent storage to ./collector/updates in order to prevent downloading the update bundle from the server each time a container/pod is spun up?

Also, how about sharing persistent storage across multiple collectors? Obviously not for logs, but what about class cache and updates? Is that supported / recommended?

And finally as somewhat related topic: What about horizontal scaling and load balancing? What would be the best strategy for (auto)scaling dockerized collectors? Should a collector group be used or rather a "transparent" way of load balancing / failover be implemented using for example OpenShift's pod autoscaling feature (in which case I assume the persistent volumes would be shared among all replicas)?

I would be very thankful for any input and ideas.

kind regards,



@Andreas G.: How about a PerfClinic on the subject? 🙂

We would also be interested if there is any instructions available how we could use persistent storage with dockerized collectors. We are currently running on version 7.0.

We are currently having mostly issues with the update procedure since the collector is constantly run-down by your customers dev group and currently I can only suggest to keep the collector up and running all the time.

So I would be highly appreciated if @Andreas G. or someone else could comment on this topic 🙂



There was a Performance Clinic on this Topic ealier this week. You can find the recording on youtube.

Thanks a lot for the pointer - looks like I missed that one 😞

Some aspects became clearer for me and I'm especially happy to know that the updates directory can be persisted. However, the question remains: How do we (auto)scale collectors that are supposed to have persistent volumes attached to them? With Kubernetes there is the concept of PetSets/StatefulSets which looks promising for this purpose but I haven't tried or looked at it in detail yet.

Also I take it from the PerfClinic that sharing volumes among different collectors is not a best practice as it was not mentioned (not even sure that's even possible in a read/write manner with Docker).