Hi Rahul, On Fri, Jan 30, 2009 at 1:06 PM, Rahul Nabar <rpna...@gmail.com> wrote: > Ah! Now I am lost! What do you mean by this. Sorry I am a networks newbiee > and especially SNMP is greek-n-latin to me!
SNMP data is represented as a huge heirarchical tree. Branches of the global tree can also be called tables. Tables are often organized by purpose. MIBs map the numerical OID tables to human readable descriptions. In tables, entities will often have a representation that is similar to how data is represented in a table in a database .. there may be a unique string identifier for an a but there is also a numeric ID (index number) for the row as well that uniquely identifies it within the table. So an interface eth0 in the IF-MIB table of an agent might have a numeric index of 1. If you are going to be working a lot with SNMP devices, I recommend getting a book on SNMP :) and reading online about it. it is fairly easy to use once you understand it, but understanding can take some serious time. > Actually I am not even sure what I should be monitoring on a switch. I was > just using the example from the nagios tutorial for now. Maybe its > "alive/dead status" ; bandwidth of individual ports (but that's mrtg's job > right?) ; dropped packets; some thermal events? How does one go about this? > What are other users montoring on their switches and how does one go about > translating the fairly cryptic SNMP fields into something usable? Should I > dig into my Dell switch manuals? Or is this reinventing the wheel and Nagios > has an automated way to achieve this already? There are a number of metrics you can monitor; which you choose depends on what is important to your network staff and your project. Yes, hardware events are good, most managed switches will send SNMP traps (asyncronous events sent by the monitored entity to the management station). Using SNMPTT and Net-SNMP's snmptrapd along with a simple shell script you can ingest these traps into Nagios and associate them with passive services on the host they are occuring on. CPU and memory utilization are always good to watch as well. There are several MIBs (SNMP tables) that network device agents can implement. The most common one is the IF-MIB. This covers a number of important, basic, fault management metrics. For polling, often these metrics from the IF-MIB are desirable: * Interface status * Discards in/out * Errors in/out * Interface speed Those are the simple fault management metrics, for performance thresholds: * Volume in/out * bits per second in/out sometimes are used, depending on the context. ISPs or companies paying for bandwidth really care about volume and bps There can be others as well, depending on how mature the SNMP agent on the device is; a common one that is implemented in agents in a number of ways is duplex. Vendors often also implement device-specific MIBs that expose greater numbers of metrics than standard MIBs do, so please make sure you read the documentation for your device carefully. MRTG does not alert based on thresholds, so no, having Nagios poll performance data doesn't duplicate effort. However, you might want to look at a framework like PNP (http://www.pnp4nagios.org) and use that instead of MRTG. There is a learning curve to integrating it, but with PNP in place each Nagios poll can do both fault management and performance trending. PNP uses RRDtool and is a very flexible and useful framework for graphing. There are other graphing frameworks as well, but thus far I have been the most happy with PNP. ------------------------------------------------------------------------------ This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword _______________________________________________ Nagios-users mailing list Nagios-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/nagios-users ::: Please include Nagios version, plugin version (-v) and OS when reporting any issue. ::: Messages without supporting info will risk being sent to /dev/null
