Logging as an Anti-Pattern
“You can use logging for everything!”
— #CowboyDeveloper
Well, technically speaking, the resident #CowboyDeveloper is correct, you can use logging for everything
- Metrics: Print out your data, and cut/paste them from the terminal into Google Sheets. Voila! You can now generate all the charts you need from this data! (I’m not joking. I know a dude that actually did this!)
- Alerting:
tail -f | grepon your logs, and if anything bad happens, pipe it to sendmail. (Yes. sendmail was a thing. Don’t ask) - Monitoring:
tail -f | grepon your logs across many, many terms. (One for each server, times the number of things you are looking for) - Debugging: You know the drill. Throw enough
print()statements in there, and, with enough hair-pulling, you can figure out the problem. - Tracing: Uhhh, what’s that? (And, once explained, “solved” by sticking unique IDs into each log statement. Again, don’t ask.)
Of course, just because you can do something, doesn’t mean you should do something. There are specific tools for each of the above — Grafana, OpenTracing, Promethus, Sentry, and a host of others — tools that are not only domain specific, but more importantly, ridiculously transparent to implement and use.
The (not so) funny thing is, the above example aren’t from some dusty old past. These are all examples I’ve encountered within the last few years, being used by people on “important” products, that companies depend on. Look around you, odds are that you know somebody who is doing at least one of the above 😨
