Sentry / Matomo override DSN

peter.grainger · 4 May 2021 19:20

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?

teocomi · 5 May 2021 09:33

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

peter.grainger · 5 May 2021 09:51

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?

dimitrie · 5 May 2021 10:03

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

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 Or actually…

peter.grainger · 5 May 2021 11:39

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.

dimitrie · 5 May 2021 14:11

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:

github.com

specklesystems/speckle-server/blob/f446af72724819e60953b46b89be93335fd9c4fb/packages/server/logging/index.js#L9


/* istanbul ignore file */
const Sentry = require( '@sentry/node' )
const Tracing = require( '@sentry/tracing' )
const { machineIdSync } = require( 'node-machine-id' )


module.exports = function ( app ) {
  const id = machineIdSync( )


  if ( process.env.DISABLE_TRACING !== 'true' && process.env.SENTRY_DSN ) {
    Sentry.setUser( { id: id } )


    Sentry.init( {
      dsn: process.env.SENTRY_DSN,
      integrations: [
        new Sentry.Integrations.Http( { tracing: true } ),
        new Tracing.Integrations.Express( { app } )
      ],
      tracesSampleRate: 0.1
    } )

For matomo, it can be disabled via DISABLE_TRACKING:

github.com

specklesystems/speckle-server/blob/f446af72724819e60953b46b89be93335fd9c4fb/packages/server/logging/matomoHelper.js#L9


const Matomo = require ( 'matomo-tracker' )
const { machineIdSync } = require( 'node-machine-id' )


const id = machineIdSync( )
const mat = new Matomo( 7, 'https://speckle.matomo.cloud/matomo.php' )


module.exports = {
  startup() {
    if ( process.env.DISABLE_TRACKING !== 'true' ) {
      mat.track( {
        url: 'http://speckle.server',
        action_name: 'startup',
        uid: id,
        cip: id,
        token_auth: '8402f0bdd767c74cce86f710fe830a2c'
      } )
    }
  },
  apolloHelper( actionName ) {

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

peter.grainger · 5 May 2021 14:12

Sounds good. Less work for me.

daviddekoning · 6 May 2021 23:29

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.

teocomi · 7 May 2021 07:33

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

daviddekoning · 13 May 2021 16:34

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)

teocomi · 13 May 2021 16:54

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!

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

daviddekoning · 13 May 2021 16:57

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

dimitrie · 24 June 2021 21:05

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 )

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

daviddekoning · 25 June 2021 19:34

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.