I've found that a key functionality to engaging and useful dashboards is the ability to control when an element is visible or not - this is a foundational function that can be used (with some effort) to replicate most widgets that are not available at present.
For example the simple ability to display an image or not, based on some condition of a query. This would allow the dashboard to show a different image for any state that you want to represent. You can then layer them on top of each other to create a dynamic dashboard.
I agree with Jeremy. Even having a basic image health widget would be useful. If it could display a different image depending on the state of a health rule, it would let us build more interesting dashboards.
Being able to show contextual data based on tags and template variables seems like it is coming in the next version of the dashboard product. I don't remember if it will have conditionals, e.g., being able to hide a particular panel if a condition isn't met, but it will have filtering, tags, and allow it to be more dynamic.
it's possible you could pass variables to a dashboard on-demand, and display just the subset of metrics you want for the condition you are looking for. We will be enriching our alerts with additional dashboard links that take advantage of the new Dashboard Variables. This way we can tie a custom dashboard to alert types and present the data filtered by the application, BT, node, or a custom metric.
The only way I could see doing something more fancy would be with scripted dashboards. You could parse json and update dashboards with relevant metrics based on whatever conditions you want it to represent dynamically. There would be a delay, but it could be something to look into.
Depending on how far AppD is going with tagging, with some API calls and a script running in cron, you could tie certain conditions (like health rule violations), to update tags on specific agents, BTs or metrics. Then you could have a widget that filters based on an active:true tag, and display only relevant content based on your own conditions.
Hey Carl, I have a follow-up question about this. Would you expect dashboard variable settings to be included in the shareable URL for a dashboard? If so, would it be safe to include the actual values and some kind of variable identifier (e.g. an ID number, maybe not any human-understandable names) for each variable? We're thinking about how to expose the values for a given variable in the URLs so that others could see the same dashboard settings you might have had made for the variable selections. Thanks!
Hi,
Absolutely!
Being able to pass a value to a dashboard would be a very useful feature, as it would let us define custom links from our alerting tool to the relevant troubleshooting page. As it stands today, we have to manually link to metric browsers or custom dashboards for each particular function. Be able to share a pre-populated dashboard automagically will help shorten MTTR, reduce static screenshots, and make the product much more usable.
This would not present us with a security concern, as the dashboard ACL is under our control, and the contents of our URLs in our private internal alerting.
That being said, if there is a concern about allowing customers to use the names of things... if we could pass the node id, app id or BT ids to the dashboard and Dash Studio would be able to translate that to the appropriate node name, Business Application and BT, then we could extract these values from the Velocity HTTP Template and pass them in a custom URL, either using our HTTP Template or by building the URL on our alerting tool.
Another prominant monitoring tool allows you to define dashboard variables in URLs like so:
https://othertool.saas.other.com/dashboard_name_or_id?my_var_Application=MyApp&my_var_BT=Search%20API
-Carl
@Carl.Brahms wrote:Another prominant monitoring tool allows you to define dashboard variables in URLs like so:
https://othertool.saas.other.com/dashboard_name_or_id?my_var_Application=MyApp&my_var_BT=Search%20API
-Carl
FYI, I found another popular monitoring tool that supports passing cleartext variables as parameters to their dashboards in the same way, so I doubt there are security concerns for this feature.
https://othertool.saas.other.com/dashboard_name_or_id?var_Application=MyApp
Again, this would allow us to include custom tags in our eventing tool (BigPanda), and link to the exact Dash Studio Dashboard content we want to include when a particular type of health rule triggers an alert. Very useful to us.
Jeremy and Carl, thanks for the feature request details! We've heard about these needs for conditional display both at a widget level, and for an entire dashboard. It's something we will be considering for the future roadmap once we feel like we have all the details. This helps a lot!