DAEMON_START metric should not be greater than APP_READY

[SgtPooki]

Describe the bug
Our countly latency dashboard shows DAEMON_START count as greater than APP_READY. This should not be the case, ever. If anything, DAEMON_START count should be lower than APP_READY count, because of users who are running the desktop app with a daemon already running.

To Reproduce
No specific reproduction steps yet, need to investigate.

Expected behavior

• DAEMON_START count should be less than APP_READY count, always.
• DAEMON_START duration should be less than, or equal to, APP_READY duration, for individual sessions.

Screenshots

Additional context
Countly metrics dashboard is only available internally at Protocol Labs on the GUI team.

[hacdias]

@SgtPooki I think you misunderstood what DAEMON_START is.

DAEMON_START count should be less than APP_READY count, always.

DAEMON_START is triggered when the IPFS daemon starts. By default, the IPFS daemon starts after starting the app (APP_READY). However, you can stop the daemon at any time through the menubar and later start it again. You can also restart it through the menubar. All this actions lead to a sequence of events DAEMON_STOP -> DAEMON_START while the application is running. Therefore, you can have multiple DAEMON_START per APP_READY.

I agree that the number of DAEMON_START events seems unproportional compared to APP_READY. However, I'm sure there are people that have IPFS Desktop running and only turn on the daemon sometimes. Others might restart the daemon to try to fix some error.

DAEMON_START duration should be less than, or equal to, APP_READY duration, for individual sessions.

Not necessarily because of the reason mentioned above. Any other DAEMON_STARTs that do not happen while APP_READY will also count for the statistics. However, just like I said above, it feels a bit unproportional.

[SgtPooki]

It does feel really out of sorts.

My intention with app_ready was to encapsulate the time it takes for the app to open, from start to close, including the pieces that make up the whole app_start process.

If our daemon_start metric is being influenced by daemon toggling outside of the initial app opening, then those are not pieces of app_ready. We need to find or define all the pieces so we can be efficient with our latency improvement work. I think we need a new metric, to encapsulate how long it takes the daemon to start only during application open.

I think this "daemon_start" is more intuitive than anything else for that metric and the desired count you describe could be named something else; Maybe "daemon_toggle_off" and "daemon_toggle_on"

Or maybe "daemon_start_init",could be the new metric that's part of "app_ready."

We should probably also have a "daemon_runtime" or "daemon_uptime" metric that shows how long "sessions" of the daemon running are.

@hacdias @lidel thoughts?

[SgtPooki]

only turn on the daemon sometimes.

Others might restart the daemon to try to fix some error.

We should have a metric to count each of these events, separately, to understand why daemon_start is currently so high.

Also, if someone opens the app and then kills the daemon, we should have a metric to accumulate downtime: "daemon_downtime"