Discussion Feed

Table of Contents Overview SIM Standalone Machine Agent   Overview AppDynamics Monitoring Extensions require a Server Infrastructure & Monitoring (SIM) agent or a Standalone Machine Agent (MA) to report metrics to the AppDynamics Controller. For more details on SIM, check Server Visibility . For more details on MA, check Standalone Machine Agent .   IMPORTANT:   AppDynamics Extensions are supported only if there is a single instance of either a MA with APM agents or a SIM agent on a physical host. Multiple instances of MA or SIM on a single physical host is not supported for extensions installation.   SIM      In this mode, it is imperative to purchase the Server Visibility license and provide the sim-enabled flag to the agent. It can be provided as a JVM argument to the MA or can be specified in the controller-info.xml. For more details, refer to Enable Server Visibility .   In this case, the agent’s metrics will be reported in the Metric Browser under the "Servers" tab in the controller as shown below : Standalone Machine Agent In this mode, there are two installation scenarios   1.  When using the APM MA installation scenario , the application name, tier name, and node name should not be provided to the MA as it will piggyback on the APM Agents running on the same server. In this case, the agent’s metrics will be reported under the Metric Browser of all the APM apps.     2.  In the Independent MA installation scenario , a Server Visibility License (SIM License) is mandatory. Please refer to SIM section above.   Once the agent setup is complete, the agent should be started and the hardware metrics reported by the agent should be verified in the Controller.   IMPORTANT: AppDynamics Extensions should be installed on the agent only after verifying whether the agent’s hardware metrics are being reported consistently in the controller.       ... View more

Assumptions There are the assumptions made before the derived metrics calculation is initiated: All the base metrics (in all different levels) are available (i.e, the metrics have been reported) for derived metrics calculation. For a derived metric to be calculated, all of its base metrics should have reported a valid Number.   Limitations The limitation when using the derived metrics calculator is:  A derived metric cannot be reused in another derived metric   If a derived metric has to be calculated at different levels, each metric has to be specified separately in the list of metrics under the derivedMetrics  section. For example, in the following metric tree:                      Server1               Queue                   Queue1                         RAM ops : 9                         Hdd ops: 3                          Total ops:12                   Queue2                         Total ops : 2                         Hdd ops: 6                          Total ops:8                     Total ops: (12 +  8 = 20)              If the "Total ops" metric is required both at the queue level and server level, then the derivedMetrics  section looks as follows:   - derivedMetricPath: “{x}|Queue|{y}|Total ops" //queue level Total ops formula: “{x}|Queue|{y}|RAM ops + {x}|Queue|{y}|Total ops” - derivedMetricPath: “{x}|Total ops" //server level Total ops formula: “{x}|Queue|{y}|RAM ops + {x}|Queue|{y}|Total ops”   The queue level “Total ops” derived metric cannot be used for calculating the server level or any other level derived metric. ... View more