StateTimeline: Improve display when state changes are missing (outside time window) in query result

[khoek]

What happened:
My state timeline panel misses out the "first logical" point, and so leaves an unsightly blank space instead:

Here I'm querying an influxdb instance and "up" and "down" strings are being returned. Because of the irregular nature of when the up and down messages are recorded, an unsightly blank space is left at the start of the first row (as opposed to the second), because the "up" data point which should logically mean that this blank space is coloured green and is labelled "Up" is outside of the time window of values to be displayed.

Of course, this gets much worse when there are no changes in the current time window for a given row, in which case that row will entirely disappear, or if there are no rows display the entire panel will show "no data".

What you expected to happen:

The blank space in the first row appears green and is labelled "Up" because of the "up" data point present in the database at a short time before the start of the time window currently being displayed.

How to reproduce it (as minimally and precisely as possible):

Simply create a data set consisting of two state changes and visualize with the state timeline visualization. Then move the time window so that only the second state change is contained within. Unituitively, the period before the second state change will appear blank, instead of being labelled with the first state change.

Anything else we need to know?:

If it helps, here is the query I'm using:

Environment:

• Grafana version: v8.0.4
• Data source type & version: InfluxDB 1.6
• OS Grafana is installed on: Ubuntu 21.04
• User OS & Browser: Firefox Ubuntu
• Grafana plugins: None

[torkelo]

Of course, this gets much worse when there are no changes in the current time window for a given row, in which case that row will entirely disappear, or if there are no rows display the entire panel will show "no data".

But that seems really hard for Grafana to solve. More of a query / data issue?

[torkelo]

Unituitively, the period before the second state change will appear blank, instead of being labelled with the first state change.

But the query does not return any state for it, so Grafana does not know what state it has initially. So what more to do than render it blank?

[lux4rd0]

I will follow this request as I just saw I had submitted a duplicate - #36922 - but how this is solved mainly by the discreet plugin is by changing the $timeFilter to something like (time >= ${__from}ms - 48h AND time <= ${__to}ms) - where "48h" is a variable in the plugin UI to extend $timeFilter variable. It works for some use cases, but there's no way of knowing "how far back" to run the time query to get a proper result. But "good enough" works pretty well rather than "perfect." :) For now, it means switching from the InfluxDB visual editor mode editor to the raw query mode. I just can't change back after an edit :)

[lux4rd0]

Not very elegant - but I updated my example with a variable and then created an interval pattern to let a user choose how much further back to look for a state change:

AND (time >= ${__from}ms - $variable AND time <= ${__to}ms) GROUP BY time($__interval)

Including something like 5m,1h,12h,1d,2d,3d,7d,14d,30d.

It's certainly heavy-handed. The only thing now is that if the previous state change is really a ways back, the label values (if centered or left rather than on right) might not be displayed. But it's workable for now. I don't really know how one would dynamically "ask" the data source for previous state changes.

[vdwpsmt]

another workaround:
Creating a second (influxdb) query, something like this:

select last(value) from measurement where time < {$__from}

and using a transformation to merge the data.
this avoids having to use an arbitrary value for the extra time offset.
Seemed ok for most cases but probably not 100% failsafe and doesn’t feel right.

[ashharrison90]

@grafana/grafana-bi-squad this was on our backlog but since it's state timeline related it should probably be with you 🤽‍♂️

[github-actions]

This issue has been automatically marked as stale because it has not had activity in the last year. It will be closed in 30 days if no further activity occurs. Please feel free to leave a comment if you believe the issue is still relevant. Thank you for your contributions!