Exceptionless Versions Save

Exceptionless application

v7.0.3

3 years ago

The 7.0.3 release resolved a search issue where the event repository wouldn't always bypass the the stack filter. This could lead to some queries returning incorrect results (https://github.com/exceptionless/Exceptionless/commit/92690e305ec1c00285249919ae0667474c0d6bec).

Upgrading to 7.0.3

The only users that need to worry about upgrading anything for this new release are self-hosters. If you are self hosting Exceptionless, please review the Self Hosting Documentation, which contains information about upgrading your existing install. Please review the self hosting documentation for more information.

Please take a look at the change log for a full list of the changes.

Always Improving

We’re always striving to improve the efficiency of Exceptionless and all of our projects. If you see any room for improvement or have any comments when using anything from us, please send us an in-app message or submit a GitHub issue.

Thanks

We'd like to say thank you to the community and project sponsors for helping us ship 7.0!

v7.0.2

3 years ago

The 7.0.2 release fixed a server side issue that ensured forwarded ip addresses were resolved correctly when using a reverse proxy (#736 @PhyxionNL).

Upgrading to 7.0.2

Please take a look at the change log for a full list of the changes.

Always Improving

Thanks

We'd like to say thank you to the community and project sponsors for helping us ship 7.0!

v7.0.1

3 years ago

With 7.0 we focused on a major new feature we call Stack Status and updated the user interface with new dashboards and many other dashboard improvements.

Stack Status

One of the biggest issues we currently have with Exceptionless is users having some rogue event going off and eating up their entire monthly plan limits. In the past we tried to say that users should fix this on their side of things and didn't give them any tools to do anything about it on the Exceptionless side. This results in users accounts getting throttled and the value we are providing to that user being diminished. One of the big reasons we took that stance is because we are paying for bandwidth and computing power required to process those events on our side and then discard them. We have decided that we are going to do the right thing for the users and eat that cost by allowing stacks of events to be marked as discarded. Any events coming in that match that stack will be thrown away and not count against your plan.

This is a massive new feature months in the making which you can read more about here: #530. We had several goals for this feature:

Improve users ability to efficiently manage their event data by allowing them to quickly mark stacks of events as fixed, snoozed, ignored or discarded.
- fixed: If you have fixed the issue, mark it as fixed and the stack will be hidden until the system sees the same type of error happen again. You can even specify a semver version that the error was fixed in and the system will only mark the stack as regressed if it sees that it happened in that version or a newer version.
- snoozed: Use this status if you would like to ignore events from this stack for a period of time. They will be removed from your dashboard views and you will not get any notifications about them until that time has elapsed.
- ignored: Use this status to permanently ignore the stack of events. The system will continue to gather the events belonging to this stack, but they will not show up in the dashboard views and you will not get any notifications about them. You can use the new Ignored report to view any stacks you have marked as Ignored.
- discarded: Use this status to indicate that you do not care about this type of event and do not wish to gather information about it. Marking a stack as discarded will cause any future events of this type to be discarded, you will not get any notifications about them and they will not count against your plan limits.
- delete: You can also still delete a stack under the options menu. Deleting a stack will delete that stack of events, but any new events of the same kind will create a brand new stack of events. You should only use this if you accidentally captured sensitive data or you just want to start over for a specific type of event.
Instant dashboard updates when stack status is changed (e.g., fixed, ignored) or deleted. We do this by making our events immutable and only updating the stack. Previously we would need to de-normalize the stack status down to every single event that belonged to that stack which could potentially be millions of events and take hours to process and completely update.

Dashboards

The Most Frequent view is now the default. We want the focus to be on the organized stacks of events which should represent a virtual todo list of things that you should look into. We think that is providing more value than looking at a log of the most recent individual incoming events.
Status Badges: We now show stack statuses in the grids for greater visibility.
Renamed Dashboard Terms We renamed Unique to Stacks, Counts to Events, New to New Stacks, Per Hour to Events Per Hour, Timeline to Events. We felt this made more sense and cleared up any confusion.
Updated Dashboards - All dashboards now have a stat box and timeline view of Stacks/Events occurring in the specified criteria. We felt this added value and was less jarring.
Simplified Stack Actions - We removed a bunch of actions like Mark Not Fixed and Mark Not Ignored. These didn't make sense can could all be replaced by Mark Open (#700).
New Reports - We added new Reports that allow you to see different Stacks grouped on stack status.
Navigation Tweaks - We changed up some icons on the left hand sidebar and added a separator to better group dashboards. We also fixed some issues with some broken links that could occur on the all dashboards.
The previous dashboard has been renamed to Events.

.NET 5.0

.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. Here is the commit (https://github.com/exceptionless/Exceptionless/commit/874f08e70a3ded2762f8d34df0378de38d7a3193) to upgrade to .NET 5.0

Improved API Documentation

We made many improvements to the generated swagger api documentation that ships with every release. Here are some of the notable changes we made

Updated code comments with improved examples which are displayed on the api documentation.
Ensure HTTP headers like UserAgent are read only in the generated api documentation.
Ensure POST endpoints (like event submission) which read from the request body now shows an input box for submitting content from right inside of swagger.

Notable Bug Fixes

Fixed an issue where the system would create a duplicate stack even though a stack for the incoming event already existed.
Fixed a concurrency issue that could cause duplicate stacks to be created (https://github.com/exceptionless/Exceptionless/commit/6d97e40036e886c48651c391fb6f26fd8afa7efd). We also added a migration to clean up any existing duplicates.

Please take a look at the change log for a full list of the changes.

Upgrading to 7.0

Always Improving

Thanks

We'd like to say thank you to the community and project sponsors for helping us ship 7.0!

v7.0.0

3 years ago

With 7.0 we focused on a major new feature we call Stack Status and updated the user interface with new dashboards.

Stack Status

This is a massive new feature months in the making which you can read more about here: #530. We had several goals for this feature:

Improve users ability to efficiently manage their event data by allowing them to quickly mark stacks of events as fixed, snoozed, ignored or discarded.
- fixed: If you have fixed the issue, mark it as fixed and the stack will be hidden until the system sees the same type of error happen again. You can even specify a semver version that the error was fixed in and the system will only mark the stack as regressed if it sees that it happened in that version or a newer version.
- snoozed: Use this status if you would like to ignore events from this stack for a period of time. They will be removed from your dashboard views and you will not get any notifications about them until that time has elapsed.
- ignored: Use this status to permanently ignore the stack of events. The system will continue to gather the events belonging to this stack, but they will not show up in the dashboard views and you will not get any notifications about them. You can use the new Ignored report to view any stacks you have marked as Ignored.
- discarded: Use this status to indicate that you do not care about this type of event and do not wish to gather information about it. Marking a stack as discarded will cause any future events of this type to be discarded, you will not get any notifications about them and they will not count against your plan limits.
- delete: You can also still delete a stack under the options menu. Deleting a stack will delete that stack of events, but any new events of the same kind will create a brand new stack of events. You should only use this if you accidentally captured sensitive data or you just want to start over for a specific type of event.
Instant dashboard updates when stack status is changed (e.g., fixed, ignored) or deleted. We do this by making our events immutable and only updating the stack. Previously we would need to de-normalize the stack status down to every single event that belonged to that stack which could potentially be millions of events and take hours to process and completely update.

Dashboards

The Most Frequent view is now the default. We want the focus to be on the organized stacks of events which should represent a virtual todo list of things that you should look into. We think that is providing more value than looking at a log of the most recent individual incoming events.
The previous dashboard has been renamed to Timeline.

Notable Bug Fixes

Fixed an issue where the system would create a duplicate stack even though a stack for the incoming event already existed.

Please take a look at the change log for a full list of the changes.

Upgrading to 7.0

Always Improving

Thanks

We'd like to say thank you to the community and project sponsors for helping us ship 7.0!

v6.1.4

3 years ago

With 6.1.4 we updated the helm charts to remove the Elasticsearch snapshot jobs. If you were using the backup jobs please migrate to using the Elasticsearch snapshot lifecycle management.

Docker

We added an easier way to try Exceptionless out locally with a single docker image. Exceptionless can be run locally as simply as docker run --rm -it -p 5000:80 exceptionless/exceptionless:6.1.4. This will run a completely self-contained simple instance of Exceptionless. It is only suitable for testing purposes since it will not persist data. For more complete setups, check out the self hosting documentation.

Bug Fixes

We had several notable fixes in this release that deserve some recognition.

Fixed an issue for users around the globe where the existing CDN provider may have not been available in some regions. This could cause the User Interface (UI) to not load (https://github.com/exceptionless/Exceptionless.UI/issues/195).

Upgrading to 6.1.4

Please take a look at the change log for a full list of the changes.

Always Improving

Thanks

We'd like to say thank you to the community and project sponsors for helping us ship 6.0!

v6.1.3

3 years ago

With 6.1.3 we focused bug fixes and improving the self hosting experience.

Docker

We added an easier way to try Exceptionless out locally with a single docker image. Exceptionless can be run locally as simply as docker run --rm -it -p 5000:80 exceptionless/exceptionless:6.1.3. This will run a completely self-contained simple instance of Exceptionless. It is only suitable for testing purposes since it will not persist data. For more complete setups, check out the self hosting documentation.

Bug Fixes

We had several notable fixes in this release that deserve some recognition.

Fixed an issue for users around the globe where the existing CDN provider may have not been available in some regions. This could cause the User Interface (UI) to not load (https://github.com/exceptionless/Exceptionless.UI/issues/195).

Upgrading to 6.1.3

Please take a look at the change log for a full list of the changes.

Always Improving

Thanks

We'd like to say thank you to the community and project sponsors for helping us ship 6.0!

v6.1.2

3 years ago

With 6.1.2 we fixed a bug that was introduced in the 6.1.1 release where health checks could return an internal url.

Upgrading to 6.1.2

Please take a look at the change log for a full list of the changes.

Always Improving

Thanks

We'd like to say thank you to the community and project sponsors for helping us ship 6.0!

v6.1.1

3 years ago

With 6.1.1 we focused bug fixes and improving the self hosting experience.

Docker

We added an easier way to try Exceptionless out locally with a single docker image. Exceptionless can be run locally as simply as docker run --rm -it -p 5000:80 exceptionless/exceptionless:6.1.1. This will run a completely self-contained simple instance of Exceptionless. It is only suitable for testing purposes since it will not persist data. For more complete setups, check out the self hosting documentation.

Bug Fixes

We had several notable fixes in this release that deserve some recognition.

Fixed an issue for users around the globe where the existing CDN provider may have not been available in some regions. This could cause the User Interface (UI) to not load (https://github.com/exceptionless/Exceptionless.UI/issues/195).

Upgrading to 6.1.1

Please take a look at the change log for a full list of the changes.

Always Improving

Thanks

We'd like to say thank you to the community and project sponsors for helping us ship 6.0!

v6.1.0

3 years ago

With 6.1.0 we focused bug fixes and improving the self hosting experience.

Bug Fixes

We had several notable fixes in this release that deserve some recognition.

Fixed a bug where requests would fail with Synchronous operations are disallowed (#572).
Fixed a bug with verifying email addresses could fail (#545)

Upgrading to 6.1

Please take a look at the change log for a full list of the changes.

Always Improving

Thanks

We'd like to say thank you to the community and project sponsors for helping us ship 6.0!

v6.0.0

4 years ago

With 6.0.0 we focused on Elasticsearch 7 and ASP.NET Core 3.1 support.

Elasticsearch 7.x

The upgrade from Elasticsearch 5.x to Elasticsearch 7.x was a massive effort and is well worth the data migration required. We took a step back and also looked at the changes we could make to improve search too! Here is some of the benefits we get by upgrading:

We reexamined all of our search queries and tweaked them to work better. Then we looked at and fixed all the user logged search issues.
Faster Shard Recovery via Sequence Ids and Resiliency. Now if a node goes down for service, it will recover even faster.
Faster query performance. Elasticsearch has done a ton of work to optimize all queries especially date based queries.
Better memory footprint. Elasticsearch has optimized the memory footprint and we have also tweaked our indexes to do multi field search so we don't have to do extra copies of data into an all field (This also means less data stored on disk).

ASP.NET Core Support

We added support for ASP.NET Core 3.1 LTS with this release. This upgrade allows us to stay on the current supported version while getting many performance improvements that come with version 3.x.

Docker/Kubernetes Support

We've done more work to stream line our docker and Kubernetes experience. We do want to make it easier to get up and running with Kubernetes and we'll be taking steps to make this process easier.

Upgrading to 6.0

Please take a look at the change log for a full list of the changes.

Always Improving

Thanks

We'd like to say thank you to the community and project sponsors for helping us ship 6.0!