Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Telemetry: Collect enabled core modules #5185

Open
klonos opened this issue Aug 29, 2021 · 10 comments · May be fixed by backdrop/backdrop#4444
Open

Telemetry: Collect enabled core modules #5185

klonos opened this issue Aug 29, 2021 · 10 comments · May be fixed by backdrop/backdrop#4444

Comments

@klonos
Copy link
Member

klonos commented Aug 29, 2021

This is part of the #285 meta.

@klonos klonos changed the title Telemetry: Gather data to determine enabled core modules Telemetry: Collect enabled core modules Aug 29, 2021
@stpaultim
Copy link
Member

I agree that this could be some very useful data.

@ghost
Copy link

ghost commented Jun 25, 2022

PR: backdrop/backdrop#4107

image

Might have to start thinking about how to format the data differently on the Telemetry page compared to how it's sent to B.org...

@indigoxela
Copy link
Member

TBH, I'm not so sure if this provides any useful info. A very long string imploded with "," will almost always be unique per site. And server-side no arrays are supported AFAIK, so it probably has to be that pointless long string.

@stpaultim
Copy link
Member

stpaultim commented Dec 2, 2022

Knowing which core modules are enabled is helpful. BUT, having the data in a single long string, might not be helpful. What I think MIGHT be helpful is a list of all core modules with a note next to each one indicating what percentage of reporting sites have that module enabled.

I can see that this is probably a much bigger task.

@jenlampton
Copy link
Member

Is this a bug fix or a new feature? I think it will need tests, so changing to new feature.

@klonos
Copy link
Member Author

klonos commented Jan 6, 2023

A very long string imploded with "," will almost always be unique per site. And server-side no arrays are supported AFAIK, so it probably has to be that pointless long string.

Yeah 😓 ...I don't see an easy way to be getting metrics about all enabled modules. Not saying that we should drop this idea, but perhaps for the time being it would be easier if we collected one metric per module. ...not ideal, I know, but otherwise we need some serious rework of the code on the receiving end on b.org 🤔

@klonos
Copy link
Member Author

klonos commented Jan 6, 2023

...here's a though: if you exclude all the test modules and all the hidden/required modules, core currently has 8 disabled vs 37 enabled modules in the standard installation profile (which is the profile being used by 98% of the sites according to https://backdropcms.org/project/backdrop/telemetry). Although people might have disabled some of the enabled-by-default OOTB modules post installation, the disabled-by-default modules are the following:

book
contact
entityreference
language
locale
simpletest
syslog
translation

Out of that list, we only have issues in the queue for entityreference (to have it be enabled by default - see #5913) and for syslog (to have it removed from core altogether - see #1260). I don't think that we currently have any intention to remove simpletest, nor book, nor contact, nor any of the language/locale/translation modules either. So how about for starters we gather some "targeted" metrics for syslog and entityreference specifically, and when we have a better way to gather array-based data, we adjust telemetry to gather metrics for all enabled and disabled core modules?

@klonos klonos self-assigned this May 26, 2023
@klonos
Copy link
Member Author

klonos commented May 26, 2023

We have discussed this during the dev meeting today, and have concluded that we'd better collect metrics for disabled core modules instead. Also, due to the limitation of the current implementation of telemetry, we unfortunately will need to collect one metric per module instead of an array of modules (otherwise we'd be getting combinations of modules as results in the telemetry, which is not ideal).

I'll work on a PR for this.

@klonos
Copy link
Member Author

klonos commented May 27, 2023

...I've worked on this on my local, and this is what I have so far:
image

The code generates a list of all disabled core modules on the site, and sends an individual metric for each one of them. I realized though that this is not ideal, nor what we really want: the above will result in individual metrics in https://backdropcms.org/project/backdrop/telemetry, which will be showing various disabled modules, which is good 👍🏼 ...however, each metric will be showing 100% as its percentage, since all sites will be reporting only disabled modules ...which means that the only useful metric will be the count (and then we'd need to be comparing that to the other non-disabled-modules metrics to get a total and do the maths in our heads ...no good 👎🏼).

I think that as things are at the moment (with the limitations of the current implementation of our Telemetry system), we'd be better off if we hard-coded the list of modules that we wanted metrics for, and we gathered metrics on whether these specific modules are enabled or disabled (as opposed to sending metrics of ALL disabled modules on the various sites).

Thoughts?

@klonos
Copy link
Member Author

klonos commented May 27, 2023

...OK, I filed a PR that checks a specific, hard-coded list of core modules, end reports whether these are enabled or disabled: backdrop/backdrop#4444

image

For now, I have excluded the simpletest module from that list (since the most common use for it is to be enabled when people want to contribute and run tests, otherwise it must be disabled on production.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment