On this page:

Your Rating:
Results:
PatheticBadOKGoodOutstanding!
17 rates

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.  

Connection Settings

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:

  • Controller host: The hostname of the Controller to connect to. Agents may connect directly to the Controller or through a proxy.
  • Controller port: The port on which the Controller listens for agent traffic. Agents use the same port as the browser connection for the UI.
  • Account name: The name of the account in the Controller. A single tenant Controller has only one default account, customer1, in addition to the internal system account. For most connections, you use the Account name. The global account name is used for certain connections to the Events Service, such as from the Analytics Agent. 
  • Account access key: A unique key associated with the Controller account. See the following section for information on getting your key.  
  • SSL enabled: If the agent should connect using SSL. 

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.

Finding Your Account Name and Access Key

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:

  1. While logged in to the Controller UI as a user with view license permissions, click the gear icon () and choose License
  2. Click on the Account tab. The account name appears next to the Name label. The name is customer1 in a single tenant, on-premises Controller, but varies on SaaS Controllers. 
  3. Click Show next to the Access Key label to reveal the account default access key setting for this instance. Use this value as the Account access key setting in agents. 

If you create license rules in addition to the default rule, the access key for each rule is displayed in the Rules tab.

Securing the Connection

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:

  • SSL
  • TLS
  • TLSv1.2
  • TLSv1.1

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. 

On-premises Controller Secure Connections

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 Controller Secure Connections

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.

App Agent Security

To configure your agents for SSL, set these SSL-related properties: 

  • Set controller-ssl-enabled to true.
  • Set the controller-port to the correct value for either on-premises or SaaS Controller.

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.       

Standalone Machine Agent Security

For information on the security settings related to the Standalone Machine Agent connection to the Controller, see Standalone Machine Agent Configuration Properties

Verify the Connection

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. 

Agent-Controller Communication Intervals

Each AppDynamics agent has multiple communication channels for different purposes that initiate connections to the Controller independently at different time intervals.

  • The agent configuration channel queries the Controller for any new configuration changes every 60 seconds and downloads the changes when they are available.
  • The agent metric channel posts all new periodic metrics, including JMX, Windows performance counters, and business transaction metrics to the Controller every 60 seconds. 
  • If there are new business transactions that haven’t been seen before by the agent, they are posted to the Controller for registration every 10 seconds.
  • If the agent has collected any new snapshots or events, they are posted to the Controller every 20 seconds.

Information Sent to the Controller

The following table shows the types of information that are collected by an application agent and sent to the Controller.

MetricDescription
Server Request GUIDA 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 PointsTransaction 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 PointsTransaction 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 MetricsIn 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 TracesCode 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 ValuesIf 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 CollectorsIf 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.
HostnameThe 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 UsageThe value of CPU that is consumed on the monitored machine/virtual machine.
Memory UsageThe value of physical memory that is consumed on the monitored/virtual machine.
Network I/O UsageThe value of network I/O that is consumed on the monitored machine/virtual machine.
Disk I/O UsageThe value of disk I/O that is consumed on the monitored machine/virtual machine.
JVM Performance

JVM Heap Usage, JVM Memory Pools Settings, Garbage Collection performance, JVM System/Start-up Options, MBean metric values (for example, connection pool names and metric values, such as active connections, maximum connections, and so on)

Blitz Load Profile

Blitz is a horizontally scalable data processing platform for SaaS deployments. It collects metric data from agents, which it then aggregates and stores.

The 10M metrics/min Blitz load profile includes the following agents and churn information:

  • Active load 10MM with 24K nodes. Total registered metrics is 40M.

  • Node distribution:

    • DotNet = 3K

    • SIM Machine Agents OR Docker Containers  = 4K
    • DBMon Data Collectors = 1K

    • Java Nodes = 16K

    • EUM Browser Apps = 60

  • Java Node Churn: 1K/hr

  • Either SIM or Docker Churn

    • Sim Node Churn = 40/hr (1% of 4K SIM nodes)

    • Docker Churn = 200 containers/hr

  • Node purger enabled with hard-limit of 4K and soft-limit of 10K

  • SIM node purger enabled with deletion max limit of 300/hr

  • No labels