I’m getting a very high volume of errors who’s reported transaction name is “400”. When I inspect further it’s coming from a wide variety of request URIs. What would cause this? A permalink can be found here https://onenr.io/0e1wZ4bZKj6
Thank you for providing the permalink, after taking a look it appears to be an expected behavior by the agent.
Have you noticed this change recently? or has it always been this way?
Essentially, the agent has a feature where it will group “unrecognized” transactions with status code errors into a transaction named after the status code in order to prevent metric grouping issues.
This looks like what is happening here.
@hzurek Interesting. This is the first I am running New Relic in production so I don’t have anything to compare by. What would cause unrecognized transactions? Is there any documentation on this? The link you provided doesn’t seem to go anywhere.
Hi @adenton ,
Thank you for your patience. Here is the correct documentation on Metric grouping issues (APM, browser, mobile). This explains why the transactions occur and ways to work around it.
Please let me know if this helps!
Thanks for linking that documentation. I read through it but it doesn’t make the root cause clear to me. The examples cited in those docs are situations like
docs/logging being grouped under the
In my case a random assortment of requests seem to be grouped by the response code. Even stranger, some requests from the same endpoint are getting grouped properly while others are being grouped under the response code.
The only thing I can think to try is setting the transaction name as per this documentation SetTransactionName (.NET agent API) | New Relic Documentation. However, even if this works this seems like more of a hack than fixing the root cause.
Thanks for you help
@tpaul1 I was finally able to test
SetTransactionName and it did not help the problem. I don’t believe the documentation provided fits this case.
This documentation makes it sound like every 400 request is intentionally grouped under a single transaction called “400”.
Requests that result in status code errors, i.e. response status code ≥ 400. This is typically due to page-not-found errors (404) often as a result of penetration tests. Agent upgrade. This is primarily an issue for older agents. Agents 6.20+ categorize these transactions as “StatusCode” and name them after the status code, e.g. “WebTransaction/StatusCode/404”
That seems like really bizarre behavior. Why would I want to disassociate the error from a legitimate transaction? I’m sure I’m misunderstanding something. However, testing locally seems to confirm this issue.
After lots of trial and error I worked out that these requests were being blocked by middleware so they effectively weren’t making it into a transaction. I started manually setting the transaction name in the middleware for those use cases. That solves the mystery. Curious if there’s a better way?