Kubernetes application monitoring with namespace-only access

jasonDUT — Mon, 02 Feb 2026 08:11:29 GMT

We want to monitor applications in Kubernetes but have strict access limitations:

Managed Kubernetes cluster
No privileged DaemonSets allowed
No hostPath / host access
Access limited to specific namespaces only
Custom ServiceAccount with read-only RBAC (get/list/watch on pods, workloads, services, and metrics APIs)

We cannot deploy Dynatrace OneAgent as a DaemonSet or use cluster-level components.

Question:
What is the officially supported way to monitor applications only in this scenario?
Is application-only monitoring (e.g., webhook or code-level instrumentation) the recommended approach, and what limitations should we expect?

Re: Kubernetes application monitoring with namespace-only access

AntonPineiro — Mon, 02 Feb 2026 09:10:40 GMT

Hi,

Maybe this table might help.

Best regards

Re: Kubernetes application monitoring with namespace-only access

t_pawlak — Mon, 02 Feb 2026 16:31:55 GMT

Hi,
With your constraints (no privileged DaemonSets, no hostPath/host access, namespace-only access, no cluster-level Dynatrace components), you cannot deploy Kubernetes Full-Stack monitoring based on a node-level OneAgent, nor the usual Kubernetes deployment model that relies on cluster-scoped components. The Dynatrace Operator is inherently cluster-scoped (ClusterRole, etc)
https://docs.dynatrace.com/docs/ingest-from/setup-on-k8s/reference/security

You effectively have two supported “application-only” paths (no host-level):

1. Dynatrace Application Monitoring / Application Observability (app-only, no OneAgent DaemonSet on nodes)

Monitoring is done by injecting Dynatrace code modules into application Pods (for example via init containers / build-time approaches), without installing OneAgent pods on every node and without host metrics.
If the Operator isn’t involved, Dynatrace explicitly notes you lose automatic injection/config/enrichment and must manually adapt your workloads.

Documentation here: https://docs.dynatrace.com/docs/ingest-from/setup-on-k8s/how-it-works/application-monitoring

2. Opentelemetry, I mean export OTLP to Dynatrace.
https://docs.dynatrace.com/docs/ingest-from/dynatrace-oneagent/oneagent-and-opentelemetry/oneagent-otel

Is application-only the recommended approach here?

IMO Yes. Given your constraints, it’s essentially the only practical, officially supportable route. Host/network-level features require components/privileges you can’t deploy (for example, CSI-related capabilities can require privileged permissions in typical setups). https://docs.dynatrace.com/docs/ingest-from/setup-on-k8s/how-it-works/components/dynatrace-operator

limitations:
No host-level infrastructure visibility and mabye limited Kubernetes platform/topology view, because without Dynatrace cluster components and broad K8s API access. But here you can do something like here:
https://docs.dynatrace.com/docs/ingest-from/setup-on-k8s/deployment/application-observability

topic Kubernetes application monitoring with namespace-only access in Dynatrace Managed Q&A

Kubernetes application monitoring with namespace-only access

Re: Kubernetes application monitoring with namespace-only access

Re: Kubernetes application monitoring with namespace-only access