After upgrading to version 20.10 the dashboard does not always show the data.

[Solomon Melamed]

Hello All,

I upgraded my second server to version 20.10 and also installed the new UMP version 20.10 after the upgraded I have a strange problem the dashboards does not always show data.

It is important to note that the old server (Primary Hub) works fine.

i increased the memory of java (On NEW UMP) to 8 gigabytes but it didn't help.

Please help.

Many thanks.

[Solomon Melamed]

[David Michel]

what dashboards? 
Perhaps you can expand upon 'does not always show data' with some helpful details and an image. 

------------------------------
Support Engineer
Broadcom
------------------------------

[Solomon Melamed]

UMP Dashboard.

Dashboard without value 

[Solomon Melamed]

For example I connect to the dashboard and see data, press F5 and came out dashboard without data

[David Michel]

sorry that's no help to me. 
by default UM has a menu bar item Unified Dashboards but one just called Dashboards would be custom. 
Also the image of the dashboard is new to me, haven't seen one with all those small tiles. 
Is this a dashboard_designer or cabi dashboard? 
Regardless so the problem is the dashboard works fine until you hit the F5 refresh. 
Test is with another browser and also via clicking the refresh icon. 
The out of the box dashboards have an auto update, is that working? 
What's the revision of UIM and the ump_dashboard?

------------------------------
Support Engineer
Broadcom
------------------------------

[Solomon Melamed]

I tested my dashboards with chrome & IE.
Secondary Hub ver 9.30
ump_dashboard ver 20.10

[Garin Walsh]

To toss in my two cents here, in my case, assuming it is the same, is that this is affecting the "Dashboard" portlet - this would be the HTMP5 based dashboard tool that's a portlet and part of UMP as opposed to the other many possible "dashboard" variants. 

Frequently the dashboards presented will fail to paint the underlying data - you get the initial painting but behavior like this:

where the datasource for this widget is supposed to replace the $VAR placeholder but it never does.

Similarly alarm widgets will show green and zero alarms when that's not true, items with SQL data sources will report "null" as their value.

You will get a display like this if you hover over the widget:

Sometimes logging out and back in will fix this. Sometimes, if the dashboard has sub-dashboards, linking into one of them and then backing out via the breadcrumb will make the previously not working page finish painting.

There appears to be nothing in the wasp log for this - and actually it looks like the requests to evaluate the widgets never get submitted ans usually you'd see indication of the query happening and there's not.

And like the original poster, this worked reliably in 8.51 but in 20.10 appears to be seriously unreliable.

[Solomon Melamed]

As I understand the version 20.10 is still unstable

[Jay Wink]

Hi Solomon,

I would disagree with you on 20.1 being unstable as a whole. This dashboard is 1 component of over 200 within the product.   

I would recommend opening a ticket with Support as the HTML 5 Dashboards are going to be a big part of the 20.3 release.  Anyone have this issue or similar one please open a ticket.

------------------------------
Customer Success Architect
Broadcom
------------------------------

[Garin Walsh]

I think that it is much more fair to say that the testing coverage for a given release is pretty low. And that results in a significant number of issues for anyone who does something with the product that is outside the standard Proof of Concept sort of usage pattern.

Additionally, with the turnover that Nimsoft/CA/Broadcom has had over the past 5-7 years, I don't think there's really anyone left who has a good big picture of the product.

So some simple things, like coming up with a new version numbering scheme, might seem innocuous but have some pretty detrimental affects in the product. About 60% of the time the version number of a probe/package is handled as a string by the product and in the past, you could rely on 9.0 occurring after 8.51 whether you treated it as a string or a number. One always had problems with strings like 9.20HF3 because numerically it was the same as the base 9.20 version but as a string it sorted after. Now with the 20.10 style string, the current versions appear older than the 8.x/9.x versions when looked at as a string but sort correctly as a number.

Now think about all the places that version is used. Did all those get fixed to work correctly when the decision to go to a 20.xx version string was made? And who tested that change? 

Looking at the 20.10 product today, it's pretty clear the version string decision was thought to be just a documentation thing. Though even there, it seems that there's some disagreement whether it's 20.10 or 20.1.0.

[Solomon Melamed]

I opened a service call, they (Support) closed the case, said I should also update the primary hub to version 20.10, maybe they want to leave me without a monitoring system.

In any case, until the secondary hub & Secondary UMP works properly, I will not upgrade the primary server.

[Jay Wink]

Solomon,

Don't quite understand the details of your last statement.   Are you saying you have a Domain with a secondary Hub and Secondary UMP on 20.1 that reports in to a Pri-Hub on an older version?  If that is the case, that isn't support and yes you must upgrade the entire backend to the same release.

I ran into a customer a few months back having Dashboarding issues because of version miss matches on the backend servers.  Everything was resolved once they got the UMP and PriHub on the same release.

NOTE:  I am not saying this will fix your issue but the Pri-Hub and UMP are the only servers you run the installers against and must be on the same OS and same product version.

------------------------------
Customer Success Architect
Broadcom
------------------------------