Hacker News Reader

> 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."

> 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.

>> 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/

Having extensive logging and sentry makes your sentry reports significantly better, it's not an either/or situation.