Dynatrace OneAgent Automatic Kubernetes Service Discovery Without Manual Instrumentation

The Problem: Blind Spots in Dynamic Kubernetes Clusters

\n

When a critical microservice fails or disappears in a Kubernetes cluster teams often struggle to identify not just that it is down but why and which other services depend on it. Pods scale restart and evict automatically and without static instrumentation the map of service interactions goes stale within minutes. Traditional monitoring requires manual service registration and rule configuration work that cannot keep pace with the velocity of modern containerized environments.

\n

Thesis: OneAgent Eliminates Manual Service Discovery

\n

With OneAgent version 1.200 or later Dynatrace automatically discovers and monitors microservices in Kubernetes clusters without requiring code changes or manual configuration. It uses PurePath technology to trace requests across containers building a real-time dependency map that shows how services interact and where failures originate. The feature adapts to both plain Kubernetes clusters and Istio-enabled service meshes updating service lists and dependency graphs as pod populations change.

\n

PurePath-Powered Dependency Mapping

\n

Dynatrace discovery engine analyzes incoming and outgoing network traffic identifying service endpoints based on HTTP TCP patterns and Kubernetes service definitions. Each request is traced end-to-end across containers and the platform correlates host metrics container resource usage and network data to maintain an accurate service-to-service map. This works without agents per service or changes to application code.

\n

Outage Detection with Correlated Insights

\n

When a service degrades Dynatrace correlates CPU and memory metrics from the host container-level resource throttling network latency between pods and Kubernetes events such as pod restarts. The platform then propagates impact analysis upstream and downstream surfacing which microservices are affected by a failure in a specific component. This reduces mean-time-to-resolution by eliminating the need to manually cross-reference logs metrics and ticketing systems.

\n

Worked Example: Verifying Automatic Discovery

\n

To confirm that OneAgent is discovering services correctly you can generate a small amount of traffic between two microservices and observe the Dynatrace UI. The following example assumes you have a Kubernetes cluster with OneAgent v1.200 or later already deployed and two microservices that communicate over HTTP.

\n

kubectl apply -f test-services.yaml

\n

Where test-services.yaml defines service-a and service-b with service-a making HTTP calls to service-b.

\n

Generate traffic from service-a to service-b:

\n

for i in {1..200}; do curl -s http://service-b.default.svc.cluster.local/health; done

\n

Run the command from within a pod that has network access to the cluster or from a temporary debug container. Required permissions include read access to pods services and endpoints in the target namespace. In Dynatrace navigate to Technologies Services within five minutes of traffic generation both services should appear and the Dependencies view should display the call from service-a to service-b. If services do not appear verify that OneAgent has the necessary RBAC permissions to list pod and service objects and that the observation window has elapsed.

\n

Limitations and Trade-offs

\n

Automatic discovery is powerful but has constraints. Short-lived or batch jobs that handle insufficient traffic within the observation window may not be classified as distinct services until they accumulate enough request data. Environments with very high pod churn more than ten restarts per hour can temporarily misclassify transient pods until the discovery engine stabilizes. Additionally all automatic mapping features require OneAgent version 1.200 or later older deployments must rely on manual service monitoring rules. The platform also uses a five-minute observation window meaning very brief traffic spikes might not trigger immediate service classification.

\n

These trade-offs mean that while OneAgent reduces manual effort teams should validate discovery outcomes in their specific environment and supplement with explicit monitoring rules for critical short-lived workloads.

\n

If you are ready to reduce manual monitoring overhead start by confirming OneAgent version and generating a small amount of traffic between two microservices. The Dynatrace UI will surface discovered services within minutes and the Dependencies view will reflect actual call patterns without any YAML edits. For clusters still on earlier OneAgent versions upgrading is the fastest path to automatic service discovery and its correlated root-cause insights.

\n