Dashboard Monitoring Improvements

Feature Suggestions
1

We LOVE the Jobs Monitoring Dashboard. But we’ve got a few requests / questions to help improve our monitoring of performance and errors and such. Some of these apply specifically to the Jobs Monitoring Dashboard, and others are more broad.

  1. There’s currently no way to setting up alerts on these widgets, exploring the data to view things in a slightly different way, or exporting the data. I could see this coming in a few different forms:
    a. Add it to the Jobs Monitoring Dashboard
    b. Expose the data somehow to admins and allow us to build our own dashboards / alerts off of it
    c. Make the data accessible via the API so we can build our own form of alerts / visualizations or possibly even match it up with internal data

  2. On the two tables called “Longest running individual widgets” or “Longest running Dashboards”, if multiple dashboards share the same name OR multiple widgets on the same dashboard share the same name OR multiple widgets share the same name on different dashboards that also share the same name, then there’s no way to differentiate them. Can Dashboard Id and Dashboard Widget Id be added like the Longest running jobs table has? It would also be really great to be able to filter on these.

  3. It would be really cool if “Longest running Dashboards” or a new table showed TOTAL load-time for a given dashboard, from when it started until when the last widget loaded. I’m not sure how feasible this is.

  4. It would be nice if we could filter / group by type of visualization, or at least see it in the “Longest running individual widgets table”. I’m wondering if there’s patterns for slowness (ex. pivot tables, data table, etc). We’ve found some improvements that we can make on certain types of visualizations, and seeing the visualization type in the table would help us evaluate if that’s a place we can make an improvement on or not.

  5. The query results seem cached for quite a while with no way to refresh other than changing the filters we’ve noticed a very small number of jobs when we check at the start of the day, it goes up if we change the filters, but goes back down when we reset the filters. We would love to update the results so that we can monitor performance, especially after we’ve made changes that we think will have an impact.

  6. The “Job Count” in “Total Job Execution Duration”, “Execution Duration per Job”, “Running Duration per Job”, and “Pending Duration per Job” all match, but they’re higher than the job count in “Job Pending-Running Ratio”. I noticed that “Job Pending-to-Running Ratio” has an extra widget filter on Done Report Jobs Status = 1,2. What’s the meaning of this filter and why only apply it to that one visualization? It’s causing a big difference in numbers ex. 300+ jobs difference on Oct 24th.

Bonus: some way to identify embed users (ex. we send an internal ID or user attribute or something). Especially if we can export the data somehow.

2

Hi Anya,

Thank you for posting the Feature Suggestion!

  1. :spiral_notepad: We have taken note of this request and added it to our backlog. In the meantime, if you have an idea for a new visualization, please let us know.
  2. :white_check_mark: We have added Widget ID to those 2 tables and also added Widget ID filter to the dashboard.
  3. :thinking: From our experience, this stat, while being quite informative, is not very actionable, mostly because it involves a lot more factors (e.g. rendering time, user’s network speed, user’s machine specs) that can be out of control or noisy. But let us revise and we will consider bringing it into the dashboard in the future.
  4. :thinking: This is a good idea. However, I think this is more of Holistics’ responsibility to serve your visualization needs without having to consider these details. If there are performance differences in different types of visualizations, then perhaps Holistics should try to provide documentations/guidelines accordingly, instead of asking the users to analyze and figure out themselves.
  5. :white_check_mark: We have just switched to Canvas Dashboard and the Refresh button should be accessible now. (Previously, we hid the Dashboard Title for aesthetics but it hid the Refresh button as well)
  6. :white_check_mark: It is supposed to filter Job Status in all widgets. We have just fixed it. FYI this filter is used to eliminate incomplete or discarded jobs.
  7. :spiral_notepad: Embed user identification is a feature that is already in our backlog.
1 Like
3

So quick! Thanks for all the fast improvements!

  1. Appreciate it! I think exporting the data and integrating it with our own data goes along really well with #7 if that happens.
  2. Amazing, thank you for adding Widget ID! Is there any chance we could also get Dashboard ID for similar cases of dashboards share the same name? Especially on canvas dashboards, the widget ID is in the form of v1, v2, v3, etc (unique per dashboard instead of unique overall) so it’s very possible that 2 canvas dashboards with the same title and widgets on the dashboards have the same name and widget ID.
  3. Heard. Maybe the “Longest Running Dashboards” widget could show like a max(widget execution time) per refresh or something like that? And similarly max(widget run time) per refresh? Doesn’t necessary need to be full dashboard load time, but I think seeing a better summary of the dashboard as a whole would be very cool! Especially the following:
  • Seeing how the average time is skewed - if 5 widgets load SUPER quickly but 2 load extremely slowly is very different then 3 loading in a medium amount of time time, but they might have very similar average times and be hard to pick out in the current viz. We can sort of get this from the widget load time chart though.
  • Are there consistently blocked tiles more on certain dashboards because of too many widgets? Is this mitigated because some of the widgets load super quickly, or is it a bigger issue?
  1. This makes sense. I know you and I were talking about some viz options that were slower than others over email (ex. pivot table + sort is slower than data table + sort, top N/bottom N filter is slower than sort by + limit N), so would be great to see that in documentation recommendations!
  2. Amazing, thank you, this is super helpful!
  3. Perfect, makes sense!
  4. Great, can’t wait!

All the best,
Anya

1 Like
4
  1. Ah sorry we missed that. We have just included the Dashboard ID.

We have added the other requests/suggestions to our backlog and will gradually process them!

1 Like
5

Amazing, thank you so much Dat, this is extremely helpful!

1 Like