The end of the console.log

I’ll admit it. I use console.log more than I should. Want to see if your function was called? Type a console.log(‘My function was called’) into your code. Need to debug an undefined message from your server? Stick the parameter in a console.log(‘The parameter is: ‘, param) and see what “it” is.

Why log it rather than console log it?

Console logs serve their purpose in giving you a quick response, but not much else. On my last big long-term project, we needed to log the requests, the stack, and responses. In fact, that was a business requirement for the project. The client needed a record of what was happening with its very expensive buy from us. The logs provided a written record of what was occurring. But my biggest “a-ha” moment happened when a bug was noted, and rather than console logging it, my coworker said, “Let’s check the logs.” I was perplexed. Why?

His thinking was that if there was a bug, the logs would record it.

The other reason why one should log is that it’s best practice in order to maintain a healthy server and to keep abreast about your server’s operations. Console logs can’t tell you latency, response time, warnings; logs can. A console log can only give you a moment’s snapshot. A log can tell you a story.

Logs are like the story of your app: the have a beginning, a middle, and an end

Welcome to Logging with Bunyan

Bunyan logging is free, fast, and easy to get started with. Its an inline tool that also comes with a CLI tool for quick parsing through log files.

The easiest way to get started with Bunyan is to throw a into function to see what appears.

Screen Shot 2017-03-08 at 10.24.29 PM

This is what shows up in your terminal

Screen Shot 2017-03-08 at 10.25.30 PM
Look at all that yummy info

At first, it looks like a lot of superfluous info, but when you use the Bunyan library correctly, it can help you trace the problems with your call stack and provides a record that your client can look through to see how the app is performing.


Streams go hand in hand with logging best practices. According to the Bunyan authors, the level descriptions of your logs should include at minimum: fatal, error, and warn. Bunyan allows for the creation of streams that will show the developer different types of logging levels.

When working in Node, I like to use the info level so I can see what the request looks like coming in. Using the streams, I can log at the very verbose level to see what services have been hit and where it exactly it errored out. Often times, this will guide me to the file I need to fix.

Log Rotation

Bunyan offers the ability to rotate out logs on a daily or at a certain time period. This will avoid having your IDE or text editor crash because of the large log files. Log rotation is as simple as adding it as a key-value pair in the stream object.

Final Thoughts

Console logs are good for development because they are quick to throw up in the code to debug your API, but they don’t provide the info you might need to thoroughly diagnose the problem. When working with complicated APIs, Bunyan provides the detailed info a developer needs to see what is being requested to an API and what the response is. Try it out today!


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s