@khansen An addition to the above statement. You could try to verify my doubt by making one of your command handlers synchronous. Move all your code in the handle method into an async inner method and then call the async inner method with .GetAwaiter().GetResult() in the handle method to see how this changes the reported time.
@hross We managed to get in touch with all our customers that complained about this issue. Seems we have a working workaround, but we’d rather have a proper fix in NewRelic. How could we raise that with you?
It’s not really a new feature, rather an update to what you already have. We can share with you the solutions we have if needed.
Should I raise a support ticket with you? Or what else could I do?
Hi there @weronika.labaj -
Thanks for the continued updates. At this time, we’ve put in the request with the engineering team to support this in the .NET agent without workarounds. So they know, but I can’t promise that it’s coming, or that it’s coming in any specific time frame.
If you do have code that you think would be helpful for us to see and you can share it publicly, please feel free to post it here, and we’ll add it to the notes about this request. Otherwise, you can DM me and I can do the same thing.
@daniel.marbach I got in touch with NR support. Their first suggestion was to add a name attribute to the tracerFactory tags in https://github.com/danielmarbach/NewRelic.Providers.Wrapper.NServiceBusV6/blob/master/NewRelic.Providers.Wrapper.NServiceBusV6/NewRelic.Providers.Wrapper.NServiceBusV6.Instrumentation.xml as follows:
However, rather than alleviating the transaction time issue, this caused reporting to go blank again (no transactions recorded).
This is the latest reply from NR support:
It seems like the call is instrumented correctly when viewed as an external but not as part of a transaction. I am wondering if we are essentially tracking/recording it twice but with different wrappers/logic. It almost sounds like it is not getting included at all in the transaction.
Also, clicking on the Transactions tab doesn’t show any transactions. However when I click on a transaction from the Overview page I do see the transactions. Not sure if it is related but it the behavior is strange. This is similar to a known issue but it has been determined that they are different.
I’m guessing that the use of NewRelic.Providers.Wrapper.CustomInstrumentationAsync.DefaultWrapperAsync is subverting the generation of the transaction which the hacked wrapper is trying to generate.
Again, there isn’t much else we can so with this since we don’t own it but if you work with other engineers and figure it out, feel free to let us know the solution.
@khansen I’m not an expert in NewRelic. According to my understanding adding that tracer factory would basically unhook the custom wrapper that I wrote and replace it with the DefaultWrapperAsync which has no knowledge of the transaction and the specific segment you want to intercept. That’s why you see nothing.
I updated the sample https://github.com/danielmarbach/NewRelic.Providers.Wrapper.NServiceBusV6/commit/fa5a9b502640e2d89d79ddabcc8204ed29045459 I tested it and I see data but I don’t think it is accurate enough yet. I will try to reach out to support of NewRelic and see if I can get someone on the phone.
@daniel.marbach, I looked into using your solution. This requires several New Relic dll’s, amongst which ‘NewRelic.SystemExtensions.dll’. This file, however, is not present in my New Relic agent folder.
I tried to contact NewRelic several times over the last few weeks. Linds promised me to come back on this but it seems the ball has been dropped. So now news yet.
About the assemblies that you need should be under
I have to stress again here that I don’t recommend this because I have no idea whether this is a violation of licenses or not. I’m also not working for NewRelic. I came up with this “hack” to get customers unstucked. Use it at your own risk. Hopefully, at one point NewRelic will get active on this issue and get all the people in this thread unstucked.
Another incredibly frustrated New Relic and NServiceBus customer here. We’ve migrated half of our MicroServices to NSB6 and paused the migration because we are now blind in New Relic. I am strongly encouraging New Relic engineering to take the Olive Branch from Particular Engineering (offered earlier in this thread). Let’s get this fixed ASAP.
We implemented a number of microservices based on NServiceBus Version 6 and I would also really like to see full-featured New Relic support for this version (and, hopefully, for the upcoming Version 7 as well).
Throwing my hat in the ring here too. This issue is 100% holding us up from upgrading to NServiceBus 6 which, among other things, would allows us to properly leverage async/await. Please, at the very least, an update from New Relic would be appreciated.
The value we get from NewRelic has gone down considerably as we’ve transitioned our microservices to the latest NServiceBus release, we now have very little insight into the services that have made the jump. NServiceBus 7 is coming down the pike as well and we’re very concerned that we’re not going to be able to recreate the level of monitoring we once had again. I’m not sure if there are technical challenges that are preventing NewRelic from supporting this class of enterprise software, but some communication is warranted from the NR team so we understand what our options will be moving forward. This is a very serious concern for us going forward, so we hope NR will begin to communicate again about this feature very soon.
I’m Daniel from Particular. I tried to reach out again to Linds and offered our help. Fingers crossed that we might get an answer this time. I’ll keep you posted.
In the meantime feel free to join https://discuss.particular.net/ if you want to discuss further details.
@daniel.marbach - thanks for offering to help. I’m a new Product Manager at New Relic and so I’m always happy to hear about the needs of our customers. Right now the focus of the .NET agent team here is majorly on .NET core 2.0 but we do recognize the value that NServiceBus provides and so, we will be prioritizing this in the roadmap for the .NET agent and will reach out to you to see how we can leverage what you have built.
We created a sample that shows how to integrate the new NServiceBus.Metrics package with NewRelic. You can find it over here https://docs.particular.net/samples/logging/new-relic/
It uses custom metrics so it might not behave exactly as the previous v5 plugin but at least it should give you good data indicating what is going on in your system. I suggest to use the Metrics v2 version with v6 since this one supports retries and also puts the message type name into the generated metric.
A sample dashboard with Insights
I hope this gets everyone in this thread unstuck.
Thanks so much for sharing @daniel.marbach. We love it when you share with your fellow friends!
Any Update? We’re also interested in full support for NSB6 in NewRelic and have lost a lot of New Relic value after our upgrade.
Sorry to hear that, @gblakely!
Be sure to add your vote in the poll above and I will pass your request on to our Product Managers.
I’d like to suggest New Relic add an ability to track APMs directly from a library call within the app. NServiceBus offers middleware support (as shown by Daniel above) which would make it easy to integrate the same stats that the Agent is automatically instrumenting in MVC applications - start transaction, end transaction, failed transaction. This would avoid the need to have users requesting updates to the New Relic Agent for every application framework out there. We’re currently making the transition to NServiceBus 7 and its sad to see this still hasn’t been resolved.
Hey @scott.wilson - I can get your +1 added here. But to your point on adding an ability to track metrics through a library call… If your app language/framework supports C as a foreign function interface, our new C-SDK might be helpful for you. See info on that here: