You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I've noticed influxdb returns no data for small timespans (eg now-2s to now). This is unhelpful when we have --interval 1 -f because it's only requesting a small enough window of data to plot the next line, but influxdb will never return anything.
One possible way to improve this is to fetch a larger span of time with each refresh. This is what grafana web ui does, and it replots everything with every refresh (I guess unless it's a streaming data source, see #4). However, I don't want to fill up the terminal history with copies of the same plotted data, so if graf replots, it should move the cursor up to the line that corresponds with whatever the first time value is in the current data.
example
Let's say we've already plotted from 07:20-07:23 using 30 lines in the terminal. This would put the line corresponding to 07:21 at line 10 from the start, while the cursor is at line 30. If we wait 1 minute, and fetch data for 07:21-07:24, then in order to plot that data we should move the cursor up 20 lines (30 - 20 = 10). So we need to send \e[20A to the terminal and then plot the data.
Not clear yet what happens when we try to move up 20 lines but the screen only has eg 10 rows.
alternative - clear screen
One alternative is to ditch the line-by-line updates and instead limit the plotting to only be as big as the current terminal size, and clear the screen with each refresh. I kind of like the scrolling plot though, so I want to keep it for now, but maybe there can be another mode that jumps into terminal alt-screen to plot without filling up the terminal scroll history.
alternative - it's the user's fault
If you try to query from: now-2sto: now in grafana, it will just print no data, and it's expected that the user figures out their error and requests a larger timespan. Similarly, we could just expect the user to set --interval to a high enough value that influxdb returns data.
I've noticed influxdb returns no data for small timespans (eg
now-2s
tonow
). This is unhelpful when we have--interval 1 -f
because it's only requesting a small enough window of data to plot the next line, but influxdb will never return anything.One possible way to improve this is to fetch a larger span of time with each refresh. This is what grafana web ui does, and it replots everything with every refresh (I guess unless it's a streaming data source, see #4). However, I don't want to fill up the terminal history with copies of the same plotted data, so if
graf
replots, it should move the cursor up to the line that corresponds with whatever the first time value is in the current data.example
Let's say we've already plotted from 07:20-07:23 using 30 lines in the terminal. This would put the line corresponding to 07:21 at line 10 from the start, while the cursor is at line 30. If we wait 1 minute, and fetch data for 07:21-07:24, then in order to plot that data we should move the cursor up 20 lines (30 - 20 = 10). So we need to send
\e[20A
to the terminal and then plot the data.Not clear yet what happens when we try to move up 20 lines but the screen only has eg 10 rows.
alternative - clear screen
One alternative is to ditch the line-by-line updates and instead limit the plotting to only be as big as the current terminal size, and clear the screen with each refresh. I kind of like the scrolling plot though, so I want to keep it for now, but maybe there can be another mode that jumps into terminal alt-screen to plot without filling up the terminal scroll history.
alternative - it's the user's fault
If you try to query
from: now-2s
to: now
in grafana, it will just printno data
, and it's expected that the user figures out their error and requests a larger timespan. Similarly, we could just expect the user to set--interval
to a high enough value that influxdb returns data.references
ANSI escapes
The text was updated successfully, but these errors were encountered: