Add tracking property for os.arch() to Amplitude / Sentry (project creation)

[gu-stav]

What does it do?

Following an internal discussion about our current support of M1 processors I got curious to find some numbers on Amplitude / Sentry, but had to learn we are currently not tracking the CPU architecture. I think for the installation this might be an interesting information and therefore I'd like to propse to track it.

os_arch could contain the following architectures: 'arm', 'arm64', 'ia32', 'mips', 'mipsel', 'ppc', 'ppc64', 's390', 's390x', and 'x64'.

Node documentation: https://nodejs.org/api/os.html#osarch

This PR adds the current CPU architecture to Amplitude and Sentry when projects are created.

Why is it needed?

I'd like to understand if users with arm64 CPU architectures have more problems installing Strapi than others.

[codecov]

Codecov Report

Merging #13872 (8e14a14) into main (e4e0981) will not change coverage.
The diff coverage is n/a.

@@           Coverage Diff           @@
##             main   #13872   +/-   ##
=======================================
  Coverage   55.58%   55.58%           
=======================================
  Files        1275     1275           
  Lines       31829    31829           
  Branches     5733     5733           
=======================================
  Hits        17692    17692           
  Misses      12323    12323           
  Partials     1814     1814           

Flag	Coverage Δ
front	58.13% <ø> (ø)
unit	49.38% <ø> (ø)

Flags with carried forward coverage won't be shown. Click here to find out more.

Impacted Files	Coverage Δ
...ges/SettingsPage/pages/ApiTokens/ListView/index.js	76.47% <0.00%> (ø)
...age/pages/ApiTokens/ListView/DynamicTable/index.js	80.00% <0.00%> (ø)

Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.

[fdel-car]

Yes, there's something to add to the tracker at the moment when you do something like this. I'll do it quickly once this PR is merged don't worry.

I second your idea, by the way, that would be quite helpful 👍

Last thing: I already shared that on Slack but I think we should be considerate with bandwidth consumption - as well as keep things a bit simpler - and stop sending all the anonymous_metadata that we add in the sender.js file along every event. As they will be considered user properties on Amplitude there's no need to do that, they will be attached to a user anyway. Sending them along willCreateProject and didStartServer should suffice for instance.

Don't worry I'm not asking for changes on that today, just wanted to share my thoughts on this, and maybe start a discussion with people interested here on GitHub.

[gu-stav]

@fdel-car That's great to hear. I was thinking something similar: I'd like to have them as part of willInstallProjectDependencies and didInstallProjectDependencies. The difference between both events does allow us to see, how many installations fail, which is the most interesting information for me at the moment.

I don't mind adding them to willCreateProject and didStartServer and I'm happy about any guidance on what you and others think would be best.

[derrickmehaffy]

@fdel-car That's great to hear. I was thinking something similar: I'd like to have them as part of willInstallProjectDependencies and didInstallProjectDependencies. The difference between both events does allow us to see, how many installations fail, which is the most interesting information for me at the moment.

I don't mind adding them to willCreateProject and didStartServer and I'm happy about any guidance on what you and others think would be best.

I agree here especially with os.arch as I imagine most of the failures at the didInstall step are going to be arm based systems (mostly arm based macs or arm based cloud providers)

[fdel-car]

User properties apply to the user for all future events until they are changed.

So my suggestion would be to maybe only send user properties whenever they could have changed, if we're confident that they would not have changed - for instance between willInstallProjectDependencies and didInstallProjectDependencies - then maybe we could avoid sending them in that case.
Not 100% sure yet that it would be the best and easiest solution, but it will lower bandwidth consumption a bit.

Lastly, keep in mind that events that are sent outside of the generators, won't benefit from your change in this PR, you'd need to also update the sender.js in the strapi package also. Yes, our telemetry code is all over the place.

[gu-stav]

@fdel-car I understand the idea, but in this case I'm not sure, because what we would want to do is to calculate the difference between willInstallProjectDependencies and didInstallProjectDependencies based on the architecture. I'd say to be able to do so, we need to send it for both events ... or do you know if Amplitude backfills them, in case the property is missing the 2nd event?

[alexandrebodin]

Hi 👋 reviving this.

Let's merge this now so we can analyze the errors more finely asap.

Those events being only sent during the creation of the project the impact is not as huge as sending that data during the normal runtime so @fdel-car you can open the discussion to put that in the backlog of the tooling squad for a bit later :)

[alexandrebodin]

Actually I was thinking about something else.

I think we need this property more on the Sentry side to debug errors during the installation process than on amplitude (we can still leave it on amplitude for consistency but not sure that's worth it as we won't do much analytics on it there probably?)

However for sentry we can add it in packages/generators/app/lib/create-project.js in the

sentry.configureScope call

[gu-stav]

@alexandrebodin That is certainly an interesting idea. Let's do that! 👍🏼

However: what do you think about keeping it for Amplitude (at least for a while) to understand the size of the problem in relation to total installations? As far as I know we currently can not have Sentry and Amplitude data in one view and would only see the total number of errors in Sentry. Therefore it might be helpful: 1) to understand the size of the problem on Amplitude 2) the mutations of the different errors on Sentry.

What do you think?

[alexandrebodin]

@alexandrebodin That is certainly an interesting idea. Let's do that! 👍🏼

However: what do you think about keeping it for Amplitude (at least for a while) to understand the size of the problem in relation to total installations? As far as I know we currently can not have Sentry and Amplitude data in one view and would only see the total number of errors in Sentry. Therefore it might be helpful: 1) to understand the size of the problem on Amplitude 2) the mutations of the different errors on Sentry.

What do you think?

Sounds good to me to have it in both places yes

[alexandrebodin]

LGTM