NP; improving QA feedback loops with IDE support is probably as useful as test coverage and test result metrics&#x2F;? vscode distributed tracing: <a href="https:&#x2F;&#x2F;www.google.com&#x2F;search?q=vscode+distributed+tracing" rel="nofollow">https:&#x2F;&#x2F;www.google.com&#x2F;search?q=vscode+distributed+tracing</a> :- jaegertracing&#x2F;jaeger-vscode: 
<a href="https:&#x2F;&#x2F;github.com&#x2F;jaegertracing&#x2F;jaeger-vscode">https:&#x2F;&#x2F;github.com&#x2F;jaegertracing&#x2F;jaeger-vscode</a>&#x2F;? line-based display of distributed tracing information in vs code: <a href="https:&#x2F;&#x2F;www.google.com&#x2F;search?q=line-based%20display%20of%20distributed%20tracing%20information%20in%20VS%20code" rel="nofollow">https:&#x2F;&#x2F;www.google.com&#x2F;search?q=line-based%20display%20of%20...</a> :- sprkl personal observability platform: 
<a href="https:&#x2F;&#x2F;github.com&#x2F;sprkl-dev&#x2F;use-sprkl">https:&#x2F;&#x2F;github.com&#x2F;sprkl-dev&#x2F;use-sprkl</a>Theoretically it should be possible to correlate deployed code changes with the logs and traces preceding 500 errors; and then recreate the failure condition given a sufficient clone of production (in CI) to isolate and verify the fix before deploying new code.Practically then, each PR generates logs, traces, and metrics when tested in a test deployment and then in production. FWIU that&#x27;s the &quot;personal&quot; part of sprkl.

Thanks for sharing all these links, super handy! I really appreciate it.

Good idea!This probably saves resources by eliminating need to re-run code to walk through error messages again.Integration with time-travel debugging would even more useful; <a href="https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=30779019">https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=30779019</a>From <a href="https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=31688180">https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=31688180</a> :&gt; [ eBPF; Pixie, Sysdig, Falco, kubectl-capture,, stratoshark, ]&gt; Jaeger (Uber contributed to CNCF) supports OpenTracing, OpenTelemetry, and exporting stats for Prometheus.From <a href="https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=39421710">https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=39421710</a> re: distributed tracing:&gt; W3C Trace Context v1: <a href="https:&#x2F;&#x2F;www.w3.org&#x2F;TR&#x2F;trace-context-1&#x2F;#overview" rel="nofollow">https:&#x2F;&#x2F;www.w3.org&#x2F;TR&#x2F;trace-context-1&#x2F;#overview</a>

We made a VS Code extension [1] that lets you visualise logs and traces in the context of your code. It basically lets you recreate a debugger-like experience (with a call stack) from logs alone.This saves you from browsing logs and trying to make sense of them outside the context of your code base.We got this idea from endlessly browsing traces emitted by the tracing crate [3] in the Google Cloud Logging UI. We really wanted to see the logs in the context of the code that emitted them, rather than switching back-and-forth between logs and source code to make sense of what happened.It&#x27;s a prototype [2], but if you&#x27;re interested, we’d love some feedback.---References:[1]: VS Code: marketplace.visualstudio.com&#x2F;items?itemName=hyperdrive-eng.traceback[2]: Github: github.com&#x2F;hyperdrive-eng&#x2F;traceback[3]: Crate: docs.rs&#x2F;tracing&#x2F;latest&#x2F;tracing

Show HN: A VS Code extension to visualise Rust logs in the context of your code