May I suggest adding some additional context to the home page? While I heard about Sentry I find difficult to understand what Spotlight does. I might not be the intended target audience though.
I agree and find this is the case for many projects like this. I read the homepage and have no idea what the tool does and why I might find it helpful, it wasn’t until I read the inset block on the “Getting Started” page for this one that I had even an inkling what it did.
Most of these types of home page seem to be written assuming I already know what their tool does.
Not in all cases do you get a traceback into the UI. In some cases you have to look at your terminal or console. In this case it goes straight into your browser window. But additionally it also shows you a bunch of traces going on for instrumented calls.
This seems to be a super shared point of view. I’ll admit we were a bit fire-and-forget on the homepage and definitely agree with all the feedback that we need to explain what it is better.
Is this supposed to be intended for people who are already all-in with Sentry? Or can you possibly share some insight as to where this makes sense to use vs instrumenting with an OTEL SDK?
Both. Fwiw lots of folks have yet to invest in OTel so the market is super open. We’re also trying to adjust our approach to leverage OTels community instrumentation when it makes sense. That means that ideally you’ll be able to invest in OTel if you want and we’ll just consume those spans.
The other thing to note: OTel doesn’t do everything and Sentrys error context is a big part of the value prop.
Thanks for the reply. Would the Spotlight sidecar possibly be able to run independently and consume spans emitted by the Sentry exporter[0] or some other similar flow beyond strictly exporting directly from the Sentry SDK provided by Spotlight?
This tooling looks really cool and I'd love to play around with it, but am already pretty entrenched into OTel and funneling data through the collector and don't want to introduce too much additional overhead for devs.
it looks to me like it covers the same funcionality as browser developer tools
but I am also pretty sure those are going away soon, which will mean the only way to inspect websites will be using tools like this (+ WASM binary formats + google controlled web-runtime[0] means the open web is not open anymore)
Your browser's dev tools don't show you what's happening inside your server (and any downstream services) when responding to the browser's HTTP requests. Spotlight does. That's what's special about it.
What? JS isn't getting replaced by WASM. Also some quick Googling says WASM is a joint project by the W3C and multiple browser owners, and debug tools exist for it in Chrome and Firefox already
