Error monitoring is vital to the success of any application. Console logs only get you so far. Once your app is out in the wild, asking your customers to open up the developer tools window and inspect it for errors is a deal-breaker. This is where error monitoring services come in. Let's take a look at three different services:
Log Rocket was founded in 2015 and is an error monitoring service that focuses on replaying the events that led up to the error. While some services focus on digging into the error details themselves, Log Rocket uses HTML from the user's session to reconstruct a playback of what the user experienced.
What LogRocket does is we capture a recording in real time of all the user activity so the developer on the other end can replay exactly what went wrong and troubleshoot issues faster.
Log Rocket is a venture-backed company that has raised $30 million in its history. It provides its tools exclusively as a for-profit, hosted solution. They do offer self-hosted options, but only as part of their enterprise, custom pricing.
Their focus is on user experience through the tracking of everything a user does on the site. While this is helpful, it is also a bit invasive in the fact that the default installation of Log Rocket captures just about everything a user does in the application.
Sentry was founded in 2012 and is focused on capturing errors at the code-level and sending them to a repository for review and organization. Sentry allows you to configure the groupings of errors and presents them in an interface designed to surface the most-pressing errors first.
In addition to surfacing errors, Sentry allows users to create custom alerts. For example, should a specific event occur, you can set up a trigger to send an email to your team. This is generally used for errors, but it could be used for just about any event sent through to Sentry.
Sentry, like Log Rocket, is also a venture-backed company. They have raised over $66 million in their history. Unlike Log Rocket, Sentry provides an open-source and self-hosted solution for free. For users that do not want to pay for Sentry's hosted option, they can utilize Docker to run a self-hosted, containerized version of the Sentry platform.
One big differentiator for Sentry is its focus on providing services for a wide array of platforms.
Sentry differentiates from legacy application performance monitoring solutions by focusing on software that runs on devices its developers have no control over, including mobile and IoT devices and smart sensor networks.
Exceptionless has been around the longest of the three services reviewed here. Created as a software offering from the parent company CodeSmith Tools, Exceptionless was established in 2010 and is privately held. It is positioned as a tool to help first and a product second. This is why one of Exceptionless's main focuses is the open-source community.
Exceptionless lets developers capture logs, events, and errors. However, Exceptionless's real differentiator is its real-time delivery mechanisms. Rather than costly code deployments to change your error monitoring configurations, Exceptionless allows you to make changes from their user interface and those changes will apply instantly in your application. This is key when it becomes clear that additional errors need to be surfaced quickly.
From the user experience and customer experience front, Exceptionless works hard to stand out from the competition. In Exceptionless 7.0, customers are now able to mark stacks of errors and logs as "discarded", the events will no longer count against plan quotas. Combine that with their chat, email, and Discord support, and Exceptionless proves its focus on customers.
Digging into the product features, Exceptionless provides one of the cleanest views for understanding events and errors in your application.
All the information you need about errors and events are captured in a simple, easy to read view. From your dashboard, you can consolidate events into stacks to help group relevant issues. You can also indicate the resolution of events based not just on the fact that the issue was resolve but based on the version of your software that fixed the event. Exceptionless will automatically recognize any new errors that come in with an older version and group them in the resolved bucket. However, should the error surface on the version of your software in which you marked the issue fixed, Exceptionless will classify this event as a regression without you having to manually do so.
The answer to this often comes down to what's most important for your application. Each service has its merits, but the value provided differs based on use-cases. Log Rocket offers full session replays, but may not be the right solution for digging deep into stack traces. Sentry offers full stack trace reviews and error categorization, but it may not be the right solution if you need the ability to update your error handling configuration in real-time. Exceptionless provides real-time error monitoring and configuration, and it is committed to the open-source community.
Imagine this scenario. You're debugging your application. You KNOW there is a problem, but your logs aren't showing you anything helpful. You've bounced your head off your desk at least 34 times. Then it hits you!
You've configured your error monitoring service to only capture FATAL errors, but this error is surely some other level. Your log level settings need to be updated.
The good news is you've figured out what the problem is (at least what the problem is that's keeping you from debugging the real problem). The bad news is you now have to update your applications code to ensure the right log levels are being passed through to your error monitoring service. You have to save your code, re-deploy, then start re-testing.
That's a pretty terrible experience, but fortunately, it's one that Exceptionless has solved for you.
You can customize the log levels Exceptionless will track for you. ON. THE. FLY. You don't have to touch your code. Instead, should you run into the problem above, you can change your default log level and it will be applied immediately. Any new events coming through that match the level you set will now be stacked up and tracked for you.
We recognize that every application is different. Every developer is different. Being able to easily customize the data captured through Exceptionless is an important part of our mission. This is why in v7.0.5, we have updated the user interface to support default log level selections.
As you can see in the image above, the current example default is "Warn." You can override that default on the Stacks page any time you'd like. But if you want to customize that default log level from the start and have it apply across the board, you can do so on your settings page.
Logging is key to understanding problems in your application, but it can also act as a historical record useful for post-mortems and general analysis. However, not all logs are important or necessary. And even if they are, you may want to filter them out in certain scenarios.
Enter log levels.
Log levels control what types of messages are logged. The general definition of log levels, and what we use at Exceptionless is:
By setting your log levels, you are essentially saying you'd like to see information grouped into the buckets defined by the log level. For example, if you'd only like to log the most severe issues, you might select a log level of FATAL.
We want to help you with this flow by automatically accepting or ignoring errors and messages that don't match the log levels you've defined in Exceptionless. We think this will help you better manage your exceptions, reporting, and overall development flow. We can't wait to hear your feedback. If there's any questions, suggestions, or general feedback, we'd love to hear from you. You can reply here or open an issue on Github.
Feedback and community support is the key to growing a successful open-source company, and you all have provided us some of the best feedback possible. With your feedback, we just released one of our biggest improvements yet. This release includes changes on both the application interface and the core functionality. We wanted to highlight some of the main improvements and why we did it.
This improvement is more than just visual. We heard the feedback from you loud and clear. There are stacks you don't want to track, but filtering them out on your end is difficult. For that reason, we are introducing the "Discarded" status. If you mark a stack with this status, it will not be tracked in your dashboards and, more importantly, it won't count against your plan limits 🎉.
As part of this improvement, we also consolidated statuses. Operations that were duplicative or didn't make sense were removed or combined.
The beauty of open-source solutions is that you are often given the option to self-host or pay for an easy hosted solution by the company or people who created the project. This is true of many projects. Ghost is a popular example of this from the blogging world. Some analytics serves, including Matomo, allow users to choose between a hosted and a self-hosted solution. In that same vein, Exceptionless provides a self-hosted option for those who would like to host their own error monitoring.
Today, we're going to walk through setting up a self-hosted Exceptionless instance. Let's get started!
Exceptionless provides a simple Docker image to help get started with self-hosting. We're going to make use of that, so the first step is to download Docker for desktop if you don't already have it. Once you're able to download that and start it, you should then be able to execute docker commands from the command line. Test it out by running docker stats in the command line.
Pretty cool, right? Just by downloading and running the desktop application, you also have access to the Docker CLI. That CLI is what we'll need to run our self-hosted instance of Docker.
Let's make sure we can get Exceptionless running locally. Ready for how easy this is? Are you?
Ok, start up Docker Desktop, then in your command line, run:
docker run --rm -it -p 5000:80 exceptionless/exceptionless:latest
This will check to see if you've already downloaded the latest Exceptionless release, and if not, it will install all of the necessary dependencies. This is important because Exceptionless is split into a client-side front-end and a server-side back-end. Docker lets all of this be combined.
When the process in your command line finishes up, open your browser and navigate to http://localhost:5000. If all went well, you should see the Exceptionless login page.
Go ahead and sign up for an account. Keep in mind, this is not a good production solution, but it's a great way to get started with a self-hosted error monitoring solution.
Along with the front-end that we're looking at now, you also have a full Exceptionless server running. To prove it, let's run a simple cURL command.
Make sure to use the email and password you just signed up with. You should get a token back. This shows you that the API is running successfully and you can now do everything you would with a hosted Exceptionless instance, but locally. Go ahead and try it out. Here are the full API docs for Exceptionless.
The problem here is the data you save in this run of your self-hosted Exceptionless instance will not be saved between runs. As soon as you shut down Docker and exit the application, your data will be deleted and you'll be starting from scratch. That's no fun. Let's fix it.
Go ahead and shut down Exceptionless either by exiting in the command line or by going into your Docker Desktop Dashboard and clicking the stop button your Exceptionless instance. Once it's stopped, open up your command line again and run:
Now, when you sign up at http://localhost:5000, your data will be persisted. You can start tracking errors locally and that data will be shown in your Exceptionless dashboard even after you shut down Docker/Exceptionless and restart it.
Your homework: Try running this locally with SSL and SMTP enabled. It's just as simple as everything else we've done so far because Exceptionless has really taken the time to make sure the developer experience is top-notch. Check out the instructions here.
Error monitoring is incredibly important to both your customer's experience and your own sanity. To give yourself true control over error monitoring, you can choose a solution like Exceptionless, and as you've seen here, self-host it pretty easily. Of course, if you'd rather let Exceptionless take care of hosting, that's covered too.
Now, you can go and experiment with your newly installed, self-hosted, error monitoring service. Will you let it run on your machine? Will you tinker and get it production-ready? Will you deploy it to a remote server somewhere? (That last one might be the subject of a future post 😉)
For anyone who has built an application, you've probably built it on some library or framework that changes over time. To keep up, you have to upgrade your application. However, there are varying schools of thought around when you should upgrade. At Exceptionless, we like to be on the bleeding edge. As an open-source company, we feel a responsibility to the community to know and understand the open-source tools we use. As such, we have already upgraded Exceptionless to use .NET 5.0.
To give you a little background, .NET 5.0 was introduced in May of 2019. The announcement was a big one as Microsoft chose to drop the .NET Core distinction. Going forward, we will just see cross-platform support in the form of ".NET X.X". The first release candidate for .NET 5.0 was announced September 13, 2020. We chose to upgrade and begin using .NET 5.0 immediately. That decision was driven by Microsoft's commitment to supporting production usage of the rc1 release. And as it turned out, the upgrade process was not too painful at all.
All in, the upgrade took about one hour and was a very small commit. You can actually see the commit here. This is really a testament to the foundation we've built here combined with the long-running foundation Microsoft has built with the .NET framework. Exceptionless is no small application and yet we were able to upgrade to an early release candidate in order to capitalize on new capabilities. To highlight the scale of Exceptionless and the relatively minor impact the upgrade process had, let's take a look at some of our numbers.
1.4 TB Elasticsearch Cluster
173M Elasticsearch Documents
384M Redis Operations/Day
122M HTTP Requests/Day
2,476 GitHub Stars
568 GitHub Forks
There are always multiple schools of thought around running pre-release code on production applications, but for us, the decision was a no-brainer. The top motivators were performance improvements, availability of new C# features, and Docker improvements for our self-hosted solution.
We are a developer tool, and as such, performance is important. .NET 5.0 allows us to leverage the performance boosts associated with the upgrade and pass that along to our customers and the community around us. We compared our memory and performance from .NET Core 3.1 to the .NET 5.0 rc-1 release and saw enough gains to help support our decision to move forward with rolling this out to production.
The .NET team's focus on pushing the boundaries of garbage collection was an important factor for us. GC is such a critical component to performance, and it impacts almost everything within the framework. We were excited to see the focus Microsoft put on continuing to improve performance in this area and felt the gains were enough to really tilt us towards our production release of Exceptionless using .NET 5.0.
As a quick, visual example, of other improvements, here's a table Ben Adams tweeted that gives us glimpse into the performance gains of .NET 5.0 over .NET 3.1
With the release of C# 9, we, once again, get significant improvements. Anytime a programming language releases new features, it's important to ask yourself whether those features are necessary for your application. In the case of C# 9, there are multiple features we believe will help improve the code legibility, overall codebase size, and ultimately performance. It always comes back to performance!
Pattern matching in C# 9 is a feature we are particularly excited about. If you're interested in a deep dive into the improvements here, Anthony Giretti has a great post highlighting the new functionality. For Exceptionless, pattern matching represents a better way for us to execute logical operations we already support. In doing so, we can reduce code complexity, improve performance, and deliver a better experience.
Records are an exciting new feature in C# 9 as well. Data immutability is important, once again, for—you guessed it—performance. The way Dave Brock puts it on his blog is apt:
Immutable types reduce risk, are safer, and help to prevent a lot of nasty bugs that occur when you update your object.
Data records give us immutability in the form of a dedicated struct. Rather than extending the functionality of C#'s existing structs, records give us the ability to reach for a data-specific type that offers built-in immutability.
We are proud of our open-source roots. We want to make self-hosting Exceptionless as easy as possible, and Docker has made this a reality. Our Docker image is the fastest and easiest way to get started with self-hosting and .NET 5.0 only improves the Docker experience.
.NET 5.0 enables better resource compaction which, in turn, reduces the cost associated with Docker images. This is important to the bottom line, but .NET 5.0's improvements go beyond dollar-savings with Docker. The new features also improve memory constraints which—say it with me now—improve performance.
One additional benefit of the .NET 5.0 rc-1 release candidate is how our Docker image now works better with Kubernetes resource constraints. We're pretty big fans of Docker and Kubernetes, so anything to improve the experience around both is a win in our eyes.
In development, we tend to think of errors as things that are thrown when our code does not execute properly. Errors can be caught and handled or they can be missed and result in uncaught exceptions. But how do we classify errors that are not directly caused by the code we write? How do we identify and address errors that are caused by the design decisions we made (or didn't make)?
You may already be using an error monitoring service, and if you are, you could continue using that and reach for yet another tool to help you with your user experience woes. Or, rather than adding another product to your endless list of tools that keep your application running, you can use the error monitoring service to both monitor for traditional errors and user experience problems.
Let's take a look at how we can do this. There are plenty of logging services out there, and most of them do the same thing. However, we're going to take a look at Exceptionless. Exceptionless is an especially attractive choice for three reasons:
The API allows us to do exactly what I'm proposing in this article.
While self-hosting may be an attractive option (and one that I will surely write about ina future post), we're going to sign up for a free account using Exceptionless's hosted platform. To do so, go to https://exceptionless.com and click the Sign Up button in the top-right:
Once you sign up, you'll be prompted to name your team and project. You'll also need to choose the language in which your project is written. I'm choosing NodeJS, but you can choose whatever language applies to you because I'll be referencing cURL commands to keep our solution as general-purpose and adaptable as possible. Once you've created a project, you will be provided an API Key. Hold on to that, we'll need to use it as a bearer token later.
*Pro-tip: To convert a cURL command to the language of your choice, use Postman and import the raw command. You can then choose the code option and see how to run the API call in the language you prefer.
You'll want to follow the documentation to set up your codebase to send errors appropriately to Exceptionless, but we will also need to think about how we are going to handle these UX errors.
To do this, let's first think about some of the problems a user may face on a site and how we can handle them. A simple example that I can think of is what I'm going to call "Happy Path Slippage." We build applications with a happy path in mind. It's how we test, naturally. We have to force ourselves to test outside of the happy path, so it's also important to monitor how often our users deviate from the happy path.
Let's say we have a simple e-commerce application. The happy path, in this case, would be:
User signs up
User searches for a product
User adds product to shopping cart
User checks out
That is the ideal flow, but we know users won't always follow that flow. However, what we don't know is how often users will deviate and if they do deviate. To track this with Exceptionless, we are going to use simple GET requests with a query parameter to build a funnel analysis. We will want to track product searches, shopping cart adds, and checkouts.
Let's start with the setup for product searches. Remember, we're going to use a GET request. You can read more of the Exceptionless documentation here, but the request is pretty simple. We will want to pass in an indicator that the event is a productSearch and what the product is. We can do that like this:
curl --location --request GET 'https://api.exceptionless.io/api/v2/events/submit/usage?source=productSearch&message=YOUR_PRODUCT'\ --header 'Authorization: Bearer YOUR_API_KEY'
Feel free to add whatever product name you'd like in the query. Just replace YOUR_PRODUCT with the name of the product you'd like to track. You can run the cURL command from the command line or you can use it to build a real request you would use in your app. If we run that then take a look at our dashboard in Exceptionless, we can start to make use of the data.
The Exceptionless dashboard takes you to a handy chart of most frequent exceptions/errors. However, we're tracking User Experience issues tied to features in our application, so those events won't appear on the Exceptions dashboard. Instead, if you click the Features Usage link on the left navigation, then click Events, you should see your new productSearch event.
Pretty cool! This alone starts to become useful. We can cut out a separate analytics tracking tool by using our error monitoring service (Exceptionless in this case) to track events outside the normal error reporting. But we can take it a step further.
Remember, we want to track the funnel from search to checkout. So, let's send through another event representing a cartAdd when a user adds a product to their shopping cart. Here we are adding an extra parameter to also track how many of the product is added to the cart.
curl --location --request GET 'https://api.exceptionless.io/api/v2/events/submit/usage?source=cartAdd&value=QUANTITY_ADDED&message=YOUR_PRODUCT'\ --header 'Authorization: Bearer YOUR_API_KEY'
Exceptionless has real-time monitoring, so if you flip back to your dashboard after running the above command, you should already see the event in the list:
I think you're already seeing how easy this is, but let's round this out by adding a checkout event to track.
curl --location --request GET 'https://api.exceptionless.io/api/v2/events/submit/usage?source=checkout&message=YOUR_PRODUCT'\ --header 'Authorization: Bearer YOUR_API_KEY'
Again, your Exceptionless dashboard should update in real-time. This is starting to shape up! Now, let's dive into the events because right now we have the start of a nice funnel analysis, but we don't know yet what products were searched for, added to the cart, and checked out. The cool thing here is we can click into an event like productSearch for example and get detailed info.
Go ahead and try it. Click on the event and you'll be taken to a dedicated Event Occurrence page.
This is useful information. Combined with our user experience funnel analysis, we can start to make product decisions. Just for fun, I want to show you what this could look like when leveraging the Most Frequent view.
Again, we should click on the Features Usage link on the side navigation. This time, we'll choose the Most Frequent option. I've created a bunch of events so that we can see how useful the Most Frequent view can be.
Now we have the makings of a useful way of tracking the user experience right from within our error reporting tool. The benefit here is that we can use a single tool to help us with monitoring, bugs, event tracking, and user experience. Exceptionless makes this incredibly easy, is self-hostable, is open source, and if you choose the hosted option is very affordable.
Go forth and track errors AND user experience all in one place.
If you are using our hosted service, you do not need to upgrade anything on your end. If you are self hosting Exceptionless and upgrading from version 4 or 5, a little work is needed to get up and running using the new docker images and configuration. See our upgrade guide for more information.
Whether you’re developing a quick module, application, or full blown, go-to-market product, you’re going to need some form of event logging throughout the development process. It can be done without, but you’ll be making your job multiple magnitudes more difficult and losing valuable man hours that could be put towards making your product better instead of just not breaking.
Event logging provides a detailed record of events, bugs, and custom triggers that occur in your application, environment, or product. The information collected gives you a wealth of data to both forensically troubleshoot a bug after it’s occurred as well as proactively to prevent future errors.
This now service is now an invaluable resource to increase your development team’s efficiency and productivity as well as increasing visibility of what goes on behind the scenes in your development environment. On top of that, it also helps maximize application uptime and operation by minimizing the long-term effects of bugs and unwanted events.
Individual raw event logs are too dense and unwieldy to be reviewed. If you were to rely on the raw data, you’d need to specifically hire someone to dig through all that info to pass on the important info to your developers. Event tracking software will parse the data and catalog the important information in an intuitive manner to make everyone’s lives easier. In a nutshell, it will shine a light on the needle in your proverbial haystack.
The great thing about event tracking is that it’s running around the clock. When you and your team aren’t in the office, it’s keeping a watchful eye on your project and collecting data 24/7. It collects data from all sources across your development environment and all of this data is funneled to your dashboard for real-time reporting and criteria based sorting. This allows you to both find the event you’re looking for and quickly dive into its potential causes.
Exceptionless groups common events into stacks based on where the event occurred and the type of error. This cleans up and consolidates the data on your dashboard and in your reports to keep it from being cluttered as well as keeping that information in a single place for your analysis. Even though the event’s footprint is smaller, you’ll still be able to identify larger iterations of the same event to prioritize your work.
It can be incredibly difficult to replicate an event that a user encountered. There’s a slew of information you need to accurately track the cause and the user simply may not, or cannot, provide it. You could spends hours or days just trying to isolate what triggered an event. Hours that could have been put towards building a new feature or getting your product to market.
Event tracking software makes it so a bug that once took a week to find can be found, patched, and pushed live in a matter of minutes or hours instead of days or weeks. Spend less time on maintenance and more time innovating.
Your developers’ time is valuable, and expensive. Even though it’s important, having them blindly diving down rabbit holes to chase bugs and other events can be incredibly costly and not productive. Not every project has a big budget and you may have to work faster and more efficiently to wrap it up without going over budget. While an event logging software may sound like an additional expense, the amount of time you save troubleshooting and fixing bugs will easily cover the cost. And the great thing is, the more you use it, the more you save.
All the information in the world won’t help you if it’s impossible to dig through. We specifically built our dashboard to give a clear high level view of your application while still being clear the further you drill down into individual events and bugs. You can quickly view the health of your application, track data from actually users, and intelligently drill down into recent errors. It seamlessly unites metrics and productivity while you analyze and explore data to rapidly troubleshoot your application.
Bugs, exceptions, issues, faults, errors, incidents, whatever you want to call them, they’re unavoidable. No matter how elegantly you think you wrote your code, no matter how many user cases you think you’ve covered, your application is going to have bugs and part of our jobs is to find those bugs and fix them. You can track these bugs using an Excel or Google sheet (if you’re a glutton for punishment), but the best way is to use a bug tracking platform that tracks, records, reports, and manages these exceptions for you.
In its simplest form, bug tracking is when a developer is alerted to an event when their code does not operate as intended. They catalog the issue, collect as much information as they can that led to said event, and attempt to recreate it so they can fix the problem.
As you can imagine, doing all of this manually becomes quite unwieldy the larger an application gets. On top of that, with larger applications comes additional layers of complexity that a user simply can’t account for or give you the proper information to set you on the path for resolving their bug. This is why it’s so important to have an automated event tracker.
A bug tracking software of any kind is a must have for any sort of application at any stage of development, even months or years after it goes live. The larger your product, the more important it is to have some form of bug tracking implemented. (This is also a tell tale sign of whether or not a development team is worth their salt.)
You can spend hours, days, weeks, and even months trying to track down a bug if you don’t have the right information. Having a software platform in place for tracking bugs helps your development team work smarter and faster when troubleshooting these issues. The software will record, document, and organize these bugs automatically with critical information about the user, event, and the application at the time it occurred. No more chasing down info. It’s already done for you!
C# is one of, if not the most used programming language of the last 15 years. It’s an elegant object oriented language that allows developers to build .NET applications. While it can be daunting at first if you aren’t familiar with it, it’s actually quite simple to use and relatively easy to learn. However, the applications can get quite complicated because of its structure. A misplaced bracket, variable, or object can cause cascading issues that aren’t easy to detect or remedy.
Due to the potentially complicated landscape that is a C# application, detecting, diagnosing, and fixing a bug can be a near-Herculean task, especially if you aren’t the developer that originally created said application. It may have been coded in a non-optimal way or due to time constraints, it had to be done in a hacky way that’s just waiting to implode. This is where a bug tracking solution for your C# application is an invaluable addition to your infrastructure.
You can’t be everywhere at once and see everything, especially in the larger C# applications. Having C# bug tracking software guarantees that you can be with it collecting data in the background. Regardless of when a bug occurs, our platform will have a full report with everything you need to set your development team in the right direction.
Exceptionless’ automated bug tracking already tracks an enormous amount of contextual information automatically, but you can track even more information by creating a custom object. If you want to grab info on what was in a customer’s before it threw a bug, custom object. Once created, you can set these objects as top level tabs to improve their visibility.
Every bug is intelligently tracked on our dashboard and consolidated into stacked groups based on where it occurred and the type of bug. Not only does this keep things nice and tidy, but it also lets you triage whether or not a bug needs to be fixed as soon as possible. These reports also persist after the bug has been fixed so you have historical data just in case the bug resurfaces later.
Our bug reports extensively tracks a robust set of information to help you quickly track down and fix the error. The default information covers type of error, stack trace, date, request information, and environment information, but that can easily be expanded upon and tailored to your application with custom objects.
We have extensively documented our platform and API to make it easy and painless to use. You can use our fluent API to easily add custom objects, tags, and other information as well as marking certain errors as vitally important.
Troubleshooting and fixing bugs is part of our jobs as developers and, as the saying goes, we need to work smarter, not harder so we can spend more time creating new features to our applications rather than patching errors. Exceptionless’ C# bug tracking software will intuitively, and automatically, organize any bugs that do occur to help you pinpoint the cause so your application can get back on track.