Errors and logging are kind of wack #24

New Issue

bvisness · 2022-05-21T23:44:12Z

bvisness commented

2022-05-21 23:44:12 +00:00

Right now we have the following for errors and logging:

Errors: Our custom oops package for exception-like "something went wrong" errors that you do not expect anyone to handle. Custom error types for everything else as necessary.
Logging: Zerolog, a library which frankly has not been worth the hassle.

At my work and here on HMN, I've been mulling over some concerns with how things currently work:

Overall there are a couple use cases I would like to improve:

Logging unknown errors along with relevant stack traces and any useful structured fields. I've considered putting those extra fields on the error itself so that the error-logging middleware will have that stuff available, but that doesn't actually work very well because you're never going to remember to put random fields like user ID on those. Instead, something like Asaf suggested above would probably be better - we can store extra log fields on the current request context, and log them on errors.
Logging structured stuff in general. Zerolog is just pretty gross, frankly—it has poor stack trace handling, it doesn't handle multiple stack traces, and the API is just clunky. It's cool and all that it avoids allocations, but the API is just annoying and I don't think we even care. Our performance constraints are just not that tight.
Logging of our custom performance metrics. If we do our own thing, we could just give this a privileged place in the log output instead of working it into Zerolog's formatting.

Right now we have the following for errors and logging: - **Errors:** Our custom `oops` package for exception-like "something went wrong" errors that you do not expect anyone to handle. Custom error types for everything else as necessary. - **Logging:** [Zerolog](https://github.com/rs/zerolog/), a library which frankly has not been worth the hassle. At my work and here on HMN, I've been mulling over some concerns with how things currently work: ![image](/attachments/8b065e2f-6df7-41c6-a9f7-4e906dc2ae60) Overall there are a couple use cases I would like to improve: - Logging unknown errors along with relevant stack traces and any useful structured fields. I've considered putting those extra fields on the error itself so that the error-logging middleware will have that stuff available, but that doesn't actually work very well because you're never going to remember to put random fields like user ID on those. Instead, something like Asaf suggested above would probably be better - we can store extra log fields on the current request context, and log them on errors. - Logging structured stuff in general. Zerolog is just pretty gross, frankly—it has [poor stack trace handling](https://github.com/rs/zerolog/pull/303), it _doesn't_ handle multiple stack traces, and the API is just clunky. It's cool and all that it avoids allocations, but the API is just annoying and I don't think we even care. Our performance constraints are just not that tight. - Logging of our custom performance metrics. If we do our own thing, we could just give this a privileged place in the log output instead of working it into Zerolog's formatting.

image.png

468 KiB

bvisness added the

hmmmm

label 2022-05-21 23:44:12 +00:00

AsafGartner referenced this issue

2022-07-11 15:48:28 +00:00

Twitch tracking sometimes misses streams #68

Sign in to join this conversation.