23 Oct 2024 03:27 PM - last edited on 24 Oct 2024 09:27 AM by MaciejNeumann
One Agent version: 1.29.x
We use Dynatrace Operator initContainer method prvision our pods with full stack. I can see that all the technolofy stack libraries (.so files) are present and LD_LIBRARY is also correctly set.
But Golang has been disabled (intentionally not selected) from Dynatrace monitoring because it might interfere with "other" things.
One example is istio sidecar proxy container that is running in the same pod. Say we don't want this container to be monitored but want our app containers (the names of which can be anything based on what teams want - and there are 1000s of them of them - some are Golang based).
Because of this Goland has been turned off but we would like to support that.
Is there any way to override the supported technologies via some annotation or something ?
Or
There is a limitation of what we can do in kubernetes environment and Dynatrace does not support this use case?
Solved! Go to Solution.
23 Oct 2024 11:47 PM
@bhantol ,
You can't exclude based on technology, but there are a couple of approaches that you can take to help minimise this.
First is to use an opt-in based approach (monitor nothing by default).
This is done by setting up a webhook label, and only applying that label to a namespace where you want monitored. Configure monitoring for namespaces and pods - Dynatrace Docs, this way only workloads that require Dynatrace will get it. This is a little more work on deployment teams, but they can add it into their build templates.
They can also go fine grain on specific deployments and or containers.
Second - which is is an opt-out based approach (monitor everything by default).
In the Dynakube CRD, you can set up a rule like below for metadata enrichment and one agent (both need to be the same or else injection will occur anyway)
---
- namespace-A
This will then exclude monitoring from the k8s critical components (where most of the go is) and anything else you might not want monitored, whilst monitoring all the workload by default. This will also help protect your platform from not crashing (something we have had outstanding issues with when the oneagent-init container fails - e.g proxy issue).
I haven't seen any issues with the istio-proxy sidecar getting instrumented, but if you wanted to exclude (same as any other deployment) you can always add the relevant annotation 'oneagent.dynatrace.com/inject: "false"' to the deployment or in the instance of istio, the istio mesh configmap.
Hope this helps.