Taming the Service Map: Optimizing Dynatrace OneAgent Auto-Discovery

The Visibility Gap in Dynamic Clusters

In a microservices architecture, the primary challenge isn't getting data—it's filtering the noise. When you deploy Dynatrace OneAgent, the auto-discovery engine immediately begins mapping every process, container, and network call. While this provides instant visibility, it often results in a "spaghetti map" where critical paths are buried under trivial health checks, internal heartbeat signals, and noisy sidecar telemetry.

The goal is to move from a raw discovery map to a functional architectural blueprint that allows an engineer to identify a bottleneck in seconds rather than minutes of zooming and filtering.

How OneAgent Constructs the Dependency Graph

OneAgent operates as a single binary that injects itself into the runtime of your applications. It uses a combination of bytecode instrumentation and network traffic analysis to identify Services (the logical unit of work) and Processes (the physical execution unit).

When Service A calls Service B via HTTP or a supported RPC protocol, OneAgent attaches a trace ID to the request. This allows the Dynatrace platform to stitch together a real-time dependency map. Because this happens automatically, you don't need to manually instrument every endpoint, but you do need to manage how these entities are categorized to keep the map readable.

Refining the Map with Custom Service Tagging

Auto-discovery tells you what is talking to what, but it doesn't understand your business logic. To make the service map actionable, you must implement a tagging strategy. This transforms a generic list of pods into logical groups like payment-gateway or auth-service.

• Environment Tags: Distinguish between prod, staging, and dev to prevent cross-environment noise.
• Criticality Tags: Mark services as tier-1 or tier-2 to prioritize alerts during a cascading failure.
• Ownership Tags: Assign services to specific teams (e.g., team-checkout) to route root-cause analysis to the right people.

Practical Example: Filtering Noisy Dependencies

Imagine a scenario where a Kubernetes-based application is flooded with health check traffic from a Load Balancer, cluttering the service map and skewing latency averages. You can use the Dynatrace settings to suppress this noise.

Configuration Step: Excluding Health Check Endpoints

To prevent /healthz or /ready calls from appearing as distinct service calls in your dependency graph, follow this logic in the Dynatrace UI:

1. Navigate to Settings > Monitoring > Service detection.
2. Locate the Ignore specific requests section.
3. Add a rule for the specific URL pattern. For example: /healthz.
4. Select the action Ignore to remove these calls from the service map and performance metrics.

Risk: If you ignore a health check that is actually failing and causing pods to restart, you may lose the telemetry that explains why the pod is crashing. Always verify that your health check logic is monitored via a different metric (like Kubernetes pod restarts) before ignoring the request telemetry.

Limitations of Auto-Discovery

While powerful, OneAgent auto-discovery has specific blind spots that require manual intervention:

• Asynchronous Patterns: Complex message queue patterns (e.g., certain RabbitMQ or Kafka configurations) may not automatically link the producer and consumer in the map if the trace context is lost during the queueing process.
• Performance Overhead: In extremely high-throughput environments (tens of thousands of requests per second per node), the continuous telemetry collection can introduce a slight CPU overhead.
• Tag Drift: If tags are applied manually rather than through an automated pipeline (like Kubernetes labels), the map can become inaccurate as services evolve.

Verifying Your Map Accuracy

To ensure your auto-discovered map reflects reality, perform a Trace Validation check:

1. Trigger a known request path (e.g., a test transaction from the API Gateway to the Database).
2. Open the Service Flow view in Dynatrace.
3. Compare the visualized path against your known architectural diagram.
4. If a hop is missing, check if the service is using a non-supported protocol or if the OneAgent version is outdated on that specific node.