Has anyone had this problem? In webview, the data lines drop below the x axis and cover the time labels?
I have stopped the EM and WebView, removed the /emhome/work contents and /emhome/product/webview/configuration/rm -r org.*. Restarted the EM, waited for the EM to finish, then started the Webview but the problem still exists.
Webview in Chrome and IE are showing the same graph issue.
CA APM 10.0
You have a case opened on this. So marking as answered . Feel free to post solution here
CA Support was able to reproduce this issue with in WebView, if you use the scale option, if there is any data below the min level, the data lines will be below the x-axis.
The initial work around is to change the scale from min/max to auto scale. So basically the scale option on graphs does not function in WebView.
I'm thinking that this issue/feature, is part of the idea to have webview display just like workstation. In this case, the scale feature is no longer functional when viewing dashboards through webview.
Thanks Billy for the update. This is good to know
Dashboards should look the same in both Workstation and Webview
There seems to be a few others that think that the display within workstation and webview should look the same. I would like to take it a step farther and say that the options that we have in workstation should be supported in webview. Such as graph scale, and pinning the the graphs.
Does anyone else know of any webview adverse behaviors or lack of behavior that we have in workstation dashboards?
Thanks Billy. Seems like a good Knowledge Document topic.
Yes, having a comparison between WebView and Workstation would be most helpful.
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
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?
Greetings, Billy. As noted in the case 676807, this issue will be fixed as of 10.5.2 and backported to 10.5.1. Thus it should be ready by the time you intend to upgrade.
CA APM Support (New York)