Errors and logging are kind of wack #24

Open
opened 4 months ago by bvisness · 0 comments
Owner

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:

image

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.
468 KiB
bvisness added the
hmmmm
label 4 months ago
Sign in to join this conversation.
No Milestone
No Assignees
1 Participants
Notifications
Due Date

No due date set.

Dependencies

No dependencies set.

Reference: hmn/hmn#24
Loading…
There is no content yet.