Python for Entrepreneurs Transcripts
Chapter: Monitoring and logging in production
Lecture: Concepts: logbook
Login or
purchase this course
to watch this video and the rest of the course contents.
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.