JSNLog - a new way to do client side logging integrated with ASP.NET and MVC

• JSNLog Nuget package
• JSNLog Detailed Documentation

JSNLog lets you put loggers in your JavaScript code, configure them in your web.config, and capture their output in your server side logs. It supports NLog, Log4Net, Elmah, Serilog, and anything else via a Common.Logging adapter.

The main goal of this article is to provide an overview of where the JSNLog project is going, and to get your feedback  on whether this would be useful to you, and how it could be improved.

This article shows:

• What client side logging is, and how it can help reduce client side production bugs (skip if you're familiar with client side logging)
• Issues with traditional client side logging packages;
• JSNLog features that address these issues. 

The main goal of this article is to provide an overview of where the JSNLog project is going, and to get your feedback  on whether this would be useful to you, and how it could be improved.

What is client side logging

Client side logging is very similar to server side logging with packages such as  Log4Net or NLog. 

Using a client side logging package such as JSNLog, you create loggers in your JavaScript code and use them to write a log message when something interesting happens. You can set severity levels to manage what loggers are active, use appenders to store log messages, etc. For example:

JL("clientsidelogger").error(
    "Something interesting happened");

One major difference is that client side log messages need to be sent over the Internet  to your server for storage, creating more load on your server. One of the reasons to introduce JSNLog was to make it easier to manage this load. 

Using client side logging to reduce production bugs

Having reliable bug free code on the client is just as important as having this on the server (ask your manager or client if in doubt). Unfortunately, client side programming throws up a few challenges here:

• JavaScript is great for quick scripting, not so good for large scale maintainable software;
• Browser compatibility issues.

No matter how careful your programming or how thorough your pre-deployment testing, you can't guarantee there will be no bugs in your production code. 

One reliable way to reduce production bugs over time is to use logging:

1. Catch all exceptions and log them, so you at least know when things go wrong in your production code:

   try {
       ...
   }
   catch(err) {
      JL().fatalException("something went wrong!", err);
   }

2. Don't forget to set the global onerror handler, to catch uncaught exceptions:

   window.onerror = function (errorMsg, url, lineNumber, column, errorObj) {
       JL("onerrorLogger").fatalException({
           "msg": "Exception!", 
           "errorMsg": errorMsg, "url": url, 
           "line number": lineNumber, "column": column
       }, errorObj);
           
       return false;
   }

3. Also include checks in your code for anomalous situations  (why):

   if (shouldBePositive < 0) { throw "shouldBePositive is negative!"; }

4. To make it easier to solve exceptions in your client side code, introduce additional loggers in your code to get additional information. Normally those loggers are disabled - you'd only enable them when needed.

   function DoSomething(a, b, c) {
       JL("DoSomething").trace("a=" + a + ",b=" + b + ",c=" + c);
       ...
   }

5. With all this in place, you have a good chance of finding production bugs and solving them, before they lead to embarrassing bug reports or angry managers.

Issues with traditional client side logging packages

There are already many client side logging packages. However, they tend to suffer from these issues:

1. Lack of server side integration -  No out of the box support for receiving and storing log messages on the server. No ability to configure client side loggers in your web.config.  No ability to see which client side and server side log messages relate to a given request.

    

2. Few options to manage the flow of log messages over the Internet - Sending log messages over the Internet is relatively expensive. However, traditional packages offer few or no options to for example batch log messages or to have only a proportion of clients send log messages.

    

3. Lack of client side specific options for enabling loggers - If a bug only affects IE7, you want to be able to enable a logger for only that browser.

    

4. Lack of performance measuring - If an AJAX call takes too long to retrieve required data, you want to know about this.

    

JSNLog Features

The  JSNLog project (JavaScript .Net Logging)  came about to provide a package that is truly geared towards client side logging,  and that integrates seamlessly with your server side logging for your ASP.NET or MVC site.

JSNLog is already available, but not all planned functionality has been implemented yet. The implemented and planned features are below. This list will be updated as more features get implemented.

Would these features be useful to you? Or is this headed in the wrong direction? Say what you think.

Full JSNLog documentation

0. Core Functionality

1. Integration with server side logging

2. Managing flow of messages over the Internet

3. Client side specific options

4. Performance measuring

Your Feedback

Does all this make sense? Or is it a complete waste of time? How could this be improved? Please leave your ideas here.

If you like this article, please vote for it.