What To Look for in a Logging Framework

If you’ve spent any amount of time in the software industry, you’ve probably bumped up against logging. Maybe you first encountered it as a way to debug your program as you worked, printing “you are here” messages. Go much beyond that, especially in 2017, and your logging efforts likely graduate to the use of a logging framework.

What Is a Logging Framework? Let’s Get Precise.

So what marks this distinction? When do you go from newbie printing out “got into the Calculate() method” to user of a logging framework? To understand that, let’s define logging framework.

A logging framework is a utility specifically designed to standardize the process of logging in your application. This can come in the form of a third party tool, such as log4j or its .NET cousin, log4net. But a lot of organizations also roll their own.

You have to go beyond just standardizing, however, to qualify as a framework. After all, you could simply “standardize” that logging meant invoking the file system API to write to a file called log.txt. A logging framework has to standardize the solution by taking it care of the logging for you, exposing a standard API.

To get more specific, we can conceive of a logging framework encapsulating three main concerns: recording, formatting, and appending. When you want to capture runtime information about your application, you start by signaling what to record. Then, you determine how to format that information. And, finally, you append it to something. Classically, this is a file, but you can also append to RDBMS tables, document databases, or really anywhere capable of receiving data.

If you have a piece of code dedicated to solving these problems, you have yourself a logging framework.

Should You Use an Existing Logging Framework or Build Your Own?

Now that we have precision around the definition, let’s examine your options for making use of a logging framework. Notice that I frame the question in terms of which one you should pick, rather than whether or not you should use one. I do that because production applications should most definitely make use of logging frameworks. Without them, you’re flying blind about what your application does in the wild.

The question then becomes whether you should use an existing one or write your own. Use an existing one — full stop. It’s 2017, and this is a well solved problem in every tech stack.  You shouldn’t write a logging framework any more than you should write your own source control tool or build a bug tracker. Others have built these, and you can have them cheaply or freely. Stick with solving problems in your own domain, rather than reinventing wheels.

So you need a logging framework, and you should use an existing one. The question then becomes “which one?” Which logging framework should you use? I won’t answer that outright, since it will depend on your stack and your needs. Instead, I’ll offer guidance for how to choose.

Read More

What Is Log Aggregation and How Does It Help You?

In order to understand the idea of log aggregation, you need to understand the pain it alleviates. You’ve almost certainly felt this pain, even if you don’t realize it.

Let’s consider a scenario that every programmer has probably experienced. You’re staring at some gigantic, dusty log file, engaging in what I like to think of as “programming archaeology.” And you have a headache.

A Tale of Logger Woe

It started innocently enough. A few users reported occasionally seeing junk text on the account settings screen. It’s not a regular bug, and it’s not particularly important. But it is embarrassing, and it seems like it should be easy enough to track down and fix. So you start trying to do just that.

You start by searching the database for the junk text in their screenshot. You find nothing.  Reasoning that application code must somehow have compiled the text in production, you figure you’ll head for the log files. When you open one up, and it crashes you text editor. Oops. Too big for that editor.

After using a little shell script magic to slice and dice the log file, you open it up and search for the text in question. That takes absolutely forever and yields no results. So you start searching for parts of the text, and eventually you have some luck. There’s a snippet of the text on line 429,012 and then another on line 431,114, with all sorts of indecipherable debug junk in between.

But you can’t find all of the text. And you have a headache. You then realize there’s a second log file for certain parts of the data access layer from before the Big Refactoring of ’15, and the rest of the text is probably in there. Your headache gets worse.

Read More

Company Culture: Actions, not just words

I recently joined the marketing team at Scalyr. I left my previous role last fall and took some time off. After a bit of travel, I spent the last few months exploring what I wanted to do next. In my next opportunity, I wanted a product first company and a culture that aligned with my values. Throughout my search, I met with several dozen people and companies, some casual catch-ups and others more formal interviews. I wanted to share some of the lessons I learned in my process that ultimately made me believe Scalyr was the right place for me.

Read More

CareerBuilder Resolves Customer Issues 5x Faster with Scalyr

We are excited to have CareerBuilder as a customer here at Scalyr. I recently sat down with Leon Chapman, Director of Cloud Operations at CareerBuilder, to learn more about their decision to use Scalyr and the impact the product is having on their teams and customer experience.

 

 

CareerBuilder chose Scalyr as their log management tool. After moving to the cloud two years ago, the team was looking to consolidate tools across their 250 person engineering organization. As a customer facing product, being able to identify issues quickly helps CareerBuilder deliver a better customer experience for the millions of people who use their products and services each day.

In particular, CareerBuilder found that when comparing Scalyr to other products, Scalyr beat the competition in:

  • Speed
  • Performance
  • Ability to scale without needing to manage infrastructure

Read More

Support Driven Development: Listen now so you don’t hear it later

Here at Scalyr, we’re big fans of Complaint-Driven Development, which I’ll summarize as “focus engineering effort on fixing the things users actually complain about.” We especially focus on issues that generate support requests, with such success that, as CEO, I’m still able to personally handle the majority of frontline support – even as we head toward eight-digit annual revenue.

An important consideration is that support requests cost money even if they aren’t your (product’s) fault. In this post, I’ll explore five common sources of support requests relating to the first piece of Scalyr software most users touch – our log collection agent and how we’ve sometimes had to think outside the box to address them. None of these were bugs, exactly. (We’ve had those as well, but you don’t need to read a blog post to know it’s a good idea to fix bugs.)

Arguably, none of these issues were “our fault.” But they generated a significant fraction of our support tickets. By eliminating them, we’ve reduced support costs significantly. Even more important, we’ve increased the probability that a user’s first experience with Scalyr is positive, especially for those users (a majority!) who will bounce off of a new product at the first sign of trouble, without bothering to ask for help.

Read More

451 Research Covers Scalyr

“For Scalyr, it’s about speed, scale, and simplicity in log management,” is the title of 451 Research’s recent report on Scalyr. Nancy reached out to us to discuss our product a few weeks ago. We gave her a demo and spoke a number of times in detail about Scalyr. I was excited when I saw that she had decided to write about us and I’m even more excited to share the content of that report with the greater Scalyr family.

Click here to read Nancy’s report. 

If you’re looking for more information on Scalyr, don’t hesitate to contact us directly or to sign up for a trial.

Please Review Scalyr (And Get Free Stuff)

To help get the word out about Scalyr, we’re looking for people to write honest reviews of our product on GetApp and Capterra. If you take the time to write a review on one of those sites we’ll send you a $20 gift card for either Starbucks or Amazon (please see details below).

To write a review on GetApp you need to have a LinkedIn account and be willing to sign into GetApp with it, but your review can be anonymous once posted. For Capterra you need to give your email address and the name of the company where you used the product that you are reviewing, and finished reviews will include your name and company name.

We are only looking for reviews from current Scalyr customers or Scalyr trial users who have uploaded data and spent more than two hours using Scalyr. In order to qualify for the gift cards, please send the following information to contact@scalyr.com:

  • a link to the review in question
  • your name and the email address you use to log into scalyr
  • the email address where you’d like us to send the gift card code

We’ll take honest reviews anytime, but this particular offer of a gift card when you review us expires on February 17th, 2017. All gift cards will be issued for USD $20 from the US Starbucks or US Amazon website.

To write a GetApp review, please start here.

For Capterra, please click here. 

Thanks in advance!

 

November 2016 Product Updates: All in on the New UI…

Our new UI is now the default

Scalyr's New UI

We flipped the switch, and our new UI is now the default. The original UI will still be available for a while, but to access it, you’ll have to click on the settings menu (upper-right corner of the window) and choose “Flip To Classic UI”.

If there’s a reason you prefer our original UI, please let us know! We’re working hard to make this an easy transition.

The log timeline chart now includes both line and bar graphs

Scalyr's Hybrid Timeline Chart

By popular demand, we’ve superimposed the old “events per second” line graph over the bar chart. This allows you to see fine-grained spikes and changes in message frequency. Note that the Y axis is scaled for the bar chart only.

Read More

Scalyr Announces $2.1M Seed Round To Reinvent System Visibility

A few years ago, we set out to rebuild server and log monitoring from the ground up. Today marks a new and exciting chapter in the story. To tell it properly, let me take you back to a simpler time: the year 2005.

I had just co-founded Writely — “The Web Word Processor!” — and usage was skyrocketing. We ran the whole thing on four leased servers in Texas. It was the clunkiest setup you’d ever seen, but there were few moving parts and it wasn’t much trouble to manage.

Within a year, we were acquired by Google, merged with a spreadsheet app, renamed “Google Docs”, and relaunched on Google infrastructure. The new system was infinitely more scalable, but quite complex. We depended on a slew of independent services: load balancing, data storage, user identity, email, spell checking, and more.

Read More

“Benchmarking in the Cloud” talk online

Amazon has posted the talks from re:Invent on YouTube. The video from the EBS session is here. My brief presentation on “Benchmarking in the Cloud” starts at the 30:16 mark (direct link). You can download my slides here.

It was a terrific conference. The pace of development, and just plain enthusiasm and energy, around cloud services in general and AWS in particular is just amazing. I do recommend checking out some of the talks if you have time.