3 ms·

> I don't get why people get so theological about logging. > If logs bring you some sort of value, then log away. I have been on the other side of the problem

> I don't get why people get so theological about logging. > If logs bring you some sort of value, then log away. I have been on the other side of the problem for years now. Logging has a cost. And the cost benefit is also not great. It requires a human to read it(either that or a regepx hellscape awaits you). This can be fine if you are working with a small service, but it quickly gets out of hand once scale increases. I've had to deal with double digits(approaching triple) terabytes of logs daily. Most of the information logged was, like the author suggests, completely irrelevant. It makes it much harder to see what's actually relevant. And, for whatever was actually relevant, generally not enough context was provided (something the author also argues). What you really have to have in production systems are metrics. That's what's going to tell you if shit is on fire and which ass is burning. Has your app has hit a catastrophic failure and cannot continue? OOM? Sure, by all means log away. Did it have an error while trying to talk to a service? Are you retrying? Then _do not log_ until your retries (or whatever recovery mechanism) fail. Networks have become very reliable, but failures are expected and normal. Spit out metrics instead. If you don't do this, some schmuck will have to spend their days trying to keep the logging infrastructure from falling over (Cthulhu helps you if you are on an ELK stack) while management will be complaining why noone seems to notice failures before customers do. If you find yourself parsing logs to alert on issues, please revisit your architecture. METRICS FIRST. Logs are a safety net and a tool for troubleshooters.

marginalia_nu 5y ago
What you are describing is pretty clearly within a domain where logging doesn't bring much value. It's either superfluous debug messages from an earlier phase in development, or at the wrong granularity. If you are dealing with thousands of events per second, you can't log at every event. Your logging probably shouldn't produce more than a couple of lines/second on average unless something has gone very wrong. Logging is something that needs to be maintained (like all code), it can't be just some vestigial by-product of the development that's left to its own devices, at least not if it's to be of any use. The same is true for metrics. If your metrics are just some arbitrary selection of times and counts that seemed good at the time, they're probably not very useful. Which data to collect is something that needs to be deliberately chosen, and re-evaluated over the lifetime of the application. When you are launching a new product, then lots of logging is probably a good idea. When that product is mature, you probably should have dialed it back several notches, as you most likely already know the general areas where things go wrong.

marginalia_nu 5y ago

What you are describing is pretty clearly within a domain where logging doesn't bring much value. It's either superfluous debug messages from an earlier phase in development, or at the wrong granularity. If you are dealing with thousands of events per second, you can't log at every event. Your logging probably shouldn't produce more than a couple of lines/second on average unless something has gone very wrong. Logging is something that needs to be maintained (like all code), it can't be just some vestigial by-product of the development that's left to its own devices, at least not if it's to be of any use. The same is true for metrics. If your metrics are just some arbitrary selection of times and counts that seemed good at the time, they're probably not very useful. Which data to collect is something that needs to be deliberately chosen, and re-evaluated over the lifetime of the application. When you are launching a new product, then lots of logging is probably a good idea. When that product is mature, you probably should have dialed it back several notches, as you most likely already know the general areas where things go wrong.