7 days of WordPress plugins, themes & templates - for free!* Unlimited asset downloads! Start 7-Day Free Trial

Next lesson playing in 5 seconds

  • Overview
  • Transcript

3.1 Logging

Of course, it’s not enough to just ship an application. We need to maintain it as well! In this lesson, we’ll learn how to use the Heroku logging system to help us maintain our app.

Related Links

3.1 Logging

One thing that's very important when you deploy your project into a production environment, is access to logs. Not everything runs smoothly in your application, so it's important to retrieve information that's sent to your application and retrieve in return, the best way to do that is with logging. And if you have important information you wanna keep in your logs then you can use logging tools to project that information into the logs. But still, even if you haven't done that Heroku already provides a logging platform that works like a charm. Let me show you what I mean by typing the standard Heroku command. If we type Heroku and then logs like that, you will see a list of all of the logs available in Heroku. I mean the entire content will be displayed. As you see here you have information that goes beyond your standard log. For example, you have the log timestamp. As you can see this was on October 6th and it shows the process it regards and also the work that's affected. So we have the app source here and the process, the work that's going on is web.1. Because we only have one dino in Heroku meaning one single processor or one single core, we will only get the first web worker. In regards to the source, you will see that this Heroku keyword mentioned something that Heroku does as an infrastructure. When you see app as a source, basically this is the apps logs. So that's pretty good. Most likely you will have only these two. You might have an EPI source in your logs, meaning there is something that's been handled via the API. Maybe you wanted to consume the Heroku API that affects this application, and you will see those logs in here as well. Also notice how we have a router worker. This is something that's very specific to Heroku. This is the specific worker around the Heroku source. Basically it registers the routes they are being hit in the infrastructure. In this specific scenario we are getting the assets and also for example the Pfaff icon. These are not actually processed by the application so Heroku takes care of that. So this is a standard way of retrieving the logs. There's one thing that you can do here. I'm gonna introduce the tail option, as you see here. Double dash and then tail and this will keep the logs fresh as they come. So, let's do something like this. I'm gonna put this on the left side, and shove in the browser on the right. As you can see, everything looks clean and stale, but watch as I click on show. There you go. We have new logs being shoved in. So, new information is being put into the logs live. This is a great procedure if you wanna test something live in production. Maybe a client has provided you with a sample demonstration on how to achieve a certain bug. Well imagine you're trying to replicate the process all over in production. And you will see the logs right there in the terminal. By providing live information you will achieve solid information on that bug. So this is one great way to retrieve valuable information around something that needs effects. So this is one more option. And I wanna provide you with something even further. The logging mechanism in Heroku is better complex there are settings that you can customize, everything is in the link in the description below. You have all the information regarding Heroku's logging process. So, one thing that I want to show you is the PS option. The PS option allows you to filter your logs through a particular process. If I type in web like this, it will show the logs for just the web worker. So if you do it like so, you will see the logs for only the web process. There you go. You won't have anything around the router or, for example, Redis workers or something like that, if you have that configured. You just want the application itself. So if you pass in --PS web, this will filter just the web process. Another thing that you can do is by specifying the source. The source will filter out the exact source of the information want to retrieve. You can use either Heroku or app or API. In this case I passed in app, and this will give me only those that regard the app, including the workers. So if you have a web application with multiple dynos and you also have a worker, for example, to send emails on the side and process information through Redis. If you specify the app source, you will have all of that included, not just a specific dyno or anything. So I guess this wraps it up for logging. There's already so much you can do with this logging mechanism from Heroku. I personally love it in order to retrieve valuable information around something I need to fix. So, feel free to explore the link that I've given you below. It has everything you need to know around logging.

Back to the top