SQL Server DataSources - Updates

Hi, @ldoodle 

To answer your question, yes, the change was specific. We made that change to our SQL modules in 2020 in order to differentiate from SQL monitoring on Windows Server Failover Clusters, which have their own SQL modules. 

https://www.logicmonitor.com/support/monitoring/applications-databases/windows-server-failover-cluster-on-sql-server-monitoring

Keep in mind these risks to updating a module are always present. We at LM Support often encourage updating, but the risks are there and it’s up to you to move with caution. Clone the current module before updating the Core as a precaution, or review the changes with a diff check.

And because we love sharing our documentation, here’s an article on updating modules and the risks involved:
https://www.logicmonitor.com/support/logicmodules/about-logicmodules/keeping-your-datasources-up-to-date#h-risks-to-updating

I’m not sure what that category (WSFC_VNN) is for, but the addition of that clause to the appliesto is probably to exclude some systems that are known not to work with that datasource. Does the datasource show data on the device level? Maybe some filtering in the dashboard widget needs to be updated.

LM generally (but not always) will summarize bigger modules changes in the next release notes. You can also check the “commit history” in the Exchange if they added any. In general I would try to review what specifically changed when upgrading DSes. Especially if AppliesTo changes as that might cause loss of historical data.

Ha, don’t need to guess - from the update log:

update value=hasCategory("MSSQL") && !hasCategory("WSFC_VNN"), old value=hasCategory("MSSQL")

I’m happy to remove that new clause in the DataSources if needed, but there must have been a reason for this change.

Licensing question: you consume a device license for every device your collectors talk to, not what they talk about. For example, you can monitor vCenter and talk about 1000 VMs managed by that vCenter, but you’re only consuming 1 license because you’re only talking to vCenter.

Not a SQL guy, so much of those terms went over my head. But if your collector is talking to a VIP, that’s an IP it’s talking to, so consumes a license.  Usually when monitoring a cluster, I’ll only monitor the individual members’ actual mgmt IPs and ignore the VIP; unless there’s value in monitoring the VIP itself, knowing that some results may differ depending on which cluster member is receiving the request.

Yes, unless you can find a way to get the iDRAC/iLO/IMC metrics by polling the main NIC’s IP address (not likely). We have two “resources” in LM for every server that has a iDRAC/iLO/IMC port, each consuming a license. Makes sense though iDRAC/iLO/IMC are similar to a separate computer built into the motherboard.

Now, if we can figure out how to mine bitcoin on the iDRAC/iLO/IMC processor...

The standard dash uses this for example (‘SQL Server Global Performance’):

And that DataSource has the new clause:

Good shout on checking at the device level - that’s a No:

Yeah for sure - same applies to basically anything we own nowadays!

Just read the link about SQL Server monitoring and is states that GlobalPerf DataSource has superseded the previous one, but I am already using GlobalPerf.

Just reading some of the DataSource descriptions… currently I have just added SQL servers and not the listener name. Am I understanding correctly that by adding the listener as a resource that resource won’t get the SQL_Node category and so will be captured by the GlobalPerf DataSource?

Out of interest, do this way consume an additional element license - or does it know that the real servers behind the listener are already added?

Been playing about with this just now. Adding the listener and resource for it still gets the SQL_Node category and so is still excluded.

Haven’t tried adding the WSFC name yet. Will do that next.