Raygun sponsored this demonstration.
Sometimes solutions to very complex problems require very clear answers. In the case of developers working with applications running on Kubernetes, microservices or numerous, complexity is certainly an issue. Monitoring these, needless to see, is challenging at best.
For this, Raygun has a relatively straightforward solution. Having always built its tools around its own developers’ trials and tribulations, Raygun has introduced this month its application performance monitoring (APM) support for .NET Core, as well as for support for multithreaded tracing.
This follows how Raygun has traditionally sought to solve the monitoring conundrum by providing the support that — as Jeremy Norman, CTO for Raygun, aptly describes — offers “the ability to see the entire picture.”
In this demo hosted by Alex Williams, founder and editor in chief of The New Stack, Norman shows on-screen examples of how Raygun’s APM support for.NET Core works. This included also demonstrating how capturing traces with the APM also involves multithreaded trace support.
Indeed, Norman described how Raygun’s latest addition to its APM capabilities “ties back to our existing customers.”
“This isn’t just a .NET Core feature — it’s going to benefit everyone that’s currently using Raygun’s APM and .Net full framework,” Norman said. “This is because people have been developing with multithreading in mind for many years. So now, we’re going to pick up those scenarios and you have a much better experience.”
This means Raygun has sought to offer more generic support for multithreading trace scenarios in general. “So, all of our existing customers that may be using .NET full framework support right now are also going to benefit from this,” Norman said.
Part of the concept for APM support for .NET Core is to help developers better monitor threads that are executed asynchronously. “There are many threads being managed by the framework,” Norman said.
“You need to adequately capture that and profile that and see what your requests look like, so you need to be able to support that capture of multiple threads and asynchronous work in executed,” Norman said.
Norman began the demo by showing a multithreaded trace where multiple products are in use in order to capture a trace that has generated an error. “So, in this code, you can see, and now that we have more than just a single, single thread being captured, we’ve got multiple threads, and how we’ve done this as sort of mocked, where those threads are being executed from in your code execution,” Norman said. “What I can do is click on us, and we can actually see through our GitHub integration with code on the code that’s actually being executed here from our source repository. And you can see here, I’ve got a fairly simple use case of using a task to run a piece of code that’s going to execute asynchronously.”
Norman also showed the solution to a common issue during the demo involving how a lot of applications that are developing microservices have “primary requests may be calling off to other microservices.”
“Maybe you might make too many microservice calls that could be optimized by maybe a bulk method or bench method or potentially splitting some of those calls off into your other tasks that could be done in parallel,” Norman said. “So, we’ve got this concept where you’re making a lot of calls to APIs that may be introducing performance bottleneck or a slowdown in your application and offer opportunities for you to improve.
As mentioned above, in general, Raygun has always built its tools around issues its own developers have faced. Norman said, as a developer, he has needed tools to “provide me with the answers that I needed.”
“In the past, when I knew there was an issue in my code, but I didn’t know where the issue was, and I was really then left to explore to try and find those issues, we came at it in a different way,” Norman said. “And we really wanted to provide people with actions — that was what was valuable to us as we could plug in this tool, and immediately, it began to identify things we could fix. So, we’ve had huge success by using our own products, by just plugging in our APM as soon as we started developing it and using it on our own code base.”