Sorry, I thonk that my previous mail was not very clear. Of course, I will define a MIB, and I know the metrics I want to put in the MIB.
But is it possible in a Sub Agent X to add dynamically a metric, instrument it, and expose it to a monitoring client? How can I do that? Thanks. >From: "Dave Shield" <[EMAIL PROTECTED]> >To: "Arnaud BODENAN" <[EMAIL PROTECTED]> >CC: [email protected] >Subject: Re: How can I extend a MIB with a subagentX >Date: Tue, 18 Jul 2006 16:16:21 +0100 > >On 18/07/06, Arnaud BODENAN <[EMAIL PROTECTED]> wrote: >> Can I instrument specific metrics in each application (which are Sub >>Agent X), metrics which do not exist in the MIB ? > >If you are going to report management values from an agent (or >subagent), then you really do need to have a MIB to describe what >these values represent, and how they are structured. It's sort-of >possible to manage without one, just as it's sort-of possible to write >a program without any form of design. But it's definitely not >recommended. > >The process of writing the MIB file will help clarify your thoughts >about what information you need to report, and how it should be >represented - whether it's a set of independent scalar values, or a >collection of similar values for each application (i.e. a table), or a >combination of the two. > >Having a valid MIB file also allows network management applications to >report values more meaningfully, with sensible names, rather than a >meaningless numeric OID. And it allows you to use 'mib2c' to >construct the basic framework of your subagent code. > >Trying to develop a subagent without having a MIB file to act as a >design is extremely short-sighted, IMO. > > >> Must I define a huge MIB containing metrics common to >>all C++ applications I want to monitor? > >No - you can define several separate MIB files - each containing the >information specific to a particular application. That's probably a >more sensible approach than trying to cram everything into one massive >MIB. The agent and/or management applications will be quite happy to >combine these various private MIBs (together with the standard ones) >into the overall OID tree. > >But it's worth spending a bit of time thinking about the information >that you want to report, to see if there's anything that's common to >most/all of the applications. Abstracting the more general >information makes it easier to manage the overall system, rather than >having to repeat effectively the same processing for each application >individually. > >There's bound to be some stuff that's unique to a given application, >but the more you can handle generally (without forcing things unduly), >the better. > >One final point - please don't just pick a starting OID at random. If >you're *sure* that your work is going to be private (and always will >be), you're free to use the NET-SNMP-MIB::netSnmpPlaypen area. But if >there's the faintest possibility that this work might end up more >widely visible, then you should apply for your own enterprise number, >and structure everything under that. > >Dave _________________________________________________________________ Express yourself instantly with MSN Messenger! Download today it's FREE! http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/ ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV _______________________________________________ Net-snmp-users mailing list [email protected] Please see the following page to unsubscribe or change other options: https://lists.sourceforge.net/lists/listinfo/net-snmp-users
