4 ms·

This looks really, really cool. In the Python world, we can rely on tools like Sentry to be able to say "on any exception or logger.warning, crawl the stack and

by btown 2y ago

This looks really, really cool. In the Python world, we can rely on tools like Sentry to be able to say "on any exception or logger.warning, crawl the stack and show me all the variables at every level." And we've also set up Honeycomb to record log entries as OpenTelemetry spans, which lets us see logs in context of database queries etc., and do structured queries about when and how certain things occur. Which means that we can just instruct our team to "err on the side of adding simple log statements, even if it's just a static string without variables; we can dig for those reactively." But in a codebase where far more of the complexity is in native code and doesn't cross network boundaries, I imagine folks feel like they're flying blind without those tools that we Python devs can take for granted. So Patchwork is desperately needed. I'd be very curious to see how your larger observability platform integrates with the broader world of OpenTelemetry, where the native code might be part of a broader distributed system. It's cool to see this space moving forward so quickly!

benjaminfh 2y ago
A big part of our journey is trying to learn the different ways people generate, collect and then retrieve context, so we really appreciate you sharing how you're doing it - thanks! Am I right in understanding that you have a two-part approach: Sentry with simply messages and all variables up the call stack + Honeycomb/OT spans. What do you collect with the spans? Regarding the platform, transparently, it's early days for us and we're focusing on vanilla structured logs (generating better ones and then later storing them efficiently in something like ClickHouse), rather than tracing. Are there particular things you'd expect to see from a platform like this?
- benjaminfh 2y ago
  Going to double tap my own reply here and come back to the OTel peice. Do you find there's a lot of effort required in adding attributes to spans through your code? A lot of people we speak to who are all-in on tracing are (we think) getting by with minimal/auto span implementation, without attributes. We're trying to keep digging and learning about how this looks at different orgs / figure out if this approach holds as systems get more complex. Would our workflow as applied to adding attributes and messages to spans be useful to you?

by btown 2y ago

benjaminfh 2y ago

A big part of our journey is trying to learn the different ways people generate, collect and then retrieve context, so we really appreciate you sharing how you're doing it - thanks! Am I right in understanding that you have a two-part approach: Sentry with simply messages and all variables up the call stack + Honeycomb/OT spans. What do you collect with the spans? Regarding the platform, transparently, it's early days for us and we're focusing on vanilla structured logs (generating better ones and then later storing them efficiently in something like ClickHouse), rather than tracing. Are there particular things you'd expect to see from a platform like this?

benjaminfh 2y ago
Going to double tap my own reply here and come back to the OTel peice. Do you find there's a lot of effort required in adding attributes to spans through your code? A lot of people we speak to who are all-in on tracing are (we think) getting by with minimal/auto span implementation, without attributes. We're trying to keep digging and learning about how this looks at different orgs / figure out if this approach holds as systems get more complex. Would our workflow as applied to adding attributes and messages to spans be useful to you?