SNMP Filesystem Monitoring

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.