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's the "personal" part of sprkl.
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; https://news.ycombinator.com/item?id=30779019
From https://news.ycombinator.com/item?id=31688180 :
> [ eBPF; Pixie, Sysdig, Falco, kubectl-capture,, stratoshark, ]
> Jaeger (Uber contributed to CNCF) supports OpenTracing, OpenTelemetry, and exporting stats for Prometheus.
From https://news.ycombinator.com/item?id=39421710 re: distributed tracing:
> W3C Trace Context v1: https://www.w3.org/TR/trace-context-1/#overview
Thanks for sharing all these links, super handy! I really appreciate it.
NP; improving QA feedback loops with IDE support is probably as useful as test coverage and test result metrics
/? vscode distributed tracing: https://www.google.com/search?q=vscode+distributed+tracing :
- jaegertracing/jaeger-vscode: https://github.com/jaegertracing/jaeger-vscode
/? line-based display of distributed tracing information in vs code: https://www.google.com/search?q=line-based%20display%20of%20... :
- sprkl personal observability platform: https://github.com/sprkl-dev/use-sprkl
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's the "personal" part of sprkl.