On 19 May 2012 12:41, Douglas Hubler <[email protected]> wrote:
> In short, the prErrorFlag flag in the prTable had to transition like so
>
> prErrorFlag values:
> 0 => 1 => 0 => 1 OK - prFixIt event fired on each transition from 0 to 1
> 0 => 1 => 1 => 1 Not OK - prFixIt event only fired once
That's correct. This is the defined behaviour of the mteTrigger table
as defined in RFC 2981. See the third paragraph of the DESCRIPTION
of mteTriggerTest
> I checked the value of mteTrigger->flags and bitmask
> MTE_TRIGGER_FLAG_DELTA was *not* set (actual value was 111100110010)
> but it acted like mteTrigger.c needed a change to actually fire the
> event.
That's not what the delta flag means.
A monitor entry with this flag set is implementing a trigger with
a mteTriggerSampleType value of deltaValue (rather than absoluteValue)
This means that it will be looking at the _difference_ between successive
readings of the MIB object being monitored, rather than the actual values.
This is most commonly used when monitoring a counter-based object
(such as if{In,Out}Octets)
> What I think is happening is there's logic to not try to send the same
> event twice.
That is correct - this is exactly what is required by the DisMan
Event MIB specification.
> There's an additional concern though! The process table
> is cached
I believe that actually depends on how the agent has been compiled.
The traditional implementation of the process table (i.e. not linked in
with the hrSWRunTable) will query the underlying kernel afresh every time.
But yes - the current hrSWRunTable implementation does use a cache
to hold this data, and the process table handling will use this cached data
(to provide a consistent behaviour between the UCD-specific and IETF
standard semi-equivalent tables)
> so even if find a way to fire prFixit events on each monitor
> run, I'll be firing events based on values in the process cache, not
> the actual process list from the OS so if the process does start ok,
> I'll be attempting to start the process unnecessarily.
Remember that you can always control the cache timeout - either
reducing it to something fairly small (e.g a few seconds, rather than
the default of 30s), or setting it to 0 to disable caching altogether.
Naturally, there's a performance hit if you do this - but the
choice is yours.
See the NET-SNMP-AGENT-MIB::nsCacheTable for details
Dave
------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
Net-snmp-coders mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/net-snmp-coders
