Dynamic Tables (dashboard widget)

Locked

Discussion interactions are currently paused.

Currently, a table must have static columns and rows defined before the widget will display data. It would be great to be able to dynamically build a table's rows based on *

To expand on this, it would be great for the table to have the option to exclude instances with zero/no data from the list.

For example, I would like a table that displays all MSMQ queue names and the number of messages in each queue - but not display anything if the current queue length = 0

ErnieC

Posted 9 years ago·Last reply 8 years ago

13 comments

mnagel

·8 years ago

@Ali Holmes Thank you!

One more desirable thing would be the ability to reference properties (device and ILPs), not just datapoints. This would enable presentation of asset information, for example, assuming propertysources are producing results.

mnagel

·8 years ago

@Ali Holmes Thank you!

Ali_Holmes

·8 years ago

Hi @mnagel, I have both of these improvements included in the requirements for phase 2. Design is almost done, release will likely be v102.

mnagel

·8 years ago

Another request -- it looks like you cannot narrow content based on instances. So... I cannot create a table of "Top C: Drives" for Windows servers, for example. Can this please be fixed?

Thanks,
Mark

mnagel

·8 years ago

So close.... Why are we still pinned to 'TopN' for selectors? Can we please also have 'BottomN'? I know this can't be difficult from a programming perspective and it is really needed.

Thanks,
Mark

ErnieC

OP8 years ago

Glad to see this was released in v99. We will be playing with it over the next few weeks. Thanks!

ErnieC

OP8 years ago

Fantastic, thank you for the update!

ErnieC

OP8 years ago

@Ali Holmes that is a good start, although I was told the same thing last November by my account manager. It's been almost a year and no progress has been made and this is still being spec'd out?

I also kinda agree with @mnagel - there shouldn't be a problem just NaN'ing the "bad" cell in the table. Doing one is a good start, but let's not be content with just that.

For what it's worth, you can kind of "ghetto" this up already with a line chart. The data and logic is already baked in, just displayed as a point on a graph over time, instead of the most recent datapoint.

mnagel

·8 years ago

Hi Ali -- thanks for responding! That sounds like it would make sense, but I can imagine some counterexamples. For example, datasources that are similar but not identical (different types of snmp_If* DSes spring to mind). I recommend allowing multiple DSes, but require the same datapoints. If the DP does not exist, then show a NaN. The next step would be to have a DP-mapping capability, but that seems overly complex.

If we had it as described, I would definitely be happier than without it, of course!

Thanks,
Mark

Ali_Holmes

·8 years ago

This is something we're spec'ing out currently. It's likely we'll have to limit the dynamic table to a single datasource to ensure columns have the same number of instances, but it sounds like that will be sufficient for the examples provided?

mnagel

·8 years ago

I found this because I just tried for the first time to add a table and was floored that I must define every row by hand. In this case, I have to work around the lack of "bottom N" in graphs so I can watch for devices that have rebooted recently in one place. I want to put in this table all devices in a group, which seems like a no-brainer from a functionality standpoint. Having to manually define those and maintain forever is a non-starter. Can we please get the rows to be enterable as device groups and/or globs, as in other places?

Thanks,
Mark

Will_Simon

·8 years ago

I agree with this 100%. Running in to this issue now.

In my example, I would like a table showing a full list of VMware datastores and their used/free capacity. With how tables are set up now, I'd have to manually enter a row for each datastore, and manually update that as we add/remove/modify them.