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

Cross posting from the github issue on this:

Hey peeps! We forgot to follow up on this one. We haven’t actually implemented it, but what we’ve done is something better & definitively cooler that provides some key activity metrics per month from the server you’re an admin at:

Screenshot 2021-06-24 at 21 50 09
(from our internal testing server - don’t ask me how a six people team has 70 accounts registered. I think I might’ve run the user tests against our server by accident once or twice :grimacing:)

What you see is some key stats - total number of users, streams, commits and objects. We’ve also included historical data on said metrics which can help you identify nicely how active your server is by actually seeing how many streams, commits and objects are created each month.

We’re looking into expanding these stats slowly - MAUs is a priority (going by unique users that created commits within one month?).

There’s an api endpoint for this, of course - so you can basically request the data behind @AlanRynne’s fancy graphs and plop it wherever you want to!

For this, you will need a personal access token generated by an admin user that includes the server:stats scope:

Alternatively, just have an admin log in to the /explorer and you’re good to go for executing that query.

I’m going to close this issue for now; the activity stream is almost backend ready, and @cristi8’s wrapping up webhooks too, so all the rest will be unblocked in good time. I should probably cross-post this to the forum too :smiley:


Hey @dimitrie - looks great! We’ll dig in and have a look. For MAU’s I would include every registered user who touches the server (logging in, viewing a stream, etc…). Number of users who create commits is a useful metric as well, but it’ll be smaller than MAU.