Dynatrace operator-managed activegate with private synthetics and AWS monitoring

[agentreno]

I'm interested in using the activegate that is installed and managed by the operator for as many purposes as possible, particularly private synthetics and AWS monitoring (including non-built-in AWS services).

I've been doing some testing and following some of the guides in the documentation and so far I've only been able to get this working in the following way:

Private synthetics: by installing another ActiveGate and associated resources separately using this guide

AWS monitoring: by installing another ActiveGate on EC2 and associated resources separately using this guide

This works but obviously involves a lot more infrastructure, hosts, manifests etc. for us to manage, and it seems unnecessary when there is an activegate installed by the operator. There might be some DynaKube interface obstacles to overcome (although things like customProperties should help a lot), and in the same way that AWS roles/permissions are my responsibility for an EC2 host, I can see that I'd need to take care of that for the containerised activegate using something like IRSA - as long as ActiveGate uses later than minimum SDK versions for that.

But I can't get that kind of configuration working - is anyone aware of some other constraints here? Is there any work in progress in this area?

[ChadTurner]

Dynatrace only just recently provided the access to private synthetics for containerized Activegates.  This guide on the AG functions should help you understand the abilities. https://www.dynatrace.com/support/help/setup-and-configuration/dynatrace-activegate/capabilities I always recommend using a full fledge AG as you get the most for your money when it comes to service offerings. Maybe in the future they will be apples to apples. 

[agentreno]

Thanks @ChadTurner - I think Dynatrace should include a fourth column on that page really e.g. "Operator deployment" so the abilities of that AG deployment are clear. There seems to be a difference between what a containerised AG that I deploy separately to the operator can do, vs what the AG that comes with the operator can do. In my case that's resulted in two AGs and only some of the resources being managed by the operator.

I agree it would be nice if there was full (or just more) feature parity between different AG deployments, particularly for common use cases like AWS monitoring and private synthetics.

I think I might not be alone in preferring to avoid a mix of EC2 hosts and Kubernetes deployments for a variety of reasons, even though it does enable more functionality today.