24 pointsby benoitgaudin16 days ago4 comments
  • murrion15 days ago
    At first I assumed this was similar to trace IDs, but it’s solving a different problem.

    This is more like giving stable IDs to individual log statements (e.g. “upload started”, “upload retrying”, “upload failed”, “upload completed”), so you can see higher-level trends.

    It makes it easy to see whether failures dropped after releasing a fix, without relying on fragile text searches.

    Useful for team leads or engineering managers who want a high-level view of how system behavior changes over time.

    • benoitgaudin15 days ago
      Exactly. The combination of trace IDs and statement IDs is also a very interesting topic as it has the potential to provide an abstracted view of the runtime behaviours of a system, making is easier to spot when those changes (e.g. as a result of a new version release).
  • 16 days ago
    undefined
  • SJBluePen16 days ago
    Are these accessible through an MCP?
    • benoitgaudin15 days ago
      We are investigating how to best leverage coding assistants to inject statement IDs into source code. So far, our experience is that there is no need for MCP tools in order to achieve it. A tool would make sense in order to report the (log statement, statement ID) mapping to backends though and this is something we are planning to add to our MCP server: https://github.com/brontoio/bronto-mcp-server
  • glennster16 days ago
    This is another step on the path to auto-healing - takes away a bunch of process effort and focuses on the root cause. AI SREs (and real ones) will love it
    • tparso16 days ago
      Super exciting time to be closing the loop between code and telemetry data - interested to see what this simple but powerful idea might bring to the world of coding agents, SRE agents and vibe platforms