Regardless of what language and framework you use, proper logging is crucial to web development. Logging is key when it comes to debugging and performance monitoring. Knowing how to properly use logging frameworks is an essential part of creating high quality software that is easy to debug.
Microsoft’s Application Insights provides a basic application performance monitoring solution for .NET applications. For some types of .NET projects, Visual Studio will automatically add it to your solution. In this article, we are going to cover how to disable Application Insights.
One of the major developments in software design and delivery over the last few years has been a movement away from monolith applications towards microservices. One of the sticking points I’ve seen on numerous microservice applications is logging. There are some unique challenges with microservice logging that need to be addressed. In this article, we’ll look at how we can make logging in a microservice as painless as in a monolith.
Logging is an important topic in software development, especially if you need to analyze bugs and other unexpected events in your production environment. Implementing your logging often seems easy. But as you probably experienced yourself, logging is far more complex than it might seem. That’s why you can find lots of articles about it here on the blog.
One of the most important aspects of developing an efficient system is to have clean, helpful logs that will help you understand what errors are being triggered, and what information is being processed. When you are first creating an application, you might not know what logging framework will be most suitable for your future needs, or you could simply want your system to remain agnostic regarding the logging implementation to be used.
Let’s begin with a little thought experiment. Imagine you’re responsible for the next release of your company’s flagship product, and today is the big day: you’re about to give a demo presentation for all the big shots in the company. The CTO is obviously there, since she’s your boss. The CEO is there as well, along with the VP of Marketing and some of the company’s investors. So, that’s your boss, your boss’s boss, and the moneymakers.
Whether you’re the consumer or producer of an API, you’ve no doubt seen that good error handling can make debugging easier. And you may have noticed that error handling works best when everyone speaks the same language and has the same expectations. But what makes for good error handling? And how can we implement it and ensure consistency across our application?
Picture this: you’re standing in the largest meeting room in your company. Behind you, a huge LED monitor. In front of you, all members of the C-suite. The CTO, your direct boss, is visibly nervous. The CEO looks interested and somewhat excited. The CFO looks happier than usual, though it probably has more to do with his very successful golf round the day before and nothing to do with the presentation you’re about to give.
I use performance monitoring tools primarily to find slow and buggy code. At the start of development, I typically use the tools more for finding software bugs. Once the codebase is at a relatively stable phase, then I shift my focus toward finding less performant code. Which is why I turn to tools like Retrace to help with profiling for better performance.
