A little while ago we talked about resources, primarily. Memory and memory is something that we obviously need to be concerned with. You know, how much memory do we use? But we also need to be concerned about disc usage because, well, we could kill our application. Now, when I refer to disc, I'm primarily referring to, well, our logs, because yes, our database lives on disc, but you know, our database is really important. So that's where we store all of our data.

but you know, our database is really important. So that's where we store all of our data. And while we could be concerned with that, that that's not what I'm referring to, I'm referring to our logs because when it comes to the DISC usage for our application or where our application runs, our logs are going to be the primary culprit when it comes to disc usage. And I have a script that simulates about 9,000 requests. And we can see that after 9,000 requests, the log size grew about four meg,

And we can see that after 9,000 requests, the log size grew about four meg, and each request was about 450 bytes. Now that doesn't sound like a lot, but remember, this is just my little environment. Let's assume that we have a huge customer base, and as we deploy our application, we're gonna have a lot more requests. And here are some projections. So for, let's go with 50,000 requests per hour,

And here are some projections. So for, let's go with 50,000 requests per hour, because you know, this is a storefront, hopefully we would have that. And, and even more so per hour, we would see our log size increase by 21 meg per day. It would be half a gig per week, it would be three and a half gigs. That's a lot. And especially if our logs don't rotate and we don't take great care when maintaining our logs,

That's a lot. And especially if our logs don't rotate and we don't take great care when maintaining our logs, we are going to fill the disc and kill our application. Now, there are actually several problems with this application as far as logging is concerned. And the first thing that we're gonna do is take a look at our logging configuration because, well, it, it is just wrong. First of all, the channel is set to single. That means that we are writing our logs to a single file

First of all, the channel is set to single. That means that we are writing our logs to a single file and it's just gonna grow and grow and grow until it can't grow anymore. There's no automatic pruning or anything like that. We don't want that for a production environment. For development. It's fine, but not for production. But then let's find the single driver. Here it is. So of course our path is the Laravel log file. The level default is debug.

So of course our path is the Laravel log file. The level default is debug. So once again, for development, that's perfectly fine. But for a production environment, debug information is a lot. Even information level logging is a lot really in production. We are only concerned about two things, warnings and errors. Those are really the only things. So yeah, this is gonna be a problem.

Those are really the only things. So yeah, this is gonna be a problem. And yes, this is going to cause our applications log to grow a lot more than it really should. But then let's take a look at the NV file. Let's see, log channel, single, we, we already know that log level debug, we already know that as well. So it's something that we need to be aware of as we deploy our application into production so that our environment is properly set

as we deploy our application into production so that our environment is properly set for logging in a production environment. But you know, that's just the second thing. The third thing is the actual logging code, because there's a lot. So this is the checkout. So let's see right here, when a user checks out, so we are, well, we're logging the entire user object. We don't need that. That's too much information.

well, we're logging the entire user object. We don't need that. That's too much information. We are also logging all of the cart items, which once again, that's entirely too much for debugging purposes. Great, but in a production environment, we don't need to know that because we already have that information being stored in the database. So for production, no. But then this is also troubling as well because we are essentially logging

But then this is also troubling as well because we are essentially logging everything about the request. So if there's any sensitive information in that request, it's getting logged. What if a password was there? Well, now we have it. There shouldn't be a password there. But you know, the, the idea is that we, we want to log useful information, but we really need to question ourselves.

to log useful information, but we really need to question ourselves. You know, is what we are logging really useful? And also more importantly is what we are logging a security issue. So one other thing I wanna look at is the log itself, because there's a lot, I mean, just look at this right here. Uh, this is viewing a product. So what are we logging? Well, everything about that product. Do we really need the id? Well, yes, we need the id.

Well, everything about that product. Do we really need the id? Well, yes, we need the id. Do we really need the category? Which you can argue, yes you do, but do we need the name and the slug and the description? Do we need all of that inside of the log? No, we don't. Maybe for debugging purposes, but not for production. So let's fix this. Now, we're not gonna fix everything

So let's fix this. Now, we're not gonna fix everything because that would mean going throughout the entire application and changing our logging code. But there are a few things that we can do to make this a lot better. First of all, we're gonna change this to daily. The daily driver automatically rotates our files. It's going to create a log file for an individual day, and then I think it's after 14 days,

It's going to create a log file for an individual day, and then I think it's after 14 days, it starts rotating the logs. So we don't have to manually go in and prune them or anything like that. Laravel is going to automatically do that for us. Sounds great. We need to use that tool. So there we go. But let's also scroll on down to the daily driver information. The driver is, of course, daily, the path is fine,

to the daily driver information. The driver is, of course, daily, the path is fine, but look at the level here. The log level is set to warning. It's not set to debug. And that's really where we want it for production. We want to know the warnings, we want to know the errors. And then we can also see the amount of days that we want, which the default is 14. We can change that to whatever we want, but 14 days of logs I think ought to be sufficient.

We can change that to whatever we want, but 14 days of logs I think ought to be sufficient. The second thing is our environment. Because in production, we never want our log level to be debug. So we're gonna change our log channel to daily, our log level to warning. And then finally, we need to change how we log. Now for actual debugging purposes, what we have is fine, but I would argue something like this would

Now for actual debugging purposes, what we have is fine, but I would argue something like this would be a little bit better. So that we would use information as opposed to debugging. And we'll just say check out started. And then we will provide the context that we want to log. In this case, we don't need the entire user information. All we need is the user's id. So we can say off ID to get that and we're good to go there.

So we can say off ID to get that and we're good to go there. As far as cart items are concerned, do we need to know all of the actual items? I don't think so. So we could just have the count of items which we can easily get from the cart because we have our items we call counts and that's fine. But then, you know, here we logged everything about the request, which could include sensitive information.

here we logged everything about the request, which could include sensitive information. We don't wanna do that. But what would be useful is, you know, the subtotal of the cart that is contextual to checking out. So we'll have our subtotal from the cart. And I think the method I have is get subtotal. Now, of course, with the log level that we are now logging at for production, we're not gonna see this.

that we are now logging at for production, we're not gonna see this. But, but that's okay because once again, in a production environment, we typically want, you know, the warnings and above. Now the script isn't finished and we're not gonna finish it because it takes a while. But we have reached 400 iterations and we can see that we are 20% done. And an iteration isn't a single request, it's about four,

and we can see that we are 20% done. And an iteration isn't a single request, it's about four, four and a half requests somewhere around there. But after what, uh, 1600 requests, we only have one item in the log. Now, you know, if we are logging just warnings and criticals and errors and all of that stuff, then those are only going to happen when those test cases happen. We haven't hit any one of those.

to happen when those test cases happen. We haven't hit any one of those. So the, the point here is that our log is going to be considerably smaller, not just one log, but all of our logs, because now we are breaking up our logs into individual days. So instead of Laravel dot log, we have Laravel, and then today's date, well, that's not today's, that's tomorrow's, but UTC time, that's, that's today's log. So our log is going to be considerably smaller than it was,

that's tomorrow's, but UTC time, that's, that's today's log. So our log is going to be considerably smaller than it was, and that's really what we are going for in a production environment. So log files are one of those things that just works until they don't. I mean, typically logs don't get very big just overnight. It's a gradual thing. But the fix is very simple. Daily rotation of logs, uh, appropriate log levels for a production environment.

Daily rotation of logs, uh, appropriate log levels for a production environment. And thoughtful logging. Don't log just anything. Log just the things that you need.