One question I always have about logging: how do I log valid and expected but prohibited actions? That is, the system is behaving as designed but the user is seeing an error message because they're using the system wrong, and I want to know how often this is happening?
Logging practices I follow
11–20 of 81 posts
Re: Logging practices I follow
#12On the levelled logging point, I stopped using levels after switching from Java -> Go and haven't looked back: https://thomshutt.github.io/opinionated-logging-in-go.html
Re: Logging practices I follow
#13One additional thing I like in structured logs is having some form of context level information be included eith your logs, so that you already know things like tenant id, user id, request id, and basic parameters of the request without having to rewrite all that everytime you get an exception. Unrelated: I live in the Pacific north west and I clicked on this expecting to find a list like "don't log old growth for ti…
re: unrelated - I too thought this was a forest-related post.
Re: Logging practices I follow
#14I fight log infra all the time. I can't win the fight against structured logging anymore, so I'm now fighting against type systems and allergies to global state to make log output available everywhere. If you're going to ram structured logging down devs' throats, then the least you can do is to make it easy enough to use. I don't want to have to pass a logging object everywhere. There's like two pieces of information…
At least passing context objects everywhere is better than dynamic dependency injection. I'm in the "dump the logger in a global variable" boat too though.
I was somewhat in that boat too, until the first time I had to make several modules in the code log in a special way (that required some custom code), determined at runtime.
Mostly I just wish more languages had Lisp-style dynamic binding / "special variables". Logging is one of the perfect use cases for dynamic scope - you'd have your normal logger object/configuration as the top-level value of a global, and then let-bind it whenever you need to alter its value for all code executed within that specific scope.
Alas, about the only widely-used form of dynamic binding today is environment variables.
Re: Logging practices I follow
#15One question I always have about logging: how do I log valid and expected but prohibited actions? That is, the system is behaving as designed but the user is seeing an error message because they're using the system wrong, and I want to know how often this is happening?
Sounds just like INFO to me. There's a difference between logging to users, logging to system administrators, and logging to developers.
Re: Logging practices I follow
#16I prefer this post which is more detailed: https://talktotheduck.dev/logging-best-practices-mdc-ingesti...
Re: Logging practices I follow
#17Earlier quoted context omitted.
You know that costs money, right?
Not as much as you'd think, and critically, the cost is largely disconnected from how you use the infra.
If your infra is not on-prem, yes it will cost you more money as you are generating more and more and bigger logs.
Re: Logging practices I follow
#18I was expecting something about sustainable forestry
Re: Logging practices I follow
#19Something I haven't seen discussed very widely: it feels like there's not only a balance needed in determine what to log vs what not to log, but also logging in a way that isn't a detriment to the readability of the code overall.
Over time I've actually found myself logging less just because having to sorta mentally elide logging lines added to the cognitive overhead of reading & understanding code.
Re: Logging practices I follow
#20Question...why no mention of "change" logs? I'm curious as to why I don't see change logs mentioned often as an important overlay to general system logging.
I liken errors and debugs all related to heart beat and breathing rate but without information like "climbing stairs" or "changed medication", it may be hard to understand context or understand why new errors are being seen. The first question I would expect to ask when seeing logged issues, is what has changed recently that could be related to the new errors. Curious to hear thoughts on this?
I actually built software/startup related to the logging of changes (architecture change/software change/server restarts) but just didn't get traction and curious to know why it's not more interesting to people.