Optimizing Ruby Logging for Faster Debugging and Problem-Solving

article

#1

Originally published at: http://www.sitepoint.com/optimizing-ruby-logging-faster-debugging-problem-solving/

This article was sponsored by Loggly. Thank you for supporting the sponsors who make SitePoint possible.

In English, words that end with the ‘-ly’ suffix are usually classified as adverbs. Adverbs, for the grammatically challenged (and many of us devs are), modify verbs. Here are some examples with the adverbs bolded:


  • Jezebel runs quickly. (meaning, very fast)

  • The comment troll hides behind the anonymity of the internet stealthily. (meaning, like a wimp or in an undetectable manner)

Regardless of your feelings toward comment trolls, I hope these examples give you a basic understanding of the English adverb. This understanding is pertinent, as I am proposing the creation of a new adverb:

Loggly: adv. , recorded in a complete and extensible way. The prudent developer deployed the application loggly.”

I do not take this recommendation lightly. While any language is a living, breathing thing, adding new terms should be done only when a concept is found to be underrepresented in the existing idiom. After trying out the service offered by Loggly, I feel like such a concept has been found.

In this article I’m going to look at Loggly from the perspective of a Rubyist, explaining how to set up Loggly by adding it to my Leaderboards example. If you’ve read that article, then you know the Leaderboard is a simple Rails app hosted on Heroku. It does have some JavaScript behavior, which will allow me to show some client-side logging.

But first, let’s look at why you’d want to log in the first place, before moving into setting it up for our purposes.

Why Log?

For years, one of the many items omitted from most applications was an effective logging strategy. In most cases, logging offers the developer the only look into an application at runtime. Effective log usage and monitoring can help you predict an application’s future, allowing a proactive approach to maintenance as opposed to reactive.

However, when there’s a time crunch, the focus is about features, not logging. Logging and testing are two items you have to be disciplined about during development. Otherwise, your production experience is likely to go poorly.

Once you’ve accepted the need to log, there’s a new problem. Most applications have tons of moving parts: the operating system, web server, application, database, background jobs… just to name a few. All of these parts have one or more processes to log, and we haven’t even talked about clustering yet. How do you manage all the logs when you need to see behind the production curtain? Loggly can help with easy and extensible log search, an intuitive UI, agent-free deployment (I think that’s the best part) and a pay-as-you-go model.

Setting Up

Head over to Loggly and sign up for a free account. The various setup pages are handily made available once you log in and use your Loggly account’s subdomain (user.loggly.com), so you can follow along with my setup below.

When you land on the Source Setup page, you can easily see how to set up Loggly for operating systems, server-side apps, and client-side apps. I’ll run through setting it up with Rails and Angular, with the aim of adding Loggly to my Leaderboards example that I mentioned above. I’ve created a branch on the app repository for these changes here.

Continue reading this article on SitePoint


closed #2

This topic was automatically closed 91 days after the last reply. New replies are no longer allowed.