2009/1/21 Daniel Montero Motilla <[email protected]>: > - In the case of memory (agent/mibgroup/hardware/memory/hw_mem.c), a > cache handler is used, but 'rootoid' parameter for > 'netsnmp_cache_create' is NULL, maybe because this cache handler is > associated to more than one oid??
Not really. It's simply that I didn't register this cache handler with the nsCacheTable. In part this probably *was* because the hardware/memory module is used by two distinct MIB modules (ucd-snmp/memory and host/hr_storage). Given that hrStorageTable is a fairly general table, it probably makes more sense to use the UCD-SNMP-MIB::memory OID. (Unless we wanted to use NET-SNMP-SYSTEM-MIB::nsMemory instead) Note that this OID isn't actually important - it's simply used as an index into the nsCacheTable. So it would be perfectly possible to decide on which OID to register with, even if the agent didn't actually implement that particular group of visible OIDs. > - In the case of cpu (agent/mibgroup/hardware/cpu/cpu.c), a cache > handler is not used by default, instead a periodic timer callback is > registered using 'snmp_alarm_register', and I suppose this timers > cannot be controlled using NET-SNMP-AGENT-MIB..nsMemory The situation with the CPU cache is slightly different. If the periodic timer approach isn't used, then we're in the same boat as with hardware/memory - there's a cache which isn't (currently) registered with the nsCacheTable. Again, we could tweak this to use UCD-SNMP-MIB::systemStats or NET-SNMP-AGENT-MIB..nsCPU or something. But by default, this information will be sampled regularly, even without any incoming requests. That's necessary to implement the "cooked" CPU statistics (ssCpuUser, etc) as well as hrCpuLoad. All of these objects rely on having a "history" of previous activity. Which means invoking this routine periodically. > Any suggestion about the better way to implement the same behaviour in > these two specific cases will be welcomed! As far as the CPU stats are concerned, it would probably be sensible (and reasonably straighforward) to add a configure token to control the frequency of sampling. As for the two cache-driven cases - that's simply a matter of adding a suitable OID to the relevant netsnmp_cache_create() calls. If it was just the memory module, then the obvious OID to use would be UCD-SNMP-MIB::memory But UCD-SNMP-MIB::systemStats is a little too general for use with the CPU stats (since this group covers IO and other stats as well). So I'm inclined to use the NET-SNMP-SYSTEM-MIB OIDs for both of these cache indexes. Thoughts? Dave ------------------------------------------------------------------------------ This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword _______________________________________________ Net-snmp-coders mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/net-snmp-coders
