Sentry / Matomo override DSN

There are a few places where sentry and Matomo are configured in the server and clients, the url to send the data to is hardcoded.

I know we can disable this telemetry but what are your thoughts on allowing a different URL / Site number, so people can track there own errors and usage?

Hey Peter,

Good news is that the Sentry DSN is now an env variable SENTRY_DSN , so feel free to plug in your own there (same goes for the desktop connectros, if you guys are compiling your own versions).

Re matomo, we can’t do that atm, our company is entirely focused on Speckle and it really helps us knowing how usage/adoption is affected by the decisions we make. So please consider leaving telemetry on if you’d like to support what we do :wink:

Hi @teocomi that was quick, thanks! Are you open to putting sentry on the frontend as well? Happy to make a PR

On the Matomo front, we also use Matomo and also like to understand our usage / adoption. Is there any way we can work together so we can both get the information we need?

That could help on our end too - so yes! We’re not using it currently, but there were some moments recently where i wished we would :slight_smile:

Re matomo - since we’re anonymising everything, it needs a wee bit more thinking on how to do it. The immediate “can we use two matomos” solution probably won’t work :smiley: Or actually

The frontend looks easy enough, the server would probably require a change to the matomo-tracker library. I think we are most interested in matomo stats from the client side anyway so if I put a PR in your happy to use the setTracker command and have a environment variable for the second Matomo tracker?

Also what are your thoughts on having separate environment variables for disabling matomo and sentry? As for some installations we would want to enable our own sentry error capture but might not be allowed to send anonymised stats to your matomo for regulatory reasons.

Good point! You can control both.

Not setting the SENTRY_DNS var will disable it. There’s a superflous extra var (DISABLE_TRACING) that I should remove at one point:

For matomo, it can be disabled via DISABLE_TRACKING:

Re the secondary tracker: this sounds like a good idea! We can easily add that for the server side, unsure at the moment how easy that would be for the frontend. This will be a good way for both of us to get the data we need!

I’ve raised this as an issue that will make its way in our next sprint - and we’ll aim to have something in place by end of the month. Does this timeline sound ok? We want to do this ourselves so we internally “grok” it, as it’s quite important :slight_smile:

1 Like

Sounds good. Less work for me.

We’d be happy to join a call and share our thoughts on general event logging if that helps with the grokking. We are currently in experimenting with a single logging function in the desktop clients that passes on the events to multiple services (so that we can evaluate them), but a similar approach would work for this situation. There is also the Kafka integration we rolled into v1 that covers similar ground.

Thanks :pray:! Will def take the opportunity once we get on to it :slight_smile:

Hey @teocomi - it is important to us to see how many of our team members are using our v2 server. While we could deploy a patched version that only points to our matomo server, we would prefer to deploy the vanilla image. Would you be open to a stop-gap PR that allows a second matomo server to be defined in ENV variables and just sends all events to both servers?

These changes would be limited to this file: speckle-server/matomoHelper.js at 7709f57776e1d7b241a489f5b52234a5b1f38d80 · specklesystems/speckle-server · GitHub (and basically duplicate the current code, while pointing at the server from ENV).

The intention here is just to allow us to start getting data on usage internally, this would be replaced by a cleaner more robust solution down the line (e.g. like the one I sketched out in Secondary Matomo Tracker Value · Issue #220 · specklesystems/speckle-server · GitHub)

Hey David,

We’ll be doing some prioritization on Monday and see when it’s best to fit this, will keep you posted - and thanks for the sketch on GitHub!

In the meantime, I’d suggest inspecting your DBs directly, which should give you plenty of insights into the usage of your Speckle servers. Please let us know if you need any pointers!

We’re not big fans of stop-gap solutions as sometimes threy require more work than doing things properly :wink:

ok, thanks - we’ll deploy a patched version to point at our matomo until then

1 Like