NodeJS Logging using Winston and Papertrail

Instructor: [00:00] We're going to enhance our login, which is using Winston in our Node app currently, and we're going to use a third-party tool called Papertrail. Papertrail is a hosted log management system, which has got a three tier.

[00:14] I like it, because it's quite simple to set up, and it has an integration with Winston. Going back to our Node application, we're going to go into our logger file, which is where we're customizing Winston. The first thing we're going to do is install the Winston Papertrail package.

[00:30] We don't need to set it to a constant. We can just require it. We don't need to add a new transport to Winston. This is one of the advantages of using Winston. It can have multiple transports, which are easy to configure.

[00:47] The host and port need to be given to you when you sign into Papertrail. When you first sign up to Papertrail and log in, you'll be given this initial page. It talks about adding your first system. When you click into that link, you'll see at the top here is a URL with a port number. It's this information you need for our Winston login.

[01:07] All this other information is not relevant for us in this instance. Going back into the Papertrail transport, I add my host. Then I add the port number. By default, Papertrail allows any system with these credentials to log to it.

[01:21] You can change that depending on what sort of security parameter you want. By default, it's nice and easy. You don't need to tell Papertrail what your source system is. I'm going to add some other properties to the Papertrail logger.

[01:32] Program allows you to easily identify what program is logging to your Papertrail system. The idea being, you could have multiple programs using the same transport. This is a way to identify them. For us, we're going to use the package name, which is our project name.

[01:51] To do that, we'll just make sure we've imported the package. We're going to make sure that all our information is stored on one line. This just makes it slightly easier to view information. We'll set inline method to true, and we're going to slightly enhance our log format. What I want to do is make it very obvious when there is an error.

[02:18] Next, we need to add our Papertrail logger to the available transports for Winston. Let's test that and see how it works. We start our server. We get the info message within the console of our server. If we look at the Papertrail events page, we can see that there is a message appearing for the info on there.

[02:38] Here's the third one. It's just appeared, where I tested it previously. Let's see what happens when we have an error. I'm going to add some code here which is going to throw an error. We'll then look on the console to see what it looks like.

[02:54] This code's going to throw an error. Let's start our Node server up and see what happens. We start the server, and the error has been thrown. It's in red, and it tells us whereabouts the error is, and what the error is.

[03:11] Going back to the Papertrail website, looking at the events page, we can see the error is now being displayed. We're going to start by enhancing this line, which is where it's taking a Node environment for production and setting the console logging to info level. We'll now enhance that for Papertrail.

[03:29] We're just going to copy this block, change it for development. We'll set the level to debug. Again, we'll copy this block. This time, we're going to have a local setting. We're going to keep debug for console, but we're going to remove the Papertrail transport. We'll just output a debug message to confirm that.

[03:57] To make life easier, I'm going to add a scripts block to my package.json, so that I can have terminal commands to indicate what level of logging I require. The default start command will just set my Node environment variable to production, and then start the server.

[04:18] My dev command will set my Node environment variable to development, which means debug will be available. Finally, local will disable Papertrail, but keep the debug level. Let's see that in action.

[04:34] The first thing we're going to test is production. That's simply npm start. That equates to our package.json file command. We expect the standard info message to appear and the error message, but no debug.

[04:50] That seems to work fine. On Papertrail, next, we're going to run locally. That should give us our debug level messages, but no output to Papertrail. That would be npm run local. Therefore, we get the output. We get debug messages.

[05:14] Let's check Papertrail. On the Papertrail event viewer, we get no additional information, which is what we wanted. Finally, we will simulate development, where we want to do, for instance, UAT testing.

[05:30] We want this to run on our server, but we want to see debug level output. We also want to see it on Papertrail. I'm going to do npm run dev. We'll get debug output, and we should also get this on Papertrail.

[05:43] Switching to Papertrail. On Papertrail, we have got the debug information, which is also coming out. Papertrail has various functionality, but some of the useful things you can do are, for instance, you could say, give me all the error messages that are visible.

[06:04] Or you could say, I'm looking for a specific keyword. Perhaps you've got a client that you log into, for instance a booking reference that you wanted to drill down to. The other sort of things you can do is, you could, for instance, set up a Slack alert.

[06:18] It has plenty of integration to third party tools, that whenever you get an error message in a certain system, it sends you a Slack alert. It worth looking around and seeing what other functionality's available to you if you use Papertrail.