Live data from Hacker News

Show HN: TraceRoot – Open-source agentic debugging for distributed services

github.com

21–28 of 28 posts

Re: Show HN: TraceRoot – Open-source agentic debugging for distributed services

#21

Very cool! I have a question, how are you evaluating the performance while you develop this. Do you have some golden set of examples that you evaluate against?

Great question! Yes, we're actively building a golden test set of debugging scenarios with known root causes and failure patterns. This allows us to systematically evaluate and improve agent performance with every release. Contributions are very welcome as we expand this effort!

In the meantime, we lean on explainability, i.e. every agent output is grounded in the original logs, traces, and metadata, with inline references. So if the output is off, users can easily verify, debug, and either trust or challenge the agent’s reasoning by reviewing the linked evidence.

Re: Show HN: TraceRoot – Open-source agentic debugging for distributed services

#22

How do you evaluate the output of your trace tool? Are some benchmarks for tracing tools?

Yep, we're working on a golden test set with known root causes to benchmark and track agent performance over time. It's taking a bit of work to get right, but we're on it and definitely open to contributions!

Re: Show HN: TraceRoot – Open-source agentic debugging for distributed services

#23

I'm curious -- let's say we have claude code hooked up to MCPs for jaeger, grafana, and the usual git/gh CLIs it can use out-of-the-box, and we let claude's planner work through investigations with whatever help we give it. Would TraceRoot do anything clever wrt the AI that such as a setup wouldn't/couldn't? (I'm asking b/c we're planning a setup that's basically that, so real question.)

Good question! Your setup already covers a lot — but TraceRoot tries to go a bit further in a few areas: In TraceRoot, we organize all logs, metrics, etc. around traces and build an execution tree. This structured view makes it much easier for our agent to reason through the large amount of telemetry data using context-aware optimizations. (We plan to support slack and notion integration as well.) It’s not a one-off…

I don't understand - otel does that unification already. Traces connected to logs etc.. I'm still missing something...

Re: Show HN: TraceRoot – Open-source agentic debugging for distributed services

#24

Earlier quoted context omitted.

Good question! Your setup already covers a lot — but TraceRoot tries to go a bit further in a few areas: In TraceRoot, we organize all logs, metrics, etc. around traces and build an execution tree. This structured view makes it much easier for our agent to reason through the large amount of telemetry data using context-aware optimizations. (We plan to support slack and notion integration as well.) It’s not a one-off…

I don't understand - otel does that unification already. Traces connected to logs etc.. I'm still missing something...

Thanks for the follow-up. Let me try to clarify!

When we say we "organize all logs, metrics, and traces", we mean more than just linking them together (which otel already supports). What we’re doing is:

- context engineering optimization: We leverage the structure among logs, spans, and metadata to filter and group relevant context before passing it to the LLM. In real production issues, it's common to see 10k+ logs, traces, etc. related to a single incident — but most of it is noise. Throwing all that at agents usually leads to poor performance due to context bloat see https://arxiv.org/pdf/2307.03172. We're working on addressing that by doing structured filtering and summarization. For more details see https://bit.ly/45Bai1q.

- Human-in-the-Loop UI: For cases where developers want to manually inspect or guide the agent, we provide a UI that makes it easy to zoom in on relevant subtrees, trace paths, or log clusters and directly select spans to be included in the reasoning of agents.

The goal isn't just unification, it's scalable reasoning over noisy telemetry data, both automated and interactive.

Hope that clears things up a bit! Happy to dive deeper if useful.

Re: Show HN: TraceRoot – Open-source agentic debugging for distributed services

#25

I can connect MCP for Datadog/NewRelic/Cloudwatch logs. Cursor or ClaudeCode would give me all that I need. Are you doing something new here?

Fair question. Here’s how TraceRoot is different. - We don’t just stream raw logs/traces into an LLM, we build execution trees and correlate data across services and threads. That gives our agent causal context, not just pattern matching. - It’s designed to debug real issues in production, where things are messy, not just dev or staging. - We are aiming for automatic bug detection and remediation soon, not just copil…

Sentry does that. Also most observability platforms have tracing built in. All of this can be fed into LLM using MCP.

I saw your video...and I see that it makes things easy to understand (in right panel) at any node.

Re: Show HN: TraceRoot – Open-source agentic debugging for distributed services

#26

Earlier quoted context omitted.

I don't understand - otel does that unification already. Traces connected to logs etc.. I'm still missing something...

Thanks for the follow-up. Let me try to clarify! When we say we "organize all logs, metrics, and traces", we mean more than just linking them together (which otel already supports). What we’re doing is: - context engineering optimization: We leverage the structure among logs, spans, and metadata to filter and group relevant context before passing it to the LLM. In real production issues, it's common to see 10k+ logs,…

The second link helps

It's interesting to wonder if 80% of the question answering can be achieved as a prompts/otel.md over MCPs connected to Claude Code and let agentic reasoning do the rest

Ex:

* When investigating errors, only query for error-level logs

* When investigating performance, only query spans (skip logs unless required) and keep only name, time. Linearize as ... .

* When querying both logs & traces, inline logs near relevant trace as part of an llm-friendly stored artifact jobs/abc123/context.txt

Are there aspects of the question answering (not ui widgets) you think are too hard there?

Re: Show HN: TraceRoot – Open-source agentic debugging for distributed services

#27

Earlier quoted context omitted.

Fair question. Here’s how TraceRoot is different. - We don’t just stream raw logs/traces into an LLM, we build execution trees and correlate data across services and threads. That gives our agent causal context, not just pattern matching. - It’s designed to debug real issues in production, where things are messy, not just dev or staging. - We are aiming for automatic bug detection and remediation soon, not just copil…

Sentry does that. Also most observability platforms have tracing built in. All of this can be fed into LLM using MCP. I saw your video...and I see that it makes things easy to understand (in right panel) at any node.

We provide an easy to use solution that Sentry is quite complex to use by connecting code context to corresponding loggings and tracings. Also, directly using MCP with LLMs may hallucinate if there are too many tool candidates and if there are a lot of loggings (which is very common) We need to have some optimizations to improve the both of the efficiency and reduce the context fed into the LLMs. An example is shown in this README https://github.com/traceroot-ai/traceroot/tree/main/rest/age... There is also some cursor like UI in TraceRoot to better involve human in the loop which is crucial to minimize the context length and other platforms such as Sentry does not have.

Re: Show HN: TraceRoot – Open-source agentic debugging for distributed services

#28

Earlier quoted context omitted.

Thanks for the follow-up. Let me try to clarify! When we say we "organize all logs, metrics, and traces", we mean more than just linking them together (which otel already supports). What we’re doing is: - context engineering optimization: We leverage the structure among logs, spans, and metadata to filter and group relevant context before passing it to the LLM. In real production issues, it's common to see 10k+ logs,…

The second link helps It's interesting to wonder if 80% of the question answering can be achieved as a prompts/otel.md over MCPs connected to Claude Code and let agentic reasoning do the rest Ex: * When investigating errors, only query for error-level logs * When investigating performance, only query spans (skip logs unless required) and keep only name, time. Linearize as ... . * When querying both logs & traces, inl…

Yes, we can connect for example CC with MCPs. But this may not work well for example if user wants to check the latency for previous 10 days error log on function A. By using MCP the agent needs to get 10 days error logs at first and then somehow get the latency and correlates them, apply filters for function A. IMO it will hallucinate a lot if there are too many tools, logs and traces. But on TraceRoot platform we "mixed" all necessary data at first, and based on user's query apply filters on structured data, which is more accurate, straightforward and efficient. Here is the README of the general design https://github.com/traceroot-ai/traceroot/tree/main/rest/age...
Post reply on HN