Automating Dependency Mapping in Dynatrace with OneAgent Full-Stack Monitoring

The problem: manual dependency maps slow down incident response

When a micro‑service architecture grows, teams often spend time drawing diagrams or maintaining spreadsheets to understand how a request travels from a web front‑end to a database, a cache, or a third‑party API. If the map is out‑of‑date, an incident can lead to wasted effort hunting down the wrong component.

How OneAgent discovers services and dependencies

Dynatrace OneAgent is a single binary that is installed on each host. It automatically detects running processes, injects a lightweight sensor into supported runtimes (Java, .NET, Node.js, Go, etc.), and begins collecting process‑level metrics, network calls, and database statements. The injected sensor creates a PurePath for each incoming request, capturing every hop across processes, containers, or services. Simultaneously, the agent reports process and network topology to the Dynatrace backend, which builds the Smartscape map—a real‑time, directed graph of hosts, process groups, services, and their dependencies.

Worked example: Java Spring Boot app + PostgreSQL

1. Download the OneAgent installer from your Dynatrace environment and run it with your environment token, for example:

   ./oneagent.sh install --set TENANT= --set TENANT_TOKEN=
   

2. After the installer finishes, verify that the host appears in the Dynatrace UI under Hosts and that the Java process is listed as a process group.
3. Navigate to Smartscape and select the host; you should see the Spring Boot process group connected to the PostgreSQL process group via a network link labeled with the destination port (typically 5432).
4. To validate end‑to‑end tracing, introduce a synthetic fault—for instance, temporarily block outbound traffic to the database port on the application host:

   sudo iptables -A OUTPUT -p tcp --dport 5432 -j DROP
   

5. Trigger a request to the application (e.g., curl http://localhost:8080/api/orders). In the UI, open PurePath for that request; you will see the PurePath start in the Java process, then show a failed or delayed SQL call, allowing you to trace the impact upstream to the web tier.
6. Remove the iptables rule to restore normal operation and observe that the PurePath now completes successfully.

Trade‑offs and limitations

• Resource overhead: each monitored process adds CPU and memory usage; the overhead grows with the number of instrumented methods and the depth of database statement capture.
• Runtime support: while OneAgent covers mainstream JVMs, .NET, Node.js, and Go, some legacy or proprietary runtimes may need manual sensor placement or custom extensions for full visibility.
• Trace retention: high‑granularity PurePath data is stored for a limited time (often a few hours to days) based on license tier; older transactions are summarized, which can affect deep forensic analysis.
• Verification: after installation, check the Processes page for expected process groups and the Smartscape view for automatic links; if a link is missing, verify that network traffic is not blocked by host firewalls and that the corresponding port monitoring is enabled in the OneAgent configuration.

Actionable next steps

Start with a non‑production host that runs a multi‑tier service you own. Install OneAgent using the steps above, confirm the Smartscape map appears, and then run a simple failure test as shown. Use the observed PurePath to validate that the dependency mapping matches your architectural diagram. If the map is incomplete, review the OneAgent logs (/opt/dynatrace/oneagent/log) for messages about unsupported runtimes or blocked network sensors, and adjust the agent configuration or host firewall accordingly.