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

v.windowPeriod in Flux queries in Chronograf 1.9 seems to be always 3ms #5810

Closed
tboehme opened this issue Sep 20, 2021 · 8 comments · Fixed by #5811
Closed

v.windowPeriod in Flux queries in Chronograf 1.9 seems to be always 3ms #5810

tboehme opened this issue Sep 20, 2021 · 8 comments · Fixed by #5811

Comments

@tboehme
Copy link

tboehme commented Sep 20, 2021

I just updated to Chronograf to 1.9 (and InfluxDB 1.8.7) and tried to use some of the newly introduced variables in Flux queries.

Custom variables seem to work, but for some reason, v.windowPeriod seems to be "stuck" at 3ms, regardless of the start/stop time window. This results in very poor performance and out-of-memory issues when trying to plot multiple days of data.

Can somebody confirm that it actually works for them using Chronograf 1.9 and InfluxDb 1.8.7? Or is this a general issue?

@sranka
Copy link
Contributor

sranka commented Sep 20, 2021

Thank you for reporting an issue. I can reproduce this issue locally. The detection fails to recognize/compute the query interval, the derived interval is then 3ms by default. It also prints an error message to console:

Error: failed to analyze query
    at rangeTimes (durations.ts:140)
    at durations.ts:116
    at Array.map (<anonymous>)
    at allRangeTimes (durations.ts:116)
    at getMinDurationFromAST (durations.ts:28)
    at _callee$ (durations.ts:12)
    at tryCatch (runtime.js:63)
    at Generator.invoke [as _invoke] (runtime.js:293)
    at Generator.next (runtime.js:118)
    at fulfilled (durations.ts:2)

This is a chronograf issue, I am now trying to find a way to fix it.

@sranka
Copy link
Contributor

sranka commented Sep 20, 2021

As a workaround, until this is fixed, you can use dashboardTime in place of v.timeRangeStart and upperDashboardTime in place of v.timeRangeStop .

@tboehme
Copy link
Author

tboehme commented Sep 20, 2021

Thanks for the prompt issue and the workaround.

If I use dashboardTime and upperDashboardTime, the initial calculation of v.windowPeriod seems to work, however, it does not change when I zoom in, so the resolution always stays the same and does not get refined when zooming.

@sranka
Copy link
Contributor

sranka commented Sep 20, 2021

If I use dashboardTime and upperDashboardTime, the initial calculation of v.windowPeriod seems to work, however, it does not change when I zoom in, so the resolution always stays the same and does not get refined when zooming.

Yes, it works this way, it is only a UI function that explores the existing result data, it does not re-execute the query.

@tboehme
Copy link
Author

tboehme commented Sep 21, 2021

When using InfluxQL the variable :interval: does adapt when zooming and data is reloaded dynamically. For us this is an essential feature in the dashboards - in my opinion, it should behave the same when using Flux.

@sranka
Copy link
Contributor

sranka commented Sep 21, 2021

Thank you @tboehme for sharing the details. Please open a new defect regarding the zoom misfunction, this one is already focusing on a different defect.

@sranka
Copy link
Contributor

sranka commented Sep 22, 2021

When using InfluxQL the variable :interval: does adapt when zooming and data is reloaded dynamically. For us this is an essential feature in the dashboards - in my opinion, it should behave the same when using Flux.

I tried it locally with chronograf 1.8.8 and 1.9.0: When using InfluxQL, chronograf also does not reload data dynamically.

@tboehme
Copy link
Author

tboehme commented Sep 22, 2021

Thanks @sranka for checking the refresh locally. With InfluxQL the refresh does work for me when zooming in Dashboards. It does not work in the explore view.

But I agree that this is a separate issue - I have opened the issue #5814 for it.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants