containers
Telemetry: Optimize `activateExtension` event
Is your enhancement related to a problem? Please describe
This event gets fired every time an extension is started. This is leading to millions of events. 23% of all our events.
Describe the solution you'd like
Reduce the amount of events that are sent.
Idea: Can we add the extensions the users has as a property to the user.
User123:
extension.kind: enabled
extension.quadlets: enabled
That we we would only need to send an event when it changes, which would significantly reduce the events.
Idea 2: Change the event into a comma seperated string after the app has started.
activatedExtensions: kind, quadlets
That way we need to change our queries to where activatedExtensions contains "kind"
It would reduce the amount of events we send significantly but it would still create an event every time the app is started so it would be less effect than the above.
Describe alternatives you've considered
- Removing the event, but this is reallly useful for us to understand which extensions users are installing using.
Additional context
No response
only a side note:
even if we do changes, it'll done only for new versions.
All previous versions of Podman Desktop would still send data
somehow, data should be backward compliant
or we drop all the previous events at the sources / discard them
and we have new events only for upcoming new versions
All previous versions of Podman Desktop would still send data
Is there a way to prevent that? I think that will always happen, right? We might consider blocking the old event in amplitude so now new data is sent? It might be relevant for https://github.com/podman-desktop/podman-desktop/issues/12635 where we send loads of extra events
somehow, data should be backward compliant or we drop all the previous events at the sources / discard them and we have new events only for upcoming new versions
We can see the charts that use the this event here we can update the query to handle both.
After the meeting / discussion we'll be:
- Removing activateExtension in favour of a new one that sends extensions telemetry after startup, once.
- Eventually blocking activateExtension in Segment / Amplitude for users not upgrading yet.
- New one named something like "activatedExtensionsOnStartup" that will fire after all extensions try to start
- Push comma-deliminated (or array depends on implementation, see main issue) of what extensions are "enabled" on startup / use has installed by default
cc @Firewall please correct if I got anything wrong!
hello, what means 'after startup' ? How you define this time
How do you capture extensions installed/started after what you called 'startup'
hello, what means 'after startup' ? How you define this time
How do you capture extensions installed/started after what you called 'startup'
That's what I'm wondering too. Maybe there's somewhere in the code after every extension has been started where we can do the telemetry sending.
Do you have any suggestions where?
But the idea is after every extension has started up on initial opening podman desktop, to report which ones were activated / in-use.
today I can get the activation time of each extension and the error
from what I see from "optimize", currently I would loose all this important data.
how to compute also: what are the most activated extensions ? what are the most errors for a given extension ?
do we have less errors over time for an extension and a given Podman Desktop version
to me it's not answering any of these questions
The title is also misleading as it's only speaking about the name of the extension while we collect the important data: time and error
today I can get the activation time of each extension and the error
from what I see from "optimize", currently I would loose all this important data.
how to compute also: what are the most activated extensions ? what are the most errors for a given extension ?
do we have less errors over time for an extension and a given Podman Desktop version
to me it's not answering any of these questions
The title is also misleading as it's only speaking about the name of the extension while we collect the important data: time and error
That's my fault as it was an oversight that we use activateExtension (despite the name) for error tracking too.
IMHO, to reduce the amount of telemetry calls, and since the only thing we really care about is the time + error, we should optimize this by only pushing activateExtension telemetry if the extension errors out.
This allows us to optimize the call, and in the future if we want to rename it or deprecate it, we can.
I also opened up another issue that covers this one as well as https://github.com/podman-desktop/podman-desktop/issues/12634 that covers a "get info on all extensions and providers activated telemetry": https://github.com/podman-desktop/podman-desktop/issues/12708
Does that sound good?
how do I get the average activation time if it's only sent if there is an error ?
how do I get the average activation time if it's only sent if there is an error ?
We won't :'(
What other ways do you suggest we optimize?
I've been looking through the code of a way to just "collect" all information and do one event after-all-extensions-activate, but I don't see anything in extension-loader.ts or other parts of the PD core.
It's also because we load the extensions asynchronously as well.
Another suggestion would maybe we track slow activating extensions and errored out ones, in order to optimize it?
Ex.
const duration = performance.now() - start;
// Only send if it failed or took > 2 seconds
if (errorOccurred || duration > 2000) {
telemetryOptions['duration'] = duration;
this.telemetry.track('activateExtension', telemetryOptions);
}