- Web applications served from an application server.
- Databases or other data stores.
- Remote services such as message queues and caches.
AppDynamics app agents automatically discover the most common application frameworks and services. Using built-in application detection and configuration settings, agents collect application data and metrics to build flow maps.
A flow map visually represents the components of your application to help you understand how data flows among the application components. For example, the business transaction flow map for a simple ecommerce e-commerce application below shows data flowing between web services, message queues, and databases:
- In an e-commerce application, a user logging in, searching for items , or adding items to the cart.
- In a content portal, a user requests content such as sports, business , or entertainment news.
- In a stock trading application, operations such as receiving a stock quote, buying , or selling stocks.
AppDynamics app agents discover requests to your application as entry points to a business transaction. Similar requests, such as user log inlogin, are treated as multiple instances of the same business transaction. The agents tag the request data and trace the request path as it passes from web servers to databases and other infrastructure components. AppDynamics collects performance metrics for each tier that processes the business transaction.
Because AppDynamics orients performance monitoring around business transactions, you can focus on the performance of your application components from the user perspective. You can quickly identify whether a component is readily available or if it is having performance issues. For instance, you can check whether users able to log in, check out , or view their data. You can see response times for users, and the causes of problems when they occur.
In a small AppDynamics deployment, only a single business application may be needed to model the environment. In larger deployments, you may choose to divide the model of the environment into several business applications.
A node in the AppDynamics model corresponds to a monitored server or JVM in the application environment. A node is the smallest unit of the modeled environment. Depending on the agent type, a node may correspond to an individual application server, JVM, CLR, PHP application, Apache Web server.
A tier is a unit in the AppDynamics model is a grouping of one or more nodes. How you organize tiers depends on the conceptual model of your environment.
Often a tier is used to a group of a set of identical, redundant servers. But that 's is not strictly required. You can group any set of nodes, identical or not, for which you want performance metrics to be treated as a unit into a single tier.
The single restriction is that all nodes in a single tier must be the same type. That is, a tier can't cannot have mixed types of agents, such as both .NET and Java nodes.
- There is no interaction among nodes within a single tier.
- An application agent node cannot belong to more than one tier.
A backend is a component that is not instrumented by an AppDynamics agent but that participates in the processing of a business transaction instance. A backend may be a web server, database, message queue, or other another type of service.
The agent recognizes calls to these services from instrumented code (called exit calls). If the the service is not instrumented and cannot continue the transaction context of the call, the agent determines that the service is a backend component. It The agent picks up the transaction context at the response at the backend and continues to follow the context of the transaction from there.
Performance information is available for the backend call. For detailed transaction analysis in for the leg of a transaction processed by the backend, you need to instrument the database, web service , or other application.
Integration with other AppDynamics Modules
- You use the Standalone Machine Agent to collect basic hardware metrics. One Machine Agent license is included with each App Agent license that you purchase. You can deploy this Machine Agent only on the same machine where the App Agent is installed. Functionality The functionality provided by the Machine Agent includes:
- Basic hardware metrics from the server 's OS, for . For example, %CPU and memory utilization, disk and network I/O
- Custom metrics passed to the Controller by extensions
- Run remediation scripts to automate your runbook procedures. You can optionally configure the remediation action to require human approval before the script is started.
- Run JVM Crash Guard to monitor JVM crashes and optionally run remediation scripts
- If you have a Server Visibility license, the Standalone Machine Agent provides the following additional functionality:
- Extended hardware metrics such as machine availability, disk/CPU/virtual-memory utilization, and process page faults
- Monitor application nodes that run inside Docker containers and identify container issues that impact application performance
- The Tier Metric Correlator, which enables you to identify load and performance anomalies across all nodes in a tier
- Monitor internal or external HTTP and HTTPS services
- Group servers together so that health rules can be applied to specific server groups
- Define alerts that trigger when certain conditions are met or exceeded based on monitored server hardware metrics
Network Visibility monitors traffic flows, network packets, TCP connections, and TCP ports. Network Agents leverage the APM intelligence of App Server Agents to identify the TCP connections used by each application. Network Visibility includes the following functionality:
- Detailed metrics about dropped/retransmitted packets, TCP window sizes (Limited / Zero), connection setup/teardown issues, high round trip times, and other performance-impacting issues
- Network Dashboard that highlights network KPIs (Key Performance Indicators) for tiers, nodes, and network links
- Right-click dashboards for tiers, nodes, and network links that enable quick drill-downs from transaction outliers to network root causes
- Automatic mapping of TCP connections with application flows
- Automatic detection of intermediate load balancers that split TCP connections
- Diagnostic mode for collecting advanced diagnostic information for individual connections
In Application Monitoring, a database called by an instrumented node is considered a remote service. You can get a significant amount of information on the interaction between the application node and database, but not from the database server 's perspective. When using Database Visibility with Application Monitoring, you can drill down to detailed database performance information directly from application flowmapsflow maps. For more information see Access Database Visibility from Application Monitoring Views.
For those times when tracing application code doesn't does not provide enough clues to track down the cause of a problem, AppDynamics provides visibility into the transaction logs that can be correlated to specific business transaction requests. Log correlation visibility requires a license for both Transaction Analytics and Log Analytics. See Business Transaction and Log Correlation.