Die Checkmk-Konferenz #6 wird virtuell! Mehr Infos hier!
Used Space and Inodes in Filesystems
|Distribution:||official part of Check_MK|
|Supported Agents:||Linux, Windows, AIX, Solaris, OpenVMS, HPUX, FREEBSD, NETBSD, OPENBSD, MACOSX|
This check measures the usage of filesystems. The usage
is checked against a warning and a critical level, which
can be specified in numerous ways.
Beware: on Linux and UNIX systems the filesystem might reserve a certain
amount for root (typical is 5%). This checks considers that reserved space
as used. This is consistent with the percentage-column in the output of df
on most distributions. So your filesystem might be at 100% in a situation
where root still has 5% free space available. On some distributions, df
seems to use the user allocatable space instead of the total filesystem size
as base for the percentage calculation, this might result in differences
between the percentage values shown by that df version and the value
shown in Checkmk. From our point of view, the calculation of Checkmk is
Inodes: if the agent provides a df subsection for inodes, this check
measures the inodes usage. Thresholds default to (10%, 5%) remaining inodes and
can be set/changed in ruleset filesystems.
Trends: This checks supports filesystem trends. This means that the df check
is able to compute the change of the used space over the time and can
make a forecast into the future. It can estimate the time when
the filesystem will be full.
In the default configuration the check will compute the trend based on the
data of the last 24 hours using a logarithmic average that gives more recent
data a higher weight. Also data beyond the 24 hours will to some small degree be
reflected in the computation. The advantage of this algorithm is a more
precise prediction and a simpler implementation, which does not need any
access to any RRDs or similar storage.
Please note that when a filesystem is started to be monitored,
the trend of the past is unknown and is assumed to be zero.
It will take at least one trend range of time until the trend
approximately reflects the reality.
Grouping: In some situations you do not want to monitor a single
filesystem but a group of filesystems forming a pool.
Only the total usage of the pool is of interest. The df check supports pools
by defining groups. For each group you specify a name and a list
of globbing patterns (path patterns containing * and ?). The name
is being used as the check item. All filesystems that match one of
the patterns are part of the pool.
When using inventory you specify the groups with the ruleset
filesystem_groups. When configuring manual checks, you specify
the list of patterns in the check parameter "patterns".
The mount point of the filesystem (UNIX) or the drive
letter in upper case followed by a colon (Windows). For groups
the item is the name of the group.
One service is created for each filesystem
the agent reports except mount points listed in
inventory_df_exclude_mountpoints and filesystem types
listed in inventory_df_exclude_fs. The Windows agent
only reports fixed disks. The Linux agent reports filesystems
that have a size and are not of type smbfs, tmpfs, cifs or nfs.
When filesystem_groups is defined and a found filesystem
is matching one of the patterns of a group, then instead of a
service of the single filesystem one service for the group is
created. The service is the name of that group in that case.