ITM Agentless Monitoring for Linux

by Anthony Mico

As previously covered in earlier articles, ITM Agentless Monitoring for Windows, Linux, AIX, HP-UX and Solaris provides a scalable and easily configurable mechanism for monitoring servers that either do not support a native operating system agent or have some other constraint (such as disk space, security etc) that prevents an operating system agent from being installed locally.

As with the other Agentless Monitoring variants, Agentless Monitoring for Linux consists of an “agentless-monitoring server” agent which is used to collect performance and utilisation information from one or more remote hosts.  The agent is multi-instance, with a single agent being able to support up to 10 instances.  Each instance can support 100 remote hosts, meaning that a single agentless-monitoring server agent can support a total of 1000 remote hosts.

Agentless Monitoring for Linux uses SNMP as the means for collecting data from the remote hosts, with SNMP versions 1, 2c and 3 being supported.

The data collected by the agent includes:

  • Logical and physical disk utilisation
  • Virtual and Physical Memory utilisation
  • Aggregate processor utilisation
  • Process availability
  • Network utilisation
  • System uptime
  • User logins

Setting up agentless monitoring is a two part process.  Firstly, for agentless monitoring to work, the remote system to be monitored must have SNMP enabled and appropriately configured.  With that in place, the agentless monitoring agent can be configured.

SNMP Configuration on Ubuntu

sudo apt-get install snmpd

Edit /etc/default/snmpd and remove localhost as the listening address:

# snmpd options (use syslog, close stdin/out/err).
SNMPDOPTS=’-Lsd -Lf /dev/null -u snmp -g snmp -I -smux -p /var/run/snmpd.pid’

Edit /etc/snmp/snmpd.conf to control access, an example version 2c configuration is shown below with a community called tivoli created with readonly access to just the information required by the monitoring agent:

######
# First, map the community name (COMMUNITY) into a security name
# (local and mynetwork, depending on where the request is coming
# from):
# sec.name source community
com2sec readonly default tivoli
####
# Second, map the security names into group names:
# sec.model sec.name
group tivoli v2c readonly
####
# Third, create a view for us to let the groups have rights to:
# incl/excl subtree mask
view tivoliview included .iso.org.dod.internet.mgmt.mib-2.system
view tivoliview included .iso.org.dod.internet.mgmt.mib-2.interfaces
view tivoliview included .iso.org.dod.internet.mgmt.mib-2.host
view tivoliview included .iso.org.dod.internet.private.enterprises.ucdavis
####
# Finally, grant the 2 groups access to the 1 view with different
# write permissions:
# context sec.model sec.level match read write notif
access tivoli “” any noauth exact tivoliview none none

Restart the snmp daemon for the changes to take effect:

sudo service snmpd restart

The snmpwalk command can be used to confirm that the configuration is correct (where remotehost is the target system):

snmpwalk -v2c -c tivoli remotehost .iso.org.dod.internet.mgmt.mib-2.system

SNMP Configuration on Redhat/CentOS

The configuration of SNMP on Redhat variants is very similar to the process for Ubuntu.

Firstly, install the net-snmp and net-snmp-utils packages:

yum install net-snmp net-snmp-utils

Then, edit /etc/default/sysconfig/snmpd to confirm the SNMP daemon will listen on all interfaces (or specify a specific interface if you wish):

# snmpd command line options
OPTIONS=”-LS0-6d -Lf /dev/null -p /var/run/snmpd.pid”

Next edit /etc/snmp/sndmp.conf to control access, the same configuration as per the Ubuntu configuration above has been used:

#######
# First, map the community name (COMMUNITY) into a security name
# (local and mynetwork, depending on where the request is coming
# from):
# sec.name source community com2sec
readonly default tivoli
####
# Second, map the security names into group names:
# sec.model sec.name group
tivoli v2c readonly
####
# Third, create a view for us to let the groups have rights to:
# incl/excl subtree mask
view tivoliview included .iso.org.dod.internet.mgmt.mib-2.system
view tivoliview included .iso.org.dod.internet.mgmt.mib-2.interfaces
view tivoliview included .iso.org.dod.internet.mgmt.mib-2.host
view tivoliview included .iso.org.dod.internet.private.enterprises.ucdavis
####
# Finally, grant the 2 groups access to the 1 view with different
# write permissions:
# context sec.model sec.level match read write notif
access tivoli “” any noauth exact tivoliview none none

Restart the snmpd service to pickup the changes:

service snmpd restart

Ensure snmpd is started when the server is rebooted:

chkconfig snmpd on

Configuring the Agentless Monitoring agent

Using MTEMS, select to configure the Agentless Monitoring Agent for Linux.  The currently configured instances will then be listed, select Add Instance to add a new instance.

Agentless1 sm

Enter the Instance name, I’ve used Ubuntu in this example, and a default value for the SNMP port number and version.  These values can be overridden later on a per monitored host basis if required.

Agentless2 sm

Enter the Community Name, based on the snmpd.conf configuration file example given, this would be ‘tivoli’.

Agentless3 sm

Now we can enter the details of the remote systems that we want this agent instance to monitor, providing the Managed System Name (the name under which the agent appears in the TEP Navigator) and the server’s hostname or IP address.  The Advanced drop down can be used to override the default connection configuration values.

Agentless4 sm

With the agent configured, we should now see the remotely monitored hosts in the TEP, the below screenshot shows two agent instances, Ubuntu and CentOS, each with one monitored remote host.

Agentless5

Views: 597