Discussion Feed

    Users who have installed an AppDynamics monitoring extension and are not able to see metrics in the controller should use the following guide to troubleshoot.   1. Is the machine agent’s "availability" metric being reported?   The machine agent’s “availability” metric confirms that the machine agent is correctly configured with Controller. If the metric is not being reported, then it is a machine agent and Controller association problem and that should be rectified first. See below to further troubleshoot this issue.       2. Is SIM enabled?   If yes, the metrics would show up in the metric browser under the Servers tab.       If not, you are running the machine agent in a standalone mode. In standalone mode, it is imperative to provide application-name, tier-name, and node-name to the machine agent. These can be provided as JVM arguments to the machine agent or can be specified in the controller-info.xml file. For more info: Independent Standalone Machine Agent Install Scenario.   In standalone mode, the custom metrics are reported in the metric browser under the specified application.     3. Is there an AppDynamics Java Application Agent running on the same host?   The application-name, tier-name, and node-name are not required if there is an app agent with a matching unique host. For more details about a unique host, see Unique Host ID .   Even if the application-name, tier-name, and node-name are set and there is an app agent running with the same unique host ID but with a different tier information, the machine agent will report only to that same tier to which the app agent is associated to. So, in this case, the application-name, tier-name, and node-name set in machine agent will be ignored.   4. Did you specify the right component/tier information in the extension's config.yaml file?   Every extension is shipped with a field called " metricprefix  in the config.yaml. There are two possible formats for this. For example, in case of Cassandra Monitoring Extension, the  metricPrefix   could be:       a. metricPrefix: "Custom Metrics|Cassandra"     b. For controller versions 4.1.x and 4.2.x (up to 4.2.9)             metricPrefix: "Server|Component:<Component_id>|Custom Metrics|Cassandra"         For controller versions 4.2.10 and above           metricPrefix: "Server|Component:<Component_id or Component_name>|Custom Metrics|Cassandra"   If you have SIM enabled, you should set the metric prefix as specified in option a. If machine agent is running in standalone mode, we should set it as specified in option b.   Note:  The component_id or component_name here is the same as the tier_id or tier_name. To get the component_id information, please check the url as specified here:       IMPORTANT: The component id or component name specified in the "metricPrefix" of the extension should match the corresponding tier of the machine agent. The extension cannot report to a tier different than its machine agent's tier.     5.  Are you hitting the metric limit in the machine agent?   The number of metrics sent by the machine agent is limited by the -Dappdynamics.agent.maxMetrics JVM argument. Try increasing the limit and restarting the machine agent. More information on this here:  Metrics Limits.    PNote that you should not just set this number to an arbitrarily large number. It is a factor of how many metrics are produced by your installed extensions, heap memory provided to the machine agent, etc. Check the hardware and sizing requirements for machine agent and extensions here: Hardware and Sizing Requirements   6. Does the extension work in Workbench mode?   Note that some of the AppDynamics extensions ship with workbench mode. The purpose of workbench mode is to view metrics before they get registered in the controller. Using this mode, you can filter the unwanted metrics and report only what is intended.   Check the corresponding extension documentation from the AppDynamics Community Exchange  to see if workbench mode is supported.     If you still face issues with the custom metrics, please open a ticket with the Support Team and provide machine agent debug logs. Machine Agent Debug logs:   Edit the file <MachineAgent>/conf/logging/log4j.xml . Change the level value of the following  <logger> elements to debug. <logger name="com.singularity" <logger name="com.appdynamics" Let it run for 10 mins and then zip and upload all the logs in the directory MachineAgent/logs/*   ... View more

AppDynamics extensions are divided into three broad categories: Monitoring extensions, Alerting extensions, and Cloud Connector extensions.      Monitoring Extensions   These extensions run as monitors on AppDynamics Machine Agent and report metrics from an artifact to AppDynamics Controller. Examples of these are Cassandra Extension and  Memcached Extension.  A guide to building monitoring extensions using Java and Shell Scripts can be found in the product documentation here and here respectively.    Alerting Extensions   These extensions are integrations that run as custom actions on the AppDynamics Controller. Most of these alerting extensions work only for dedicated (single-tenant) SaaS Controller or on-premises Controllers. Examples of these are PagerDuty Extension and VictorOps Extension.   Cloud Connector Extensions   These extensions enable custom implementations of orchestration functionalities such as creating, destroying, restarting, configuring, and validating machine and image instances directly from the AppDynamics Controller user interface. Example of this is AWS Cloud Connector Extension.  A guide to building cloud connector extension can be found here. Find more information in the AppDynamics Exchange. ... View more