All of our signalr transactions are recorded as /302. There are no trace details about the individual calls. Is there anyway to get this data from new relic’s monitoring?
@marc.downer Welcome to the community! Sorry you’ve been waiting awhile for a response from our community. I’m going to reach out to our support team to get an answer soon.
Hey @marc.downer, do you have a link to an example of this I can look into?
In doing a little research I did find this doc regarding SignalR and 302 errors, in case it helps:
“301 Moved Permanently” or “302 Moved Temporarily” error
This error may be seen if the project contains a folder called SignalR, which will interfere with the automatically-created proxy. To avoid this error, do not use a folder called
SignalR in your application, or turn automatic proxy generation off. See The Generated Proxy and what it does for you for more details.
In our monitoring dashboard, when I go to APM and select any of our signalR applications the only transactions listed is “/302” - . Here is a screenshot. There are no other transactions recorded. So I’m trying to understand why we cannot get any monitoring data from our signalR application other than these /302 transactions. When I use our web applications I don’t see “/302” urls or http statuses.
Hi @marc.downer thanks for that screenshot! Based on the thoughput of that
/302 Transaction would you say that your other Transactions are getting mislabeled as
/302 or that they’re being missed entirely?
I ask because, if they’re being missed entirely, you may just need to use some Custom Instrumentation for the .NET Agent so that the Agent knows how to trace the proper Transactions. My guess is that this is the case since, taking a look at our Compatibility docs here, I don’t think we have any out-of-the-box instrumentation directly for SignalR.
It’s possible that the Agent is ready to capture activity within these Transactions, such as external calls, but the big factor is that it first needs a Transaction object to store that data within; Which is where the .NET custom instrumentation would be most useful(although it can do plenty more). But let us know you think as far as whether it’s missing data or not!
I’d say the transactions are being entirely missed.
I’ll look into the custom instrumentation. It may be necessary to add attributes to all of the hub actions.
How would that compare to using the node.js custom instrumentation? This document outlines that https://docs.newrelic.com/docs/agents/nodejs-agent/supported-features/nodejs-custom-instrumentation It states “Create web transactions (useful for things like web sockets, where transactions can’t be automatically created).” Would it be able to link client usage to .NET code execution/transactions like is done for the other, traditional web applications?
Can you provide a New Relic link to the app. Only Support will be able to look at that. We might be able to tease out more info - not 100% sure.
I’d recommend setting the agent log level in newrelic.config to “debug” or maybe “finest” (which can be very busy) and looking at the “agent” log for any interesting messages including errors which might show it’s not recognizing transactions.
Yes, is there any particular way to provide a link, or just copy the NewRelic dashboard URL into a forum post?
Here’s the link for the last seven days. You can see the transactions are all /302.
This query shows the endpoints that are being called that result in the 302s. See the request.uri column in the result set. Does that shed any light?
The requests didn’t hit any controllers or handlers the agent instruments therefore when the agent saw the 302 response code it renamed the transaction from a request uri name to the 302 name. If the request had hit, say, an MVC controller, the agent would have given the transaction a controller based name regardless of the status code.
It might also be useful to look at agent debug logs to see if any other transactions are being missed. Look at the procedure here for gathering debug logs: https://docs.newrelic.com/docs/agents/net-agent/troubleshooting/generate-logs-troubleshooting-net. I think you want to look for messages about the agent disabling or shutting down instrumentation “wrappers” or anything else that looks suspicious.
I’ll dig into this more when I have time, but that is helpful.