Version 2.0 was a pretty big rewrite for us, and we're happy with how everything played out, but that doesn't mean we're done!
We've been working on 3.0, and it's ready.
What was the focus, you ask? To make life easier for you! We've simplified the build process, removed dependencies, and drastically improved the ease of self hosting.
Previously, MongoDB was a major dependency that increase the complexity of the overall project. All the data previously hosted in MongoDB is now hosted in ElasticSearch, making it super easy for users to self host or develop Exceptionless since you only need to set up ElasticSearch (which you had to do anyway).
With this, Redis is no longer configured by default, but you can set it up easily by setting the connection string. We definitely recommend using it.
Removal of the MongoDB dependency brings us one step closer to running Exceptionless on vNext, on any operating system. We hope to achieve this soon, but do not have a timeline.
The goal is to make self hosting as easy as possible so anyone can set it up and try Exceptionless out.
With Exceptionless 3.0, we now have a single build artifact that contains bo the SPA app and the API end server, with default configuration. The ZIP file contains a batch file you can run to download and start ElasticSearch, launch IIS Express with a temp website, and load your browser automatically with the Exceptionless test instance. This lets you load up everything and play around with Exceptionless in a single click!
Another change to the configuration is that you now have the ability to set every Exceptionless API Setting via Environmental Variables.
In order to make it easier and faster to deploy, we removed the OctopusDeploy build dependency and are now using Azure Git deploy, which pulls directly from a GitHub repository that contains the build artifacts.
With this move, our mindset changed regarding the master branch. For us it means production, but for you it means that whatever is in our master branch is stable and currently deployed to live. We no longer have to wait for a build to complete, create a production release in OctopusDeploy, then manually deploy it, we just commit to git and the rest is history!
Expect more on this topic from us soon. In the mean time, enjoy the simplified build process.
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.
Well, what all this means for you is that we will be able to update things much quicker, and that life just got way easier for all you self hosters out there!
Let us know what else we can do to make life easier for you.
In the process of developing Exceptionless, we realized there was a lack of good, simple, open source solutions for caching, queues, locks, messaging, jobs, file storage, and metrics when building scaleable applications.
We tried an open source Redis cache client for caching, but it went commercial (expensive) and there wasn't any in-memory implementations. For the message bus, we looked at NServiceBus (good product, high cost, not open source friendly) and MassTransit (local setup a pain, Azure support lacking), but were left disappointed. For storage, we simply could not find a solution that was decoupled and supported in memory, file storage, or Azure Blog Storage.
So, naturally, we built our own!
Meet Foundatio - your key to painless, scalable development and testing for your app! Let's take a look at some examples, below.
Below are small examples of what is possible with Foundatio caching, queues, locks, messaging, jobs, file storage, and metrics. We hope you find these explanations and samples useful, but please let us know if you have any questions or comments.
Foundatio provides four cache implementations, all derived from the ICacheClient interface, that save you expensive operations when creating or getting data by allowing you to store and access the data super fast.
For Exceptionless, we use RedisHybridCacheClient to cache users, organizations, and projects, which has a huge performance boost since we don't have to serialize the item if it's in local memory cache.
We use queues, along with Foundatio Storage (below) to queue events for Exceptionless. Using both allows us to keep payloads small and limit system load.
Foundatio Queue Example
usingFoundatio.Queues;
IQueue queue =newInMemoryQueue();
queue.Enqueue(newSimpleWorkItem{ Data ="Hello" });
To ensure any resource is only accessed by one consumer at any one time, use one of the two Foundatio Locks implementations, each derived from the ILockProvider interface. These implementations include CacheLockProvider and ThrottlingLockProvider. These providers take an ICacheClient, ensuring code locks across machines. Read more on the repo.
We use locks to only run single instances of jobs (below), and more.
Run jobs by calling Run() or passing it to the JobRunner class, which allows you to easily run jobs as Azure Web Jobs. All jobs are required to derive from the JobBase class.
Around here, we use the jobs feature for processing events, sending mail messages, and more. Some jobs, such as our DailySummaryJob, which we only want to run once, also use locks (above) to only run one instance.
Metrics are used throughout the Exceptionless system to provide insight into how the system is working and get external alerts if events are not processing or report how much load is on the current system.
If you would like to contribute to Foundatio, clone the repo and open the Foundatio.sln Visual Studio solution file to get started. Let us know if you have any questions or need any assistance.
As with any development project, Foundatio is a work in progress and we will continue developing it, however it is extremely stable and used in production by various companies, including Exceptionless (obviously). The next major steps are full Async support (some implementations already have it), and vnext support.
Naturally, we want to know what you think and what we should work on next, so please let us know!
Over the past few weeks, we have taken all the existing documentation on the docs subdomain and migrated it over to the respective GitHub repo.
We also pulled out worthy examples, demos, and tutorials from past blog posts and created pages for those, so information is in a more centralized area that is hopefully easier for our users to locate and utilize.
As new features, demos, examples, and clients come online, expect to see them added to the new documentation system and updated regularly.
This documentation contains all the documentation and details/usage for the platform's features and dashboard/ui. That includes information on project settings, security, API usage, filtering & searching, email notifications, bulk actions, frequently asked questions, how to contribute to the project, and the basic requirements to run the platform.
And, of course, you can get to the documentation for the individual clients (below) from this primary site as well.
Basically, you can always start here and branch out to whatever client or feature you're looking for documentation for.
As you may have guessed, this documentation site resides within the Exceptionless.NET repo and contains .NET-specific info, examples, demos, and tutorials for different features. If you're a .NET user, this should be where you look for examples if you're just getting started or solutions to troubleshooting problems if you've run into a snag.
The newest addition to Exceptionless, our JavaScript / Node.js client, needs a place for documentation too! Naturally, that place is within the Exceptionless.JavaScript repo! Here you'll find JavaScript-specific details, examples, and tutorials for things like configuring the client, sending events, self hosting, RequireJS, SystemJS, TypeScript, Express, and client configuration values.
We really hope this helps users familiarize themselves with the JavaScript client and get the most benefit out of it. We know its flexibility will help a ton of developers get their apps in order.
Do you know something that could use a better example, description, or tutorial? Have you put together something that would add value for other Exceptionless users if added to the documentation? Shoot any thoughts, examples, feedback, or requests our way and we'll make sure it gets handled properly.
It's always great to hear back from our users, whether it's a simple "atta boy" or a full page's worth of feedback.
Today we thought it would be nice to share a recent case study from one of our users that lives in the scientific laboratory and processing equipment space. Their company is a leading provider of stirring, mixing, and kneading machines, among other things, that are used by the pharmaceutical, chemical, food, paint, cosmetic, and plastics industries around the world. Neat!
"It helps me zero in on what could be the issue, AND have a documented track of what all errors I’ve seen."
When a user hits a certain number of sessions with Exceptionless, we shoot them a quick survey email asking them a few things that might help us improve our product and get a better feel for how our users are utilizing it's features.
In a nutshell, we ask the following:
What's the number one customer-facing bug Exceptionless helped you squash?
Were you surprised at the initial results of using Exceptionless for the first time? How many errors were you seeing?
What is the number one internal bug you were able to track down with Exceptionless?
If you had one feature you'd like us to add to Exceptionless, what would it be?
"I’d say that Exceptionless helps me find all the bugs which I’d have to spend more time on zeroing in on, faster."
The user was gracious enough to provide us with the following answers to the above general questions.
"Well, since our application is not yet released to the customer, I’m using Exceptionless to report bugs/crashes which I encounter routinely while testing the UI. It helps me zero in on what could be the issue, AND have a documented track of what all errors I’ve seen."
"Since Exceptionless is being used by me DURING development, it’s not surprising at all! 🙂 Maybe 4-5 bugs per day in sporadic bouts of crashes. Sometimes no bugs for a long time!"
"More than ONE major bug, I’d say that Exceptionless helps me find all the bugs which I’d have to spend more time on zeroing in on, faster."
"Support for snapshots (user reviewed), memory dump files is my number ONE feature request."
"Will update you on this once I release to customers. But it’s nice having the confidence that Exceptionless will help me squash bugs AS they get reported, instead of having to wait for that brave customer who girdles up his loins and takes up the onerous task of finding out how to report bugs and whom to report them to! Most customers would have just cursed me and gone ahead with workarounds! :)"
Consider this for a second: If every user provided 10 minutes of feedback on the products they use and love, the owners of those products/programs/tools/experiences would be able to improve them much faster and with drastically more focus and drive.
With that said... give us 5, 10, or maybe 15 minutes and answer the above questions for us in the comments below. We're no Microsoft - your voice will be heard, and any suggestions will be strongly considered/debated. Who knows - maybe we work on your feature request next!
We realize you may have sensitive data that could potentially be transmitted within an Exceptionless error, event, log message, etc.
In order to help make sure that information is not compromised, we have included a simple comma delimited field for data exclusions on the Exceptionless Project Settings page where you can add field names that you would like to be excluded from any error or event that is reported.
Once set, the excluded field data is discarded at the client level and never hits our servers.
One potential example is, let’s say, user addresses. Perhaps you have multiple user addresses that may get transmitted, and you want to exclude some or all of them. Maybe you have "HomeAddress" and "WorkAddress".
To exclude only "HomeAddress" data, you would just add HomeAddress as an exclusion. The same goes for "WorkAddress."
To exclude both, you could either add HomeAddress and WorkAddress, separated by a comma, or you could use *Address if those were the only two fields that ended with "Address." If those were the only fields that contained "Address" at all, you could use *Address*.
It's easy stuff, but powerful enough to be aware of and use where possible to ensure security.
We are sure you can come up with some creative exclusions for various types of sensitive data. At Exceptionless, we exclude any and all relatively sensitive data to protect our users as much as possible.
Obviously, things like passwords, credit card info, etc are encrypted, but other fields such as addresses, etc, are also relatively sensitive information that typically doesn’t need to be displayed.
What do you exclude? Do you have any feedback about this Exceptionless feature? Let us know!
Did you know there are customizable server/client configuration values within your Exceptionless Project's settings? Well now you do - and knowing is half the battle!
These project level settings are a dictionary of key value pairs (string key, string value). They are defined server-side and automatically pushed to the client when they are updated. Using this feature allows you to control what you send without redeploying your app, which we think is pretty cool!
You can use these client configuration settings for a variety of applications, including:
Controlling data exclusions for protecting sensitive information
Enabling / Disabling user signups
Turning logging on or off
Enabling analytics
Controlling information collection
And many more! You can send any key value pair to control whatever you like within your app.
Let's take a look at a JavaScript and .NET client usage example to get your rolling with this feature.
Before we get started with more of an explanation and an example, we need to add a new key and value. To do so, we go to Admin > Projects in our Exceptionless Dashboard, select the project we are working on, then go to the "Settings" tab.
This is where we can add a "New Client Configuration," which simply consists of the key and value. For the example below, we'll add the (fictional) enableLogSubmission key and set it to true.
When your application first starts up, your project's client configuration settings are read (from storage) and applied.
If a setting value doesn’t exist in storage, it will be retrieved from the server after the next event submission occurs. We do this by inspecting the response headers and comparing a response header that contains the setting version. If the version doesn’t match the saved setting value then we make a request to get the setting and apply it.
It’s worth noting that we allow you to define your own default settings and overwrite them with server side settings, which we'll include in our example.
In the example below, we will dynamically turn on or off the log event submissions at runtime without restarting the app or logging into the server to change configuration settings.
Why, you ask? Maybe we don't care about log submission until there is a really tough issue to solve. With Client Configuration Values, we can simply turn it on only when needed.
We’ll assume for this example that we are using the enableLogSubmission key we created above to control this. This setting is made up and doesn’t have to exist server side since we will be providing a default value client side. This allows us to define it via the project settings page at anytime and change our applications behavior.
To control this we will be registering a new client side plugin that runs every time an event is created. If our key (enableLogSubmission) is set to false and the event type is set to log, we will discard the event.
ExceptionlessClient.Default.Configuration.AddPlugin("Conditionally cancel log submission",100, context =>{ var enableLogSubmission = context.Client.Configuration.Settings.GetBoolean("enableLogSubmission",true);
// only cancel event submission if it’s a log event and enableLogSubmission is false if(context.Event.Type == Event.KnownTypes.Log &&!enableLogSubmission){ context.Cancel =true; } });
You might notice that we are calling the GetBoolean method to check the enableLogSubmission key. This is a helper method that makes it easy to consume saved client configuration values. The first parameter defines the settings key (name). The second parameter is optional and allows you to set a default value if the key doesn’t exist in the settings or was unable to be converted to the proper type (e.g., a boolean).
.NET Helpers
Above, we used the GetBoolean helper method. In the .NET client, we have a few helpers to convert string configuration values to different system types. These methods also contain overloads that allow you to specify default values.
Helper List
GetString
GetBoolean
GetInt32
GetInt64
GetDouble
GetDateTime
GetDateTimeOffset
GetGuid
GetStringCollection (breaks a comma delimited list into an IEnumerable of strings)
The same functionality above can also be achieved using our new JavaScript Client.
exceptionless.ExceptionlessClient.default.config.addPlugin('Conditionally cancel log submission',100,function(context, next){ var enableLogSubmission = context.client.config.settings['enableLogSubmission'];
// only cancel event submission if it’s a log event and // enableLogSubmission is set to a value and the value is not true. if(context.event.type ==='log'&&(!!enableLogSubmission && enableLogSubmission !=='true')){ context.cancelled =true; }
If you would like to be notified when client configuration settings are changed, you can subscribe to them using something like the below code. This is useful when you want to update your application in real time when settings change server side.
These Client Configuration Values are somewhat of a hidden Exceptionless gem, but we think they are power and that many of our users can find real value in using them to control the flow of information, specifically sensitive data.
If you have any questions or comments, please let us know. As usual, we're all ears!
Last week we announced the V1 release candidate for the Exceptionless JavaScript/Node.js Client. This week we've got official release notes for you! Have a look.
We built the Exceptionless JavaScript/Nodes.js Client with the past and future browsers in mind. Everything is testable via components injected on startup (via dependency injection), which means you can replace any component of the system to fit your specific needs.
Client is a full feature parity of our .NET clients, including:
Support for custom objects
Mark events as critical
Server side settings
Data exclusions
Plugins
and more...
Includes first class integration for third party libraries like AngularJS and Express
Everything you need to get up and running (including contributing/developing) can be found on the Exceptionless.JavaScript GitHub repo. JavaScript, Express, TypeScript, SystemJS, and RequireJS examples can be found in the example folder. As always, you can contact us via an in-app message for help, or submit an issue on GitHub with bugs, feedback, etc. We're here to make sure you get things working properly so you can take full advantage of Exceptionless!
If you've been following along the last few weeks, you know we've been working hard to get the new JavaScript Client up to speed and ready for a version 1 release.
We think we're there!
Whether you're a JavaScript or Node.js user, you'll be able to enjoy the same full featured exception and event reporting platform that our primary .NET client offers, with fewer platform specific boundaries.
We have been doing extensive testing over the course of the last month, which has allowed us to identify issues and inefficiencies throughout. Each of those has been addressed with several improvements and fixes, leaving us with a much faster, more stable client.
Many of the tweaks we made were related to IE9 and Node. Those issues have been resolved and things are working well now. In addition, we further increased performance by shrinking the library size fairly drastically.
Moving forward, we will just be working on bug fixes related to user-reported issues as usage picks up.
We've already released a few blog posts (linked below) that detail how to get up and running, but please visit the Exceptionless.JavaScript GitHub Repo for the most up-to-date documentation.
JavaScript Users can find installation, configuration, usage details and examples here.
We're suckers for feedback, so let us have it whether good, bad, or indifferent. Bugs, etc should be reported on the GitHub Issues page, but feel free to shoot us an in-app message, email, etc and let us know what you think and if you had any issues getting everything working.
We're getting closer and closer to version 1.0 of our JavaScript client, and we wanted to give everyone a demo of installation, configuration, and usage.
If you're using Node.js, make sure to check out last week's blog post for Node specific examples. Otherwise, continue reading for JavaScript examples.
As you read and begin playing with the Exceptionless JavaScript client, please make note of any feedback, bugs, etc, and submit a GitHub issue so we can fast track version 1.0 - we surely appreciate it!
Install the package by running bower install exceptionless
Add the Exceptionless script to your HTML page. We recommend placing the script at the top of the document to ensure Exceptionless picks up and reports the absolute most potential exceptions and events.
Configuration of the Exceptionless JavaScript client can be accomplished a variety of ways. We list the common ways below, but make sure to check the Exceptionless.JavaScript GitHub repo for the most up to date documentation if you run into any problems using this example code. NOTE: The only required setting you need to configure is the client's apiKey.
Unhandled exceptions will automatically be sent to your Exceptionless dashboard once the JavaScript client is configured properly. In order to send additional events, including log messages, feature usages, and more, you can use the code samples below and check the Exceptionless.JavaScript GitHub Repo for the latest examples and documentation.
var client = exceptionless.ExceptionlessClient.default;
client.submitLog('Logging made easy');
// You can also specify the log source and log level. // We recommend specifying one of the following log levels: Trace, Debug, Info, Warn, Error client.submitLog('app.logger','This is so easy','Info'); client.createLog('app.logger','This is so easy','Info').addTags('Exceptionless').submit();
To manually send events other than the automatically reported unhandled exceptions, you can use our fluent event builder API.
The below example demonstrates sending a new error, "test," and setting the ReferenceID, Order and Quote properties, Tags, Geo, UserIdentity, and marking it as Critical.
var client = exceptionless.ExceptionlessClient.default;
try{ thrownewError('test'); }catch(error){ client.createException(error) // Set the reference id of the event so we can search for it later (reference:id). // This will automatically be populated if you call client.config.useReferenceIds(); .setReferenceId('random guid') // Add the order object (the ability to exclude specific fields will be coming in a future version). .setProperty("Order", order) // Set the quote number. .setProperty("Quote",123) // Add an order tag. .addTags("Order") // Mark critical. .markAsCritical() // Set the coordinates of the end user. .setGeo(43.595089,-88.444602) // Set the user id that is in our system and provide a friendly name. .setUserIdentity(user.Id, user.FullName) // Submit the event. .submit(); }
We built the JavaScript client to be full featured and allow you to report and log all the data our other clients do. It has a fluent API, as mentioned above, and is ready to rock and roll.
We wire up to the window.onerror handler by default, in order to send unhandled exceptions to your Exceptionless dashboard automatically.
Finishing off the Exceptionless JavaScript client features, every event also includes request information.
A few screenshots of an individual event can be found below.
Request Details
Sample
We have put together an example that you can use to get an idea of how everything works. It is available on the GitHub Repo.
Edit the HTML file in the root example folder and replace the existing API Key with yours. Also, comment out the serverUrl.
Open the HTML file in your browser
Open the console so that you can see the debug messages that the example generates
Click the buttons on the page to submit an event
Troubleshooting
Calling client.config.useDebugLogger(); to enable debug logging is recommend and will output messages to the console regarding what the client is doing. Please contact us by creating an issue on GitHub if you need help or have any feedback regarding the JavaScript client.
As we move forward towards version 1.0 of our JavaScript client, we are looking for any and all feedback, so please don't hesitate to let us know what you think, report a bug, etc.
Last week we announced our full featured JavaScript client, and we're super excited about releasing a version 1.0 soon.
This week we'd like to put more details out there on the Node.js version of the JavaScript client, including installation, configuration, and usage. We've also set up an Express.js sample app that you can spin up locally to play with things.
You can configure the Exceptionless client a few different ways for Node.js. The below is the most common way, but for more configuration options and documentation, visit the Exceptionless.JavaScript GitHub repo. NOTE: The only required setting you need to configure is the client's apiKey.
Set the apiKey on the default ExceptionlessClient instance.
var client =require('exceptionless.node').ExceptionlessClient.default; client.config.apiKey ='API_KEY_HERE';
Once configured, the Exceptionless Node.js JavaScript client will automatically send your dashboard any unhandled exceptions that happen in your application. If you would like to send additional event types, such as log messages, feature usages, etc, take a look at the below examples.
var client =require('exceptionless.node').ExceptionlessClient.default;
client.submitLog('Logging made easy');
// You can also specify the log source and log level. // We recommend specifying one of the following log levels: Trace, Debug, Info, Warn, Error client.submitLog('app.logger','This is so easy','Info'); client.createLog('app.logger','This is so easy','Info').addTags('Exceptionless').submit();
In addition to automatically sending all unhandled exceptions, you can also manually send events to Exceptionless using our fluent event builder API.
The below example demonstrates sending a new error, "test," and setting the ReferenceID, Order and Quote properties, Tags, Geo, UserIdentity, and marking it as Critical.
var client =require('exceptionless.node').ExceptionlessClient.default;
try{ thrownewError('test'); }catch(error){ client.createException(error) // Set the reference id of the event so we can search for it later (reference:id). // This will automatically be populated if you call client.config.useReferenceIds(); .setReferenceId('random guid') // Add the order object (the ability to exclude specific fields will be coming in a future version). .setProperty("Order", order) // Set the quote number. .setProperty("Quote",123) // Add an order tag. .addTags("Order") // Mark critical. .markAsCritical() // Set the coordinates of the end user. .setGeo(43.595089,-88.444602) // Set the user id that is in our system and provide a friendly name. .setUserIdentity(user.Id, user.FullName) // Submit the event. .submit(); }
If you are using Express.js to develop a web application, you can add Exceptionless and start collecting unhandled errors and 404s very quickly. To start, just add the following middleware to the bottom of your middleware definitions.
// This middleware processes any unhandled errors that may occur in your middleware. app.use(function(err, req, res, next){ client.createUnhandledException(err,'express').addRequestInfo(req).submit(); res.status(500).send('Something broke!'); });
The JavaScript/Node.js client is full featured, will collect all the information our other clients collect, and has a fluent API as shown above.
By default, we wire up to the processes' uncaught exception handler to automatically send any unhandled exceptions to your Exceptionless dashboard. We also submit a log message if your app doesn't shut down properly via inspecting the exit code, which is very useful and lets you know what your app is doing. Additionally, any queued up events are processed and sent before your app closes.
Each event contains environment and request information, as well, rounding out the complete list of Exceptionless features that we have made available via the JavaScript client, making it a great error and event reporting/logging solution for all your Node.js projects.
Environment Details
Sample Express.js App
We have built a quick Express.js sample app that you can play around with to get an idea of how the Node.js JavaScript client works with Exceptionless.
We recommend enabling debug logging by calling client.config.useDebugLogger();. This will output messages to the console regarding what the client is doing. Please contact us by creating an issue on GitHub if you need assistance or have any feedback for the project.
As we move forward towards version 1.0 of our JavaScript client, we are looking for any and all feedback, so please don't hesitate to let us know what you think, report a bug, etc.
Version 2.0 was a pretty big rewrite for us, and we're happy with how everything played out, but that doesn't mean we're done!
In the process of developing Exceptionless, we realized there was a lack of good, simple, open source solutions for caching, queues, locks, messaging, jobs, file storage, and metrics when building scaleable applications.
The 
It's always great to hear back from our users, whether it's a simple "atta boy" or a full page's worth of feedback.
We realize you may have sensitive data that could potentially be transmitted within an Exceptionless error, event, log message, etc.
Last week we announced the 
