I'm brainstorming a work around to the webview graph not supporting the workstation graph scaling data display options.
0. Wait for a hotfix to correct webview.
We have very few graphs within our dashboard presentation and we might be able to try one of the other options till we receive and apply a hot fix. This assumes that CA defines this as a defect and will back-port the hotfix to 10.0.
If there won't be a back port, then hopefully push off our upgrade from 10.0 to the 10.5, 10.5.1 or 10.6 with hopes that in one of those might have a hotfix we can apply to fix webview graphs.
1. Try to make due, Migrate and drop on saber
In this case, do not use scaling on graphs if your user base uses WebView. Set all graphs to auto-scale.
With the behavior of the webview graph not adhering to scaling, could have two sets of dashboards, one for workstation and the other that is webview friendly. When an end user asks why they are different, or were changed if you only have one set, state that the display option is not supported within webview.
2. Duck and Cover
Place a solid, background color square on top of the graph, have the square be at the front to cover the graph below the min. Problems with this is the scale will auto-scale and your blinder might hide more than you want. This would also cover the time x-axis labels, but you might be able to train the end users to do the float over to get time references.
3. Calculator Metrics
Define a Javascript calculator that will query for a value and then only publish values above let say 75. If the value is below 75, publish 75 so that the line will be continuous.
A problem with this is if there are hundreds of thousands of metrics to publish a scaled value for might take took long. a possible work around would to have Javascript agent expressions break up the domain into reasonable chunks so the calculator can do the evaluation and publish within 8 seconds.
With the multi-calculator thought, would need to balance the operational costs of implementation with the benefits to the end user presentation.
4. Plugin - dual publish
For metrics that are alerted on with greater than conditional:
With an epagent plugin, publish two values, an actual and then a scaled value. for the scaled value, If the value is above 75 publish actual value, if the value is below 75 publish 75.
For metrics that are alerted on with less than conditional
Instead of 75, use the general caution level +10, so if your caution level is when there is 5% space left, then any values above 15 become 15.
5. Graph placement and size
One of the primary reasons why we would use scaling on a graph is to reclaim some of the uninteresting sections of the graph, freeing up the presentation space to focus on more important visual elements. If your dashboard has several of these non-scalable graphs, move the graphs to the bottom and increase the vertical size to spread out the metrics toward the top end of the graph.
Have an alert button that takes the end user to a single graph dashboard that covers the complete vertical height of the presentation.
6. Use Introscope Workstation (java web start)
Since 9.6 we have been pushing our end users to webview, with limited success. We have about a dozen or so end users still using the installed Java-based Workstation. Really don't want to start installing the Java workstation to this new group of UNIX admins. The new dashboards are the only ones thus far to use scaling so might be able to get away with one of the previous options
7. Keep the graph from auto-scaling with an alert
In one of my previous messages, instead of assigning a metric group to a graph for webview, define a dummy alert with the upper bound, such as 2500. Yes, this does prevent the display of the actual danger/caution red and yellow lines, but if it is more important to preventing auto-scaling, you can use an alert key like on the APM dashboards:
Does anyone else have any suggestions on how to work around the webview graph scaling issue?