On this page:
AppDynamics app agents need to connect to an AppDynamics Controller to retrieve configuration data and send back information about the monitored environment. This page provides general information on the connections between the agents and Controller.
The connection between the agent and Controller is a one-way connection initiated by the agent. Therefore, you only need to configure connection settings in the agent.
To be able to connect to the Controller, the agent needs to know the following information:
If you downloaded the agent through the Agent Download Wizard in the Controller, the Controller host, port, and account settings are already configured for you.
If the agents in your environment connect to the Controller (whether a SaaS Controller or a on-premises Controller) through a proxy, the Controller host and port settings should be those of the Controller, but you will need to configure the proxy settings for that agent. See, for example, the proxy settings descriptions in Java Agent Configuration Properties.
To connect to SaaS Controllers from agents in environments that limit outbound connections, you need to set firewall rules that permit access to AppDynamics SaaS platform components. For a list of SaaS IP addresses, see SaaS Domains and IP Ranges.
If configuring the agent manually rather than through the agent download wizard, you will need to set the Controller host and port, account name, and account access key settings manually. If you have an Admin account, you can find your account name and access key in the AppDynamics Controller UI. If you are not an admin, you must ask your administrator for your access key.
To view your account name and default access key:
If you create license rules in addition to the default rule, the access key for each rule is displayed in the Rules tab.
The .NET Agent uses the settings in the container to negotiate the SSL protocol with the Controller. Normally you do not need to configure the security protocol for the .NET Agent.
For the Java Agent, see the Agent and Controller Compatibility for a list of the default security protocol for the different versions of the Java Agent.
If the default security protocol for your version of the Java Agent is incompatible with the Controller or an intervening proxy, pass the
‑Dappdynamics.agent.ssl.protocol system property to set the protocol to one of the following security protocols:
Use the following format:
java -javaagent:<agent_home>/javaagent.jar ... -Dappdynamics.agent.ssl.protocol <protocol> ...
Controller-specific security considerations vary between SaaS and on-premises Controllers, as described below.
An on-premises Controller has both an active secure (HTTPS) port and an HTTP port. Agents can use either to connect to the Controller. By default, the certificate used for the secure connection is a self-signed certificate. The .NET agents cannot connect on a secure port that uses a self-signed certificate, so you will need to apply your own certificate to the port. App Agents connecting to an AppDynamics SaaS Controller also must use an HTTPS connection.
To implement SSL for the Controller-agent connection:
SaaS Controllers require the use of SSL. Thus, you only need to enable SSL in the configuration settings for your agents and connect them to the secure Controller port, 443. For more information, see the following sections App Agent Security and Machine Agent Security.
To configure your agents for SSL, set these SSL-related properties:
In multi-tenant and SaaS environments, App Agents authenticate themselves to the Controller using the required account name and account access key values set in the connection properties configuration file.
For information on the security settings related to the Standalone Machine Agent connection to the Controller, see Standalone Machine Agent Configuration Property Reference.
You can verify that an app agent is reporting to the Controller from the Tiers & Nodes list in the Controller UI (see Tiers and Nodes) or from the AppDynamics Agents page under the gear icon (see Manage App Agents).
In the Tiers & Nodes pages, for instance, the App Agent Status column indicates the agent connectivity with a green arrow icon for active, connected agents, or a red down arrow for a agent that has been previously recognized but not currently connected.
If the agent is not reporting to the Controller, see troubleshooting information:
If traffic is not being properly correlated between tiers, make sure that any network components (such as load balancers or routers) that sit between monitored nodes need to preserve the AppDynamics correlation header from HTTP traffic.
Each AppDynamics agent has multiple communication channels for different purposes that initiate connections to the Controller independently at different time intervals.
The following table shows the types of information that are collected by an application agent and sent to the Controller.
|Server Request GUID||A unique GUID identifying a request, known as a Business Transaction, in the form of "xxxxxxxx-xxxx-xxxx- xxxx-xxxxxxxxxxxx" where the x's are lowercase hexadecimal digits.|
|Application Entry Points||Transaction entry points are identified among various frameworks and technologies. This includes Servlet URIs, Strut Action and Method name, Spring Bean Name and Method Name, JMS queue destination or listener name, Web Service/WCF action/operation name, PHP Virtual Name, and more.|
|Application Exit Points||Transaction exit points are identified among various frameworks and technologies. This includes: HTTP URL end points, JMS queue/destination, type, and vendor; database URL endpoint and vendor/version, web service Service Name, cache name and URL endpoint.|
|Performance Metrics||In general, for each monitored metric in AppDynamics, a response time, call rate, and error rate are collected. Each of these metrics also have an automatic baseline derived for each respective metric value.|
|Thread Stack Traces||Code level method execution metrics that comprise the application request are collected. This data includes the class and method that executed and the line number within the source code. Note that less than 5% of transactions will have stack traces collected. Errors/Exceptions Exception and stack trace of error data will be collected.|
|SQL Query Values||If assigned with administrative permissions, SQL query variables within a query can be enabled, collected, and viewed. Note that the parameter data is collected for less than 5% of transactions. Configuration changes are logged in an audit log that is available for security review.|
|Data Collectors||If assigned with administrative permissions, data in the form of HTTP values or method payload can be collected and viewed. Note that a specific data collectors and code payload accessors require explicit configuration to be collected. Also, data is collected for less than 5% of transactions. Configuration changes are logged in an audit log that is available for security review.|
|Hostname||The DNS hostname of the machine (virtual/physical) from where the agent is installed and reporting monitoring data.|
|IP Address Internet Protocol (IP)|
IP Address Internet Protocol (IP) address of the machine (virtual/physical) from where the agent is sending monitoring data.
|CPU Usage||The value of CPU that is consumed on the monitored machine/virtual machine.|
|Memory Usage||The value of physical memory that is consumed on the monitored/virtual machine.|
|Network I/O Usage||The value of network I/O that is consumed on the monitored machine/virtual machine.|
|Disk I/O Usage||The value of disk I/O that is consumed on the monitored machine/virtual machine.|
JVM Heap Usage, JVM Memory Pools Settings, Garbage Collection performance, JVM System/Start-up Options, MBean metric values (e.g., connection pool names and metric values, such as active connections, maximum connections, etc)