(/assets/versioning.png)Do you get annoyed and overwhelmed by event and error notifications?
You probably have more than one version of your application running, and often older versions of your app may still be triggering events that have been fixed in newer versions.
**Those events and notifications aren't very **helpful, so we implemented a versioning system that allows you to set an application version on all events!
After setting an application version, when you mark an event fixed and give it a version number, it will only regress if it occurs again in a newer version of your app.
That means there is less noise for you to wade through, and you can focus on new issues in your application without seeing old or non-relevant events constantly.
Setting an application version in Exceptionless is easy. By default, we attempt to resolve one automatically based on assembly attributes, but we recommend specifying one yourself for improved reliability and accuracy using the following examples.
Great! Now, when you mark an error stack as fixed and enter the version that you fixed it in, that event stack will have a Fixed In [Version] tag and will only regress if it occurs again in a later version of your app. If it does regress, the stack then gets the REGRESSED tag.
(/assets/regressed.jpg)Regressed
If you would like to view fixed events, you can always use the * wildcard or fixed:true in search.
We hope you find this feature useful, and as always don't hesitate to leave us feedback over on GitHub or by commenting below.
Bet You Didn't Know Exceptionless Could Do This... #
Have you ever needed to cut through the noise and just focus on one type of event(in real time), such as only error logs, to track down a bug?
Do you want to limit certain types of event reporting(in real time) to save your event quota and limit clutter?
What about controlling your application's settings or featuresin real time via Exceptionless, without having to update your files and deploy your app!?
Well, with our client configuration settings, you can do all that, and more, in real time, on a per-project basis via your Exceptionless dashboard!
Let's say you're on the small plan, and you've got a bunch of warning log events clogging your system that you know about and are working on, but they are pushing you over your plan limits.
#BOOM - set a minimum log level of error, and Exceptionless won't report those warnings anymore and they won't count against your plan limits! This is a great way to get the most out of your Exceptionless plan.
Scenario 2 - This Authentication Issue is KILLING Me! #
Maybe you're having major issues with an authentication bug, but you've already set minimum log levels to only include errors. Well, now you also want to see the trace values for those events without opening the flood gates for every event by removing your minimum log level.
#NOPROBLEM - Just add a key for authentication that just lets trace events through!
Scenario 3 - You Said Something About Controlling My App's Features In Real Time? #
Yup! Our client configurations are basically just a key value pair dictionary, but what makes them powerful and helps them control your application's features is that they get updated in nearly real-time, meaning you can build settings, features, etc into your app that react to value changes, and if you change that configuration setting in Exceptionless, your app will react almost instantly!
This can be super useful, especially if changing your app's settings would normally require you to deploy to production. No need - just use Exceptionless!
First, settings updates do not count towards plan limits. We say that because each time an event is submitted, we send a response header with the current configuration version to the client, and if a newer version is available, it is retrieved and the latest configuration is applied. That means that config changes are nearly real time.
When the client is idle, we also check for config changes, including five seconds after client startup if no events are submitted at startup, and every two minutes after the last event submission.
If the version hasn't changed, nothing is retrieved, limiting data transfer, and no user information is ever sent when checking.
If you do not want the configuration settings to update when idle, you can turn off automatic updates. To do so, please follow the respective .NET or JavaScript/Node.js documentation.
Exceptionless client configurations are a dictionary of key value pairs that can be used to control the behavior of your app in real time by doing things like controlling data exclusions, protecting sensitive data, enabling and disable features, or disabling certain types of events (error, usage, log, 404, or session).
We also have some built in configuration key naming conventions (@@EVENT_TYPE:SOURCE) that the clients recognize for ignoring events based on event type and event source. Just replace EVENT_TYPE part with the event type (E.G., error, log...) and the SOURCE (E.G., exception type or log source) you'd like the setting to apply to. Next, specify key value of false to discard matching events client side. It's worth noting that log event types can also accept a log level value (E.G., Trace, Debug, Info, Warn, Error, or Fatal).
For example, we can use it to turn off all error events of type, lets say, System.ArgumentNullException, by using the key @@error:System.ArgumentNullException and the value false.
Or, we could turn off all error events entirely by using the * wildcard. So, the key would be @@error:* and the value would be false again.
In scenario 1, above, we were trying to save our plan limits by limiting log events to only errors. So our Client Configuration key would simply be @@log:* with value Error.
Scenario 2
Here we already limited our log events to errors, but now we're troubleshooting a specific issue with authentication (let's say we're using the AuthController API), so we want to look at the trace messages coming through. We can override any general minimum log levels that we've defined by setting a level for a specific log source. So, all we would do is add the @@log:*AuthController key with value Trace! Then, when the bug's fixed, turn it off as needed.
Scenario 3
This is the cool one. Here you are wanting to, let's say, pass a value for a setting in your app that turns something on or off without having to re-deploy everything. This is super easy to accomplish all we need to do is create a setting which will control our feature! Let's assume we have have a feature flag to show a welcome screen. We will name this feature flag enableWelcomeScreen and create a new configuration setting respectively with a value of true (You can change this value at any time). These changes will be pushed based on the above "How Project Settings Work" section automatically, all we have to do is check the setting as shown below.
C#
usingExceptionless; // Check the configuration settings for our enableWelcomeScreen feature flag with a default value of false. if(ExceptionlessClient.Default.Configuration.Settings.GetBoolean("enableWelcomeScreen",false)){ // Show the welcome screen! }
JavaScript
// Check the configuration settings for our enableWelcomeScreen feature flag if(exceptionless.ExceptionlessClient.default.config.settings['enableWelcomeScreen']===true){ // Show the welcome screen! }
If you go to Admin > Projects in Exceptionless, you can choose the project you would like to edit the settings for. Each project can have unique settings.
The default tab is "General," which simply houses the project name and attached organization. Nothing fancy here - pretty self explanatory.
This tab is where you can generate an API key for your project. Again, pretty self explanatory. Hit "New API Key" and one gets generated. For more details on API usage, check out the API Usage documentation on GitHub.
This is where you can set data exclusions, customize error stacking, and build in some spam detection to your project.
Data Exclusions
There are several use cases where you might not want to send some data to your Exceptionless project. This field allows you to enter a comma delimited list of field names that will be removed and not transferred to Exceptionless. The perfect example here is a password field, or other personal and sensitive data.
The * wildcard is supported in this field and can be used at the end (password*), beginning(*password), or on both sides (*password*) of the field name to further customize your data exclusion.
Error Stacking
Control over error stacking is another level of customization project settings allows. You can specify user namespaces or common methods to ignore. More details below.
User Namespaces
Here you can enter a comma delimited list of namespace names that own your application. With those in place, the only methods that will be considered stacking targets are ones inside those namespaces.
Common Methods
If your code has shared utility methods that may generate a bunch of errors, this could be useful. Enter a comma delimited list of common method names that shouldn't be used as stacking targets, and they will be ignored.
Spam Detection
Spam is the worst. So, we added a "Spam Detection" list of common user agents that should be ignored, which you can add to as you see fit. This eliminates a lot of noise, and can be customized to help trim even more depending on your application.
Along with the comma delimited list of user agents to ignore, you can also tick the box that says "Reduce noise by automatically hiding high volumes of events coming from a single client IP address." This can ward off large numbers of events being submitted by a spammer or attack on your app.
Integrations
Integrations with tools like Slack, HipChat, JIRA, Basecamp, and others are very popular and can add a level of automated notifications, etc, to your workflow. So, on the integrations tab of your project's configuration you can create web hooks to integrate with your service or others as mentioned. Each web hook has a URL that it can call, and options for when it should be called. When a selected event occurs, a POST request is submitted with either event or stack data in JSON format. For more details and sample data, visit the Exceptionless integrations documentation.
We hope this will help you make the most out of your Exceptionless projects, allowing you to save some event submissions, get that customization you were looking for, etc.
Please let us know if you have any questions, comments, concerns, bugs, or anything else we can help with!
The latest Exceptionless release has several additions we think most of our users will find helpful. We sat down and worked on the UI, fixed some bugs, and spend a considerable amount of time improving reliability and efficiency of some of the primary pieces of the app.
If you're a self hoster, you'll need to upgrade your existing install, but if you're hosting with us there is no action required on your part to experiences the Exceptionless 3.4.
The new most users dashboard allows you a quick view of events sorted by the highest number of affected users. This is great for helping prioritize your work pipeline.
Also, as an aside, we've added the users affected column to the dashboard. We know some of you guys will find that helpful.
MacOS & Linux keyboard shortcut support has been added, as well as additional shortcuts such as C to chat with support, S to focus the search bar, and ga to go to your account. Hit SHIFT + / (also known as ? ) to access the keyboard shortcut list on any screen.
As an aside here, there is also now a </> button near the top of the event occurrence that lets you quickly copy the JSON to your clipboard with a click.
We made several reliability and performance enhancements to queue and job processing. A few specific examples include fixing auto-abandoned jobs and instances where batch events weren't being requeued.
Previously we had worked on making heartbeat events efficient so we didn't have to count them toward event quotas, and with this release we've added new API Endpoints that allow clients to submit those heartbeats cheaply.
Support has been added for Active Directory Authentication. Thanks @laughinggoose! To enable this feature, head over to the Active Directory Authentication documentation page on GitHub.
This Count property was added to the event model that tracks deduplicated events and allows for some pretty cool metrics from here on out while avoiding the full cost of storing every event.
MaximumRetentionDays is pretty self explanatory. It controls the max retention perdiod for events, which allows the retention job and plans to be smarter about cleaning up old data.
The NuGet package now supports .NET Standard 1.2+, PCL Profile 151, and .NET 4.5.
To make upgrading easy, the Exceptionless.Portable NuGet package still exists and is dependent on the Exceptionless Package.
If .NET 4.0 is a requirement for your projects, you will need to continue using the Exceptionless.NET v3.5 NuGet Packages, which are not being deprecated.
As a matter of housekeeping, we removed the ExceptionlessClient.Current property, which was replaced with ExceptionlessClient.Default in v2.0.0, and the configuration EnableSSL properties (also deprecated in v2).
Updating the NuGet packages should be all you need to do if you are upgrading from Exceptionless.NET v2 or v3. Take a look at the upgrade guide if you have any questions.
That's right! We've re-imagined how session heartbeats and session end events should work on the back end and were able to make them much more efficient, allowing us to stop counting them toward user plan limits!
This blog post explains our original goals and implementation of these session events, and how we were able to retain the same functionality of the feature while limiting resource usage.
Our hope is that this will obviously make our users happy, but also that all the developers out there can benefit from our process and solution.
In the beginning, we set out to create a sessions feature that allowed our users to submit a session start event and the session would be automatically updated by sending a session heartbeat event, as well as a session end event, respectively.
These session heartbeats and session end events were meant to be session markers to show that a user was active or a session had ended.
We wanted to leverage our existing infrastructure, and the easiest way to do so was to introduce new event types that we recognized. This meant that these events went through the client side plugins (extra work) and server side processing. As such, there was no way to tell these events apart from any other event.
And because of that, they counted against user plan limits.
After releasing the sessions feature, it didn't take us long to notice that the heartbeats were noise. However, we knew that users wanted to see what their customers or users were doing while being active throughout the session, so we didn't remove them.
We knew they were counting towards plan limits, causing some users to reach theirs quickly, and we knew they were adding noise, thus limiting the feature's value, but we also wanted to keep the feature alive because of the potential value offered. So, we had to react and make the entire feature more feasible, streamlined, and cheap.
We did some thinking (and coding), trying to determine the best way we could provide end users with a great session tracking feature without over-taxing our system in the process, and we were able to come up with a solution!
So, we created a new GET API endpoint /api/v2/events/session/heartbeat (api source) that takes a session id or user id and a flag if the session is closed. This API endpoint then sets a unique session cache key with the current time.
Our existing CloseInactiveSessionsJob.cs was already periodically polling for open sessions to check for inactive sessions so it could automatically close them after a period of time if no session end event was sent, so we just updated this job to check for the unique session cache keys (source) and get the last time a heartbeat was sent in or see if it was closed. It then takes the appropriate action and updates the session event.
Then we just updated the clients to call this new API endpoint when client.Submit.SessionHeartbeat("id") or client.SubmitSessionEnd("id") is called.
Our new solution gives us the ability to have clients send us session heartbeat and session end information very efficiently, which lets us provide a great session tracking feature without adding any additional cost to our plans!
That's how we like to roll, and we hope you find value from the feature and our run down of the process we went through to get it to our users.
Exceptionless.NET v3.5.0 and Exceptionless.JavaScript v1.4.0 have been released and they are chock full of new features and feature improvements!
There weren't a whole lot of bug fixes with these releases. Could it be that Exceptionless is working and we've squelched most of the bugs? We think so!
Notably, we focused on sessions, real time configuration, and logging, all of which we think you'll find super helpful.
Session Heartbeats No Longer Count Towards Plan Limits! #
We've updated Session Heartbeats and Session End events to be sent through an optimized API end point, and they will no longer count towards your plane's event limits.
You can now exclude events by type and source, along with setting minimum log levels, in real time. So, for example, if you accidentally disable logging completely, you can simply update your settings and the updates will go into affect, restoring functionality!
UI support will be expanded moving forward, but for the time being here is an example project configuration.
Source
Key:@@EVENT_TYPE:SOURCE<br />
Value:false
Any event type or source can be used, and wildcards * are supported, so you can ignore whole event types and set the source to *.
Disable Submissions of Events with Type Name
Key:@@error:*MyCustomException
**Value: **false
This configuration will disable submission of any error event with a stack trace containing an exception with a type name that ends with MyCustomException. You could also remove the wildcard and specify the full type name with the namespace.
Log Message Settings
Key:@@log:*
Value:off
Even though log types are special cased, they still accept rue or false values, so this example completely turns off log messages.
Other known values are Trace, Debug, Info, Warn, Error, Fatal, and Off.
Minimum Log Level
**Key: **@@log:MyNamespace.EventPostsJob
**Value: **Info
This example is setting the minimum log level for EventPostsJob to Info.
Automatically Check for Updated Configuration Settings on Client Idle #
We've implemented an automatic recurring check for updated configuration settings that occurs two minutes after the last event submission.
A few notes:
Each configuration check does not count towards your account's plan limits.
No user information will be sent - only the current configuration version.
Nothing will be retrieved if no settings have been changed.
The automatic recurring configuration settings check can be disable by calling:
New Easy Way to Exclude Events from Being Submitted in .NET #
You can now define a simple Func<Event,bool> callback to stop events from being submitted in the .NET client.
For example, if I wanted to ignore any event with a value property of 2 I could use client.Configuration.AddEventExclusion(e => e.Value.GetValueOrDefault() != 2);
Bug Fix for SettingsCollection Boolean Values Support in .NET Client #
SettingsCollection.GetBoolean(name) was not supporting `` or 1 as boolean values, but now it does. We are also now supporting yes and no as valid values.
We hope these new features and feature improvements help your Exceptionless experience, and we plan to continue to listen to user feedback and improve the system where improvements need to be made. To do that, though, we need to hear what you want out of the app. If you have a favorite feature request, or something that just bothers you, please let us know by dropping us a line on GitHub Issues under the appropriate repository, listed below, or just comment here and we'll figure it out!
Today we've got a quick article on one of the little known features of Exceptionless: keyboard shortcuts.
In an effort to help you navigate Exceptionless event stacks better and troubleshoot faster, we've added keyboard shortcuts that lets you do things like go to the stack from an individual event occurrence, copy the event JSON, navigate to the previous event occurrence, etc.
Let's take a look at all the quick shortcuts you can use to make your Exceptionless usage more efficient.
To bring up the keyboard shortcuts available to each page, simply hold the shift key and hit the forward slash key (SHIFT + /, think ?). This will bring up an overlay showing you which shortcuts are available on that specific page.
Don't see shortcuts available on a page? Don't freak out, there may just not be any. Feel free to suggest something that you think would save yourself and others time, though!
If you hit SHIFT + / (?) on an event occurrence, you will see three or four new options, depending on whether you are on the first occurrence in the stack or not.
**Go to Stack
** On any event occurrence, you can hit CTRL + UP to go to that event's stack quicker than finding the "Go To Stack" button and clicking.
**Copy Event JSON to Clipboard
** Hit CTRL + SHIFT + C to copy that event's JSON data to your clipboard.
**Previous Occurrence
** CTRL + BACK (LEFT) will take you to the previous event occurrence.
**Next Occurrence
** And CTRL + FORWARD (RIGHT) will take you to the next occurrence of that event.
On any dashboard or stack, SHIFT + / (?) brings up a simple overlay letting you know that ? will close the overlay and F1 will take you to the Exceptionless documentation on GitHub.
We're open to suggestions for other dashboard or stack shortcuts, just let us know in the comments!
We'd love to get some community input here. What shortcuts do you think would be useful on which Exceptionless pages? Do you have something you do repeatedly on a dashboard or stack page that you think a keyboard shortcut might speed up or make more efficient? Let us know in the comments and we'll do our best to implement your ideas!
Prioritizing your bug fixes and development time in general can be a daunting task.
Sometimes, as developers, we want to work on this shiny widget or this annoying bug, and we don't really have anything in our face telling us to quit focusing on our dreams and work on what matters to the bottom line.
I can hear you over there: "But, my dreams are important!" Well, yes, but you don't get to have fun working on those until you've made your users happy by fixing the bugs that are affecting the majority of them or expanding on that feature that they are all using every single time they use your app.
We've got something that will let you get those pesky tasks off your plate though, so you can move on to the fun stuff!
Our new "users" column and "Most Users" dashboard lets you know exactly what percentage of your users are being affected by events or using features. This allows you to prioritize the most important bugs or features to work on right away and potentially backlog things that only a few users are having issues with or using.
Of course, you'll need to be sending at least a user id (and preferably a display name) for each user. We'll cover how to do that later in the article.
The new Users column on your Exceptionless dashboard displays a percentage value for each event stack that represents the number of users that have been affected by the event or, if it is a feature, that have used the feature.
If you mouse over the percentage, you can see the number of users the percentage represents out of the total.
These numbers are dynamically calculated for your selected timeframe that you are currently viewing.
Because the main dashboard shows you the most frequent events, not necessarily with the highest usage, we thought it would be helpful to have a new dashboard that automatically sorts event stacks by the percentage of users affected, letting you start at the top of an exception list, for example, and work your way down knowing you're always working on a bug, etc, that is affecting the highest percentage of users.
In order to assure you are getting value out of the user feature, you want to make sure you are setting the user. For Exceptionless to track a user for your app, you need to send a user identity with each event. To do so, you need to set the default user identity via the following client methods:
Once the user is set on the config object, it will be applied to all future events.
Please Note: In WinForms and WPF applications, a plugin will automatically set the default user to the **Environment.UserName** if the default user hasn't been already set. Likewise, if you are in a web environment, we will set the default user to the request principal's identity if the default user hasn't already been set.
You can also manually set the user info on the event directly. This is intended for **multi-user processes (web applications). **For most MVC and WebAPI packages, the user will be set automatically based on the logged in principal, so you don't have to do anything.
// Import the exceptionless namespace. usingExceptionless; ExceptionlessClient.Default.CreateFeatureUsage("MyFeature").SetUserIdentity("123456789","Blake Niemyjski").Submit();
If you're using the JavaScript client, the entire session of the client will typically be for a single user, so you should be able to set it one time when they log in to your app.
We are always interested in how our users use our features, and if our users feature helps our users help their users, well, that's a win win for our users and their users. Go users!
Don't forget to stop by and let us know if you love or hate it, and of course let us know if you think we can improve on anything within Exceptionless.
We've continued to focus some of our attention on our pluggable app foundation block solution, Foundatio, and last week it got some attention from the Microsoft .NET Blog as well!
We've got a few new implementations with this release, including Amazon S3 storage, Azure Service Bus queue (thanks @jamie94bc!), and Redis metrics client. Users should find those helpful.
The APIs have been drastically simplified for ease of use and straightforwardness, which should allow for easier creation of new implementations and consumption of existing ones.
Once example of this simplification is that we've paired down jobs to having only one lock, instead of four.
Logging has also seen huge improvements to make sure we are aligned with future API implementations, etc.
We always work hard to keep improving Exceptionless, and this release is no different!
Since the last release, we've put a lot of time into making the filtering and searching more user friendly and intuitive, improving the reliability of jobs, and of course fixing any bugs that you guys (or Exceptionless) have been able to find.
For starters, as mentioned above, we relocated the search bar to exist on the top level of the UI, and the date picker filter now shows the current choice on the top level. Both icons were replaced, and we really think it's much more intuitive and efficient. You can read more and see examples over on the dedicated blog post we did last week.
Session management has been drastically improved by doing a few different things. For instance, inactive sessions are now closed faster, but they can be opened again if need be. We hid heartbeat events by default, too, and you can now specify manual sessions for desktop-based apps.
We introduced custom event stacking a few weeks ago, and @adamzolotarev has added the ability to specify a manual stacking key on the client side with this release. Thanks Adam!
A default list of bot wild card exclusions is now automatically set on new projects, so if you're upgrading, you now have the ability to run a maintenance job via the admin controller to set a default bot list. All events with user agents matching these wild cards will then be discarded on the client side.
Marking stacks as fixed or hidden was causing some significant slow down and sometimes wouldn't work at all. This has been remedied!
Redis connection failures and lock timeouts were sometimes causing jobs to stop working or fail. We dug through and found what was causing that and fixed it as well.
When the geo field contained a localized number, sometimes events were not being processed. This localization issue has been solved.
And last but not least (well, maybe least), a seralization bug has been fixed that would cause query strings, cookies, and other extended data items to be transformed to lowercase and underscored.
Well, only if you're a self hoster. Everyone else will experience all of these awesome improvements and bug fixes the next time they log in. If you are a self hoster, please review the Self Hosting Docs for info regarding upgrading your current Exceptionless install. Naturally, if you have any questions please let us know and we will get you taken care of.
You can find a complete comparison changelog over on GitHub, where you can also submit any issues, etc if you run across anything. Please also let us know what you think of the changes by commenting below, pinging us on social media, or simply sending Blake a glitter bomb(site/link not endorsed in any way, lol - first one I found!).
(/assets/versioning.png)Do you get annoyed and overwhelmed by event and error notifications?
(/assets/regressed.jpg)
(/assets/exceptionless-3-4-header.png)
(/assets/Screen-Shot-2016-06-28-at-3.08.17-PM.png)
That's right! We've re-imagined how session heartbeats and session end events should work on the back end and were able to make them much more efficient, allowing us to stop counting them toward user plan limits!
Exceptionless.NET v3.5.0 and Exceptionless.JavaScript v1.4.0 have been released and they are chock full of new features and feature improvements!
Today we've got a quick article on one of the little known features of Exceptionless: keyboard shortcuts.
Prioritizing your bug fixes and development time in general can be a daunting task.
We've continued to focus some of our attention on our pluggable app foundation block solution, Foundatio, and last week it got some attention from the Microsoft .NET Blog as well!