As a software engineer, I think there are a lot of 'best practice' articles and 'in an ideal world...' kind of articles. Here's a more practical one. Here's how I actually use logging in the web applications I build at home.
Why Log?
I use my logs for three main reasons: troubleshooting, identifying improvements and security.
When a user is struggling, they're often not great at explaining what they were doing when they encountered a problem. They're usually (understandably) annoyed and don't want to explain, they just want it to work. To save us both time and energy, it's far easier to dip into the logs, see the actions the user took and the error that occurred. If you've logged effectively, it's obvious where they've gone wrong and you can either direct them to the proper usage, or get in a quick bug fix. This is a huge timesaver and it is probably the main reason that I build logs into my applications.
Logs can give an indication of where users are spending the most time. One of my old portfolio projects was a map/world statistics application and I could see from the logs that a lot of users were clicking map markers repeatedly and quickly. I did a bit of digging around and it turned out that the one of the API queries that ran when you clicked a marker was running insanely slow, so this behaviour was clearly users angry-clicking to try to get my application to work. I adjusted the code and I saw the behaviour reduced in the logs. Although it's time consuming to trawl through your logs looking for patterns in behaviour (hello AI?), it can make it obvious where improvements are needed.
The last reason is security. I need to know who is accessing the application and what they're doing so that, like Santa, I can figure out who's naughty or nice.
Although not relevant to me since I'm talking about web apps that I've written at home that aren't bound by the fun legal stuff, I'm also going add regulatory things like non-repudiation, auditing and compliance. If you're thinking about implementing logging for you company's applications, you need to think about these requirements. However, I think that, if you've logged for security, troubleshooting and improvements, you've probably covered most compliance requirements (probably still check though, don't believe a stranger on the internet).
What to Log
Don't log all the things.
Think about why you're logging and what you need. If you don't need to know that someone clicked on btnSendChristmasCard then don't log that someone clicked it.
I log for the reasons above, so I collect stuff like:
Authentication events.
Authorisation events.
Key interactions (save buttons, search buttons, etc.) that show me the basics of what users are doing.
File upload attempts (and what file types they are).
Breaches of validation rules.
Requests to external services (whether my own APIs or third party ones).
Errors. You've got to love a good try catch.
If there's a new feature that I'm not 100% sure about yet, I'll log minute interactions until I'm more confident that it functions ok. Then, I'll reduce the logging back to a normal level.
How to Log
I love the idea of everyone using OWASP's standardised format for logging. It'll make incident response better and it opens the door to automated log scanning and all sorts of fancy parsing. I don't follow it though. Maybe one day I'll rewrite.
Mine tend to follow the format of:
2023-12-20 - WARNING - UserID - Action
Where 'WARNING' is interchanged with 'INFO' and 'ERROR'.
The actions are described in normal people language, not software engineer language, although I do include stack traces when there's an error. This makes it easier to scan, particularly if anyone other than me has to look at it (which they never do, but you never know).
It's brief because I don't want to use all the storage. It's also relatively light on identifiable information. GDPR still applies to your logs so an IP address and a user ID/name is fine, but logging a full name, location and the plain text password they've just attempted to log in with is pushing it.
Final Thoughts
Logs are an absolute iceberg. There's the matter of CIA protecting the logs, log shipping, log parsing and analysis, log storage, and how to write logging into your application without it turning into an ivy plant that invades everywhere and is impossible to extract. It's a super interesting topic when you start digging into it.
I'm also going to take this opportunity to say something controversial and disagree with the devs who say you should never reinvent the wheel. They'll tell you that if there's a library, you should use it. This isn't always good advice. Third party libraries add risk and additional maintenance requirements to your application. When it's something as simple to implement as logging, it's not going to take a long time to build it into your applications yourself. Coding from scratch is more fun, you'll learn something along the way and you'll save yourself the chore of updating the library and amending your code to cope with the changes. Then do what I'm in the process of doing and build yourself a nice Python log parser for extra funsies.
I'd actually love to hear how other people are doing this. Like I said at the beginning, there's a lot of best practice articles about logging and not enough 'here's what I actually do' articles, so share away.