We finally have an answer for this. Thanks to neilhallyburton for his assistance.
As you may know, Squared Up pulls all performance data from the SCOM Data Warehouse, not the SCOM Ops DB. Unfortunately, the SolarWinds MP doesn’t correctly insert data into the SCOM DW because it breaks the rule of “one counter per collection rule”.
Oleg Kapustin explains this concisely in his blog:
In the SolarWinds MP, the "Collect Device Data from SolarWinds server" performance collection rule collects all performance counters (for all nodes). There are good reasons for doing it this way - namely efficient querying of the SolarWinds database - but unfortunately it does not work with the SCOM Data Warehouse.This is yet another call for SCOM Management Pack developers: never ever try to implement dynamic object and counter names for performance collection rules! This has been explained billion times by many people (including myself), but I have faced (and successfully terminated) another attempt to do that again.
The reason for not implementing dynamic object and counter names for performance collection rules is simple and straightforward: this kind of implementation is not supported by OpsMgr data warehouse. Take a look at dbo.PerformanceRule table and note that CounterName andObjectName columns are stored there, RuleRowId is a primary key. That means that one and only one object\counter pair can be stored for a given rule. One. No exceptions.
The result is that all the performance data is collected and stored in your DW, but the DW can’t distinguish what data points are for what counter (because they all reference the same collection rule). Using Squared Up, if you drilldown into a Node and export the “status” performance graph to Excel, you’ll see multiple data points for the same timestamp - each data point is actually for a different performance counter but you can’t tell which.
We’re not aware of any workaround for this.