This post originated from an RSS feed registered with .NET Buzz
by Christian Horsdal.
Original Post: Shipping Error Logs from an Angular App
Feed Title: Horsdal
Feed URL: http://www.horsdal-consult.dk/feeds/posts/default
Feed Description: A blog that will be about code, architecture, design, and .NET.
By populardemand1 I'm writing this post describing how I've gone about implemented log shipping in an Angular app. It's what worked for me. YMMV.
Why?
The reasons for logging messages in an SPA are the same as in any other applications: To gain insight into what happens in the app at run time. The problem with client side logging is that it is hard to get at once the app is in production - that is, once it is running on a machine you (the developer) do not have access to. Collecting the log messages on the client side and sending them back to the server lets you put the client side log messages into a log store on the server, where they are available for analysis.
Client Side
In my situation the SPA is written in Angular which provides a logging service called $log. The $log service can be used anywhere in application code and is also used by Angular itself to log stuff. So the messages written to $log are messages I would like to ship back to the server. Out of the box $log simply logs to the console. Therefore I wrap $log in a decorator and tell Angular to inject my decorated $log wherever $log would otherwise be injected. My decorator stores all log messages along with the log level - error, warning, information, debug - in an array an then delegates to the default $log implementation. That way log messages are both stored for shipping at a later point in time and logged to the console immediately. The decorator also adds a method called shipLogs that sends the current array of log messages to the server and then clears the array on success. The decorator is set up like this:
The shipping of the logs can be done periodically - in my case every 10 seconds - using Angulars $interval service
This is not a fool proof process: There is no handling of situations where shipping takes more than 10 seconds, there is no guarantee that the shipping won't happen in parallel with other requests and thus compete for bandwidth and there is no guarantee that all log messages are shipped before the user leaves the app. But it works well enough for my particular case.
Server Side
The service side is exceedingly simply. The only point of interest is deciding how to log the client side logs on the server. I've decided to start out by degrading all client side log messages to information level on the server regardless of the level on the client. This is done because certain things - e.g. lost network - will cause error situations on the client - like failed ajax requests - even though they are not really errors seen from the server side - we cannot do anything about clients losing network. This is contextual and might be completely different in your situation. Furthermore I decided to log each batch of client side log messages in one go, in order to avoid spamming my server side log. Both of these decisions might change at a later stage once we have more insight into characteristics of the logs we get back from clients. As I said, the server side is simple, it boils down to a single simple endpoint:
That's it. Again YMMV.
1. OK 2 tweets doesn't constitute popular demand. But hey.
Previous Topic
