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