These likely bear no semblance to Official Computer Science categorization, but these are the categories of logs in my head:
- Ad Hoc Logs
- The
echo,console.log,fmt.Println, andputsof the world. 👕 - “I need to look at some values at this exact step, while I’m actively working” with a dash of “I really should learn proper step-and-breakpoint debugging but hey, I’ve made it this far.”
- These are typically removed from code before committing because they add noise for everyone else who are
debugging their own problemsworking.
- The
- Automatic Logging
- When you spin up your slurry of development tooling, your terminal is spittin’ stuff out that those tools (+ your configuration) have decided should go to “standard out”.
- Just doin’ stuff on your website is also likely generating lots of other logs that are probably going to literal log files on disk or some other kind of log storage. This is an ancient best practice that ensures that if an alien race were to gain access to mankinds entire digital archives, they would assume that
69.699.123.420 - - [17/Feb/2023:00:01:36 +0000] "GET /feed/ HTTP/1.1" 200 121434 "" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/106.0.0.0 Safari/537.36" chriscoyier.net HITis our formal planetary greeting. - Often used for analytics reasons and rooting out problems via output that may be suppressed in other contexts.
- Error/Event Logging
- Something happened, so I’m intentionally logging it.
- Sentry! Data is missing!
- Appcues! A user did something interesting!
- Mixpanel! Someone in London bought something!
- These tend to stay in place.
I suspect a decent amount of computer work is tending to logs of one sort or another. I’m thinking about this because it’s come up at work a decent amount lately in the form of:
- Pull Request comments to make sure to remove logging statements. (Ad Hoc Logging)
- Ensuring that logs are being sent to our main logging service, Amazon Cloudwatch, for a new service. (Automatic Logging)
- Setting up logging for a strange problem that keeps coming up with hard-to-replicate data. (Error Logging)
I also recently read Logging practices I follow from Eliran Turgeman which also mentions the concept of logging levels:
Whenever you write a log, it’s important you choose the correct log level. I personally mostly use ERROR, WARNING, INFO, or DEBUG
I imagine this is most important in Automatic Logging. So, for instance, you could completely turn off certain logs in staging and production to avoid noise there. In Ad Hoc logging, I don’t find myself using levels all that much. I know JavaScript has console.warn and console.error and such, but I don’t find them all that useful, client-side at least. We have a pretty lovely homegrown Go logger that supports levels too, but I tend to only use the default for Ad Hoc logging.
🧠 Galaxy Brain thought: I wish I could leave my own personal logging in place, and have it not bother anybody else. A console.chris(), as it were. Maybe it’s stripped in CI, but somehow my machine remembers them. Then I’d never accidentally leave logs in PRs, and could log locally with reckless abandon.
I agree. I use console.error/warn in production code where appropriate. Though I just use console.log() for ad hoc debugging like you do.
I do use a pre-commit hook to stop a commit if a console.log is left in and we also run all our pre-commit hooks on branches in our CI system in case a dev somehow doesn’t configure the hooks so they get fixed before PR review.
would be cool to see your setup for catching those console.log’s
It’s logs “all the way down” :)
Even the plain old web access log will serve you better, if you do some minor changes:
make it json, so every log management solution can easily parse into fields that you can easily use as filters (requests with 503? with loglevel INFO? in most cases you can log it all and filter when you look at it)
have timestamp with milliseconds – your blog does not care (well, perhaps unless you are Chris Coyer), but your client may have some traffic and knowning the answer to chicken-and-egg question may be important
timezone – we tend to have more than one log per request, so milliseconds might not help if you are unknown number of timezones off
if you are using Nginx – please find a way to log the timestamp of request start, it is rather difficult to find out what caused a lock if you only know when the lock got released
log some extra data – for web servers response time of application helps a lot (also knowing, if it was a static file serve by Apache/Nginx or actually run some code)
I did a “Logs don’t lie” preso on BSides Tallinn https://www.youtube.com/watch?v=JIA1yI486jk trying to illustrate these points