Annotation or Label to block Dynatrace Injection

[Stephen_Schaff]

I have a pod (running an Octopus Deploy Tentacle) that keeps getting Dynatrace injected into it.  I have tried excluding the namespace in the Dynatrace UI (Container Monitoring Rules), but that has no effect.

I am wondering if there is a Annotation or Label I can apply to my pod that Dynatrace would look at and then choose to ignore the pod?

NOTE: I tried adding the annotation of feature.dynatrace.com/automatic-injection set to "false". But it had no effect.

[Julius_Loman · Accepted solution]

Hi!

You need to put different annotations, see https://www.dynatrace.com/support/help/shortlink/dto-config-k8s#annotate

However this works only for CloudNativeFullstack or ApplicationOnly depolyments of Dynatrace operator. In this case DT will not touch the pods at all. Other options such as container monitoring rules or disabling the process monitoring will still inject code modules, but will disable them.

[bkimbrough88]

The link you shared is a bad link, could you refresh the link? Or better yet, just specify the annotation we need to set to disable auto-injection?

[erh_inetum]

Hi @bkimbrough88 ,

You can find here the annotation to disable auto-injection in pods. 

Hope it helps.

Regards,

Elena.

[erh_inetum]

Hi,

We're trying to exclude namespaces in Kubernetes. For that, we've created some anotations.

First, we created labels to say which of our namespaces must be monitored and which don´t:

kubectl label namespace mynamespace dynatrace.com/inject=true

kubectl label ns mynamespace monitor=exclude

Then we modified dynakube.yaml adding this namespaceselector inside spec section:

namespaceSelector:
  matchLabels:
    dynatrace.com/inject: "true"
  matchExpressions:
    - key: monitor
      operator: NotIn
      values:
        - exclude

we applied dynakube.yaml file in Kubernetes and we restarted all pods.

But we carry on watching all the namespaces when we only should watch three with the changes applied.

We are using CloudNativeFullstack deployment.

What's wrong? Are any step missing?

Thanks in advance.

Regards,

Elena.

[Julius_Loman]

Are you sure the Code Modules are injected? You are using cloudNativeFullStack, so you will always see processes, just the deep monitoring (tracing) should not be available for pods not fulfilling the conditions.

[Stephen_Schaff]

@erh_inetum 

We went many rounds with Dynatrace support on this one and in the end they could not make this process work. (It always added the One Agent container everything on the cluster, regardless of the annotations/labels we put on.)

Dynatrace ended up just telling us that the vendor we were using was not supported. (Sorry I cannot be of more help.)

[erh_inetum]

Hi @Julius_Loman and @Stephen_Schaff ,

Thanks both for your answers.

Julius: you're right. We've checked that deep monitoring isn´t active in pods that match the conditions. But it's very strange in our case. Before having cloudNativeFullStack, we had ClassicFullStack deployment. And we defined rules on Settings >Processes and containers > Container monitoring rules. And we've seen the rules continue applying.

Anyway, the reason for we changed the deployment mode was for excluding specific namespaces from monitoring to reduce licensing. But as I've seen in this table, it's licensed per Node RAM.

So, although we exclude namespace, we don´t reduce license cost, right? And we carry on watching all namespaces in the Kubernetes app at least that we filter by specific criterias like the picture below, right?

Stephen: like you I was thinking about opening a support ticket and your comment helps me a lot. Thanks 🙂 Have you try to configure rules from Container monitoring rules? From our surprise the rules from Container Monitoring Rules are applying although Kubernetes isn´t in classicfullstack node.

Many thanks, guys.

Regards,
Elena.

[Julius_Loman]

Yes, correct. You will need applicationOnly monitoring if you need license reduction. However, depending on your workloads and memory limits for them, it's easily possible you can end up with much higher host unit consumption. And you must have memory limits for you containers, which are required also for proper scheduling in Kubernetes.

Just imagine two containers running on a single node, each one without limits. In cloudNativeFullStack (also in classicFullStack) it consumes just the license according to host memory. With applicationOnly the consumption is doubled as each container is considered as a host.

Considering licensing - applicationOnly has benefits where you need deep monitoring just for a fraction of workloads or your cluster underutilized in terms of memory.

[erh_inetum]

Hi Julius,

Understood. Thank you very much for your good explataion.

Regards,

Elena.