Workbench is an inbuilt feature provided with each extension to help you to fine-tune the extension setup before you actually deploy it on the Controller. Workbench functionality is inbuilt with each extension JAR file. Currently, the AppDynamics Platform does not allow a user to delete a metric once it has been registered. As soon as you deploy an extension directly after downloading, it will have several default settings. If you wanted to make a minor change, say in the metricPrefix of the extension, after you deployed it with the default configuration, the platform would not allow you to delete the metrics with the default metricPrefix and you would have to keep the old metrics as well. This useful feature should be used during the process of deploying each extension, since it will give you a better idea of what metrics will be recorded. If you see that you are missing some metrics, this tool will give you an opportunity to add those metrics as well. In order to use Extensions Workbench, follow these steps: Following the instructions on Cisco DevNet, build the specific extension's ZIP file and place it in the monitors folder. In the terminal, navigate to the extension folder. Verify that you have the main extension JAR file. Navigate to the extension folder that contains the jar file and execute the following command to start Workbench mode: java -jar cassandra-monitoring-extension.jar NOTE | Workbench by default uses port 9090. If you would like to change that to another port,  use the following structure to build your command:  java -jar <extension-jar> <host> <port> If you see the following output in the terminal, this means that it worked correctly and you have officially started Workbench Mode. Now, open your browser and navigate to  http://localhost:9090/ . This starts the HTTP server that allows you to access the Workbench Mode. Verify that all the desired metrics are present. Remove any unwanted metrics from the config.yml file to reduce noise. As you explore the map of metrics, you can see if you are getting a valid output on the graph on right. The metrics that are listed in the config.yml are the ones that are shown on the Workbench. Once you are satisfied with the metrics and their values that are received, stop the current process and start the Machine Agent to view the metrics being reported on the metric browser.  ... View more

What is the use case for using "taskSchedule" for extensions? How do I configure "taskSchedule"? Contents Why use "taskSchedule" to monitor intervals? How do I configure "config.yml" to use task schedule mode?  Details to know about using "taskSchedule" Why use "taskSchedule" to monitor intervals? The execution frequency for an extension is typically set using the element <execution-frequency-in-seconds> in the monitor.xml . However, this value cannot be higher than 300 seconds. For use cases where an artifact needs to be monitored with an interval greater than 300 seconds, taskSchedule should be used. The SDK provides a mechanism to cache the metrics and retain them for a maximum period of 15 minutes. When taskSchedule is configured, the Machine Agent still runs the extension as configured in <execution-frequency-in-seconds>. However, the extension returns cached values until the cache refreshes, as specified in the taskDelaySeconds field of the configuration. How do I configure config.yml to use task schedule mode? In order to use task schedule mode, the following line should be included in the config.yml . taskSchedule: numberOfThreads: taskDelaySeconds: numberOfThreads is the size of the core thread pool that is used by the Scheduled Threadpool Executor. The default is 1. taskDelaySeconds is the scheduling interval in seconds. Here is an example to schedule tasks for every 12 minutes (12 * 60 seconds) taskSchedule: numberOfThreads: 1 taskDelaySeconds: 720 Details to know about using "taskSchedule" The ideal scenario for using taskSchedule is when you want to fetch current metrics at an interval of more than 300 seconds (5 minutes). The cached metrics are only retained for 15 minutes, after which they expire and are re-cached in the next scheduled run. If taskDelaySeconds is configured to be more than 15 minutes, the extension will report null values which will lead to gaps on the Metric Browser. ... View more

Metric Transformers in the Extensions Commons Library The Java Extension SDK provides an automated utility that allows extensions developers to transform a metric name and value as it would be represented in the Metric Browser. These transformers include the Alias, the Multiplier, the Delta, and the Convert. In this article... How should the transformers be configured? List of transformers: Alias | Multiplier | Delta | Convert Additional resources How should the transformers be specified? metrics.xml <stat url="/nitro/v1/stat/lbvserver" rootElement="lbvserver" alias="Load Balancing Server Metrics"> <metric attr="cursrvrconnections" alias="Server Connections"/> <metric attr="memoryInMBytes" alias="Memory in KB" multiplier="1000"/> <metric attr="throughput" delta="true" /> <metric attr="state"> <convert str="DOWN" value="0"/> <convert str="UP" value="1"/> <convert str="UNKNOWN" value="2"/> </metric> </stat> config.yml metrics: - name: “cursrvrconnections” alias: “Cursor RV Connections” delta: true multiplier: 1000 convert: “DOWN”: 0 “UP”: 1 “UNKNOWN”: 2 NOTE | Multiple transformers can be applied to the same metric as follows: <metric attr="cursrvrconnections" alias="Server Connections" multiplier="10" delta="true"/> Please note the following: It is not mandatory to specify any of these transformers. By default, a metric does not have an alias and will be named as-is from the artifact being monitored. The default value for the multiplier is always 1. The default value for the delta is always false. A metric that yields text values will simply be skipped if a convert transformer isn’t specified. On calling transformAndPrintMetrics(List<Metric> metrics) in com.appdynamics.extensions.MetricWriteHelper , the SDK automatically applies any configured transformers before publishing these metrics.   List of transformers Alias The Alias transformer can be used to replace a metric’s name. Often, metrics are represented by ambiguous names in the artifacts being monitored, as evident in the example above. In this case, cursrvrconnections will be represented as Server Connections in the Metric Browser. Multiplier The Multiplier transformer can be used to multiply the original metric value by a configured factor. From the example above, consider that an artifact returns memory in MB and a requirement is to monitor this metric in KB. A multiplier of 1000 can be applied to this metric to satisfy this requirement. Delta Consider an ever-increasing metric value and a requirement is to monitor the number of units by which this metric increases every minute. A Delta transformer can be applied in this case. This transformer compares the value of a metric at minute X with its value at minute X-1 and publishes the difference as a metric value. NOTE | Every time the extension is run, the first value will not be reported if the delta is true. Convert The Convert transformer can be applied to metrics that return a text value from an artifact’s API. These text values can be represented as numeric values. From the example above, DOWN will be represented with a value of 0, UP with 1 and UNKNOWN with 2 for the state metric. Additional resources (Machine Agent) Extensions and Custom Metrics in the documentation ... View more

What do I need to know to use the metricPath CharSequence replacement feature of the Java SDK for AppDynamics extensions? Contents When and how can I use the metricChar replacement? How do I configure the metricChar feature? When and how can I use the metricChar replacement? The AppDynamics Controller currently supports only ASCII characters in the metric path. Several reserved characters are not supported and can cause undesirable behavior if present in the metric path. The characters separated by "|" in the metric path are called tokens. The Metric Char Replacement can be used on all metric paths that belong to any of the following scenarios : The tokens have characters outside ASCII range (unicode characters) The tokens have some reserved characters The user wants to replace some text across all tokens with shorter or more meaningful text These are things to consider when forming a metric path: Non-ASCII characters are not allowed. The default metric separator for any metric is “|” and an occurrence of “|” creates a new level of hierarchy in the metric tree. Therefore, unless “|” is actually meant for creating hierarchies, it should not be part of a metric token. “:” is similar to “|” in that it will create a new hierarchy. “,” is a special character and cannot be used in the metric path. How do I configure the CharSequence feature? In order to use the metricPath CharSequence replacement feature of the Java SDK for AppDynamics Extensions, the following section must be included in your config.yml : metricPathReplacements: - replace: replaceWith: In the section: The “replace” value cannot be empty. The “replaceWith” value cannot contain: non-ASCII characters “|” “,” “:” For example:  metricPathReplacements: - replace: "&" replaceWith: "" - replace: "-" replaceWith: "_" This example configures two replacements: replace “&” with “” and replace “-” with “_”. So, if a metric has tokens like “Read&Write”, it will be converted to “ReadWrite”, and tokens like “wait-time” will get converted to “wait_time”. The metric replacement module also loads some default replacements:  “|”, “,”, “:” are replaced with “” (empty string). These default values can be overridden by configuring them in your config.yml to be replaced with another character. For the “metricChar” replacement to work correctly, the path should not be formed in the extension’s code. Rather, the extensions commons library methods should be used to form the metric path. There are two ways to do this: Directly use the Metric constructor with signature. public Metric(String metricName, String metricValue, Map<String, ?> metricProperties, String metricPrefix, String... tokens) Use MetricPathUtils.buildMetricPath(String metricPrefix, String... metricTokens) to first build the metric path and then create the Metric object using the Metric constructor that accepts the metric path created earlier. ... View more

Contents Use Case Configuration Events Service Client Creating a Schema Retrieving a Schema Deleting a Schema Publishing Events Use Case The AppDynamics Metric Browser only supports numerical values for metrics. In order to store and monitor non-numerical values, AppDynamics has the Events Service platform. The Events Service can be accessed and used through extensions by using the Events Service client from the Java SDK for AppDynamics Extensions. The Events Service client uses the AppDynamics Analytics Events API to send non-numerical values to the AppDynamics platform. Once this information is sent to the Events Store using the client, you can query it via the Controller UI. Configuration In order to configure the Events Service client, you need to fill in certain fields of the config.yml to initiate a connection with the Analytics Events API. These fields are configured as follow: eventsServiceParameters: host: # Events Service Host port: # Events Service Port globalAccountName: # Found in Controller -> Settings -> License -> Account eventsApiKey: # Generated from Controller -> Analytics -> Configuration -> API Keys useSsl: # true/false Any existing SSL and/or proxy configurations in the config.yml are automatically used while initiating this connection. Events Service Client The Events Service Client can perform CRUD operations. The following section explains how a user can perform these operations through an extension. The Events Service client can be obtained and used in the following manner: ABaseMonitor.getContextConfiguration().getContext().getEventsServiceDataManager() For purposes of this article, we'll use the Log Monitoring Extension as an example here. Previously, if the extension captured a match, it would only send the number of match occurrences to the Metric Browser. Now, the extension uses the client to send both the number of matches and the actual log matches as strings to the Events Service API. Consider the following log snippet: [Thread-1] 29 Apr 2014 12:31:18,647 INFO DynamicServiceManager - Scheduling DynamicServiceManager at interval of 30 seconds [Thread-1] 29 Apr 2014 12:31:18,647 DEBUG LifeCycleManager - Started service [DynamicServiceManager] [Thread-1] 29 Apr 2014 12:31:18,647 INFO LifeCycleManager - Starting services [Thread-1] 29 Apr 2014 12:31:18,660 DEBUG JMXService - ###### Using config from controller for JMX operations [Thread-1] 29 Apr 2014 12:31:18,665 INFO ServerMBeanManagerVersion2 - Initialized MBean Finder with delay=120 secs [Thread-1] 29 Apr 2014 12:31:18,679 DEBUG MemoryMetricGenerator - Identified minor collection bean :ParNew Creating a Schema The first step is to create and register a custom schema with the Analytics Events API using the below method. public void createSchema(String schemaName, String schemaBody) The schema defines the overall structure of an Event Type by field and data type. In this case, let's create a schema called LogSchema with the following fields: - logDisplayName - logDirectory - searchPattern - match The schema body must be passed to the API as a JSON formatted name-value pair, as follows: { "schema": { "logDisplayName":"string", "logDirectory":"string", "searchPattern":"string", "match":"string" } } The supported data types are string, integer, float, boolean and date in either ISO 8601 or UNIX epoch format. Note that the following two timestamp fields are automatically added to every custom schema: - eventTimestamp (the time at which an event occurs) - pickupTimestamp (the time at which the event is received by the Events Service) Once you have defined all the information, this method can be called and used in the following manner:  ABaseMonitor.getContextConfiguration().getContext().getEventsServiceDataManager().createSchema( schemaName, schemaBody) Retrieving a Schema Once a schema has been created, the below method can be used to retrieve its details. A JSON formatted name-value String representing the schema is returned, identical to the body described in point 1. public String retrieveSchema(String schemaName) This method can be used in the following manner: ABaseMonitor.getContextConfiguration().getContext().getEventsServiceDataManager().retrieveSchema( schemaName) Updating a Schema This method is used to update an existing schema using an HTTP Patch operation. public void updateSchema(String schemaName, String schemaUpdates) Consider replacing the logDisplayName field in the schema body with logName and adding a new field called fileEncoding. These updates are passed to the client as a String in the following format: [ { "add": { "fileEncoding": "string" }, "rename": { "logDisplayName": "logName" } } ] This method can be used in the following manner: ABaseMonitor.getContextConfiguration().getContext().getEventsServiceDataManager().updateSchema( schemaName, schemaUpdates) Deleting a Schema These methods can be used to delete one or more previously registered schemas. They can take a single schema as input or a list of schemas. public void deleteSchema(List<String> schemaNames) public void deleteSchema(String schemaName) These method can be used in the following manner: ABaseMonitor.getContextConfiguration().getContext().getEventsServiceDataManager().deleteSchema( schemaName) // OR ABaseMonitor.getContextConfiguration().getContext().getEventsServiceDataManager().deleteSchema( listOfSchemaNames)  Publishing Events The Publish Events API call takes a collection of events and stores them in the Events Service storage. The data must comply with an existing schema. If the event data doesn't match an event schema, the API will return a 400 bad request. public void publishEvents(String schemaName, List<String> eventsToBePublished) For this example, consider monitoring the log snippet for two patterns: \\.*DynamicServiceManager.*\\ \\.*JMXService.*\\ The events should look like this: [{ "logDisplayName":"Dynamic Service Manager Logs", "logDirectory":"Some directory", "searchPattern":"\\.*DynamicServiceManager.*\\", "match":"[Thread-1] 29 Apr 2014 12:31:18,647 INFO DynamicServiceManager - Scheduling DynamicServiceManager at interval of 30 seconds" },{ "logDisplayName":"JMX Service Log", "logDirectory":"Some directory", "searchPattern":"\\.*JMXService.*\\", "match":"[Thread-1] 29 Apr 2014 12:31:18,660 DEBUG JMXService - ###### Using config from controller for JMX operations" }] The Events Service client publishes events in batches of 1000 events to conform to the Controller's custom event ingestion limits. This method can be used in the following manner: ABaseMonitor.getContextConfiguration().getContext().getEventsServiceDataManager().publishEvents( schemaName, eventsToBePublished) Detailed information about the Analytics Events API can be found here: Analytics Events API ... View more

How is HttpClient used in the extensions commons library? This document explains the httpClient used by the extensions commons library, part of the Java SDK for AppDynamics Extensions. Table of Contents Goal Usage Configuration Goal Most of the extensions collect metrics from an HTTP(s) endpoint. Instead of creating an httpClient in every extension, we have created an httpClient for the commons library that can be used in all the extensions. Usage CloseableHttpClient httpClient = configuration.getContext().getHttpClient() , where configuration is an object of the MonitorContextConfiguration class. Configuration To use httpClient in any extension, provide the following configuration in the config.yml file: Server Configuration Connection Configuration Server Configuration The two servers configured below are valid. Config1 is preferred over Config2. Config1 servers: - uri: "" username: "" password: "" encryptedPassword: "" Config2 servers: - host: "" # Avoid this, use uri instead port: "" # Avoid this, use uri instead useSsl: false # Avoid this, use uri instead. username: "" password: "" encryptedPassword: "" Configuring multiple servers Configuring multiple servers in a single config.yml is also supported. servers: - uri: "" username: "" password: "" encryptedPassword: "" # Uri is preferred instead of host-port-useSsl combo. - host: "" # Avoid this, use uri instead port: "" # Avoid this, use uri instead useSsl: false # Avoid this, use uri instead. username: "" password: "" encryptedPassword: "" A username and password can also be provided or you can provide the encrypted password and leave the password field empty. NOTE: You can add an encrypted password for each server, but the encryptionKey will be the same for all the servers as defined in the config.yml file. If you provide values for both the password and encryptedPassword, the extension will give precedence to the value provided in the password field and the encryptedPassword will be disregarded. If you would like to use HTTPS, specify protocol as https in Config1 or change the value of useSsl to true in Config2. Connection Configuration Connection configuration is optional, but enables you to have more choices when trying to establish a new connection with a server. Like the encryptionKey, this section is universal for all the servers listed in the config.yml file. connection: socketTimeout: 3000 connectTimeout: 1000 sslProtocols: ["TLSV1.2"] sslCertCheckEnabled: true sslVerifyHostname: true sslCipherSuites: [] sslTrustStorePath: "" sslTrustStorePassword: "" sslTrustStoreEncryptedPassword: "" sslKeyStorePath: "" sslKeyStorePassword: "" sslKeyStoreEncryptedPassword: "" Flag Description Remarks socketTimeout Time limit in milliseconds for a socket to time out after establishing a connection   connectTimeout The connection will timeout after this number of milliseconds   sslProtocols Array of strings of all the protocols to be followed Defaults to "default" sslCertCheckEnabled Set this to true to enable Certificate checks Ideally, it is suggested that both sslCertCheckEnabled and sslVerifyHostname listed about should be true for security reasons. sslVerifyHostname Set this to true to enable host name verification   sslTrustStorePath Path to the SSL TrustStore Defaults to machine-agent/conf/extensions-cacerts.jks sslTrustStorePassword Truststore password in cleartext The keystore needs to have either sslTrustStorePassword or  sslTrustStoreEncryptedPassword sslTrustStoreEncryptedPassword Encrypted TrustStore password   sslKeyStorePath Path to the SSL KeyStore Defaults to machine-agent/conf/extensions-clientcerts.jks sslKeyStorePassword SSL Keystore password in cleartext   sslKeyStoreEncryptedPassword Encrypted SSL Keystore password   ... View more

What extension Health Checks generate logs I can use for debugging issues? The Java SDK for AppDynamics Extensions runs a few checks to validate the Application and Machine Agent configuration and to ensure an error-free run of any configured extensions. These checks on validation (or failure) log messages in the Machine Agent logs to help debug any issues. These checks are primarily categorized into: RunOnce Check: Runs only once on the start of the extension. RunAlways Check: Run periodically based on the defined frequency. RunOnce Check AppTierNode Check: Ensures correct Machine Agent and SIM configuration with the following checks: ControllerInfo: Controller information can be configured either using System properties or via the controller-info.xml file present in the path <MachineAgent>/conf . Extension checks verify data from both places. In case the Controller information is not found in either of the places, then the missing ControllerInfo error message is logged. SIM Enabled: From the controller-info obtained in the previous step, this checks if SIM is enabled or not. Application/Tier/Node: Based on the result obtained in the previous step: When SIM is disabled, configuring the App/Tier/Node is mandatory, or an error will be reported. When SIM is enabled, App/Tier/Node does not need to be configured. ExtensionPathConfig Check: Performs the following checks on the extension path configuration: Metric Prefix: Logs errors if the metric prefix retrieved from config.yml is null or empty. Tier ID: This check is performed as follows: When SIM is enabled, there is no check for Tier ID. When SIM is disabled, the Tier ID set in config.yml is verified with the TierName (or the corresponding Tier ID)  in controller-info.xml . Machine Agent Availability Check: When SIM is disabled, this checks whether the Machine Agent Availability metric reports 1 or not. A GET request to the Controller for the following URL checks the MA availability: /controller/rest/applications/ApplicationName/metric-data?metric- path=ApplicationInfrastructurePerformance|TierName|Agent|Machine|Availability&time-range- type=BEFORE_NOW&duration-in-mins=15&output=JSON RunAlways Check  MaxMetricLimit Check: Machine Agent metrics limit is a frequently encountered error. Whenever this error occurs, the following message appears in the Machine Agent logs: ERROR ManagedMonitorDelegate - Maximum metrics limit reached [450] no new metrics can be created. This exception will not repeat until restart. The MaxMetricLimit check logs an error on any occurrences of this string in the Machine Agent logs.  MetricBlacklistLimit Check: A Blacklist limit error is logged as in the following warning:  WARN ManagedMonitorDelegate - Metric registration blacklist limit reached This check looks up the Machine Agent logs for any occurrences of this string and, if found, logs the message and the error details. ... View more

Uploading pre-built extension dashboards automatically: when and how do I do it? Contents When can pre-built extension dashboards be automatically uploaded? How do I configure the extension with the necessary Controller information? Configuring the "controllerInfo" section Configuring the "customDashboard" section What post-configuration steps and considerations are there? What is the use case for automatically uploading dashboard extensions?  AppDynamics extensions support automatically uploading a pre-built dashboard with every extension. This feature will help customers use an extension to extract all the listed metrics and provide an overview of how the product is doing in terms of certain key metrics. These dashboards can all be updated, and more data can be added to increase the visibility of the metrics the extension provides. Back to Contents How do I configure the extension with the necessary Controller information? In order to upload a dashboard to the Controller, you need to provide some information about the Controller that will help the extension log in and upload the dashboard to the Controller. Each new extension is going to be equipped with two dashboard files: one for the Standalone Machine Agent model and one for the Server and Infrastructure Monitoring (SIM) model. While configuring the extension, you will need to configure the following sections: controllerInfo and customDashboard.  Configuring the "controllerInfo" section This section requires you to fill out the information about the Controller, which in turn is used to make sure that the extension can establish a connection to the Controller and upload the dashboard. The extension pulls the information in the following order from the following resources: controller-info.xml System Properties Config.yml Update the following section in the config.yml : controllerInfo: controllerHost: "" controllerPort: "" account: "" username: "" password: "" encryptedPassword: "" encryptionKey: "" controllerSslEnabled: "" enableOrchestration: "" uniqueHostId: "" accountAccessKey: "" machinePath: "" simEnabled: "" applicationName: "" tierName: "" nodeName: "" As you start your agent, a number of the fields will be auto-populated. But a few fields will need to be  manually populated. These are:  username: "" password: "" These fields are required for the Machine Agent to be able to log in and upload the dashboard. Once all this information is provided, populated, and validated, the extension will upload the dashboard to the Controller.   After filling it out, this section should look like this:    Configuring the "customDashboard" section Similar to ControllerInfo, another section called customDashboard needs to be updated in order to make sure that a dashboard can be uploaded to the Controller from the extension. customDashboard: enabled: true dashboardName: "Custom Dashboard" pathToSIMDashboard: "monitors/<ExtensionName>/simDashboard.json" pathToNormalDashboard: "monitors/<ExtensionName>/maDashboard.json" periodicDashboardCheckInSeconds: 300 If enabled is false, the dashboard will not upload. If dashboardName is not present, the extension Monitor Name will be used as the dashboard name. The two fields that you should verify are the pathToSIMDashboard and pathToNormalDashboard. Both of these fields need to point to two files that are provided with the extension. If there are any changes made to these files, you must make sure that the changes are saved to these files, and in the case they are replaced with new files, their path should be updated in the config.yml . As the extension sits in the Machine Agent, the path after the base directory of the Machine Agent is needed. Make sure you have the correct file separator:  (\) for Windows OS (/) for Linux-based OS Dashboards cannot be overwritten on the Controller. Therefore, if a dashboard is already present on the Controller, you will not be able to upload another dashboard with the same name. If you make any changes to the dashboard file to suit your needs, you should save the dashboard.json file and delete the current dashboard on the Controller. By default, the extension will check to see whether a dashboard is present on the Controller every 5 minutes (300 seconds). If it is not present, it will attempt to upload it. You have the option to increase or decrease this limit using the periodicDashboardCheckInSeconds parameter. Back to Contents What post-configuration steps and considerations are there? After filling in both these sections and configuring the rest of the extension to its specific needs, you can start the Machine Agent to gather metrics, and check to confirm that the dashboard has been uploaded and is being populated with the correct data. What if I need to make changes to the dashboard file? Every extension that comes with a dashboard has preconfigured metrics set to show in the dashboard. If any changes are made to the dashboard file, you will need to delete the existing dashboard present on the Controller so that the extension can upload a new copy of the dashboard with those changes. How do I compare differences in versions of the dashboard file? If you would like to compare the differences after making changes to the dashboard file, bear in mind that dashboard file names on the Controller must be unique. So, you should: Make sure your intended new dashboard name isn't already present on the Controller Change name of the dashboard in   config.yml under the customDashboard section Once the extension hits the periodic dashboard check limit, it will again check if the dashboard with the new name is present. If not, it will upload the new dashboard which you may then use for comparison. How do I add metrics to the dashboard file? Each extension has specific metrics you can choose to display on the dashboard. If you would like to see other metrics, you can add them to the same dashboard (on the Controller) manually. If any changes are made to the metric names/aliases in the config.yml , those changes need to be replicated in the dashboard.json files since they are preconfigured to look for metrics with the default metric names/aliases that are provided with a new copy of the extension. If changes to the metric names/aliases in the config.yml  are not replicated, there is a good chance that the dashboard widgets associated with the corresponding metrics may not work. Back to Contents ... View more

The following Knowledge Base articles contain detailed information related to features in AppDynamics Extensions. They can help you troubleshoot your extension, as well as helping you become more informed on when and how to use different extension functionalities.  PLEASE NOTE | Not all features are available for every extension.  How-to articles How do I troubleshoot missing custom metrics or extensions metrics in the Controller? How do I use password encryption with extensions? How do I use the Extensions Workbench? How are derived metrics calculated in AppDynamics Extensions? Derived metric calculation in AppDynamics extensions — what are the assumptions and limitations? How do I upload pre-built extension dashboards automatically? What extension Health Checks are useful for debugging? When and how can I use "HttpClient" with extensions? How do I use Events Service with extensions? Metric path "CharSequence" replacements in extensions: What do I need to know? What Metric Transformers can I find in the extensions commons library? Why and how do I use "taskSchedule" for extensions? Errors and troubleshooting How do I troubleshoot AWS extension issues? Troubleshooting extension HealthCheck issues due to incorrect parameters JMX-based extension connectivity: How do I troubleshoot issues? My extension is getting a 'PKIX path building error.' Why? ... View more

Configuring extensions for password encryption Most of our extensions support password encryption. To use this service, please follow these steps exactly as specified. NOTE | Once done, you will have to uncomment the encryptionKey and encryptedPassword and update them with the ones that you generate in the config.yml file. When you complete these steps, your extension will be ready for password encryption. Contents Generate the encrypted password Configure config.yml with the encrypted password   STEP 1. How do I generate the encrypted password? In this case, we will take Cassandra Monitoring Extension as an example.  Navigate to your Machine Agent installation folder, then head to the “monitors” folder.       Now enter your Extension folder, or in our case, “ CassandraMonitor ” and copy the name of the jar file (here, “ cassandra-monitoring-extension.jar ”) Open your terminal and navigate to the CassandraMonitor folder. In the folder within terminal, make sure the jar file is present  (i.e., cassandra-monitoring-extension.jar ). Once you’ve verified all the details, run the following command. This command will give you your encrypted password. java -cp "cassandra-monitoring-extension.jar" com.appdynamics.extensions.crypto.Encryptor myKey myPassword The “myKey” in the command can be any random key that you'd like to use to encrypt the password. The “myPassword” is the plaintext password that you normally use to log in to your product. This is the password that you are trying to encrypt. NOTE | If you have special characters in your plaintext password or your encryption key, you need to escape the special characters with a backslash (\) in the above command.  For example, if the plaintext password is myPa$$word , the encryption command should look like this: java -cp "cassandra-monitoring-extension.jar" com.appdynamics.extensions.crypto.Encryptor myKey myPa\$\$word Once you run the command, here is how the encrypted password will be generated: The value under “ Encrypted String ” above corresponds to your encrypted password.   Save the values for your encryptionKey  and Encrypted String  in a text editor so that you don’t lose them. STEP 2. Configuring config.yml with the encrypted password: In the config.yml of the extension, insert the encryptionKey  and Encrypted String . The value for encryptionKey field is the random encryption key that was used in the command. For example, in the example above we used myKey as the encryption key. The value of encryptedPassword is the result of the above command. Once you complete all the steps in this article, your extension will be ready to use the newly generated encrypted password. ... View more

AppDynamics Extensions Troubleshooting Guide Before proceeding with this document, go through the Extensions Prerequisites Guide and verify whether the environment and agents being used have been set up correctly. PLEASE NOTE | Not all steps may be applicable for your extension.   Contents How do I build and place an extension? How do I configure an extension? What do I need to know about the Machine Agent restart? Where do I look for custom metrics? Additional troubleshooting resources 1. How do I build and place an extension? To build the extension artifact from the source, follow the prerequisite and installation steps from individual extension documentation.  Once the artifact is generated, extract it to the <MachineAgentHome>/monitors directory. It is important to verify the supported Controller, Machine Agent, and artifact versions from the extension's documentation. 2. How do I configure an extension?  Every monitoring extension is shipped with a file called config.yml. The following steps must be verified for the config.yml: A. Metric Prefix Most config.yml files contain two metricPrefix sections which may look like the following (Considering the Redis Monitoring Extension as an example): metricPrefix Prefix Recommended use "Custom Metrics|Redis" This metric prefix is recommended when SIM is enabled. "Server|Component:<COMPONENT_ID>|Custom Metrics|Redis" This metric prefix is recommended when you would like to publish metrics to the Machine Agent configured tier. This metric prefix points to one specific component (tier). The COMPONENT_ID can be found by using these steps: Go to your Controller Select the application associated with your Machine Agent Select Tiers and Nodes, then select the exact tier corresponding to your Machine Agent Once you select the tier, click the Details button to open the Dashboard Once you reach the Dashboard, take a look at the URL and find the word Component and the value corresponding to it That value should be a number and is the tier ID or Component ID that you need to update as your Component_ID value in the config NOTE | The component ID, or component name, is the same as the tier ID, or tier name. To get the component ID, go to the URL under Applications > Tiers & Nodes > Dashboard, as shown in the image, below. Applications > For your component ID URL, go to Applications > Tiers & Nodes > Dashboard, then copy the URL field IMPORTANT | The component ID (or component name) specified in the metric prefix of the extension should match the corresponding tier of the Machine Agent. The extension cannot report to a different tier than its Machine Agent's tier.  LEARN MORE | To read about advanced metric prefix configuration scenarios, please refer to the Advanced Metric Prefix Configuration Scenarios for AppDynamics Monitoring Extensions Knowledge Base article. B. How do I format the config.yml? After verifying the metric prefix and configuring the details of the artifact monitored by the extension, ensure that the config.yml is correctly formatted. The use of Tabs is not supported by YML files. You can validate the file using an online YML validator like https://codebeautify.org/yaml-validator.   C. How do I modify the monitor.xml file? Another file present in the extracted extension's directory is the monitor.xml. In most cases, this file does not need any changes. If the monitor.xml does need to be modified, complete the following steps: Execution frequency An extension ships with a default execution frequency of 60 seconds. The highest execution frequency supported by monitoring extensions is 5 minutes (300 seconds). It is important to ensure that this limit is not exceeded, as it will lead to inconsistencies in metric values. Path to config Ensure that the path to the config.yml is correctly specified under the following tag: <task-arguments> <argument name="config-file" is-required="true" default-value="monitors/RedisMonitor/config.yml" /> </task-arguments> An absolute path can also be used here. 3. What do I need to know about the Machine Agent restart? At this point, ensure that the Machine Agent has restarted.  Deploying new extensions and making changes to the monitor.xml for previously deployed extensions require a Machine Agent restart. However, simply changing the contents of a previously deployed extension's config.yml does not require a Machine Agent restart. 4. Where do I look for custom metrics? Once everything has been configured correctly, follow the relevant steps below to look for Custom Metrics in the Controller: A. When the SIM is enabled If SIM is enabled, navigate to the Servers tab in the main menu bar. Click on Metric Browser at the bottom-left. A new window should open up. Expand the 'Root' server, or alternatively, the server configured under the 'Machine Path' section of the <MachineAgentHome>/conf/controller-info.xml. Select Custom Metrics. Metrics from the configured extensions should show up here, in their respective directories. B. Machine Agent (When the SIM is disabled) Find the Application associated with the Machine Agent under the Applications tab in the main menu bar. Click on Metric Browser at the bottom-left. A new window should open up. Select Application Infrastructure Performance, and look for the Tier associated with the Machine Agent Under this tier, look for Custom Metrics. Metrics from the configured extensions should show up here, in their respective directories. The data in the previous point is a tier-level value, an aggregation of data represented by each node under this tier. To get metrics pertaining to a specific node, the Individual Nodes section must be used.   5. Metric Limits What if you followed all the steps up to this point, but still don’t see all the required metrics in the Metric Browser?  It could be a case of the Machine Agent's metric limit being hit. In this case, you should restart it with a higher metric limit. For example, to increase the limit to 5000, you can use the following command while starting the Machine Agent: java -Dappdynamics.agent.maxMetrics=5000 -jar machineagent.jar However, this limit should not be an arbitrarily large number. It is a factor of the number of metrics generated by any installed extensions, heap memory provided to the Machine Agent, etc. Check the hardware and sizing requirements for Machine Agents and extensions in the Machine Agent Requirements and Supported Environments documentation. For more information, see the latest Metric Limits documentation. Increasing metric limits in Windows For Windows, where the Machine Agent is running as a service: Uninstall/delete the already installed service Use this command to increase metric limit cscript <machine_agent_home>\InstallService.vbs -Dappdynamics.agent.maxMetrics=5000 If at this point the extension’s metrics are still not visible, please refer to the extension-specific troubleshooting steps (if any) found on the respective extension documentation pages. Additional troubleshooting resources My extension is getting a 'PKIX path building error.' Why? Troubleshooting extensions HealthCheck issues due to incorrect parameters  When uploading custom dashboards from extensions, how do I resolve issues? Metric processing qualifiers for extensions: what do I need to know? Troubleshooting connectivity issues for JMX based extensions How do I troubleshoot AWS extensions issues? Advanced extension configurations and troubleshooting ... View more