Python for Entrepreneurs Transcripts
Chapter: Monitoring and logging in production
Lecture: Concepts: logbook
0:01 Let's review what we did to set up Logbook in our environment. First thing we did is we imported Logbook and we actually imported sys as well,
0:13 then what we did is we actually got the log file name, and the log level. Now, here I just typed it in, and we saw that we use the file,
0:24 if we were going to trigger file logging and if there was nothing, we just logged standard out. Now, in practice this probably as we did goes into your
0:33 development.ini and your production.ini, but where you get it from it doesn't matter,
0:37 we set the filename and we set the level, and then if we have a filename, we must want to log to it but if we don't we'll say
0:44 stream handler, standard out, we set the level. Remember, here we are setting it to trace, that's one of the most verbose things
0:52 you can do and because we said "push to application", that means this stream handler is available from anywhere in the entire process.
1:01 OK, next, we said if we do have a filename, instead of creating a stream handler, we are going to go to timed rotating file handler.
1:12 So every day we get a new file, and after a few months you can clean out the really old files, keep the last month, two months,
1:18 actually I archive mine, put them into a Dropbox somewhere, things like that, so we give it the filename and the level and a date format, and again,
1:24 we just push this to make it globally available. So it's the levels here that act as a filter for the rest of the messages,
1:32 where you see things like log.notice, log.trace, log.info, log.error and so on. Once we have the setup, how do we create
1:41 one of these Logbook loggers and actually use it? Well, we say logbook.logger and allocating instance of the logger class
1:49 and here it takes the name of the logger and you saw that they actually appears in the output.
1:55 Then we come up with some message, right, there is just random text, this is the text of the message we want to send in our log,
2:02 and then we just say startup_log in this case or name of the logger instance . critical error,
2:08 notice, info, trace, etc and then we get some message that looks like this. We've got the date and the date format that we put out,
2:17 we've got the notice because we did a log.notice, and then just the text, well actually then the app that we specified in the name
2:25 and then the message we sent out. So really nice to trace back what type of message it is, where did it come from in your app and so on.
2:34 Finally we saw that the controller infrastructure provides a really nice way to create
2:40 customized loggers for every single web request that is instantly and always available.
2:45 So in our dunder init for the controller base, we just say logbook.logger and we came up with the naming scheme,
2:53 mine was Ctrls/ the short name of the type because I always called it account controller, home controller, store controller,
3:00 I don't really need that in my log, so we just did a little bit of work with the replace that dropped that name,
3:07 and then, like in our account controller here, we are going to say "self.log..." and then "notice", users are attempting to log in.
3:13 And users successfully logged in, and you see messages like this at the bottom,
3:17 so "NOTICE: Ctrls/account: User login SUCCESSFUL", and I wrote this function,
3:23 property really, extra_log_details, and I put that in the controller base as well
3:28 and it looks at self.request and it will pull out the ip address, the user agent, the URL etc,
3:34 there is a bunch of things on the request object you can log automatically and that gives you additional information so if some user comes and says
3:43 oh I had this error, this thing didn't show up you can look at their OS, look at their browser and you have a better chance of reproducing it.