-
Notifications
You must be signed in to change notification settings - Fork 8.2k
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
[Regression] Telemetry Usage Stats API no longer honor timeRange
parameter
#109960
Comments
Pinging @elastic/kibana-telemetry (Team:KibanaTelemetry) |
@ycombinator sorry about the confusion. It's indeed an intentional change: #81579 We realized that each collector internally needed different ranges (#55171), no matter what the If it's not causing too much of a problem, I'd close this issue with "works as designed" flag. |
Yeah, it's fine to close this issue with the "works as designed" flag but it would be helpful if you could post here an example or two of what the equivalent calls should be starting Kibana version 7.11.0. AFAICT, this API is not documented (probably since it's an Elastic-internal API) so I can't easily tell what the new contract is. This will help us (Cloud Billing) write code to call the right APIs depending on the Kibana version, since there could be a variety of Kibana instance versions running in Cloud at any time. |
@ycombinator this is the new contract:
As you may have noticed, there is no concept of Sorry! We didn't know you used it for Cloud Billing purposes. We'll keep you in mind for any changes we may need to introduce in the future (i.e.: #96538). cc @elastic/kibana-core |
@afharo I want to clarify this part a bit. Cloud Billing's use case for this API is to know which features, e.g. Reporting, were being used between a start and end timestamp. This is because there is a process we run (roughly every hour, but the exact interval could vary a bit) that calls this API and asks the question: give me the telemetry usage stats between the last time I ran ( Starting with 7.11, since there is no concept of Also, under what conditions does this API use monitoring indices as the source vs. local collection as the source? Is this something that can vary, depending on when the API is called? |
That's kind of the reason we preferred to remove the concept of time from this API. AFAIK, this API has never returned the usage stats between
From 7.11, we stopped shipping Kibana's usage to the To identify the source of the data, if you can see I've tried to summarize all the above in the table below:
I'll cc @Bamieh just in case he wants to add anything. |
Thanks for the detailed explanation and the summary table at the end, @afharo!
When you say "full snapshot", you mean the duration between when the Kibana server started up and the time of the API request ( |
As always, IT depends 🙃 |
That makes sense, thanks @afharo. At the moment the only feature we're looking at from this API's response is Reporting. That will definitely change in the future. For Reporting (the "all" key), are the metrics from the time the cluster was created or from the time of the latest restart? |
I'll defer on @elastic/kibana-reporting-services to fully confirm. But, looking at the implementation, I'd say it's for the entire life of the cluster. |
Kibana version:
7.11.0
Elasticsearch version:
7.11.0
Describe the bug:
Up through version
7.10.0
, thePOST /api/telemetry/v2/clusters/_stats
API used to accept atimeRange
parameter in the request body like so:Starting from version
7.11.0
, however, the same API call returns the following error response:Steps to reproduce:
Expected behavior:
API honors
timeRange
parameter as before and returns usage stats.Context:
The Cloud Billing team calls this API on a periodic (roughly hourly) basis on every Kibana instance running in Cloud. We are not currently using the data returned by this API but it would be good to know whether this is indeed a regression that will be fixed or if this was a deliberate change. If it's the latter, it would also be good to know if there's an alternate way to make the equivalent request starting with Kibana version
7.11.0
.The text was updated successfully, but these errors were encountered: