Re: Cacti 0.8.6j Released (fwd)
Matthew Palmer wrote: On Tue, May 08, 2007 at 08:10:56PM -0700, matthew zeier wrote: and more to the point how the whole shebang (I'm using net-snmpd) is typically used. Agent on device provides values, management app(s) collect data by polling (and possibly via traps), sysadmin gets to go home on time for once. I have yet to see this work in practice however. Yeah, I misread 'typically' as 'theoretically'. Practical experience is more like: Agent on device lies about it's values, management apps collect lies (and ignore/lose traps), and the sysadmin has yet more software to swear at. grin - Matt Just for curiousities sake IASON is reading logs most of the time. proc2pl is reading the /proc filesystem. I did not find the time and equipment for testing so I used snmpwalk to write a file and read it just like any normal file or /proc. Processing the output of snmpwalk just got me the normal log file I was interested in. I tried writing back into snmp variables but I never got a HP Procurve switch to do what I wanted. When they used different MIBs for different families of their switches, I gave up. Now I see linux boxes most of the time. They all use different MIBs for different things. Reading /proc is much easier and there a fewer differences between the machines. The soho stuff I find mostly uses web interfaces sometimes a real linux with a real log but almost never snmp. Looks sad, but I am still interested as it could make things a lot easier. Cheers Peter and Karin -- Peter and Karin Dambier Cesidian Root - Radice Cesidiana Rimbacher Strasse 16 D-69509 Moerlenbach-Bonsweiher +49(6209)795-816 (Telekom) +49(6252)750-308 (VoIP: sipgate.de) mail: [EMAIL PROTECTED] mail: [EMAIL PROTECTED] http://iason.site.voila.fr/ https://sourceforge.net/projects/iason/ http://www.cesidianroot.com/
Re: Cacti 0.8.6j Released (fwd)
[If people think this is off-topic, please let me know and I'll take it to private mail with Travis.] On Tue, May 08, 2007 at 07:32:18PM -0500, Travis H. wrote: Hey folks, I am following up to an ancient email because I'm curious if anyone has some SNMP-related resources. Basically, there's a lot of how-to or manpage sort of information, but I'm still unclear on what an MIB actually _is_, It's an overloaded term. Technically, I think it's the values which you can query by OID in an agent, but most people use the term to describe the textual description of the OIDs and what they mean, especially when they talk about downloading a MIB. what problem ASN.1 actually solves, How to encode the queries and responses. Unless you're actually writing an agent or low-level manager library, ignore it. Seriously, you don't need the headache. and more to the point how the whole shebang (I'm using net-snmpd) is typically used. Agent on device provides values, management app(s) collect data by polling (and possibly via traps), sysadmin gets to go home on time for once. I believe that what I need to do is get any/all MIBs for all entities (typically networking hardware devices) that I want to monitor, and import them into the net-snmp configuration somehow, and then software that calls on net-snmp can access the information from the devices. Is this accurate? Kinda-sorta. You don't actually need a MIB to be able to query a device -- you can, in theory, just walk it from the root and get all the OIDs (and their values) that the agent provides. However, since all you'll get are massive quantities of numbers, that'll be fairly useless, and the MIB file you refer to will help you (and your agent software) decode the OIDs into something more readable. That being said, if you only want to monitor a few OIDs, and you know the OIDs already, then the MIB is unnecessary. Where you put the MIBs to net-snmp can find them depends on where net-snmp has been told to look for them. /usr/share/snmp/mibs is where they go on my system, but $DEITY knows where they might end up on some Unices. Will I need to import MIBs to every net mgmt application? Should they If they use different OIDs, and you want to be able to use them easily, yes. This using different OIDs thing is depressingly common -- although there are RFC standards for a lot of the common types of networking data, a combination of the RFCs don't define all our statistics and NIH means that a lot of vendor equipment does it's own SNMP thing. be carefully accounted for and synchronized, or can I treat them like a typical configuration file, where it is obvious if I need it and I get them as needed? They're not critical to the operation of the whole thing, merely the comprehensibility, so don't get too obsessed over your MIBs. - Matt -- Just because we work at a University doesn't mean we're surrounded by smart people. -- Brian Kantor, in the monastery
Re: Cacti 0.8.6j Released (fwd)
and more to the point how the whole shebang (I'm using net-snmpd) is typically used. Agent on device provides values, management app(s) collect data by polling (and possibly via traps), sysadmin gets to go home on time for once. I have yet to see this work in practice however.
Re: Cacti 0.8.6j Released (fwd)
On Tue, May 08, 2007 at 08:10:56PM -0700, matthew zeier wrote: and more to the point how the whole shebang (I'm using net-snmpd) is typically used. Agent on device provides values, management app(s) collect data by polling (and possibly via traps), sysadmin gets to go home on time for once. I have yet to see this work in practice however. Yeah, I misread 'typically' as 'theoretically'. Practical experience is more like: Agent on device lies about it's values, management apps collect lies (and ignore/lose traps), and the sysadmin has yet more software to swear at. grin - Matt -- I'm seriously considering getting one of those bright-orange prison overalls and stencilling PASSENGER on the back. Along with the paper slippers, I ought to be able to walk right through security. Not. -- Brian Kantor, in the Monastery
