ipmimonitoring(8)

."############################################################################# ."$Id: ipmimonitoring.8.in,v 1.11.6.2 2007/07/18 20:13:42 chu11 Exp $ ."############################################################################# ." Copyright (C) 2006 The Regents of the University of California. ." Produced at Lawrence Livermore National Laboratory (cf, DISCLAIMER). ." Written by Albert Chu <chu11@llnl.gov> ." UCRL-CODE-222073 ." ." This file is part of Ipmimonitoring, an IPMI sensor monitoring ." library. For details, see http://www.llnl.gov/linux/. ." ." Ipmimonitoring is free software; you can redistribute it and/or modify it under ." the terms of the GNU General Public License as published by the Free ." Software Foundation; either version 2 of the License, or (at your option) ." any later version. ." ." Ipmimonitoring is distributed in the hope that it will be useful, but WITHOUT ." ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or ." FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License ." for more details. ." ." You should have received a copy of the GNU General Public License along ." with Ipmimonitoring; if not, write to the Free Software Foundation, Inc., ." 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA. ."############################################################################

NAME
ipmimonitoring - IPMI monitoring tool

SYNOPSIS
ipmimonitoring [OPTIONS]

DESCRIPTION
ipmimonitoring is an IPMI sensor monitoring tool that utilizes the libipmimonitoring library to interpret sensor readings rather than just report them. The tool will output if sensors are in Nominal, Warning, or Critical states. The state interpretations are determined by the configuration file /usr/local/etc/ipmi_monitoring_sensors.conf. The library and tool are primarily used for host monitoring activities. For more general sensor reading use, it is recommended that users use ipmi-sensors(8). Ipmimonitoring will cache the sensor data repository of the machine for later retrieval. So the first time you run ipmimonitoring may take longer to complete that later executions. By default, the SDR data is cached in /var/db/freeipmi/ipmimonitoringsdrcache.

OPTIONS

-h, --hostname host
    Specify the remote host or hosts to connect to. May include host ranges. See HOSTRANGED OUTPUT below.

-u, --username name
    Specify the username to use to establish communication. If not specified, the NULL user is assumed.

-p, --password pw
    Specify the password to use to establish communication. If not specified, a NULL password is assumed.

-l, --privilege str
    Specify the privilege type to use. The currently available privilege types are "user", "operator", and "admin". If not specified, a privilege of "admin" is assumed.

-a, --authentication-type str
    Specify the authentication mechanism to use. The currently available authentication mechanisms are "none", "straight_password_key", "md2", and "md5". If not specified, "md5" is assumed.

-s, --sensors list
    Specify a list of sensors record ids to specifically monitor. List of sensors can be separated by commas.

-g, --groups list
    Specify a list of groups to specifically monitor. List of groups can be separated by commas. The available groups are: temperature, voltage, current, fan, physical_security, platform_security_violation_attempt, processor, power_supply, power_unit, memory, drive_slot, system_firmware_progress, event_logging_disabled, system_event, critical_interrupt, module_board, slot_connector, watchdog2.

-c, --cache-dir dir
    Specify an alternate directory to read and write SDR caches.

-r, --regenerate-sdr-cache
    By default ipmimonitoring, caches the sensor data repository (SDR) of a node for quicker monitoring on subsequent executions of ipmimonitoring. This option informs ipmimonitoring to regenerate an SDR cache. This is often used if the firmware for a remote node has been changed.

-q, --quiet-readings
    Do not output sensor reading values, only Nominal, Warning, or Critical states. This option is particularly useful if you want to use hostranged output across a cluster and want to consolidate the output.

-B, --buffer-output
    Buffer hostranged output. Each node's standard output will output after the node has completed its IPMI operation. When specifying this option, data may appear to output slower to the user since the the entire IPMI operation must complete before any data can be output. See HOSTRANGED OUTPUT below for additional information.

-C, --consolidate-output
    Consolidate hostranged output. The complete standard output from every node specified will be consolidated so that nodes with identical output are not output twice. A header will list those nodes with the consolidated output. When this option is specified, no output can be seen until the IPMI operations to all nodes has completed. If the user breaks out of the program early, all currently consolidated output will be dumped. See HOSTRANGED OUTPUT below for additional information.

-F, --fanout num
    Set multiple host fanout. A "sliding window" (or fanout) algorithm is used for parallel IPMI communication so that slower nodes or timed out nodes will not impede parallel communication. The maximum number of threads available at the same time is limited by the fanout. The default is 64. See HOSTRANGED OUTPUT below for additional information.

-E, --eleminate
    Eliminate hosts determined as undetected by ipmidetect. This attempts to remove the common issue of hostranged execution timing out due to several nodes being removed from service in a large cluster. The ipmidetectd daemon must be running on the node executing the command. See HOSTRANGED OUTPUT below for additional information.

-H, --help
    Output help menu and exit.

-V, --version
    Output version and exit.

HOSTRANGED OUTPUT
The host input specified by the user can accept multiple hosts for parallel out of band communication and output. Multiple hosts can be input either as an explicit comma seperated lists of hosts or a range of hostnames in the general form: prefix[n-m,l-k,...], where n < m and l < k, etc. The later form should not be confused with regular expression character classes (also denoted by []). For example, foo[19] does not represent foo1 or foo9, but rather represents a degenerate range: foo19.

This range syntax is meant only as a convenience on clusters with a prefixNN naming convention and specification of ranges should not be considered necessary -- the list foo1,foo9 could be specified as such, or by the range foo[1,9].

Some examples of range usage follow:
    foo[01-05] instead of foo01,foo02,foo03,foo04,foo05
    foo[7,9-10] instead of foo7,foo9,foo10
    foo[0-3] instead of foo0,foo1,foo2,foo3

As a reminder to the reader, some shells will interpret brackets ([ and ]) for pattern matching. Depending on your shell, it may be necessary to enclose ranged lists within quotes.

By default, standard output from each node specified will be output with the hostname prepended to each line. Although this output is readable in many situations, it may be difficult to read in other situations. For example, output from multiple nodes may be mixed together. The -B and -C options can be used to change this default.

In-band IPMI Communication will be used when the host "localhost" is specified. This allows the user to add the localhost into the hostranged output.

KNOWN ISSUES
Interpretation rules have not been written for all sensors permutations and types. If sensor interpretation rules are needed, please contact the author listed below.

FILES
/var/db/freeipmi/ipmimonitoringsdrcache /usr/local/etc/ipmi_monitoring_sensors.conf

ORIGIN
Developed by Albert Chu <chu11@llnl.gov> on LLNL's GNU/Linux clusters. This software is open source and distributed under the terms of the Gnu GPL.

SEE ALSO
ipmi-sensors(8), libipmimonitoring(3)