question

Enrico F. avatar image
Enrico F. asked ·

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,
Enrico

configuration6.5installationcollector
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.

Enrico F. avatar image
Enrico F. answered ·

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

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.

Janne O. avatar image
Janne O. answered ·

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 :)

Br,

Janne

2 comments 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.

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

1 Like 1 · ·

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).

cheers,
Enrico

0 Likes 0 · ·