apm overview - node

APM Overview - Node.js
APM Overview - Node.js . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 AppDynamics for Node.js Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
Supported Environments and Versions for Node.js . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 Install the Node.js Agent . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
Upgrade the Node.js Agent . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 Uninstall the Node.js Agent . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
Run the Proxy Daemon Manually for Node.js Agents . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 Set Up A Multi-Tenant Proxy for Node.js Agents . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
Configure AppDynamics for Node.js . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 Configure Transaction Detection for Node.js . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
Import and Export Transaction Detection Configuration for Node.js . . . . . . . . . . . 21 Configure Error Detection for Node.js . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
Monitor Node.js Applications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27 Monitor Node.js Business Transactions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
Monitor Node.js Processes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30 View Process Snapshots . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33 Node.js Process Metrics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
Process Snapshots and Business Transaction Snapshots . . . . . . . . . . . . . . . . . . 38 Monitor Node.js Backends . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
Troubleshoot Errors for Node.js . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40 Resolve AppDynamics Issues for Node.js . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
First Time Using the Node.js Agent . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
Copyright © AppDynamics 2012-2014 Page 3
APM Overview - Node.js This information covers using and configuring the Node.js Agent.
For general information about AppDynamics see and Application Intelligence Platform AppDynami .cs Features
Monitor Node.js Applications
Install the Node.js Agent
AppDynamics for Node.js Architecture
The AppDynamics Node.js Agent instruments your application running one or more Node.js processes. Instrumentation enables the agent to discover, map and track metrics for business transactions, application services, and backends in your Node.js application. Typically there is a
one-to-one correspondence between a process and a Node.js application but sometimes an application consists of multiple processes.
This agent communicates with a Java proxy dameon that handles the communication between the Node.js Agent and the AppDynamics Controller. The proxy reports the performance metrics to the Controller, where the data is stored, baselined, and analyzed. You can access this performance data interactively using the Browser UI or programmatically using the AppDynamics REST API.

Supported Environments and Versions for Node.js
Supported Platform Matrix for the Node.js Agent Node.js Versions Operating Systems Transaction Naming HTTP Exit Points Database Exit Points Cache Exit Points
Supported Platform Matrix for the Node.js Agent
Node.js Versions
0.8
0.10
Node.js Web URI
HTTP Exit Points
Database Exit Points
Requirements AppDynamics Controller Permissions
Advanced Instructions Node.js Agent Settings Older Node.js Versions Instrumenting a Cluster of Node.js processes 3.9 Controller Temporarily Unavailable Resolving Installation Issues for Node.js
Logs Node.js Agent Log Proxy Log
Installing the Standalone Machine Agent on a Node.js Node Learn More
Requirements
AppDynamics Controller
To use the AppDynamics Node.js Agent, you need an AppDynamics account on a running v3.9+ controller.
You can use the AppDynamics SaaS controller. If you do not already have an account on the SaaS controller you can .sign up for a subscription here
Or you can use an on-premise controller that is installed at your site. You can download an , and then .on-premise controller from here follow these instructions on how to install it
You need to know the controller host and port to complete the agent installation. Check your welcome email from AppDynamics for the host and port if you signed up for a SaaS account.
Permissions
Installing the Node.js Agent
To install the latest version you can run 'npm install appdynamics' for each application you want to monitor, but we recommend matching the agent version to your AppDynamics Controller version:
npm install appdynamics@<version>
1. 2. 3. 4. 5. 6.
For example, if your AppDynamics controller version is 3.9.0, we recommend installing the 3.9.0 Node.js Agent:
npm install [email protected]
Then paste the following in your application as the very first line of your application source code, before any other require statement. Replace the variables with the values for your setup:
require("appdynamics").profile({ controllerHostName: '<controller host name>', controllerPort: <controller port number>, controllerSslEnabled: false, // Set to true if controllerPort is SSL accountName: 'AppDynamics_account_name', // Required for SaaS accounts accountAccessKey: 'AppDynamics_account_key', // Required for SaaS accounts applicationName: 'your_app_name', tierName: 'choose_a_tier_name', nodeName: 'choose_a_node_name', });
Testing the Installation
Stop and restart your application. Run some traffic through the application. Wait a few minutes. Log into your controller. Select the newly instrumented application. You should see metrics reported in the flow maps.
Advanced Instructions
Node.js Agent Settings
This is the complete list of settings in the require statement that you insert into your application code. Not all these settings are required.
controller host name: the ip address or host name of your controller. SaaS customers receive this url in their welcome email from AppDynamics. On-premise customers set them when they install the controller. controller port: 8080 c : set to true if connecting to the controller via SSL. Otherwise removeontrollerSslEnabled this line.
accountName: your username on the SaaS controller or multi-tenant on-premise controller. SaaS customers receive this their welcome email from AppDynamics. If you have a single-tenant controller, remove this line. accountAccessKey: your account access key on the SaaS controller or multi-tenant on-premise controller. SaaS customers receive this their welcome email from AppDynamics. If you have a single-tenant controller, remove this line. applicationName: name that represents the entire application in the AppDynamics console tierName: name that represents your Node.js app or service in the flow maps nodeName: prefix to the name of the instrumented Node.js process(es) on a single machine. There can be multiple nodes. The agent uses this setting as the prefix to the node name and then auto-numbers the suffixes for the remaining nodes on the same machine to create the node name that you see in the AppDynamics UI. For example, if you set this value to MyNode, nodes are named MyNode-0, MyNode-1, MyNode-2 . . . for multiple worker processes on the same machine. If you have only one process to monitor, the node is still named MyNode-0 according to this convention. To suppress the -0 suffix use .noNodeNodeNameSuffix If you have clusters of worker processes on different machines, the agent begins numbering the suffixes at -0 on each machine. In this case you could specify different prefixnodeName es for each server to name the nodes according to the pattern Server1-0, Server1-1, Server1-2 . . ., then Server2-0, Server2-1, Server2-2 and so on. Each combination must be unique.applicationName/nodeName btEntryPointDelayDisabled: true|false - Optional: defaults to false. Setting to true can accelerate the startup of business transactions, but it can adversely affect drilldown in distributed transactions. maxProcessSnapshotsPerPeriod: integer - Optional: defaults to 2. Number of automatic process snapshots allowed in processSnapshotCountResetPeriodSeconds seconds (see below). processSnapshotCountResetPeriodSeconds: Optional: defaults to 60. Frequency, in seconds, at which the automatic process snapshot count is reset to 0. autoSnapshotDurationSeconds: Optional: defaults to 10. Length, in seconds, of automatically-triggered process snapshots. proxyAutoLaunchDisabled: true|false - Optional: default to false. Set to true if you need to manually launch the proxy for this agent. See Run the Proxy Daemon Manually for Node.js
.Agents Optional: Set to true if you do not want the agent to add a suffix (-0,noNodeNameSuffix:
-1, -2, etc.) to the node name. In this case multiple worker processes appear in AppDynamics as a single node. proxyCtrlDir: directory path for the directory containing the domain control socket, which the agent uses to start an AppDynamics node. Optional: set by the agent. Set manually if you are setting up a multi-tenant proxy. See Set Up A Multi-Tenant Proxy for Node.js Agents . rootTmpDir: directory path for the root of the directory that stores the agent's files. Optional: defaults to /tmp/appd. tmpDir: directory path for the sub directory of the root directory for the monitored node. Optional: defaults to a hash of the controller info for the instrumented node. debug: true|false - Optional: defaults to false. Turn this option on for logging and troubleshooting.
Older Node.js Versions
If your Node.js version is between 0.8.1 and 0.8.18 inclusive, you need to set the user-agent npm property before you run the npm install command. The syntax is:
npm config set user-agent "node/<version> {linux|darwin} {x64|i86}"
For example:
Instrumenting a Cluster of Node.js processes
If you are launching a cluster of Node.js processes to implement your app, add the appdynamics require statement to the master process code and to the code of each of the worker processes.
3.9 Controller Temporarily Unavailable
If you cannot obtain a 3.9 controller, it is possible to get started using the agent with a 3.8.6 forcontroller, until you can upgrade. For more information, contact [email protected]
information on how to do this.
Resolving Installation Issues for Node.js
If you are trying to install the Node.js Agent on a version of Node.js that the agent does not support, the installation will fail and you will see a message similar to the following:
npm ERR! notsup Unsupported npm ERR! notsup Not compatible with your version of node/npm: [email protected] npm ERR! notsup Required: {"node":">=0.8.0 <=0.10.31"} npm ERR! notsup Actual: {"npm":"1.4.28","node":"0.10.32"}
npm ERR! System Linux 2.6.18-348.16.1.el5 npm ERR! command "<your command>" npm ERR! cwd <path> npm ERR! node -v v0.10.32 npm ERR! npm -v 1.4.28 npm ERR! code ENOTSUP npm ERR! npm ERR! Additional logging details can be found in: npm ERR! <path>/npm-debug.log npm ERR! not ok code 0
Check the AppDynamics to find out the latest Node.js version supported by therelease notes agent.
If you need an agent for an unsupported version, contact about getting anAppDynamics Support agent for that is compatible with your environment.0.8.X and 0.10.X versions of Node.js
Logs
There is an agent log and a proxy log for each application.
Node.js Agent Log
If the agent is running in debug mode, the agent component logs stdout/stderr. This log containsto the transactions that the agent processes and sends to the proxy. This log is available in the same location to which stdout/stderr streams are directed from the monitored application.
If debug mode is not enabled, no agent log is generated.
You may set debug mode in the require statement that instruments your Node.js application. See .Node.js Agent Settings
Proxy Log
The proxy logs the transactions that it accepts from the agent and sends to the Controller. The proxy generates logs whether or not the agent is running in debug mode.
When the agent component launches the proxy, it displays in the agent log the directory path to which the proxy is logging.
1. 2.
Installing the Standalone Machine Agent on a Node.js Node
If you install the Standalone Machine Agent on the machine hosting the instrumented Node.js node and you specify the tier and node name in the machine agent's controller-info.xml file, the Node.js Agent will fail to register.
To avoid this problem:
Install the Node.js Agent before you install the Standalone Machine Agent. Do not specify the tier and node in the machine agent controller-info.xml, where it is optional. The Standalone Machine Agent will pick up the tier and node from the app agent configuration.
Learn More
Upgrade the Node.js Agent
If you are upgrading both the Controller and agents, first upgrade the Controller and then upgrade the agents.
Also, if you are upgrading multiple agents in your monitored environment, upgrade the agents for the tiers on which business transactions originate last. For more information about this requirement, along with Controller and agent compatibility information, see Agent - Controller Compatibility Matrix.
To upgrade the app agent
Stop the Node.js application. From the root directory of the application for which you want to upgrade the agent, uninstall the old version of the agent by entering:
npm uninstall appdynamics
From the same directory install the new version by entering:
npm install appdynamics@<version>
The version is the three-digit version number of the new version that you are installing; for example, 3.9.1. Restart the Node.js application.
1.
2.

To uninstall the Node.js Agent
From the application root directory of the application from which you want to uninstall the agent enter:
npm uninstall appdynamics
Remove the "require("appdynamics")" statement from your Node.js applications.
Run the Proxy Daemon Manually for Node.js Agents
By default, when the Node.js Agent starts up, it automatically executes the runproxy shell script. This script runs the Java proxy daemon that handles communication between the Node.js Agents and the controller. See for information about how the Java AppDynamics for Node.js Architecture proxy daemon fits into the Node.js Agent architecture.
Automatic startup of the proxy works for the great majority of situations. However, you can suppress the automatic startup of this script and run it manually. You would do this if you are running a cluster of Node.js nodes on the same machine and you want to reduce overhead by having them report to a single proxy. In this case, you need to configure the agents for a single proxys and for manual proxy launch. Then you need to launch the proxy manually. See:

Multi-tenant Setup To configure agents for a multi-tenant proxy
Limits on Agents Sharing a Proxy Learn More
By default, if you are running multiple agents, each agent automatically launches its own Java
1.
2.
3.
4.
5.
proxy to communicate with the controller.
In this single-tenant scenario, each agent has its own proxy control directory. In the require statement for each agent, the proxy control directory is set to a unique path (a unique app/tier/node combination). The agent creates these directories automatically.
This results in a configuration in which each agent has its own proxy. The Node.js Agents will auto-launch their proxies when they start up.
If you want to run multiple Node.js Agents on the same machine, you can reduce your overhead by setting up the agents to report to a single multi-tenant Java proxy. In this case, you would need to start that proxy manually and create the mutli-tenant proxy directory manually. This configuration is appropriate for Node.js processes running in cluster mode.
Multi-tenant Setup
To set up a multi-tenant proxy, you need to configure the proxy control directory. This directory contains the domain control socket, which the agent uses to start an AppDynamics node. This directory is where the agent gets the configuration for the node. The permissions on this directory must be readable and executable by the application user that the application and writable by the proxy user.
To configure agents for a multi-tenant proxy
Configure each agent for manual launch of the proxy. To do this, in the require statement of each agent, set the proxyAutoLaunchDisabled setting to true. Manually create a single proxy control directory for use by all the agents that will share the proxy. In the AppDynamics require statement for all the agents reporting to the proxy, set proxyCtrlDir to the directory that you created in step 2. Verify that each agent reporting to the multi-tenant proxy is configured with a unique node name. Manually launch the multi-tenant proxy before you start the agents, passing the agent control directory set in step 3 as the proxyCommunicationDir argument to the runproxy script. See . AppDynamics recommends that you Run the Node.js Proxy Daemon Manually launch the proxy on system startup.
Limits on Agents Sharing a Proxy
The proxy is set up to handle a maximum of 10 agents reporting to a single proxy. The proxy.out file, visible if you are running in debug mode, indicates if the proxy is running out of heap. You may need to adjust the maxHeapSize and maxPermSize settings in the runproxy script if you have more than ten agents reporting to a single proxy. Contact if you need toAppDynamics Support change these settings.
Learn More
Set User Preferences
Accessing Transaction Detection To Access Business Transaction Detection Configuration
Node.js Web Entry Point Business Transaction Naming and Identification
Dynamic Transaction Naming Based on the Request Default Detection for Node.js Web Entry Points Configure Custom Match Rules for Node.js Web Entry Points
To configure a custom match rule for a Node.js Web entry point To modify a custom match rule for a Node.js Web entry point To remove a custom match rule for a Node.js entry point
Configure Exclude Rules for Node.js Web Entry Points To configure an exclude rule for a Node.js Web entry point To modify an exclude rule for a Node.js Web entry point To remove an exclude rule for a Node.js Web Web Services entry point
Learn More
1. From the left navigation pane select .Configure -> Instrumentation
2. Click the Transaction Detection tab if it is not already selected.
3. Click the Node.js -Transaction Detection tab.
4. Do one of the following:
To configure transaction detection at the application level, in the left panel select the application. If you select the application, you can optionally click the button to configure all tiers to use the application-level configuration.
To configure transaction detection at the tier level, in the left panel select the tier for which you want to configure transaction detection. You can choose the button to apply the application configuration to the selected tier or the button to create a custom configuration just for this tier.
Node.js Web Entry Point
The entry point is where the business transaction begins. Typically an entry point is a method or
operation or a URI.
To enable transaction monitoring check the Transaction Monitoring check box. You can disable monitoring at any time by clearing this check box.
For Node.js Web entry points to be automatically detected, check the Automatic Transaction Detection check box.
Business Transaction Naming and Identification
The default convention for Node.js Web transactions is to use first two segments of the URI of the application to name the transaction. Click if you want to change the namingConfigure Naming convention to the full URI or to use different segments of the URI to give the business transactions more meaningful names.
If the first two segments of all your transactions are similar, you might want to base the business
Both Transaction Monitoring and Automatic Transaction Detection have to be enabled for the agent to collect metrics for business transactions.
If you disable automatic detection for a specific entry point type for which you have been detecting transactions (by clearing the Automatic Transaction Detection check box for the entry point type in the transaction detection configuration screen), the agent will stop collecting metrics for transactions of those entry point types. It will also stop detecting new transactions of those types.
But the transactions that the agent has already detected will still appear in the transaction list, with metrics no longer being reported, unless you have explicitly deleted them from the list. You can delete transactions from the business transactions list using the More
item. See .Actions->Delete Transactions Business Transactions List
transaction names on a different part of the URI:
Dynamic Transaction Naming Based on the Request
You can also configure dynamic transaction naming based on the details of the user request.
For example:
If the web context is ,/secure/internal/updateinventoryhttp://example.com/store the naming strategy would use last two segments to name these requests as ./internal/updateinventory
If the web context is http://wines.com/store/orders.special the, the naming strategy would use combination of the parameter value for "type" and the last two segments to name such requests
. as /orders/process.special Similarly, depending on the web could, you can use the cookie, header, request method or any combinations of URI segments to configure useful business transaction names.
Default Detection for Node.js Web Entry Points
By default, AppDynamics automatically names Node.js Web transactions based on the url of the application.
You may be seeing too many or too few Node.js Web transactions. If you are not getting the visibility that you need with the default configuration, create one or more custom match rules for Node.js Web entry points.
If you are seeing too many transactions, create exclude rules to prevent the agent from discovering the entry points that you do not need to monitor. Or create custom match rules that group several entry points into a single entry point.
If you are seeing too few transactions, review your custom match rules rules to make sure that they detect all the entry points that you want the agent to discover.
Configure Custom Match Rules for Node.js Web Entry Points
You can configure multiple match criteria for the agent to use to detect the transaction.
The agent determines the match using only the configured criteria.
To configure a custom match rule for a Node.js Web entry point
1. Access the Node.js transaction detection instrumentation window. See Accessing Transaction .Detection
2. Scroll down to the Custom Match Rules section.
3. Click the add icon to add a new custom match rule.
4. In the New Business Transaction Match Rule - Web window, enter a name for the rule.
5. Check the Enabled check box to enable the rule.
6. Optionally enter the priority of this rule for the app agent to use when multiple rules could apply to the same entry point. See .The Priority Parameter when Multiple Rules Apply
7. In the Transaction Match Criteria section, for each match condition that you want to specify, do the following:
a. Check the check box for the segment for which you are configuring a match.
b. In the text field, enter the value against which to match.
c. Select the condition to use to determine the match from the dropdown list. To reverse the condition, click the gear icon and check the NOT condition check box.
8. Click .Create Custom Match Rule
To modify a custom match rule for a Node.js Web entry point
3. From the Custom Match Rules list, select the rule that you want to modify.
4. Double-click the rule or click the edit icon.
5. Modify the rule as needed. See steps 6 and 7 in To configure a custom match rule for a Node.js . If you want to disable the rule, clear the Enabled check box.Web entry point
6. Click .Save
To remove a custom match rule for a Node.js entry point
3. From the Custom Match Rules list, select the rule that you want to remove.
4. Click the delete icon.
5. In the Confirm Delete window click .OK
Configure Exclude Rules for Node.js Web Entry Points
You can configure an exclude rule to exclude from detection any entry point that matches the configured match conditions. The match conditions are the same as those available for configuring
.a custom match rule
Transactions excluded through exclude rules are never detected and are not counted towards the business transaction limit.
By default, a pre-configured exclude rule is provided to exclude business transactions for static content such images, CSS files, JavaScript files, and static HTML pages.
You can modify or remove this exclude rule if it does not fit your needs.
To configure an exclude rule for a Node.js Web entry point
2. Scroll down to the Exclude Rules section.
3. Click the add icon to add a new exclude rule.
4. In the New Exclude Business Transaction Match Rule - Web window, enter a name for the rule.
5. Check the Enabled check box to enable the rule.
6. In the Transaction Match Criteria section, for each match condition that you want to specify, do the following:
a. Check the check box for the segment for which you are configuring a match.
b. In the text field enter the value against which to match.
c. Select the condition to use to determine the match from the dropdown list. To reverse the condition, click the gear icon and check the NOT condition check box.
7. Click .Create Exclude Rule
To modify an exclude rule for a Node.js Web entry point
3. From the Exclude Rules list, select the rule that you want to modify.
4. Double-click the rule or click the edit icon.
5. Modify the rule as needed. See step 6 in To configure an exclude rule for a Node.js Web entry
. If you want to disable the rule, clear the Enabled check box.point
6. Click .Save
To remove an exclude rule for a Node.js Web Web Services entry point
3. From the Exclude Rules list, select the rule that you want to remove.
4. Click the delete icon.
5. In the Confirm Delete window click .OK
Learn More
Import and Export Transaction Detection Configuration for Node.js
Import and Export Auto-Detected Entry Point Configurations To import or export the configurations for all the auto-detected entry-points to or from an application To import or export the configuration for a single auto-detected entry point type to or from an application To import or export the configurations for all the auto-detected entry-points to or from a tier To import or export the configuration for a single auto-detected entry point type to or from a tier
Import and Export Custom Match Rules To import or export a single custom match rule to or from an application To import or export a single custom match rule to or from a tier
Import and Export Exclude Rules To import or export a single exclude rule to or from an application To import or export a single exclude rule to or from a tier
Overwrite Parameter
AppDynamics lets you migrate transaction detection configurations for Node.js entry points from one application to another using a REST API. Use the API to copy transaction detection configurations rather than manually re-configuring multiple applications in the Controller.
Import and Export Auto-Detected Entry Point Configurations
You can import and export all your entry point configurations or one entry point configuration in a single request. Lists of multiple entry point names are not supported.
You can import to or export from the following application-level and tier-level configurations:
auto-detected entry point configurations custom match rules exclude rules
Here are some guidelines for exporting entry point configurations:
Use the HTTP GET method. Encode the URI using UTF-8 URL encoding. The base URI is the source application and, optionally, the source tier for your configuration export.
http://<controller host>:<controller port>/controller/transactiondetection/<application name>/<optional tier name>
The Controller exports the configurations to an XML file. If necessary, you can edit the XML file before you import it. For example, if you export the all the auto-detected entry points but don't want to import them all, delete the ones you do not want from the file before import.
Here are some guidelines for importing entry point configurations:
Export the auto-detected entry point configuration, custom match rule, or exclude rule from the Controller. Alternately, you can manually create the XML, but that option is more work for you. Use the HTTP POST method. Encode the URI using UTF-8 URL encoding. The base URI is the destination application and, optionally, the destination tier for your configuration import.
http://<controller host>:<controller port>/controller/transactiondetection/<application name>/<optional tier name>
Include the XML configuration as a file attachment to the request. Use UTF-8 URL encoding of the URI before posting. For example, use the plus symbol "+" to replace the space character in the URI. To overwrite an existing configuration with the same name see .Overwrite Parameter A successful import request returns HTTP status code 200.
To import or export the configurations for all the auto-detected entry-points to or from an application
http://<controller host>:<controller port>/controller/transactiondetection/<application name>/auto
exports all the auto-detected entry point types for all agents: ASP.NET, Java, PHP, NodeJS, etc.
For example:
produces the output in .auto_all.xml
To import or export the configuration for a single auto-detected entry point type to or from an application
http://<controller-host>:<controller-port>/controller/transactiondet ection/<application name>/auto/<entry point type name>
Entry point types names are case insensitive. The following entry point type name is valid:
nodeJsWeb
For example:
http://appdcontroller.example.com/controller/transactiondetection/Wi ne+Cellar/auto/nodeJsWeb
To import or export the configurations for all the auto-detected entry-points to or from a tier
http://<controller-host>:<controller-port>/controller/transactiondet ection/<application name>/<tier name>/auto
For example:
http://appdcontroller.example.com/controller/transactiondetection/Wi ne+Cellar/wineTier/auto/
To import or export the configuration for a single auto-detected entry point type to or from a tier
http://<controller host>:<controller port>/controller/transactiondetection/<application name>/<tier name>/auto/<entry point type name>
For example :
http://appdcontroller.example.com/controller/transactiondetection/Wi ne+Cellar/wineTier/auto/nodeJsWeb
Import and Export Custom Match Rules
To import or export a single custom match rule to or from an application
http://<controller host>:<controller port>/controller/transactiondetection/<application name>/custom/<entry point type name>/<custom rule name>
For example:
http://appdcontroller.example.com/controller/transactiondetection/Wi ne Cellar/custom/nodeJsWeb/Sample+Rule
To import or export a single custom match rule to or from a tier
http://<controller host>:<controller port>/controller/transactiondetection/<application name>/<tier name>/custom/<entry point type name>/<custom rule name>
For example:
http://appdcontroller.example.com/controller/transactiondetection/Wi ne+Cellar/wineTier/custom/nodeJsWeb/Sample+Rule
Import and Export Exclude Rules
To import or export a single exclude rule to or from an application
http://<controller host>:<controller port>/controller/transactiondetection/<application name>/exclude/<entry point type name>/<exclude rule name>
For example:
http://appdcontroller.example.com/controller/transactiondetection/Wi ne+Cellar/exclude/nodeJsWeb/My+Exclude+Rule
To import or export a single exclude rule to or from a tier
1. 2. 3.
For example:
http://appdcontroller.example.com/controller/transactiondetection/Wi ne+Cellar/wineTier/exclude/My+Exclude+Rule/My+Web+Service+Exclude+Ru le
Overwrite Parameter
Use the overwrite parameter to overwrite a configuration of the same name. Without this parameter, if the import encounters a configuration for a component of the same name, the request will fail.
For example, to import a configuration for a custom match rule named "My Rule" to an application that has an existing "My Rule" custom match rule that you want to overwrite use:
http://appdcontroller.example.com/controller/transactiondetection/Wi ne+Cellar/custom/nodeJsWeb/My+Rule?overwrite=true
The default is overwrite=false.
Configure Error Detection for Node.js
Accessing Error Detection Configuration for the Node.js Agent To Access Error Detection Configuration
Ignoring Exceptions To configure the Node.js Agent to ignore an exception
The Node.js Agent reports exceptions thrown by the Node.js application or by Node.js itself.
You can configure which exceptions the Node.js Agent reports.
Accessing Error Detection Configuration for the Node.js Agent
To Access Error Detection Configuration
From the left navigation pane select .Configure -> Instrumentation Click the Error Detection tab. Click the Node.js - Error Detection subtab.
3.
1.
You can use the asterisk ("*") as a wild card to match zero or more characters in the exception name.
Ignoring Exceptions
Exceptions in the Ignored Exceptions list are not reported and not counted. This feature especially is useful if the application throws exceptions for certain conditions that are not really errors.
"Ignored exceptions" are not really ignored. The agent still detects the exception, logs the exception, increments the exception count, and displays the exception in the Exceptions subtab of the Errors tab of the tier and node dashboards. But it does not increment the business transaction error count for errors caused by an ignored exception or report the transaction as an error transaction in the transaction snapshot. See for more information.Configure Error Detection
To configure the Node.js Agent to ignore an exception
Click under the Ignored Exceptions list.Add New Exceptions to Ignore
In the Exception field, enter the name of the exception to ignore,.
1.
2.
3. 4.
Optionally, further qualify the exceptions to ignore by configuring a match condition for the exception message. Enter the string to match and the qualifier from the dropdown list (Equals, Contains, Starts with, Ends with, Matches Reg Ex). . For example, the following configuration specifies that all exceptions for which the exception message contains the string "SQLRecoverableException" should not be reported or counted as an error.
Click the gear icon to configure the NOT condition for the match. Click .Save Click in the top left corner of the window.Save Error Configuration
You can later edit an ignored exception configuration by selecting it in the Ignored Exceptions list and clicking the button. You can remove it by clicking the Delete icon in the upper right cornerEdit of the list.

A node in the AppDynamics model is a single Node.js process instrumented by an AppDynamics Node.js Agent.
The node dashboard for Node.js is like the node dashboards for the other app agent except:
It includes a Process Snapshots tab for accessing the process snapshots for the node. It does not include a Memory tab for monitoring memory usage.
See for general information about node dashboards.Node Dashboard
The tier dashboard for Node.js is similar to the tier dashboards for the other app agents except that it includes a tab for accessing the process snapshots for the nodes contained by the tier.
See for general information about tier dashboards.Tier Dashboard
See for information about process snapshots.Monitor Node.js Processes
See also .Troubleshoot Slow Response Times for Node.js
Monitor Node.js Business Transactions
Distributed Business Transactions Learn More
See and for general information aboutMonitor Business Transactions Transaction Snapshots monitoring business transactions.
Node.JS Transaction Snapshots
This is a call drill down window for a transaction snapshot captured by the Node.js agent.
See forDiagnostic Data Captured by a Transaction Snapshot in the Call Drill Down Window information about the tabs that the Node.js agent transaction snapshots have in common with the transaction snapshots of other application agents.
Node.js transaction snapshots do not have call graphs. To view call graphs that reveal bottlenecks in your Node.js code, use .process snapshots
If a business transaction snapshot was taken at approximately the same time as a process snapshot, click the associated Process Snapshot GUID link in the transaction snapshot summary to view the call graph in the process snapshot. For more information about business transactions and process snapshots see .Process Snapshots and Business Transactions
The ADDITIONAL DATA tab displays the process snapshot GUID and process id of the process associated with the snapshot.
SERVICE ENDPOINTS are not currently supported for this agent.
EXIT CALLS in Transaction Snapshots
The EXIT CALLS tab traces exit calls from slow transactions made during the interval covered by the snapshot. In the list, click the exit call that you want to examine.
If the exit call you are viewing makes another exit call, click call toDrill Down into Downstream see a transaction snapshot of the call on the downstream tier.
Distributed Business Transactions
Distributed transaction tracing allows you to trace the performance of a business transaction across multiple tiers. It provides metrics for the time spent in all the tiers through which the business transaction passes and the ability to get call graphs displaying activity for all the tiers. See and Organizing Traffic as Business Transactions Measure Distributed Transaction
for general information.Performance
The tiers in a distributed transaction can be heterogeneous. All combinations of Node.js, Java, .NET, and PHP tiers are supported, whether they are an originating, continuing, or terminating tier in the transaction.
Watch this short video to see a distributed business transaction in action: <p> </p>
Direct link: https://appdynamo.wistia.com/medias/33m8tmpxb5
Monitor Business Transactions Transaction Snapshots Process Snapshots and Business Transactions
Monitor Node.js Processes
Set Up Process Snapshot Collection Process Snapshots List
To filter the process snapshots list More Actions Menu
Learn More
One reason for slow load times is inefficient code that uses a lot of CPU time. In a single-threaded model, such as Node.js, one slow process forces other processes to wait.
You can monitor Node.js processes using lists of process snapshots to identify which processes have high CPU times. From the list you can select and examine process snapshots of slow processes to identify exactly which functions in your code are blocking the CPU.
A process snapshot describes an instance of a CPU process on an instrumented node.js node. It generates a process-wide call graph for a CPU process over a configurable time range. Process snapshots are independent of any running business transactions. Process snapshots persist for 14 days, unless you archive them in which case they are available forever.
You can monitor process snapshots at the tier level or the node level.
Automatic Process Snapshot Generation
When a business transaction snapshot is triggered by periodic collection or by a diagnostic session, a ten-second process snapshot is automatically started. By default the agent starts no more than two process snapshots per minute automatically, but this behavior is configurable.
You can also start process snapshots manually on demand. See Set Up Process Snapshot below.Collection
It is common to have transaction snapshots with no corresponding process snapshots, if the period of the transaction snapshot and the period of the process snapshot do not overlap. To maximize the chances of corresponding snapshots, you can increase the maximum number of process snapshots taken in a period. The tradeoff is increased overhead. For more information see .Process Snapshots and Business Transactions
Configure Automatic Collection
You can configure automatic process snapshot collection using the following settings:
processSnapshotCountResetPeriodSeconds: Frequency, in seconds, at which the automatic process snapshot count is reset to 0, default is 60 maxProcessSnapshotsPerPeriod: Number of automatic process snapshots allowed in processSnapshotCountResetPeriodSeconds seconds, derfault is 2
1.
5.
6.
1.
2.
To configure these settings, add them to the require statement in your application source code as described in . Then stop and restart the application.Install the Node.js Agent
Set Up Process Snapshot Collection
Navigate to the dashboard for the tier or node for which you want to collect process snapshots. Click the Process Snapshots tab. Click . Collect Process Snapshots If you are in the tier dashboard, select the node for which you want to collect snapshots from the Node dropdown list. If you are in the node dashboard, you can only set up snapshot collection for that node.
Enter how many seconds you want to collect process snapshots for this node. The maximum is 60 seconds. Click .Start
The agent collects process snapshots for the configured duration.
Process Snapshots List
To access the process snapshots list:
Navigate to the dashboard for the tier or node for which you want to view process snapshots. Click the Process Snapshots tab.
For each process snapshot the list displays the time the process started, the process's execution time in milliseconds, and the tier and node in which the process executed.
Click the Exe Time column and then toggle the direction to sort the snapshots in descending order by execution time. The processes with the slowest CPU times will be at the top of the list. These are the snapshots you will want to examine.
To examine a process snapshot, double-click it in the list. See for detailsView Process Snapshots about what you see.
To filter the process snapshots list
You can filter the process snapshot list to display only the snapshots that you are interested in. You can filter by execution time, whether the snapshot is archived, and the GUID of the request. If you access the list from the tier dashboard, you can also filter by node.
More Actions Menu
Use the More Actions menu to select one or more process snapshots in the list and perform the following actions on them.
Archive Use this option to archive the selected process snapshots. Normally snapshots are purged after two weeks. You can archive a snapshot beyond the normal snapshot lifespan to retain it for future analysis. You can view archived snapshots by checking the Archived filter in the Filters panel. Delete items Use this option to remove the snapshot from the list. Copy a Link to this Snapshot to the clipboard Use this option to send a link to the snapshot to someone. Export Grid Data Use this option to export the snapshot data to a file.
Learn More
View Process Snapshots

A process snapshot describes an instance of a CPU process on an instrumented Node.js node
From the process snapshots list, double-click the process snapshot that you want to view. See Pro if you do not know how to access the list.cess Snapshots List
A process snapshot contain the following tabs:
SUMMARY: Displays the execution time of the process, timestamp of the snapshot, CPU time used, tier and node the process ran on, GUID of the request, etc.. You can click the link icon to copy a link of the snapshot URL.
CALL GRAPH: Shows the execution time of methods on the process's call stack. In the Time column you can identify which calls take the longest time to execute.
Click the at the end of the row to see more information about a call.
HOT SPOTS: Sorts calls by execution time, with the most expensive calls at the top. To see the invocation trace of a single call in the lower panel, select the call in the upper panel. Use the slider in the upper right corner to filter which calls to display as hot spots. For example, the following setting filters out all calls faster than 1.5 ms from the hot spots list.
BUSINESS TRANSACTIONS: Displays information about calls to the process captured in the snapshot per associated associated business transaction when the entire business transaction executes within the time covered by the process snapshot. See Process
for information about what you see in a call graphSnapshots and Business Transactions when part of a business transaction is captured in a process snapshot. The Calls column reports the number of instances of the business transaction that were
running during the time of the process snapshot. The Total Time is the sum of the execution time for all those business transaction instances.
See for information about what you see in aProcess Snapshots and Business Transactions call graph when part of a business transaction is captured in a process snapshot.
ADDITIONAL DATA : Displays the unique id of the process.
Learn More

Garbage Collection Memory
I/O Disk Network
The Node.js Agent provides metrics related to CPU usage, memory, and I/O for each Node.js process.
These per process metrics are available in the Metric Browser.
Process Metrics Defined
Memory Metrics
Garbage Collection
number of full garbage collection cycles the V8 JavaScript runtime has performedFull GC: in the selected time range
Incremental GC: number of incremental garbage collection cycles the V8 JavaScript runtime has performed in the selected time range
Memory
Heap size change: total amount of memory reclaimed by the full and incremental garbage collection cycles (as a percentage) in the selected time range
On this page:
Watch the video:
Current usage (V8 heap used in MB):total size of the heap at the current time point. This reports how much memory the node process is using for data storage.
Resident Set Size of the Node process. This reports the amount of memory (heap andRSS: stack) that is allocated for the process and in RAM, not swapped out.
I/O
Disk
KB Read: KB read from disk per second for the selected time range KB Written: KB written to disk per second for the selected time range
Network

Process Snapshots and Business Transaction Snapshots
This topic explains in detail the relationship between transaction snapshots and process snapshots created by the Node.js Agent. Its goal is to help you access and interpret call graph data associated with business transactions to troubleshoot application performance problems.
This page will be moved to the public documentation after the setting to increase the default length of a process snapshot is added to the agent. Meanwhile it is posted to help elucidate this topic.
V8 Sampler
Node.js is built on the V8 JavaScript engine, which includes a code sampler.
The Node.js Agent uses the V8 sampler to create , which contain call graphs ofprocess snapshots the methods on the Node.js process's call stack.
Business Transaction Snapshots Trigger Process Snapshots
Unlike other AppDynamics agents, which contain call graph data in the business transaction snapshot, the Node.js Agent provides call graph data only through the process snapshot.
To provide call graph data associated with business transaction snapshots, the agent starts a ten-second process snapshot whenever it starts a business transaction snapshot that is triggered by periodic collection or a diagnostic session, if there is no existing process snapshot in progress for the current process. Process snapshots do not overlap. Periodic collection means that a business transaction is collected at periodic intervals, by default every ten minutes, but configurable. Diagnostic session means that either the agent has detected a pattern of possible performance issues and automatically started capturing transaction snapshots or a human has manually started a diagnostic session for the same reason.
.
Concurrent Transaction and Process Snapshots
The result is that you will usually see a process snapshot that ran concurrently with a business transaction snapshot, which you can use for troubleshooting the business transaction. How well the two snapshots line up depends on the relative durations and start times of the transaction and the process snapshots.
In the scenario sketched below, all of the 5-second blue transaction's calls, and most of the 10-second green transaction's calls are captured by a 10-second process snapshot, but only the about half of the 14-second orange transaction snapshot's calls.

Monitor Node.js Backends
A backend is an entity in the AppDynamics model that the app agent does not instrument directly, but monitors traffic flows to it. The Node.js Agent monitors flows to database and cache exit points. See for the current list of supported backends.Supported Environments and Versions for Node.js
You cannot configure detection and naming for Node.js backends.
For general information about monitoring backends see:
Backend Monitoring Monitor Databases Monitor Remote Services
Troubleshoot Errors for Node.js Error Transactions and Exceptions
To Troubleshoot Error Transactions To Troubleshoot Exceptions
Identifying and troubleshooting errors in your application.
Error Transactions and Exceptions
The Node.js Agent reports an unhandled exception as a business transaction error if it occurred in the context of a business transaction. This includes exceptions occurring during an exit call that
prevent the transaction from working properly. If no business transaction context can be established, unhandled exceptions are reported as application errors.
If a business transaction experiences an error, it is counted as an error transaction and not as a slow, very slow or stalled transaction even if the transaction was also slow or stalled, unless the exception that caused the error was configured to be an "ignored exception".
Operations returning HTTP status codes between 400 and 505 are reported as errors.
There is not a one-to-one correspondence between the number of errors reported and the number of exceptions that occurred. For example, a business transaction may experience a single code 500 error in which several exceptions were logged as the transaction passed through multiple tiers.
You can limit the types of exceptions that the agent reports. See Configure Error Detection for .Node.js
To Troubleshoot Error Transactions
The error viewer opens.
2. Click the tab if it is not already selected.Error Transactions
3. From the time range drop-down menu select the time range for which you want to view information about error transactions.
A graph of the error transactions displays at the top of the viewer. You can get an exact count of the errors per minute at a particular point in time by hovering with your pointing device on the line in the graph.
To the right of the graph is a summary of the load and the error transactions.
Check the Plot check box if you want the graph at the top of the viewer to show the load as well as the errors over the selected time period. Clear this check box if you want the graph to show only the error transactions.
4. The error transaction snapshots are listed in the lower part of the viewer. To filter this list click S and select the filter criteria.how Filters
5. To examine the root cause of an error, select a snapshot from the list and click View . See for information about examining snapshots.Transaction Snapshot Transaction Snapshots
6. To identify the most expensive calls or queries:
Select one or more snapshots from the lists and click and then click Analyze Identify the .most expensive calls / SQL statements in a group of snapshots
The Most Expensive Methods / SQL Statements viewer opens.
In the upper panel you can click the links to the business transaction, tier and node dashboards for those expensive calls. In the lower panel, click the tabExpensive Methods to view the expensive methods with their total and average execution times and call counts. Click the tab to view the queries with their counts and execution times.Expensive SQL
To Troubleshoot Exceptions
2. Click the tab if it is not already selected.Exceptions
The total exception count, HTTP Error Codes and Error Page Redirects for the selected time range are reported in the upper panel. You can get an exact count of the exceptions per minute at a particular point in time by hovering with your pointing device on the line in the graphs.
The exceptions list is displayed in the lower panel.
To filter the exception list, enter the filter term in the filter text field. To see only exceptions with performance data, clear the Show Exceptions with 0 count checkbox.
3. To view details of a particular exception, select the exception the list in the lower panel and click .View Details
4. To view transaction snapshots for an exception:
a. In the exception detail window, click the subtab to viewOccurrences of this Exception information about the exception
b. In the exception detail window, click to see a stack trace ofStack Traces for this Exception the exception.
Resolve AppDynamics Issues for Node.js
Starting and Stopping an Instrumented Node.js Instance
Starting and Stopping an Instrumented Node.js Instance
Any scripts that you use to start and stop your instrumented Node.js instance should use SIGTERM if at all possible.
If you use SIGKILL (kill -9), the agent's proxy component will not be cleaned up and will leak.
First Time Using the Node.js Agent
All Applications Dashboard Application Dashboard
Time Range Flow Map and KPIs Events Transaction Scorecard Exceptions and Errors
Learn More
This topic assumes that an application is already instrumented and configured in AppDynamics and that you have already logged in to the AppDynamics Controller.
It is an overview of how AppDynamics displays actual and potential problems that users may experience while they are using your application - transactions that are slow, stalled or have errors. After you know where your problems are, you can easily identify their root causes.
All Applications Dashboard
When you log into the Controller you see the Home page.
Click to see the All Applications dashboard.View All Applications
The All Applications dashboard displays high-level performance information about one or more business applications. Load, response time, and errors are standard metrics that AppDynamics calls "key performance indicators" or "KPIs". Other dashboard information includes:
Health Rule Violations: AppDynamics lets you , which consists of a conditiondefine a health rule or a series of conditions based on metrics exceeding predefined thresholds or dynamic baselines. You can then use health rules in to automate optional remedial actions to take if thepolicies conditions trigger health rule violation events. AppDynamics also provides default health rules to help you get started.
Business Transaction Health: The health indicators are a visual summary of the extent to which a business transaction is experiencing critical and warning health rule violations. See Troubleshoot
.Slow Response Times
Server Health: Additional visual indicators track how well the server infrastructure is performing.
Application Dashboard
Click an application to monitor, one that has some traffic running through it. The Application dashboard gives you a view of how well the application is performing.
Time Range
From the time range drop-down in the upper-right corner select the time range over which to monitor - the last 15 minutes, the last couple of hours, the last couple of days or weeks. Try a few different time ranges and observe how the dashboard data changes.
Flow Map and KPIs
In the flow map, click any of the blue lines to see more detail on the aggregated key performance metrics (load, average response time and errors) between two servers. For example, clicking the data on the line from wineTier to the Redis backend displays the detail for that flow.
Events
An event represents a change in application state. The Events pane lists the important events occurring in the application environment.
See .Monitor Events
Transaction Scorecard
The Transaction Scorecard panel displays metrics about business transactions within the specified time range, covering the percentage of instances that are normal slow, very slow, stalled or have errors. Slow and very slow transactions have completed. Stalled transactions never completed or timed out. You can configure the thresholds that define the level of performance for the slow, very slow and stalled categories. See and .Scorecards Transaction Snapshots
Exceptions and Errors
An exception is a code-logged message outside the context of a business transaction.
An error is a departure from the expected behavior of a business transaction, which prevents the transaction from working properly.
See .Troubleshoot Errors
sFlow Map Configure Thresholds Monitor Events Troubleshoot Application Problems - Node.js
Upgrade the Node.js Agent
Uninstall the Node.js Agent
Configure AppDynamics for Node.js
Import and Export Transaction Detection Configuration for Node.js
Configure Error Detection for Node.js
Monitor Node.js Backends
First Time Using the Node.js Agent

apm overview - node

Documents