-
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
[Lens] Formula: Time scaling #94605
Comments
Pinging @elastic/kibana-app (Team:KibanaApp) |
I was expecting that we'd do time scaling as a named parameter, not a separate function. But no strong opinion about how we do this. |
If we do it as a named parameter the user can't use it on a math node anymore: That's not a big issue because time scaling is distributive and I can't think of a good reason to do anything else besides adding / subtracting time scaled metrics, so would work just as well. It still seemed more consistent to me to have it as a separate function because it's very similar in nature to calculations like |
Brainstorming some alternatives here, just for completeness:
I think the |
Agreed, this should be the go-to solution. This issue was meant as an extension of this for the cases a global setting won't work
I'm not sure whether I'm a big fan of this - as there are edge cases with uneven intervals (like months, leap years, DST switches and so on), I think a function would be a cleaner approach because we handle these cases already. |
Just to be sure: as of now (8.1.0), I cannot accomplish any "normalize by time unit" output in lens for data coming from a custom formula? My use case is to display an index against its |
@ojdo That's correct, but by using the "customize interval" option for the underlying date histogram, the bucket size will stay the same for most situations, so you could hardcode the value in there: Caveat: If the user selects a long time range (e.g for the hour interval more than a week), Lens will change the used interval and the calculation won't be accurate anymore. You can push out that limit by increasing the value in advanced settings here: But the general point still applies, it will just happen later. If that works for your use case it might be a good work around until we will get to this feature. It's planned for the near term future though (probably 8.3) |
First, thanks for confirming and fueling my anticipation for future 8.x releases. |
This can be built super similar to the existing Line 28 in 4681a80
|
It's easy to allow the user to do time scaling of the full formula using the UI outside of the formula syntax itself.
However in some cases, it's easier to understand or even necessary to do time scaling of just a part of the formula which requires a way to call it from within the formula.
Implementation
Add a function
time_scale(<metric or math>, unit=<unit>)
(unit is s/m/h/d, metric is just another AST node) which compiles in the same way as a calculation operation like cumulative sum (nested math is calculated as a separate operation, then the time scaling, then the root math context as a separate operation) and uses the existing time scale expression function.Use case
Adding a counter metric and a gauge metric:
time_scale(counter_rate(max(in_bytes)), unit=s) + last_value(internal_traffic_speed)
The text was updated successfully, but these errors were encountered: