In this article I’m going to go over two cases why your Node application’s transaction names may look a little funky in APM and how you can get yourself on the road to being fresh.
You should take action because:
- creating too many unique transaction names makes it impossible for our limited human brains to interpret the results of the data.
- The UI starts to load slowly because of all the data being loaded
- New Relic will eventually enact a metric clamp if there are too many metrics which will prevent new metrics from being created until the issue is resolved.
Scenarios this might occur:
- The Node Agent uses NormalizedUri naming because it is not correctly instrumenting your code for some reason (with common reasons why explored below).
- You are using custom transaction naming via
setTransactionName()from our Node API in a way that is sub-optimal.
The case of NormalizedUri naming for transactions:
First - How can I tell if my transactions are being picked up by NormalizedUri naming?
- In APM on the Transaction page, hovering over a singular transaction will bring up a tool tip that has information including if the transaction is named by your supported framework, Custom instrumentation, or via the catch-all NormalizedUri naming.
- Also in APM, go to Show All Transactions Transactions -you’re going to see an overabundance of transaction names here when you expand the time window to a sizeable amount of time. There’s going to be more transactions than you can ever draw meaningful conclusions from and many of them may just have a single occurrence in the Count column.
- The names are very close to other transaction names. Common problems include having GUIDs in the name, IDs, or numerous web articles, such as:
What is NormalizedUri naming and why does it happen?
One of our Node Agent developers, wrote this excellent article on how transactions get named in New Relic:
An excerpt pertinent to this discussion is here:
There are some edge cases where no middleware will send a response but the result is not a 404. Like with 404s Get Special Names, this means the Name Stack is empty when the transaction is named, however the status code will be something other than 404. This usually is a sign of an uninstrumented feature of either the web framework or some other module. When this happens, we pass the requested URI through transaction and metric naming rules and create a NormalizedUri transaction.
Our agent is not able to instrument frameworks that are not currently supported[https://docs.newrelic.com/docs/agents/nodejs-agent/getting-started/compatibility-requirements-nodejs-agent#supported-frameworks]. This includes frameworks that are written with supported frameworks (e.g., Sails with Express).
Using an older Node Agent version but using a supported framework:
We always recommend to be on the latest and greatest version of Node Agent, but we made a lot of progress and improvements with agent instrumentation after version 2.0.0 and continued improvements after that. So please make sure to update and mind the migration guide for major version upgrades and also the requirements for newer versions.
You see a banner for Uninstrumented Modules with your app on a supported framework on an up-to-date agent version
If you’re using a supported framework, you’re up-to-date on the latest Node agent, and you’re seeing a banner on the main Overview page, I would want to consider this being a possibility to why transactions aren’t named correctly - especially if the uninstrumented module(s) includes a framework.
For more tips on revolving this - please see this article:
Using a Supported Framework and on the latest agent version:
Review Natalie’s article here and make sure you’re not falling into a scenario where the agent would default to this behavior.
You may want to let us know more the routing of those transactions. Additionally, you can use the Node agent configuration settings to adjust how these transactions get named.
setTransactionName() function can be called within the context of an HTTP request handler between when the request has started and finished and allows you to name the transaction how you would like it to appear.
If adding code isn’t possible for your application, you can use regular expressions by using naming rules in your
newrelic.js configuration file:
If the above scenarios don’t seem applicable or aren’t working for you, reach out to us so we can dig in.
The case of too many Custom transactions:
Oops! Thinking you may have misused our Node Agent API
setTransactionName() to name transactions?
How can I tell if I’m misusing Custom Transaction naming?
Similar to the NormalizedUri symptoms - you will see an overabundance of transaction names in the Show All Transactions page when you look at a substantial time period. These often include parameters that change frequently or URIs.
How to fix Custom Transaction Naming issues:
Important general guidelines for using custom transaction naming is that you do NOT name based on changing parameters like session ID, user ID, article name or even actual URL on a busy blog (instead consider calling all article displays "show_article"), etc.
I would suggest modifying how you are using
newrelic.setTransactionName(name) via the Node.js API:
Of course, there is also the Node API for collecting custom attributes. This has the effect of reducing the number of transactions, but adding the custom attributes to the transaction traces and also being queryable in Insights.
So if you are saying “I think I really need the detail I get in these Transaction Names” you still might want to consider collecting it as an attribute instead. You can do this by removing these detailed attributes from the API call
setTransactionName() and instead adding them by using the API call addCustomAttributes().
Hope this helps~! Post your questions!