✳flâneur — a map of the web's best reading

On actionable and actually useful logs | Lanre Adelowo

lanre.wtf · 1,167 words · saved by 1 readers

A few months ago, I responded to a Twitter thread on application logging. My response was simple and as follows: There was also a caveat I made about scale. Maybe for a 1000 requests per day product, it's fine to log everything even including stack traces. Maybe not. But if you have ever worked on something at scale, you'd figure out how expensive logging can get. I will give two quick examples in the next two paragraphs. Before starting Fluidcoins, I contracted for a company in Europe. The task was to refactor a ridiculously slow PHP app in Go. We were working ~14 hours/day. When it was time to launch, lead devops was away for some family reasons, the junior devops guy had to stand up to the task of pushing this to production. To keep the story short, the K8s manifest didn't include the LOG_LEVEL env value as he thought it would default to error mode by default, but it meant trace/debug mode instead. It was time to rest and monitor for bugs and all that stuff but around 72 hours later

back Jan 12, 2023 On actionable and actually useful logs 6 min read Tags devops A few months ago, I responded to a Twitter thread on application logging. My response was simple and as follows: Make your logs actionable yet very detailed. Not all logs are equal! My golden rule is to only store what is useful to debug an issue in production. No redundancy. Neither should there be any ambiguity. Metrics do not belong in logs. Measuring the time to completion of your registration route shouldn't be something you are analyzing from your log. Consider event sourcing and/or audit logging. Almost any

Explore this link on the map →

related reading