Adding a CMS to Your Flask Web App Transcripts
Chapter: Logging activity
Lecture: Demo: Tour of logging
0:00 our goal in this chapter is toe add logging to the Web app. But what I've done is actually gone and added a little bit of logging to the
0:08 core Web application, the part that we're not really working on, the part that we started from in the very,
0:13 very beginning. I don't think the logging was there, so went back and added that. And then we're gonna and a little bit more logging for admin section.
0:21 Anytime you have something like out protected area, you probably wanna have some kind of notices of people doing things over there.
0:28 And then finally, in this section, we're gonna take an integrate output that's coming from the markdown subsystem and plug it into
0:35 our existing A logbook framework. So in this first section here, let's go and just look at what we've done. Let's do a quick survey of where we are.
0:44 So he turning the very beginning. That's what runs when our app starts up. And what we're doing is we're gonna go over here and call configure,
0:53 which is calling first, innit? Logging. It does this notice now there are different levels. So we have. I have noticed Wales have warnings.
1:04 We have errors. We have critical errors. We have trace traces like very verbose. Probably don't want to see it.
1:10 But sometimes if you want to see all the details, you can turn it on to be more chatty. Lots of info, right? So notices medium level of information,
1:19 probably the lowest we would still run at in production, or either doing notice or info most of our production ups. So down here in the Net,
1:28 logging, we're going to log book and one time for the whole application were saying your output goes to standard out.
1:34 That's basically like if we did a print statement, we're also setting the level to various. Think we have the bug, noticed error and so on.
1:43 The bug moons everything. And then we're going to just say load that setting for the application in production. You wouldn't do a print statement.
1:52 You would save this to a file. The file would probably be changed. Every single day would have the log name plus the file. The date the you know, year,
2:02 Mother Day, something like that effect, and that's what we do every day. The system automatically generates a new one,
2:07 but just for our demo. We're just going to do basically print statements. Then we create this logbook longer and give it a category.
2:15 Let's go and run our AB first. Notice down here. We're doing log notice. Set the mark down storage engine to this.
2:22 A lot of these used to be print statements. Walk, notice the databases initialized. Blueprints were registered and we go in here.
2:30 We'll see other systems, like the logger for the D. V. And these used to be a print statements as well.
2:35 But now we're saying we have a notice we're connecting over here and info about whether or not already been initialized what is initializing and so on.
2:44 So if we'd run this now here you can see all this stuff coming out. Now you may wonder, why is it running twice?
2:52 This is because of the debug version of Flask. I believe it's like restarting in debug mode, watching the files for automatic restarts.
3:00 So hey, see the time on the left? The level of message noticed. Where is coming from? AP configuring the flask cabin. There's during blueprints,
3:12 and then we get involved level notice from the database that it's initializing and then notice notice that it's connected and so on.
3:19 Then here we set the mark down storage engine. You can see we got these levels and we've got categories or sections over application,
3:27 like AP and database and views and so on. All right, so let's go over here and we can just look at that page Let's see what we get.
3:38 Then we get some markdown output from the markdowns of template library. But that is actually not going through the same system as logbook,
3:47 even though they have square brackets. It's just kind of a style. It's not the same thing. What were one of the goals is to take these
3:54 messages and help them go into the same system here. The reason that's important. For now, it looks like they're the same,
4:00 just slightly different format. But when we go to somewhere else, like running in production Web server, these we're gonna be going to a file.
4:07 This is still just gonna be printing out, which may or may not get captured,
4:10 but it won't get interwoven and in the right place with the stuff that you want Okay, so we also have over in our account views.
4:17 We have an Accounts section and let's see Go down here. Let's look at the register bond. So, for example, somebody tries to register.
4:25 We say there's an anonymous user coming in. If there's an error, we say, Oh, they couldn't do it. Here's why we can't create the account.
4:34 We send out another message saying the same thing. Then finally, we haven't noticed that the user successfully created an account when they registered
4:42 right. So throughout this website, now we have basically this type of logging over in the CMS section, we have one more the CMS logger,
4:53 and this one's pretty straightforward. It's a little verbose if you turn it all the way up, but every time you request a page will.
4:59 So hey, here's a request for this CMS page we're processing. Or here's a redirect that we're processing or more common.
5:06 Not entirely common. Info is not that high. Well, we'll say there was a request for something that wasn't found.
5:13 All right, so let's see if we run this show. If we could get it to do it again, let's see you get a 44 now.
5:21 I think the word brothers cashed it Every now and then, you'll see that it's getting a 404 for like,
5:25 a favor icon. I guess we could ask for something that is not there. Then here, you get this warning. CMS request not found. Help,
5:33 G. Okay, so this is the logging as it is in our website, and our goal is to extend this for admin section and a plug marked on sub
5:42 template output into it as well.