11 Jun 2024 08:08 PM
11 Jun 2024 09:39 PM
Hello @henk_stobbe Could you please check if you have something of the type DO NOT MONITOR configured here:
regarding NGINX pods?
11 Jun 2024 09:51 PM
Hallo Daniel,
Thanks for your reply, to be honest I did not check. But I am lucky (-;
Again thank you!
12 Jun 2024 05:55 AM
Hi @henk_stobbe
I confirm you that Container Monitoring Rules disable processes injection as Daniel says. We've configured some rules here and it's disabled the deep monitoring in the processes running in the namespaces that match with the rules.
But in our case, Kubernetes is on cloudNativeFullStack and it shouldn´t apply the rules:
But it's doing it!
We changed the deployment mode from classicfullstack to cloudnativefullstack.
Maybe this is reason for which the rules continue applying. Does anyone know if this may be the reason?
Regards,
Elena.
12 Jun 2024 08:17 AM
Daniel Elena,
Both, thank you for your great tips, but there was one (and wrong) namespace defined in the dynakube.yaml.
My apologies,but still great hints, thanks!
KR Henk
13 Aug 2024 10:04 AM
Hi @henk_stobbe - are you able to share which bit in the dynakube yaml file you've seen the error in?
18 Jun 2024 12:21 PM
I'm facing the same issue...
We did a fresh installation, with Cloud Native Full Stack, and nearly every application process shows this message: so, no services monitored 😞
We did not have any rule on the environment nor any annotation/label on any Kubernetes entity.
Does anyone know what might be the cause of this and what should we do to ensure that every application pod has deep monitoring??
Thanks!
18 Jun 2024 03:03 PM
Have you validated the deployment? If possible, could you please share the results of the following commands?
kubectl get dynakube -n dynatrace
kubectl get pods -n dynatrace
are you able to see the dynatrace-oneagent-csi-driver?
Please note that both the OneAgent and the CSI driver are deployed as DaemonSets. Therefore, you should have a OneAgent and a CSI driver pod running on each node.
18 Sep 2024 09:38 AM
Hi @PedroDeodato,
I'm having the precise same issue. Fresh installation using cloudNativeFullStack. On a surface level, the full-stack monitoring seems to be working normally, but then all potential processes which could be deep monitored are seeing this error message. Did you manage to resolve it? Any idea where that "Kubernetes injection was not configured for this process" is coming from?
At least is doesn't appear to be coming from custom process monitoring rules, because then it would specifically say it's disabled due to a rule.
18 Sep 2024 10:53 AM
Greetings, @kalle_lahtinen !
I also replied above on @erh_inetum 's message, but I'll leave it here also a more detailed description, for reference.
Basically, after several interactions with Dynatrace Chat & Dynatrace Support, we gave up on Cloud Native Full-Stack.
In our case, it was not working as it is unable to instrument namespace that have a label "managedby: aks" (not the actual name of the label, but it was something like that). But our client's namespace did have this labels, purposedly, which could not be removed.
So, facing this dead end, we uninstalled the Cloud Native Full Stack and proceeded with Classic Full Stack.
All we did was install, restart application pods and everything was instrumented right away.
Since then, just to be safe, we have always went straight with Classic Full Stack: it was working great before Cloud Native Full Stack was even the default, and it continues to work great now.
Yes, it does require a restart but it is much easier to deal with customer expectations/unsatisfaction with requesting a restart, rather that having lots of messages that raise questions and services not being instrumented.
Hope this helps!
15 Jul 2024 04:07 PM
Any suggestion/recommendation on "Deep monitoring is not active". We are seeing this for all .net/Java/ngix
We installed using cloud native full stack monitoring steps and all Dynatrace pods are running but seeing following message.
18 Sep 2024 09:53 AM - edited 18 Sep 2024 09:54 AM
Hi @umeshdt2023, @kalle_lahtinen and @PedroDeodato ,
Did you try to lauch this
kubectl label namespace <my_namespace> dynatrace.com/inject=true
?
Doc: https://docs.dynatrace.com/docs/shortlink/annotate#monitor-specific-namespaces
As far as I know, deep monitoring for Cloud Native Full Stack is not enable at least you specify what namespaces, pods, etc. you want to monitor.
On my experience, I had to do that for having deep monitoring in the namespaces in which we wanted to have deep monitoring.
Hope it helps.
Regards,
Elena.
18 Sep 2024 10:16 AM
Hi Elena,
At the beginning of that doc it says:
"By default, Dynatrace Operator injects OneAgent into all namespaces, except for:
Namespaces prefixed with kube- or openshift-.
The namespace where Dynatrace Operator was installed."
Therefore we shouldn't have to separately use that config, like it says: "To configure the Dynatrace Operator to inject OneAgent into only certain namespaces".
It sounds like that config can be used if you want to disable the injection for most namespaces, and then only include a handful. But by default we should have everything included (except ones starting with kube- or openshift-).
18 Sep 2024 10:45 AM
My interpretation was the same as @kalle_lahtinen ...
But I haven't test this again for a long time... after facing the issue, we tried Classic Full-Stack and it worked like a charm, first try (after restart, obviously). Never tried Cloud Native Full Stack since.
18 Sep 2024 10:50 AM
Hi Pedro and @kalle_lahtinen ,
Thanks both for your comments.
Yes. I though like you two but we did that I said and got enabling deep monitoring. For that reason I suggested testing that.
Thanks and Regards,
Elena.
18 Sep 2024 12:29 PM
Hello @henk_stobbe
Kindly,
first check on the environment level
container monitoring level
ensure cloud application and workload detection is enabled for K8s
ensure onaagent services are configured and Restart is executed
try adding container monitoring rule
update operator version, restart and validate the Process technology is supported or not
https://docs.dynatrace.com/docs/shortlink/section-technology-support#nginx
Thanks.
12 Nov 2024 12:04 AM - edited 12 Nov 2024 12:07 AM
kubectl cluster-info
gcloud compute firewall-rules create allow-webhook-api-server \
--direction=INGRESS \
--action=ALLOW \
--rules=tcp:8443,8383,100200,8443 \
--source-ranges=192.168.0.0/8
- Service Restart: