9 ms·
Launch HN: Patchwork (YC S24) – Automatically add structured logs to your code
Hey HN! We are Sam, Alex and Ben from Patchwork Technologies (https://getpatchwork.io https://getpatchwork.io). Patchwork automatically adds actionable structured logs to your code. Big picture: we are building a next generation logging and observability platform which gives engineers the rich debugging context they need.
There’s a demo video (https://youtu.be/ObIepiXfVx0 https://youtu.be/ObIepiXfVx0), as well as a demo^ instance with some results for you to explore at https://hackernews.getpatchwork.io https://hackernews.getpatchwork.io (no sign-in required!) The demo shows the analysis and improvement (against a style guide) of existing logs. It’s set up for two OSS repositories,
https://github.com/elastic/cloud-on-k8s https://github.com/elastic/cloud-on-k8s and our awesome friends at Glasskube (https://github.com/glasskube/glasskube https://github.com/glasskube/glasskube). We welcome suggestions of other OSS Go repositories that you would like to see added!
Why we are building this: At our previous company, we relied heavily on actionable, context-rich structured logs. They were the unsexy but critical tool for managing complex software at scale. When they’re implemented well, they allow you to understand the application state when things break. Structured logs are easier to search and run analytics on. The trouble is that they are time-consuming to implement properly – if you’re reading this, you know it’s a chore. We all know it’s usually an SRE (like Alex) that finds out at 2 am that logs were added as an afterthought. Unstructured and spammy – Error: Failed to do task. Datadog made metrics easy; we are creating that moment for logs.
We've grappled with some tough technical challenges to build our product. First, identifying log statements in codebases where logger symbols are inconsistently named or output directly to stdout/stderr. We solved this with SCIP, indexing symbol references at compile time. Next, we needed to provide the LLM with method context and variable types to ensure we accurately understand what the code is doing. This is achieved using tree-sitter for parsing and SCIP for repo navigation. Finally, we addressed the critical need to reason whether specific data can/should be logged before bringing this all together in an improved logging statement. We’re staring down the next challenge – where should logging statements go in new code?
Refactoring the logs in existing code bases today is a manual slog. Even finding the existing logging and printf statements is tricky at scale. It’s possible to rely on Copilot in VS Code or Cursor to help construct logs as you write new code. However, there are many more reasoning steps required than these tools are designed to do. They are general purpose, zero-shot machines.
Our first goal is to reliably improve existing logging statements (as in the demo). In the next couple of weeks we aim to prove-out adding logs to new applications. Structured logs provide downstream benefits when it comes to storage and query time – our final goal is to build a storage layer that exploits this.
Your honest feedback would mean a lot to us. We have a lot of conviction that observability needs a shake up, and that going back and getting the basics right is valuable. We’d love to hear what you think works and doesn’t work in current approaches, and whether Patchwork solves a problem for you. Chat with us on Discord: https://discord.gg/fkVTgX5s https://discord.gg/fkVTgX5s.
^If you'd like to enrol additional repos and run analysis on them, there's a magic link step.
- btown 2y agoThis 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 agoA 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 agoGoing 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?