SQL Server DataSources - Updates
Hi,
I did a DataSource update the other day and it looks like the built-in SQL Server dashboard is now broken, because the updated DataSources now have one of these:
hasCategory("MSSQL") && !hasCategory("SQL_Node")
hasCategory("MSSQL") && !hasCategory("WSFC_VNN")
I’m guessing the bold bit is new/changed because previously my SQL AG servers were shown in the built-in Dashboards and now they’re not. Only non AG SQL’s are shown.
Is this intentional?
Thanks
ldoodle
Posted 2 years ago·Last reply 2 years ago
12 comments
LM User
·2 years agoYes, 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...
ldoodle
OP2 years agoThinking about it differently… I think based on what you said it would be 2 licenses:
a physical server getting polled on its OOB port (iDRAC, iLO etc.) AND Windows IP, that would be 2 rather than just 1.
LM User
·2 years agoNot 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.
ldoodle
OP2 years agoLicensing 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.
Yeah I understood that - that vCenter example was major plus for us with choosing a monitoring product/platform.
But I wasn’t quite sure how it worked with a virtual thing like a cluster name, VIP, SQL AG listener etc.
ldoodle
OP2 years agoAm 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?
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.
LM User
·2 years agoLicensing 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.
ldoodle
OP2 years agoHi, @ldoodle
Keep in mind these risks to updating a module are always present.
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?
ldoodle
OP2 years agoI’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.
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:
Kwame Armstrong
·2 years agoHi, @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
Mike Moniz
·2 years agoLM 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.
LM User
·2 years agoI’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.
ldoodle
OP2 years agoHa, 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.