SNMP for server monitoring purposes

[NDO]

Hi

Please can anybody help on this: I want to use SNMP to monitor and produce graphs of CPU load, Memory and disk space.

I am running hp-ux 11.31, and the servers to monitor are using 11.23 and solaris 10.

I did some research and I have to edit the following /etc/SnmpAgent.d/snmpd.conf file but I am not sure how to setup community strings, traps, 

I am not sure if I also need to have rrdtool in conjunction with this.

regards

[Matti_Kurkela]

So, the 11.31 system would be your monitoring station then?

On the monitoring station, you'll need some tools that can send SNMP queries and collect the answers, and produce graphs out of the collected answers. If you want to minimize the amount of installed software, one possibility would be to install the net-SNMP package (that includes the "snmpwalk" and "snmpget" tools) for the queries and rrdtool for storing the answers and producing graphs out of them. Then you would need to design some scripts to actually use the net-SNMP tools and rrdtool in a meaningful way. It might be useful to do it once to really learn and understand the tools, but it is not very convenient to monitor a large number of hosts that way.

However, if you have more than a handful of hosts to monitor, then something like MRTG or Cacti might be a better choice for you:

http://oss.oetiker.ch/mrtg/index.en.html

http://www.cacti.net/

Both are completely free open-source products.

MRTG is available as a pre-compiled HP-UX depot from the Porting Archive:

http://hpux.connect.org.uk/hppd/hpux/Networking/Admin/mrtg-2.16.4/

(note that it has quite a lot of run-time dependencies that must be installed too.)

Cacti is PHP-based, so to make it work you'll need a web server that supports PHP on your monitoring station. You'll also need net-SNMP, rrdtool and MySQL installed. Cacti can be somewhat complex to install and configure, but once properly set up, it will be a very powerful tool.

For example: you can define multiple password-protected views, so each of your users can see only the graphs that are relevant to him/her. And instead of producing weekly or monthly graph print-outs, you can give your boss real-time access to the graphs s/he needs. The graph viewer allows an easy way to zoom into a selected part of the graph timeline, if there is something that needs to be examined in more detail.

Community strings

With SNMP protocol versions 1 and 2, a SNMP community string is essentially a password. If the monitoring station sends a SNMP query using the same community string that is configured to the SNMP agent, the agent will answer the query; if the community string is wrong, the agent will not answer to the monitoring station. (The agent may even send a trap message, telling "I just received a SNMP query with a wrong community name from IP address X"; see below.)

The community strings are sent with no encryption, so you should assume that they won't remain secret if someone really wants to know them and can monitor your network traffic. (You should configure the SNMP agents to allow only read-only SNMP access unless you know you have a specific requirement for SNMP write access.)

Most SNMP agents will accept at least two community strings: one for read-only access and another for write access. Some agents will accept more than two, with the ability to define more complex access rules. But essentially, you configure your SNMP agents to accept a specific SNMP community name, and then configure the same community name to your monitoring scripts or applications on the monitoring station.

Traps

Normally, a SNMP agent only sends some information when directly asked to. Sometimes it is useful to have the SNMP agent send notifications of important events without having the monitoring station ask for it. These notifications are called SNMP traps. A printer might send a SNMP trap to tell it's out of paper; a server might send a SNMP trap to notify it's shutting down, or that it's just booted up; any device with a temperature sensor might use SNMP traps to send an over-temperature alert; etc.

Graph production tools like MRTG and Cacti don't use SNMP traps at all, so you can completely ignore them. But if you want, with the net-SNMP tools you can set up a SNMP trap receiver daemon that will output any received trap messages to syslog on your monitoring station.

The traps can also use the "community name" password system: you can usually configure a different "trap community name" to the SNMP agent, so that the trap receiver can check for it to see if the trap messages are genuine. SNMP is based on UDP protocol and is very simple, so it would be very simple for a malicious person to create fake SNMP trap messages with a forged source IP address.