Another option, if you are working anyways with a database is to store your “logs” in an own table. There are pros and cons to this. Though Database accesses are usually very, very fast, a written file log is aways (by nature) the fastest approach.
But I still often use an own table on a database, as I can then access it for many customers and condense this information into an own dashboard very easily. I like as well to keep some logs in a productive release. Of course this all depends on any GDPR requirements, the nature of your app, your customer etc. For instance I might store where in my code I believe it will never be executed, just to be informed ASAP that it happened.
For deleting old entries, I’m creating a console app for Linux, deleting old data in that table periodically via CRON.
Sometimes it is helpful to know ahead of your customer, what their next problem (or even better for us devs: their next requirement) most likely will be
In regards to filespace consumption and performance I would not care (until you will run into an issue in 10 years). Just look at the logs of Apache2 in Nginx after a standard installation. They write much more, then you probably ever will achieve with your few logs, even if you will keep them for eternity.