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] The local strategies should call areAllCollectorsReady #79142

Closed
afharo opened this issue Oct 1, 2020 · 8 comments · Fixed by #79398
Closed

[Telemetry] The local strategies should call areAllCollectorsReady #79142

afharo opened this issue Oct 1, 2020 · 8 comments · Fixed by #79398
Assignees
Labels
enhancement New value added to drive a business result Feature:Telemetry Team:Core Core services & architecture: plugins, logging, config, saved objects, http, ES client, i18n, etc

Comments

@afharo
Copy link
Member

afharo commented Oct 1, 2020

We've noticed that the local telemetry strategies should call the areAllCollectorsReady method before fetching the data.

We should validate all collectors are ready before pushing anything.

⚠️ Mind race conditions: X-Pack might get false but OSS to get true (when they are iterating over the same collectors because of the way UsageCollection is done)

@afharo afharo added enhancement New value added to drive a business result Feature:Telemetry Team:KibanaTelemetry labels Oct 1, 2020
@elasticmachine
Copy link
Contributor

Pinging @elastic/kibana-telemetry (Team:KibanaTelemetry)

@afharo afharo added the bug Fixes for quality problems that affect the customer experience label Oct 1, 2020
@TinaHeiligers
Copy link
Contributor

Good catch!

@afharo
Copy link
Member Author

afharo commented Oct 1, 2020

All praise to @rudolf

@TinaHeiligers
Copy link
Contributor

TinaHeiligers commented Oct 1, 2020

@afharo is #79156 what you had in mind? It's very rough and doesn't handle the "race conditions" you speak of...
We need to implement the check when we send the usage data.

@Bamieh Bamieh self-assigned this Oct 4, 2020
@Bamieh
Copy link
Member

Bamieh commented Oct 4, 2020

I've debugged this and I dont think it is valid. areAllCollectorsReady is only called by the monitoring bulk uploader which sends the data to the monitoring indices. It will keep retrying until they are.

When telemetry collection is called to fetch usage it will fetch whatever is available at that time to send it. We dont want to miss sending the whole usage because of some collectors not being ready (or even all of them).

We cannot also hold from sending until they are ready because we are bound by request timeouts.

We can wait for collectors to be ready from the server side sender before sending the usage from the fetcher. I'll submit a PR for it, although this is an enhancement not a bug at this point.

@afharo afharo removed the bug Fixes for quality problems that affect the customer experience label Oct 5, 2020
@afharo
Copy link
Member Author

afharo commented Oct 5, 2020

I agree with @Bamieh. It’s an enhancement, not a bug (updated the labels). And by holding and waiting for all collectors to be ready, we risk a collector will always return isReady: false and block any telemetry collection.

On the flip side, we might suffer from race conditions where we attempt to send telemetry and miss some fields that may take a bit longer to be ready (they'll likely be on the next report 24h later).

Maybe the solution to this issue is a detailed reason of why we won't fix it 🙂
Or an improvement to only run the fetch methods for those reporting isReady: true.

@afharo
Copy link
Member Author

afharo commented Oct 5, 2020

And by holding and waiting for all collectors to be ready, we risk a collector will always return isReady: false and block any telemetry collection.

We've had a discussion about this and the method areAllCollectorsReady already takes care of this use case. So the changes in #79398 make sense to me! Thank you @Bamieh!

@lukeelmers lukeelmers added the Team:Core Core services & architecture: plugins, logging, config, saved objects, http, ES client, i18n, etc label Oct 1, 2021
@elasticmachine
Copy link
Contributor

Pinging @elastic/kibana-core (Team:Core)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New value added to drive a business result Feature:Telemetry Team:Core Core services & architecture: plugins, logging, config, saved objects, http, ES client, i18n, etc
Projects
None yet
5 participants