An application map is a topology view of the components of a distributed application and the network or interprocess interactions between them. A recent article gives an overview of application mapping approaches adopted by various tools like AppDynamics, OpenTracing and Netsil.
An application map can be viewed as a graph of of nodes and edges where the nodes represent components and the edges represent interactions between the components. Components can be processes (on the same machine) or compute instances, or a combination of both. In the former case, the edges would represent the interprocess communication (IPC) interactions between processes, and communication over the network in the latter. Important characteristics of application maps are grouping of instances, application level details, and visibility into key metrics like error rates.
Why are application maps important? They provide visibility into components and their dependencies, help in incident response by finding the root cause, identify critical paths for monitoring and alerting, help in data-driven capacity planning, and identify possible security issues.
The article summarizes two approaches to application mapping - static and dynamic, with a detailed explanation of the dynamic approach. The mapping software has to trace the path of requests between the various components to arrive at an application map for a distributed application. Dynamic tracing techniques include end-to-end tracing and individual tracing.
End to end (E2E) tracing software like Application Performance Management (APM) tools and code instrumentation SDKs both require the presence of either a local software agent or modified code in the application. AppDynamics, Dynatrace and New Relic use code profiling and tracking of transaction paths to create maps. The proliferation of new technology stacks is a challenge for APM tools, as they constantly need to keep adding support for newer stacks. Tracing SDKs like OpenTracing, Datadog APM and AWS X-Ray collect correlation information between various components by injecting headers into requests. Unique ids and metadata in the headers then help build up the map.
End to end tracing can assist in tracing the exact path of requests, but they also generate huge amounts of data, can be intrusive in terms of integration, and do not give any indication of performance issues. Some tools like Zipkin, however, aim to provide performance insights also.
Individual tracing (also referred to as Ingress and Egress) leverages log files and operating system level tracing. These two sources of data change less often compared to technology stacks, providing a stabler method. Since this technique works at the network layer, it can map any component that communicates over the network, including those that cannot be traced using E2E methods. However, the low-level nature of this method has downsides. The context of where a specific data packet occurs in a request’s lifecycle may not be evident from such tracing. Deriving this context can be complex depending on the application software. This method does not work for encrypted calls and might require deep packet inspection to correlate the data with business transactions.