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.
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).
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
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
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
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.