4 ms·

Weird article. As greatly represented in this comment section, this article touches on maybe 1/10 of the usecases of logging...and than pretends that the opini

Weird article. As greatly represented in this comment section, this article touches on maybe 1/10 of the usecases of logging...and than pretends that the opinion is applicable everywhere. > And yes, you got it correctly: it sounds like a job for Sentry, not logging. okay, I guess I will not write a log file for my Raspi bash script then and instead setup a third party service? > We don’t really care about exceptions and how to handle them. We care about the business value that we provide with our app. That's how you get shitty software which can be fixed relatively quickly regarding large scale black swan events (everything broken) and retains their annoying edge case bugs forever, slowly driving users away... All the while, the arguments against logging seem to be the same against implementing, well anything. More things = more complexity. New things = new problems. By all means be aware of these pitfalls in the context of logging and anything else. But as a whole, this article awfully smells like an unreasonably strong opinion wrapped in pseudo-intellectualism.

ekidd 7y ago
> this article touches on maybe 1/10 of the usecases of logging...and than pretends that the opinion is applicable everywhere. It's definitely a weird article. I maintain an open source tool called dbcrossbar that automates data transfer between several kinds of databases. It uses multiple async streams to copy data, and it has a "backpressure" system that keeps every step of the transfer in sync. Usually it's very reliable, but if it goes wrong, then I need debugging tools. We use the "slog" library for structured logging. This allows us to add extensive structured data to our logs, and to keep track of what's coming from where. We can increase or decrease the log level for each component individually. And these logs are invaluable for debugging. Like, almost every time we have any problem at all, we all sit around saying, "Wow, we're so glad we have such good logging."
masklinn 7y ago
>> And yes, you got it correctly: it sounds like a job for Sentry, not logging. > okay, I guess I will not write a log file for my Raspi bash script then and instead setup a third party service? They're not even exclusive. You can and should feed your logs into sentry. It can use low-sev logs as breadcrumbs and the high-sev logs as events: https://docs.sentry.io/platforms/python/logging/ https://docs.sentry.io/platforms/python/logging/ Having extensive logging and sentry makes your sentry reports significantly better, it's not an either/or situation.
hinkley 7y ago
> We don’t really care about exceptions and how to handle them. We care about the business value that we provide with our app. This is famously not true. When the system is working, “we”, as in the business, only care about the business value. The moment things break or get slow it’s all recriminations about “how could you let this happen?” Then later it’s right back to, “why can’t you go faster?” until it happens again.

ekidd 7y ago

> this article touches on maybe 1/10 of the usecases of logging...and than pretends that the opinion is applicable everywhere. It's definitely a weird article. I maintain an open source tool called dbcrossbar that automates data transfer between several kinds of databases. It uses multiple async streams to copy data, and it has a "backpressure" system that keeps every step of the transfer in sync. Usually it's very reliable, but if it goes wrong, then I need debugging tools. We use the "slog" library for structured logging. This allows us to add extensive structured data to our logs, and to keep track of what's coming from where. We can increase or decrease the log level for each component individually. And these logs are invaluable for debugging. Like, almost every time we have any problem at all, we all sit around saying, "Wow, we're so glad we have such good logging."

masklinn 7y ago

>> And yes, you got it correctly: it sounds like a job for Sentry, not logging. > okay, I guess I will not write a log file for my Raspi bash script then and instead setup a third party service? They're not even exclusive. You can and should feed your logs into sentry. It can use low-sev logs as breadcrumbs and the high-sev logs as events: https://docs.sentry.io/platforms/python/logging/ https://docs.sentry.io/platforms/python/logging/ Having extensive logging and sentry makes your sentry reports significantly better, it's not an either/or situation.

hinkley 7y ago

> We don’t really care about exceptions and how to handle them. We care about the business value that we provide with our app. This is famously not true. When the system is working, “we”, as in the business, only care about the business value. The moment things break or get slow it’s all recriminations about “how could you let this happen?” Then later it’s right back to, “why can’t you go faster?” until it happens again.