I am using the Solarwinds connector to pull data from Solarwinds into SCOM. Within the SCOM console, there are performance graphs that show network interface metrics:
I am trying to recreate those graphs within SquaredUp using the Object/Counter/Instance names as shown in my screenshot above. So for example, the Object would be “SolarWinds.Orion.SCOM.Node”. The Counter would be CPULoad. The instance would simply be the IP address of the device.
However when I try to recreate that performance dashboard within SquaredUP, SquaredUP does not seem to be able to access that performance data. When I specify that same network device and then hit the down arrow to get the list of available performance counters I only see this:
So it appears that the only performance metric it can pull is the hardware status. Using the advanced menu option to specify “SolarWinds.Orion.SCOM.Node” as the object makes no difference as the graph says “no available data”.
I am wondering if anybody has been successful doing this?
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:
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.
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.
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.
I’m trying this Solarwinds MP by Ruben but I can’t get data. My data in the reg file works when using a tool like Postman and the server shows up in SCOM, but no data in Switches, Routers, etc. Any ideas from anyone who has successfully implemented Ruben’s MP?
What counters specifically are you interested in viewing?
I struggled with this as well using the Orion MP. I am only using it to monitor the hardware of my switches as I don’t have that covered with any other management packs. If you are interested in interface monitoring, you are better off using the default metrics SCOM collects, although you will have to enable these rules, as they are only enabled for interfaces you explicitly want to monitor.
I would also advise that, should you use the out of the box interface monitoring of SCOM, to use this management pack that changes the displaynames of the interfaces to a more readable format. This allows for much betterdashboards within Squared Up. Here’s the link:
Example screenshot with the rename of the adapters.
Just wanted to give everyone an update on this…..It’s been well over 3 months since I submitted my case to SolarWinds about this and they have not yet provided an update or a response. All I’ve gotten is that they forwarded my case to their developers and have yet to hear back from them.
Some of the others here mentioned that they would open cases with SolarWinds as well. Any progress on your fronts?
As clarkd suggested, it might be that the dashboard is scoped to the wrong object, because they have the same name but are actually different types (SCOM classes). For example, “SolarWinds.Orion.SCOM.Node” vs “SolarWinds.Orion.SCOM.HardwareHealth.HardwareInfo”. (To add to the confusion, these are also the “object” names used for the performance counters.)
The SCOM Console view is showing objects of class “SolarWinds.Orion.SCOM.Node” so try to reproduce that in Squared Up.
Try the following:
- Create a new dashboard, and add a Status section
- Choose Scope > Advanced
- In the Class box, enter “SolarWinds.Orion.SCOM.Node” (this is scoping to all objects of this class)
- Make sure a list of objects appears
- Either drilldown into one of these objects and click “view performance” or –
- Change the section type to Performance
- Choose Metric, and press the down arrow to see all available metrics
has anyone got a solution to this?
I’m having the same problem with Solarwinds MP aswell as different MP called Metrex Cisco Monitoring which is trying to monitor the performance graphs for Jitter Packet Loss, I just get no data in SquaredUp but the performance graphs appear in SCOM.
Thanks for your time today Richard and getting an answer to many people’s problem.
I too will log a support call with Solarwinds to back up WilsonWong hopefully they will recognise the need to fix this.
WilsonWong, do you have a support ticket number from Solarwinds so I can reference it?
Update just in case anybody was still interested in this. It’s been a year since I had originally submitted my support case to SolarWinds. I recently re-opened the case asking them if they were ever going to fix this issue or release an updated MP with support for SCOM2016 and they said they had no plans to do so.