How is everyone here instrumenting exception track...
# best-practices
d
How is everyone here instrumenting exception tracking into their taps/targets?
v
Not great 😕 I have been thinking about this a bunch though. Right now if I get an exception it stops everything and gets thrown
d
same for us. I’ve been considering forking the singer-sdk and wrapping the
cli
tap method with a catch-all exception handler just for forwarding exceptions to rollbar and re-raising
v
https://gitlab.com/meltano/sdk/-/issues/134 here's the issue I put together which has a bit more detail
Sounds kinda like what you're talking about
If you could add your thoughts there, Aj was asking me some questions that I haven't had time to dive into
d
this is semi-related to what Im talking about. Im more just talking about instrumenting taps/targets such that exceptions/errors get forwarded to an error tracking service (e.g. Rollbar, Sentry, etc.)
less-so the underlying exception handling logic
v
Log aggregation is more of what you're talking about?
d
sort of! Im thinking more about exceptions than logs
concrete example - we had an exception get raised in a tap recently that never made it to datadog logs
effectively a silent failure since we arent currently forwarding exceptions anywhere
v
Seems like a major issue that exceptions are not being caught in logs!
d
yeah tbh it could also be a configuration issue. But the general idea of exception tracking being separate from log aggregation is a pretty common pattern.
v
got it! Sounds interesting I'd love to learn more
d
was really just curious if anyone here is already doing this and if there have been any patterns established around it