Speed: I haven’t independently tested the benchmarks, but I really like logging that doesn’t slow down the application. I want to be able to sprinkle logging generously in the application without slowing it down.
Simplicity: Take a look at the example below. We go from logging to the console, to logging in a database. The configuration and execution of log processing is entirely outside of the application.
Sticker: Because it has a logo that looks nice on a hex sticker? OK, not really. But @matteocollina presented this logger so effectively at NodeSummit, I asked for a sticker. Today, I’m glad to give something back to the community.
Let’s do a quick demo here, with a simple app that emits some logs:
With the nice pino API you have lots of options for emitting logs.
trace() details were below the current level, so were omitted.
This is detailed, but not super readable. If you are running something from the commadn line, the
pino global utility tidies up the output nicely—in color, even, if your console supports it.
pino-couch comes in. I’m going to set up a https://cloudant.com database
to store these logs (as I do in production), but you can also use a local or any other
couchdb instance (as I do when developing locally).
- First, create a database
- Next, give appropriate permissions.
pino-couch only needs to write to the database, it doesn’t need to read. Click the Permissions tab, then Generate API Key. Choose only the
_writer column for our new API key.
That’s actually it for configuration.
- Start up our app, but using
pino-couch. Use the APIKEY and PASSWORD that were generated above. And of course, your own ACCOUNT.
- The output is about the same. We chained on a
| pinoat the end to keep the output human-readable— that's optional.
Let’s take a look at the Cloudant dashboard again:
There’s our data!
Here are a couple of things you might do with your new logging pipeline:
Even something as simple as the following will get you timestamp-ordered documents.
Note that besides the
time field with epoch time,
hostname contains the current hostname. This is really useful for distinguishing logs from among a cluster of servers.
We’ve done this with great success. We were already pulling from another Cloudant DB, so it was easy to add the application logs.
And of course: