If you are able to retrieve data using the Perfmon utility and the Collector Debug Facility, but receive an error such as “Object Not Found” when attempting to view specific counters, the issue may be due to corrupted or improperly registered performance counters. To resolve this, see the following steps to rebuild the counters:

1. Open a Command Prompt with administrative privileges.
2. Run the following commands to repair the counters:

   cd C:\Windows\System32
   lodctr /R
   cd C:\Windows\SysWOW64
   lodctr /R
   WINMGMT.EXE /RESYNCPERF
   

3. If a system restart is not possible, manually restart the following services:
   • Windows Management Instrumentation (WMI)—Ensure the service is set to Automatic.
   • Performance Logs and Alerts—Ensure the service is set to Automatic.

([xml](((Get-Counter -Counter "\System\Processes").CounterSamples | ConvertTo-Xml -As String))).Objects.Object.Property |
    Where-Object { $_.Name -eq 'CounterType' } |
    Select-Object -ExpandProperty '#text'

For more information, see Microsoft SQL Server Monitoring.

For additional help with troubleshooting, submit a support ticket or use the support chat. 

rocommunity YOURSNMPCOMMUNITY 10.0.0.0/8

smuxsocket 127.0.0.1
smuxpeer .1.3.6.1.4.1.674.10892.1

restrict 10.0.0.0 mask 255.255.255.0

bsnmpd_enable="YES"

freebsd# pkg_add -r bsnmp-ucd
 Fetching ftp://ftp.freebsd.org/pub/FreeBSD/ports/i386/packages-9.0/Latest/bsnmp-ucd.tbz
... Done.

begemotSnmpdModulePath."ucd" = "/usr/local/lib/snmp_ucd.so"

begemotSnmpdModulePath."hostres" = "/usr/lib/snmp_hostres.so"

/etc/rc.d/bsnmpd restart

Overview

LogicMonitor’s Windows Server Failover Cluster (WSFC) monitoring is performed on a virtual device called a virtual network name (VNN). Each VNN is assigned a virtual IP address and, in some cases, multiple virtual IP addresses for specific services. There is no physical device for the cluster; nodes are added as physical devices or virtual machines.

All cluster alerting comes from the VNN. The nodes are monitored the same as any standard device. If a clustered service fails on a node and successfully rolls over to another node, there will be no alerts generated on the cluster unless redundancy is at a critical level.

As of March 2021, LogicMonitor has added support for Storage Spaces Direct (S2D). These modules can be used to track the status and performance of Storage Spaces Direct and alert for failure conditions.

Note: If Microsoft SQL Server is running on a node as a stand-alone server, LogicMonitor will not automatically find it. See Windows Server Failover Cluster (on SQL Server) Monitoring for information on monitoring WSFCs on SQL Server.

Compatibility

As of December 2020, LogicMonitor’s WSFC monitoring package is known to be compatible with Windows Server 2012 through 2019. Clusters have been tested with PowerShell version 5 or greater and may not work with earlier PowerShell versions.

As of March 2021, Storage Spaces Direct modules are known to be compatible with 2016 and 2019 Windows Servers.

As Microsoft releases newer versions of Windows Server, LogicMonitor will test and extend coverage as necessary.

Setup Requirements

Satisfy Dependencies

• Requires the use of a Windows Collector
  • Recommended to install the Collector in the domain of the cluster or set the WMI user as a local account on the domain
• The following PropertySources must be present in your portal:
  • addCategory_WindowsFailoverCluster
  • Powershell_Info (not part of this monitoring package)
• Remote PowerShell must be enabled on all nodes in the cluster (see Using PowerShell Scripts in LogicMonitor)

Add Resources into Monitoring

Add your cluster nodes into monitoring. For more information on adding resources into monitoring, see Adding Devices.

After all nodes are discovered by LogicMonitor, manually add a resource for the cluster. This resource must use the cluster VNN as its hostname (which is entered into the IP Address/DNS name field). Be sure to use the fully qualified domain name (FQDN) as the hostname; do not use the IP address.

Note: Once the nodes are configured and LogicModules imported, the addCategory_WindowsFailoverCluster PropertySource will automatically add the name of the cluster, the IP addresses, and all node names in the cluster as properties on the nodes, as discussed in the following section. These can then be used to manually add the resource used for the cluster VNN.

Assign Properties to Resources

If the Collector is running as a domain account with local admin privileges on the host to be monitored, it is not required that you set the following custom properties. However, if the remote host requires credentials be specified, you’ll need to manually set several credentials as custom properties on the resource. See Credentials for Accessing Remote Windows Computers.

The addCategory_WindowsFailoverCluster PropertySource automatically finds all cluster virtual resources and nodes and sets their system.categories properties to “WSFC_VNN” or “WSFC_Node” respectively.

The PropertySource will also add the following properties to the node and virtual cluster resources.

Import LogicModules

From the LogicMonitor public repository, import all Windows Server Failover Cluster LogicModules, which are listed in the LogicModules in Package section of this support article. If these LogicModules are already present, ensure you have the most recent versions.

Once the LogicModules are imported (assuming all previous setup requirements have been met), data collection and property assignment will automatically commence.

Migration from Legacy LogicModules

In December of 2020, LogicMonitor released a new suite of WSFC LogicModules. The DataSources in the new suite run on only the cluster virtual device, whereas the prior suite’s DataSources ran on each node in the cluster. Alerting on only the cluster virtual device reduces the number of duplicate alerts generated.

The release of the new suite serves to deprecate the following legacy DataSources:

• Microsoft_Windows_Cluster_Disks
• WinClusterGroupToNode-
• WinClusterNodes-
• WinClusterResourceGroup-
• WinClusterResources-
• Windows_Cluster_DiskPartitions
• Windows_Cluster_NodeState
• Windows_Cluster_ResourceState

If you are currently monitoring WSFC devices using any of these legacy LogicModules, you will not experience any immediate data loss due to the name variation that LogicMonitor expressly adds. However, there will be a diversion in data collection between the deprecated and new LogicModule, and you will potentially collect duplicate data and receive duplicate alerts for as long as both LogicModules are active.

For this reason, we recommend that you disable monitoring of DataSource instances at the resource or resource group level after you have imported the replacement. When DataSource monitoring is disabled in this way, it stops querying the host and generating alerts, but maintains all historical data. At some point in time, you may want to delete the legacy DataSource altogether, but consider this move carefully as all historical data will be lost upon deletion. For more information on disabling DataSource monitoring, see Disabling Monitoring for a DataSource or Instance.

LogicModules in Package

LogicMonitor’s package for WSFC and Storage Spaces Direct monitoring consists of the following LogicModules. For full coverage, please ensure that all of these LogicModules are imported into your LogicMonitor platform.

When setting static datapoint thresholds on the various metrics tracked by this package’s DataSources, LogicMonitor follows the technology owner’s best practice KPI recommendations. If necessary, we encourage you to adjust these predefined thresholds to meet the unique needs of your environment. For more information on tuning datapoint thresholds, see Tuning Static Thresholds for Datapoints.

Configuring Windows Firewall to Allow Remote WMI

When obtaining data from a remote computer, WMI must establish a DCOM connection. If a Windows firewall is running with default settings, it will not allow this connection. To allow remote WMI through the firewall, on the computer to be monitored, perform one of the sets of steps outlined next.

Using the Command-Line Shell

To allow remote WMI through the firewall using the command-line shell:

1. Enter one of the following commands, depending upon your Windows version:
   • netsh firewall set service RemoteAdmin enable
   • netsh advfirewall firewall set rule group="windows management instrumentation (wmi)" new enable=yes

Using the Group Policy Editor

To allow remote WMI through the firewall using the Group Policy editor, perform the following steps to enable “Allow Remote Administration” on the computer to be monitored:

1. Under the Local Computer Policy heading, double-click Computer Configuration.
2. Double-click Administrative Templates, Network, Network Connections, and then Windows Firewall.
3. If the computer is in the domain, then double-click Domain Profile; otherwise, double-click Standard Profile.
4. Click Windows Firewall: Allow remote administration exception.
5. On the Action menu, select Properties.
6. Click Enable, and then click OK.
7. See Connecting Through Windows Firewall

Connecting Through External Firewalls

In the monitoring industry, it is typically not recommended to connect to a remote Windows computer through an external firewall via WMI. Rather, if you have different security zones in your network that are separated by firewalls or NAT devices, and no host is excluded from these restrictions, then simply install multiple Collectors—one on each side of the firewall or NAT devices—to monitor hosts in those zones appropriately.

The reason it is not recommended to connect through external firewalls is because it requires that hosts then be configured to restrict to a port range. In addition to creating an administrative burden, this customization can lead to port exhaustion if other applications rely on WMI but available ports are restricted, which can then subsequently prevent those applications or even LogicMonitor from referencing or collecting data. In addition, because customizations are in place, LogicMonitor’s ability to provide troubleshooting support may be limited if issues arise.

With that said, if you wish to try monitoring Windows hosts from a Collector that is firewalled from them, you must ensure that DCOM works, and that no NAT is being performed. While it can be done, you are accepting some risks as this configuration could present many No Data alerts and possibly result in poor monitoring reliability.

Overview

LogicMonitor uses SNMP to monitor host filesystem capacity across a variety of operating systems.

Filesystem Monitoring DataSources

LogicMonitor offers several DataSources for filesystem monitoring via SNMP:

• SNMP_Filesystem_Usage
• SNMP_Filesystem_Status
• FreeBSD_Filesystem_Usage

Understanding the SNMP_Filesystem_* DataSources

The SNMP_Filesystem_Usage and SNMP_Filesystem_Status DataSources offer filesystem usage and status monitoring respectively for operating systems such as Linux and Unix.

These two DataSources were released in December 2020 and are intended to eventually replace snmpHRDisk- and snmpHRLargeDisk-. However, because of widespread usage of snmpHRDisk- and snmpHRLargeDisk-, LogicMonitor is providing ample time for adoption of these new DataSources before the now-legacy DataSources are officially deprecated. In that same vein, the new DataSources have been temporarily rolled out without alert thresholds in place to ensure that users of both sets are not bombarded with duplicate alert noise. (Recommended alert thresholds are documented in the technical notes when you are ready to enable alerting on the new set of DataSources as part of your migration process.)

Although the new SNMP_Filesystem_Usage and SNMP_Filesystem_Status DataSources offer many monitoring enhancements, there are three primary differentiators between the newest set and the now-legacy set:

• Status monitoring has been separated from usage monitoring to prevent filtering of instances where filesystem usage data would be desired.
• The new SNMP_Filesystem_Usage DataSource supports larger block sizes so there is no longer a need to have a dedicated DataSource for larger file systems.
• The new DataSources no longer force a 5% adjustment to account for standard root reservation. Instead, root reserved data is incorporated into the alert threshold rather than forcing the calculation on the collected data. This makes understanding and setting alert thresholds more intuitive and avoids the potential confusion of seeing filesystem usage exceed 100%. (If you are still using the legacy DataSources and would like to troubleshoot usage showing as exceeding 100%, see the Troubleshooting Usage that Exceeds 100% section of this support article.)

Understanding the FreeBSD_Filesystem_Usage DataSource

The FreeBSD_Filesystem_Usage DataSource monitors filesystem usage for the FreeBSD operating system. It was released in December 2020 and replaces the now-deprecated snmpFreeBSDDisk- Datasource. Enhancements include an updated AppliesTo statement that includes OpenBSD systems; updated filters to allow discovery of files between 0-100 bytes on file systems; new complex datapoints; support for drives over 8 TB and block sizes other than 4 K; and the fixing of a 5% overcorrection in the graph.

Troubleshooting Usage that Exceeds 100%

If you have not yet migrated away from the legacy snmpHRDisk- and snmpHRLargeDisk- DataSources, you may potentially see usage metrics that exceed 100%. This is because LogicMonitor assumes that your file systems have 5% of file system space reserved for root use only (a standard practice that allows some ability to move and copy files if the filesystem becomes full). While this percentage is generally tunable upon filesystem creation, the DataSources assume a default of 5%.

The reason LogicMonitor reports the filesystem capacity from the perspective of a non-root user is to prevent a situation in which LogicMonitor indicates that there is 5% free space when a non-root user would experience a filesystem full error. If you would like to update this default reporting, you can modify the datapoints to reflect absolute usage numbers. The math for the relevant datapoints is (StorageUsed/(StorageSize*0.95)100); simply remove the .95 factor.

Migration from the Legacy FileSystem DataSources

If you are currently monitoring file systems using any of the legacy DataSources named previously, you will not experience data loss upon importing their replacements. This is because DataSource names have been expressly changed to eliminate module overwriting. However, there will be a diversion in data collection between the deprecated and new DataSource, and you will potentially collect duplicate data for as long as both are active.

For this reason, we recommend that you disable monitoring of the DataSource instances at the resource or resource group level after you have imported its replacement. When DataSource monitoring is disabled in this way, it stops querying the host and generating alerts, but maintains all historical data.

At some point in time, you may want to delete the legacy DataSource altogether, but consider this move carefully as all historical data will be lost upon deletion. For more information on disabling DataSource monitoring, see Disabling Monitoring for a DataSource or Instance.

extend diskstats /bin/cat /proc/diskstats

extend lm-nfsd /bin/cat /proc/net/rpc/nfsd

echo "$((`date +%s ` - `date +%s -r dump.sql` ))"