Logging practices I follow
16elt.com
Logging practices I follow
1–10 of 81 posts
Re: Logging practices I follow
#2> Whatever service you are using for logging, it costs money, and a fast way to burn money is to log the entire json object that was relatively small on your dev env, but blew up on production.
You could also, you know, run your own infrastructure and log to your heart's content.
Re: Logging practices I follow
#3> Whatever service you are using for logging, it costs money, and a fast way to burn money is to log the entire json object that was relatively small on your dev env, but blew up on production. You could also, you know, run your own infrastructure and log to your heart's content.
There are still going to be time and effort costs involved in scaling that infrastructure as your log volume increases
Re: Logging practices I follow
#4I 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 you need in order to make a logger. Just write it to global state somewhere so I don't have to worry about it and can call it anywhere.
I absolutely loathe reinventing global state by passing "context" objects and the like everywhere. It's the dumbest thing in the world but no one ever questions it.
Re: Logging practices I follow
#5> Whatever service you are using for logging, it costs money, and a fast way to burn money is to log the entire json object that was relatively small on your dev env, but blew up on production. You could also, you know, run your own infrastructure and log to your heart's content.
You know that costs money, right?
Re: Logging practices I follow
#6> Whatever service you are using for logging, it costs money, and a fast way to burn money is to log the entire json object that was relatively small on your dev env, but blew up on production. You could also, you know, run your own infrastructure and log to your heart's content.
There are still going to be time and effort costs involved in scaling that infrastructure as your log volume increases
You have to output a lot of logs before you fill up even a single large consumer-grade hard drive, especially given logs are typically compressed when rotated.
It's usually only when you involve ELK or something like that your logs start to get big. Which in turn is typically necessitated by over-complicated distributed software design.
If you're at the scale where this actually matters and you're serving millions or requests per second from a worldwide user-base, then affording storage for the logs really shouldn't be a problem anymore (idk, with the possible exception of Twitter)
Re: Logging practices I follow
#7> Whatever service you are using for logging, it costs money, and a fast way to burn money is to log the entire json object that was relatively small on your dev env, but blew up on production. You could also, you know, run your own infrastructure and log to your heart's content.
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.
Re: Logging practices I follow
#8One 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 timber, don't log the entire area", fun how your brain can associate a word with a concept and ignore the more context-relevant meaning.
Re: Logging practices I follow
#9I 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.
Re: Logging practices I follow
#10Log frugality and log uniqueness are great concepts.
+1 for mentioning both the financial and cognitive costs of excessive logging.