David from Sentry here. If yall have feedback around Spotlight we’d love to hear it. This is a passion project for a few of us and seemed like a natural fit for our technology, and becomes especially interesting with the service oriented world we all find ourselves in.
Both say 'Unable to connect' for me (Firefox built in page) in the UK. Which I think means the name resolved but no response. (But I'm on mobile so can't say more than that.)
Are you using NextDNS by chance? Someone reported an issue with it blocking the domain on there, but it was unclear _which_ setting was blocking it. Was also odd given its just a Vercel website and the domain (afaik) was unused prior.
The domain name is new, and those get blocked by many DNS-based ad-blocks. I use NextDNS and get the same error - spotlightjs.com is blocked (resolves to 0.0.0.0)
NextDNS calls this "Block Newly Registered Domains (NRDs)", and applies to all domains <30 days. ZScaler has something similar for corporate users, so people connecting from work might see a big red warning page.
It happens I frequently enough that I forgot it, I've used NextDNS for at least a year, and it's happened at most once before. How often do you try (deliberately) to use something so newly registered?
Frankly even most new things have older domains. (I know I'm not alone here in having domains registered for projects that may or may not ever materialise..!)
Also maybe worth saying that it's not even really about NextDNS as a tool, it's that block list or ones like it. I'm not sure if it's enabled by default or not.
More control and far lower barrier to hack on. This actually opens up a lot of doors for us even if you ignore usability and discoverability. For example, we have a POC that pops the overlay when a server error happens, giving you a rich debug experience where otherwise you might not be able to have one.
Mostly other devs seeing instrument.js everywhere in devtools vs. the actual source. The issue is for all envs and in development has been most problematic.
So obscuring console.log or network initiators the way Sentry currently does.
Webpack and bundlers seem to generally have this problem too. Sourcemaps help resolve when present in dev.
Hey David! Few questions: I'm slightly stuck with the Vite plugin
Currently getting this when trying to do an npm run dev:
[plugin externalize-deps] No known conditions for "./vite-plugin" entry in "@spotlightjs/sidecar" package
The plugin "externalize-deps" was triggered by this import
vite.config.ts:7:29:
7 │ import spotlightSidecar from '@spotlightjs/sidecar/vite-plugin';
Should I be telling externalize-deps to leave it alone somehow?
Also, I note the PHP SDK has gotten support for Spotlight - are there plans to do the same for the .NET SDK too?
Let me circle back on the Vite issue. Bundles are the biggest challenge when doing this turns out :)
Would you mind opening a GitHub so we can circle back there?
Regarding .NET - it’s coming to all Sentry SDKs (even mobile!). They were looking at .NET already but I’m not sure off hand what prevented its release. I’d expect our other core languages have full support in the next 60 days.
> Let me circle back on the Vite issue. Bundles are the biggest challenge when doing this turns out :)
>
> Would you mind opening a GitHub so we can circle back there?
For anyone else in this boat, I got it working by adding "type": "module" to my package.json file. Getting Tailwind to play nice with this was a bit of a battle, and I didn't manage to figure out how to import the defaultTheme properly, but Spotlight works flawlessly and the Vite plugin auto-starts the sidecar.
Yep- runs fully local! We had to make some small changes to our SDKs to support the sidecar, but a fundamental goal was that this was free software and valuable without the core Sentry service.
Can we stop this? There's only so many names in this world and we're going to find overlap. If you're afraid of confusing two projects that are two completely separate things just because they share the same name, instead of reading what you're using, that's a you issue, not the projects.
Its run on your local device - its just a local devserver that allows Sentry's SDKs to pipe data to it. The overlay (the Spotlight UI) then connects to the sidecar via a Server-Sent Events stream (basically a pubsub HTTP stream which operates unidirectional - think websockets but simpler). This is needed due to the distributed nature of services, but our goal is to push this abstraction into dev servers, e.g. Vite.
Its related in that we (Sentry) built it, and that it uses Sentry's open source SDKs to create its payloads, but its separate in that it doesnt require Sentry's monitoring service to work.
Hopefully that helps, and definitely something that is quite tough to clarify but we are still looking to improve upon.
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.
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.
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.
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
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.
It basically leverages the Sentry SDKs during development and sends them into a local UI rather than a production Sentry instance. It also shows the data in a way that's more akin to local development.
It leverages the sentry SDKs so not so much a replacement but something else that you can use during local development (vs sending this data to the Sentry dashboard which is a little odd in development).
Feature request: documentation for running this with a Python web app. It looks to me like it should work - the Python Sentry library can presumably publish to the local Spotlight forwarder.
I don't have a npm/npx/etc build mechanism setup, so I'd appreciate instructions for running a separate web server to serve the UI, rather than running the UI integrated directly into my existing Python web application.
It seems to be getting more and more common to leave your git repository completely undocumented. If you're releasing a software project on github, I want to read about it on github.
A basic README that outlines what it does, how it does it, and basic syntax - this is really easy. Table stakes, I might say. I can checkout your repo and I have everything I need to work
Don’t disagree, but technically the docs are in the same repo. Not easily consumed though.
We removed bits from the readme as it kept becoming duplicated and eventually wrong. I think that’s the usual reason folks like to avoid it. DRY and all.
Hey I see you are interested in spotlight and 78 other things and your ip belongs to fortune 1k. May be you should buy the sentry enterprise license. Just my ads. I work on martech.
I assume you're not talking about this company because there is no such script on spotlightjs.com (easily verifiable), and the docs are also actually in the repository:
It's a terrible habit. Documentation is a nonfunctional requirement. It should describe what is not obvious to someone new and the value of it. Without the conveyance of utility and purpose, all of a project's potential value goes to waste with foot-gunning accuracy.
In this case it makes sense: it’s a UI widget. We wrote the proxy also in Node just because you already likely needed JavaScript to install the UI component that it felt logical.
Aside, 2019 and onward JavaScript has become the largest and fastest growing ecosystem of developers.
To others feedback though there’s no reason we should force you to take a bundler running in your UI. We’re gonna fix that quickly.
This doesn't seem to be it, but I always wondered if it would make sense to have an extension to the IDE that uses the aggregated data from Sentry to highlight lines of code that have caused errors or slowdowns.
82 comments
[ 2.9 ms ] story [ 139 ms ] threadOnly http
NextDNS calls this "Block Newly Registered Domains (NRDs)", and applies to all domains <30 days. ZScaler has something similar for corporate users, so people connecting from work might see a big red warning page.
I guess I can see the upside in terms of helping avoid newly registered phishing sites, but I don't think I could live with the downsides.
Frankly even most new things have older domains. (I know I'm not alone here in having domains registered for projects that may or may not ever materialise..!)
Also maybe worth saying that it's not even really about NextDNS as a tool, it's that block list or ones like it. I'm not sure if it's enabled by default or not.
Often when myself or one of my friends launches a new web project!
So obscuring console.log or network initiators the way Sentry currently does.
Webpack and bundlers seem to generally have this problem too. Sourcemaps help resolve when present in dev.
Currently getting this when trying to do an npm run dev:
Should I be telling externalize-deps to leave it alone somehow?Also, I note the PHP SDK has gotten support for Spotlight - are there plans to do the same for the .NET SDK too?
Would you mind opening a GitHub so we can circle back there?
Regarding .NET - it’s coming to all Sentry SDKs (even mobile!). They were looking at .NET already but I’m not sure off hand what prevented its release. I’d expect our other core languages have full support in the next 60 days.
>
> Would you mind opening a GitHub so we can circle back there?
For anyone else in this boat, I got it working by adding "type": "module" to my package.json file. Getting Tailwind to play nice with this was a bit of a battle, and I didn't manage to figure out how to import the defaultTheme properly, but Spotlight works flawlessly and the Vite plugin auto-starts the sidecar.
I'm actually looking forward to it, I wanted to try on NuGet Trends but stopped on the first hurdle: https://github.com/dotnet/nuget-trends/pull/247
Pretty cool that this is a feature. I was assuming you'd be required to use Sentry to use Spotlight.
Could be confusion
stop vs spot
Is the sidecar run on the server or in the client?
Added a ticket to track improving the docs here: https://github.com/getsentry/spotlight/issues/242
It seems like it isn't, but I can't tell from looking through the website. If it's totally separate, that's a quite unfortunate namespace collision
Hopefully that helps, and definitely something that is quite tough to clarify but we are still looking to improve upon.
Also added a ticket here to track this in case other folks have thoughts: https://github.com/getsentry/spotlight/issues/243
The other thing to note: OTel doesn’t do everything and Sentrys error context is a big part of the value prop.
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.
[0] https://github.com/open-telemetry/opentelemetry-collector-co...
The idea is that any data source could stream to the sidecar and at the same time consume from it with a curated panel in the UI.
If you’re interested in poking around def hop in our Discord (https://discord.gg/sentry #spotlight) and let us know your thoughts.
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)
[0] https://thewebshowcase.withgoogle.com/bring-code-from-platfo...
Most of these types of home page seem to be written assuming I already know what their tool does.
Makes it much easier to debug local systems during development.
Same kind of thing for errors- takes something that shows up in a console somewhere and brings it into a UI.
I don't have a npm/npx/etc build mechanism setup, so I'd appreciate instructions for running a separate web server to serve the UI, rather than running the UI integrated directly into my existing Python web application.
Feel free to add a GitHub issue with more details if that’s easier!
Or even something like "npx sentry-spotlight-http-server" which starts a server running containing the UI.
1- serve the widget from the sidecar 2- add the CDN distro
A basic README that outlines what it does, how it does it, and basic syntax - this is really easy. Table stakes, I might say. I can checkout your repo and I have everything I need to work
We removed bits from the readme as it kept becoming duplicated and eventually wrong. I think that’s the usual reason folks like to avoid it. DRY and all.
Example: https://github.com/getsentry/spotlight/blob/main/packages/we...
Aside, 2019 and onward JavaScript has become the largest and fastest growing ecosystem of developers.
To others feedback though there’s no reason we should force you to take a bundler running in your UI. We’re gonna fix that quickly.