I recall working on a web project once when a senior developer came along and poked his nose into what we were doing. Before too long he helped us with a number of trouble spots in the project. Much to our annoyance he also insisted on building a logging tool into the app. We had so much work to do, who has time to deal with something as mundane as logging? Months later when the application crashed or had issues we would find ourselves checking the log files frequently. The importance of being aware of how your application is working is essential to the long term success of a project.
Our simple logging tool consisted of adding events to an ever growing file. Every day it grew bigger, becoming increasingly unwieldy as time went on. This is a common solution to tracking applications since you typically only use them when things go wrong. They contain so much valuable information though. You can find out who’s doing what and when. Perhaps the vast majority of your signups occur at a specific time of day. Or maybe they’re all coming from big cities or specific countries. Knowing intimately what’s going on with your application can not only tell you about problems that need to be fixed but can also give you vital information on how to improve it.
Tracking such information would require doing a lot more than tacking on a simple logging tool to one’s project. To build it properly would require building an entire separate project to gather all the data. That project now has a name- Loggr. It’s a web service that developers can connect to in order to track all the events of their applications. In so doing they’ll be able to monitor all the events of their application. They can track anything from errors, sales, to the day to day activities of their users.
The official description of Loggr’s service is, “A complete logging, analytics and notification system that will easily bolt on to your next software project.” Never mind their blatant attempt at power word lingo with the talk about bolting things. It integrates into your project and gives you insight, graphs, notifications, reports, and a variety to tools to manage what historically has been a single lengthy log file.
Loggr is not to be confused with Google Analytic which tracks web traffic, nor is it a syslog viewer. For that you can use Splunk. Its focus is high-level events and general usage of the end product. As such its configuration isn’t a simple code snippet that a marketing person can mindlessly tact on at the end of a project and then go back to drinking their latte. It fits squarely in the domain of developers who are comfortable making HTTP calls to Loggr’s API. It’s all very simple for those who know how to use the curl command and also avid Star Trek fans. Copious amounts of Doritos and soda tend to help as well.
Some of the ways Loggr can help is by visualizing trends over time. Single events may be isolated incidents, but if your spouse comes home late all the time you might have a problem. Or in the case of software projects you may notice trends with signups, errors, or other events. Loggr doesn’t help with tracking the comings and goings of one’s significant other. It is fully customizable to track all aspects of one’s project though. It’s also easy to configure and control what information is shared with various team members. For instance sales events may go to the marketing department and errors will be sent to developers.
Loggr is a fabulously built tool which virtually every project could benefit from. To that end it’s easy for development teams to manage multiple projects at the same time under the same account. I’ll always recall our initial hesitation to make logging capabilities a priority. Such foolishness is a mark of inexperience. On the other end of that spectrum is Loggr, which is the most robust, granular, and useful logging tool we’ve come across. Development teams can easily and readily build top logging features into their projects.