[Telemetry] Use server's lastReported on the browser

[afharo]

Summary

Resolves #87846.

This PR normalizes the logic to decide whether to send telemetry or not:

• Moves isReportIntervalExpired to common so both the server and public ends use the same logic to decide whether the lastReport date is expired.
• On the UI, it requests the stored value on the server-side so, if the server or any other browser has already reported telemetry in the expected interval (24h), it will skip it on this browser (cc @thesmallestduck @elastic/infra-telemetry).
• On the server, the stored value also applies now. So, the same behaviour applies to the UI: if another Kibana instance or any browser has reported telemetry in the last 24h, it won't report again.

NOTE: All these changes are done in favour of reducing the number of requests, hence, the load of Kibana and Elasticsearch due to the generation of the telemetry report multiple times per day.

Checklist

Delete any items that are not applicable to this PR.

• Unit or functional tests were updated or added to match the most common scenarios

Risk Matrix

Delete this section if it is not applicable to this PR.

Before closing this PR, invite QA, stakeholders, and other developers to identify risks that should be tested prior to the change/feature release.

When forming the risk matrix, consider some of the following examples and how they may potentially impact the change:

Risk	Probability	Severity	Mitigation/Notes
It may fail to store the lastReported updated value after a successful send if the process goes down, the tab is closed or there's a network issue right between the successful report and the SO update.	Low	Low	A new report may be generated if the "in-memory" value says so. However, this is not an issue per-se. It will only momentarily add some extra load to the servers.
Having one sender per day reduces some visibility in our usage: it'll be harder to know how many different instances of Kibana are running for the same cluster, we'll get fewer reports, meaning fewer variability in the user-agents	High	Low	We should actually collect that information explicitly instead.

For maintainers

• This was checked for breaking API changes and was labeled appropriately

[afharo]

only removed the unused elasticsearch

[afharo]

This implies the 2nd risk I listed in the description of the PR. I hope we're OK with it.

[elasticmachine]

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

[afharo]

@elasticmachine merge upstream

[Bamieh]

With this PR we're basically removing any redundancy in reporting telemetry usage. since we have no way to confirm that we actually got the data other than the status: 200 to check if the endpoint is reachable we'd be risking losing usage due to any connectivity issues.

Do you think adding another counter redundancyFactor that allows reporting usage 3 times a day for example before shouldSendUsage starts returning false? This way we have some redundancy while reducing the number of telemetry calls.

We'd also need product approval (@thesmallestduck ) that we are OK with losing any kind of redundancy we have.

Note that we do cache usage now every 4 hours so the cost of redundancy is greatly reduced.

[afharo]

since we have no way to confirm that we actually got the data other than the status: 200

Shouldn't this highlight an issue on the receiving side instead? IMO, if the request made it to the receiving end, that's a success from the Kibana POV. IMO, we shouldn't overload Kibana at the cost of performance to overcome issues on the receiving end.

If the users find that Telemetry is heavily decreasing the performance of their deployments, they'll simply disable it. I'd rather lose 1 day worth of telemetry (if the receiving end falsely replies 200) vs. missing the entire dataset.

We'd also need product approval (@thesmallestduck ) that we are OK with losing any kind of redundancy we have.

I completely agree! Adding him as a reviewer to make sure we wait for his approval.

Note that we do cache usage now every 4 hours so the cost of redundancy is greatly reduced.

Indeed it does! However, IMO, there are some cases that are not covered by the caching solution: big deployments with multiple instances of Kibana behind a load balancer, serving a high number of users. Each additional Kibana instance in the deployment will come with the cost of one "empty cache". This PR allows scalability at zero cost.

The cache mechanism is still useful for any retries we may need due to the receiver being down.

[afharo]

@elasticmachine merge upstream

[kibana-ci]

💚 Build Succeeded

• Buildkite Build
• Commit: 4ca341a
• Storybooks Preview

Metrics [docs]

Module Count

Fewer modules leads to a faster build time

id	before	after	diff
telemetry	28	29	+1

Page load bundle

Size of the bundles that are downloaded on every page load. Target size is below 100kb

id	before	after	diff
telemetry	24.3KB	24.7KB	+457.0B

History

• 💛 Build #14978 was flaky 974a425
• 💚 Build #14438 succeeded ac45fa1
• 💔 Build #14312 failed fb9e7aa

To update your PR or re-run it, just comment with:
@elasticmachine merge upstream

[thesmallestduck]

Reducing to 1 browser-transmitted payload per day is okay by me.

[kibanamachine]

💔 Backport failed

The backport operation could not be completed due to the following error:
You must specify a valid Github repository

You can specify it via either:

• Config file (recommended): ".backportrc.json". Read more: https://github.com/sqren/backport/blob/e119d71d6dc03cd061f6ad9b9a8b1cd995f98961/docs/configuration.md#project-config-backportrcjson
• CLI: "--upstream elastic/kibana"

The backport PRs will be merged automatically after passing CI.

To backport manually run:
node scripts/backport --pr 121656

[afharo]

💚 All backports created successfully

Status	Branch	Result
✅	8.0

Note: Successful backport PRs will be merged automatically after passing CI.

Questions ?

Please refer to the Backport tool documentation