[AGENT++] Advice for the statistic traps?
Frank Fock
fock at agentpp.com
Wed Apr 14 22:58:53 CEST 2004
If you want to distinguish the 10 statistic objects, then you can
introduce a discriminator index to distinguish between the 10
statistic objects as follows (note that the discriminator index
could also be a string or enumerated integer):
STATISTICS-MIB DEFINITIONS ::= BEGIN
IMPORTS
OBJECT-GROUP,
NOTIFICATION-GROUP
FROM SNMPv2-CONF
enterprises,
MODULE-IDENTITY,
OBJECT-TYPE,
NOTIFICATION-TYPE,
Counter32,
Unsigned32
FROM SNMPv2-SMI;
statRegMIB MODULE-IDENTITY
LAST-UPDATED "200404142052Z" -- Apr 14, 2004 8:52:00 PM
ORGANIZATION " "
CONTACT-INFO
" "
DESCRIPTION
" "
REVISION "200404142052Z" -- Apr 14, 2004 8:52:00 PM
DESCRIPTION
"Initial version."
-- 1.3.6.1.4.1.0 -- ::= { enterprises 0 }
-- Scalars and Tables
--
statObjects OBJECT IDENTIFIER
-- 1.3.6.1.4.1.0.1 -- ::= { statRegMIB 1 }
statTable OBJECT-TYPE
SYNTAX SEQUENCE OF StatEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
""
-- 1.3.6.1.4.1.0.1.1 -- ::= { statObjects 1 }
statEntry OBJECT-TYPE
SYNTAX StatEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
""
INDEX {
statObjectDiscriminator,
statIndex }
-- 1.3.6.1.4.1.0.1.1.1 -- ::= { statTable 1 }
StatEntry ::= SEQUENCE {
statObjectDiscriminator Unsigned32,
statIndex Unsigned32,
statObject Counter32 }
statObjectDiscriminator OBJECT-TYPE
SYNTAX Unsigned32
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
""
-- 1.3.6.1.4.1.0.1.1.1.1 -- ::= { statEntry 1 }
statIndex OBJECT-TYPE
SYNTAX Unsigned32
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
""
-- 1.3.6.1.4.1.0.1.1.1.2 -- ::= { statEntry 2 }
statObject OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
""
-- 1.3.6.1.4.1.0.1.1.1.3 -- ::= { statEntry 3 }
-- Notification Types
--
statEvents OBJECT IDENTIFIER
-- 1.3.6.1.4.1.0.2 -- ::= { statRegMIB 2 }
statEventSMIv1CompatibilityNode OBJECT IDENTIFIER
-- 1.3.6.1.4.1.0.2.0 -- ::= { statEvents 0 }
-- Conformance
--
statConf OBJECT IDENTIFIER
-- 1.3.6.1.4.1.0.3 -- ::= { statRegMIB 3 }
-- Groups
--
statGroups OBJECT IDENTIFIER
-- 1.3.6.1.4.1.0.3.1 -- ::= { statConf 1 }
-- Compliance
--
statCompls OBJECT IDENTIFIER
-- 1.3.6.1.4.1.0.3.2 -- ::= { statConf 2 }
statChangedEvent NOTIFICATION-TYPE
OBJECTS {
statObject}
STATUS current
DESCRIPTION
""
-- 1.3.6.1.4.1.0.2.0.1 -- ::= { statEventSMIv1CompatibilityNode 1 }
statBasicGroup OBJECT-GROUP
OBJECTS {
statObject }
STATUS current
DESCRIPTION
"Basic objects."
-- 1.3.6.1.4.1.0.3.1.1 -- ::= { statGroups 1 }
statBasicEvents NOTIFICATION-GROUP
NOTIFICATIONS {
statChangedEvent }
STATUS current
DESCRIPTION
"Basic notifications."
-- 1.3.6.1.4.1.0.3.1.2 -- ::= { statGroups 2 }
END
Mr. AWD wrote:
> Thanks for the reply!
>
> But, even tough, you labeled it as a fourth option, it looks like the
> second option that I have mentioned bellow. Basically, you have stat
> objects (not just one as in your example, which makes things a bit
> more complicated) in the table (or several tables in my case), that
> was added as a varbind companion to the trap it self.
>
> Well ,the question is what to do in that case if you have let say 10
> statistic tables with 10 objects inside (without the index) each one
> and one trap to handle them?
>
> ---------------------------------
>
> -- Statistic objects
>
> ---------------------------------
>
> statTable1 OBJECT-TYPE
> SYNTAX SEQUENCE OF StatTable1Entry
> MAX-ACCESS not-accessible
> STATUS current
> DESCRIPTION
> ""
> -- 1.3.6.1.4.1.0.1.1 -- ::= { statObjects 1 }
>
>
> statTable1Entry OBJECT-TYPE
> SYNTAX StatTable1Entry
> MAX-ACCESS not-accessible
> STATUS current
> DESCRIPTION
> ""
> INDEX {
> statTable1Index }
> -- 1.3.6.1.4.1.0.1.1.1 -- ::= { statTable1 1 }
>
>
> StatTable1Entry ::= SEQUENCE {
>
> statTable1Index Unsigned32,
> statTable1Object1 Counter32,
>
> statTable1Object2 Counter32,
>
> statTable1Object3 Counter32,
>
> statTable1Object4 Counter32,
>
> statTable1Object5 Counter32,
>
> statTable1Object6 Counter32,
>
> statTable1Object7 Counter32,
>
> statTable1Object8 Counter32,
>
> statTable1Object9 Counter32,
>
> statTable1Object10 Counter32 }
>
>
> statTable1Index OBJECT-TYPE
> SYNTAX Unsigned32
> MAX-ACCESS not-accessible
> STATUS current
> DESCRIPTION
> ""
> -- 1.3.6.1.4.1.0.1.1.1.1 -- ::= { statTable1Entry 1 }
>
>
> statTable1Object1 OBJECT-TYPE
> SYNTAX Counter32
> MAX-ACCESS read-only
> STATUS current
> DESCRIPTION
> ""
>
> -- 1.3.6.1.4.1.0.1.1.1.2 -- ::= { statTable1Entry 2 }
>
> statTable1Object2 OBJECT-TYPE
> SYNTAX Counter32
> MAX-ACCESS read-only
> STATUS current
> DESCRIPTION
> ""
>
> -- 1.3.6.1.4.1.0.1.1.1.3 -- ::= { statTable1Entry 3 }
>
> ------- and so on for the rest of the sequence ----------
>
> ---------------------------------
>
> -- Notifications
>
> ---------------------------------
>
> statChangedEvent NOTIFICATION-TYPE
> OBJECTS {
> statTable1Object1,
>
> statTable1Object2,
>
> statTable1Object3,
>
> statTable1Object4,
>
> statTable1Object5,
>
> statTable1Object6,
>
> statTable1Object7,
>
> statTable1Object8,
>
> statTable1Object9,
>
> statTable1Object10 }
> STATUS current
> DESCRIPTION
> ""
> -- 1.3.6.1.4.1.0.2.0.1 -- ::= { statEventSMIv1CompatibilityNode 1 }
>
> Here is just a core of the MIB that you send in, and I added only one
> table and in actual case I have 9 more. Shall I add all of them then
> into the statChangedEvent object as a VarBinds or what? Even with just
> 10 statistic object, sending one with the higher number would be
> require to send all of the previous ones, which will increase the size
> of the packet overall. Then when you get to the larger number of the
> objects, what then?
>
> Fedja
>
> --- On Wed 04/14, Frank Fock < fock at agentpp.com > wrote:
>
> *From: *Frank Fock [mailto: fock at agentpp.com]
> *To: *mrawd at excite.com
> *Cc: *agentpp at agentpp.org
> *Date: *Wed, 14 Apr 2004 21:04:45 +0200
> *Subject: *Re: [AGENT++] Advice for the statistic traps?
>
> No, my suggestion was a fourth approach as illustrated by
> the following MIB module:
>
> STATISTICS-MIB DEFINITIONS ::= BEGIN
>
> IMPORTS
> OBJECT-GROUP,
> NOTIFICATION-GROUP
> FROM SNMPv2-CONF
> enterprises,
> MODULE-IDENTITY,
> OBJECT-TYPE,
> NOTIFICATION-TYPE,
> Counter32,
> Unsigned32
> FROM SNMPv2-SMI;
>
> statRegMIB MODULE-IDENTITY
> LAST-UPDATED "200404142052Z" -- Apr 14, 2004 8:52:00 PM
> ORGANIZATION " "
> CONTACT-INFO
> " "
> DESCRIPTION
> " "
> REVISION "200404142052Z" -- Apr 14, 2004 8:52:00 PM
> DESCRIPTION
> "Initial version."
> -- 1.3.6.1.4.1.0 -- ::= { enterprises 0 }
>
>
> -- Scalars and Tables
> --
>
> statObjects OBJECT IDENTIFIER
> -- 1.3.6.1.4.1.0.1 -- ::= { statRegMIB 1 }
>
> statTable OBJECT-TYPE
> SYNTAX SEQUENCE OF StatEntry
> MAX-ACCESS not-accessible
> STATUS current
> DESCRIPTION
> ""
> -- 1.3.6.1.4.1.0.1.1 -- ::= { statObjects 1 }
>
>
> statEntry OBJECT-TYPE
> SYNTAX StatEntry
> MAX-ACCESS not-accessible
> STATUS current
> DESCRIPTION
> ""
> INDEX {
> statIndex }
> -- 1.3.6.1.4.1.0.1.1.1 -- ::= { statTable 1 }
>
>
> StatEntry ::= SEQUENCE {
>
> statIndex Unsigned32,
> statObject Counter32 }
>
>
> statIndex OBJECT-TYPE
> SYNTAX Unsigned32
> MAX-ACCESS not-accessible
> STATUS current
> DESCRIPTION
> ""
> -- 1.3.6.1.4.1.0.1.1.1.1 -- ::= { statEntry 1 }
>
>
> statObject OBJECT-TYPE
> SYNTAX Counter32
> MAX-ACCESS read-only
> STATUS current
> DESCRIPTION
> ""
> -- 1.3.6.1.4.1.0.1.1.1.2 -- ::= { statEntry 2 }
>
>
> -- Notification Types
> --
>
> statEvents OBJECT IDENTIFIER
> -- 1.3.6.1.4.1.0.2 -- ::= { statRegMIB 2 }
>
> statEventSMIv1CompatibilityNode OBJECT IDENTIFIER
> -- 1.3.6.1.4.1.0.2.0 -- ::= { statEvents 0 }
>
> -- Conformance
> --
>
> statConf OBJECT IDENTIFIER
> -- 1.3.6.1.4.1.0.3 -- ::= { statRegMIB 3 }
>
> -- Groups
> --
>
> statGroups OBJECT IDENTIFIER
> -- 1.3.6.1.4.1.0.3.1 -- ::= { statConf 1 }
>
> -- Compliance
> --
>
> statCompls OBJECT IDENTIFIER
> -- 1.3.6.1.4.1.0.3.2 -- ::= { statConf 2 }
>
>
> statChangedEvent NOTIFICATION-TYPE
> OBJECTS {
> statObject}
> STATUS current
> DESCRIPTION
> ""
> -- 1.3.6.1.4.1.0.2.0.1 -- ::= { statEventSMIv1CompatibilityNode 1 }
>
> statBasicGroup OBJECT-GROUP
> OBJECTS {
> statObject }
> STATUS current
> DESCRIPTION
> "Basic objects."
> -- 1.3.6.1.4.1.0.3.1.1 -- ::= { statGroups 1 }
>
> statBasicEvents NOTIFICATION-GROUP
> NOTIFICATIONS {
> statChangedEvent }
> STATUS current
> DESCRIPTION
> "Basic notifications."
> -- 1.3.6.1.4.1.0.3.1.2 -- ::= { statGroups 2 }
>
> END
>
>
> Mr. AWD wrote:
>
> > So is that like my third option mentioned bellow which could
> look like
> > this:
> > latestEventInfo OBJECT-TYPE
> > SYNTAX DisplayString (SIZE(0..255))
> > MAX-ACCESS read-write
> > STATUS current
> > DESCRIPTION { ... }
> > ::= { statGroup 1 }
> >
> > statisticGenericTrap NOTIFICATION-TYPE
> > OBJECT { latestEventInfo }
> > STATUS current
> > DESCRIPTION { ... }
> > ::= { trapGroup 1 }
> >
> > Or, maybe something else that you had in mind?
> >
> > Thanks again!
> >
> >
> > Fedja
> >
> >
> >
> >
> >
> > --- On Wed 04/14, Frank Fock < fock at agentpp.com > wrote:
> >
> > *From: *Frank Fock [mailto: fock at agentpp.com]
> > *To: *mrawd at excite.com
> > *Cc: *agentpp at agentpp.org
> > *Date: *Wed, 14 Apr 2004 20:25:03 +0200
> > *Subject: *Re: [AGENT++] Advice for the statistic traps?
> >
> > Hi Fedja,
> >
> > I would prefer putting the statistic objects into a table and
> > then send only the instances that has changed in the< BR>> trap.
> >
> > Best regards,
> > Frank
> >
> > Mr. AWD wrote:
> >
> > > I am using agent++ for the implementation of the statistic agent
> > that
> > > is suppose to send a notification whenever one of the stats
> > breaks the
> > > range that was specified. So, one way would be to implement one
> > > notification object for each of the statistic objects, but that
> > would
> > > be overkill since there are over 100 or so of the stat objects
> > in there.
> > >
> > > Other way would be to have a generic trap that would somehow add a
> > > varbind object that points to the statistic object it self, but
> > that
> > > would still be too many varbinds in there.
> > >
> > > Third option could be to have a generic string object that gets
> > filled
> > > in whenever event gets to the agent and include that into the
> > trap as
> > > a varbind object.
> > >
> > > Is there a better way to do this kind of task that someone can
> > add in
> > > here?
> > >
> > > Thanks!
> > >
> > >
> > > Fedja
> > >
> > >
> > >
> > >
> >
> ------------------------------------------------------------------------
> > > *Join Excite! - http://www.excite.com*
> > > The most personalized portal on the Web!
> > >
> >
> >------------------------------------------------------------------------
> > >
> > >_______________________________________________
> > >AGENTPP mailing list
> > >AGENTPP at agentpp.org
> > >http://agentpp.org/mailman/listinfo/agentpp
> > >
> > >
> >
> >
> > _______________________________________________
> > AGENTPP mailing list
> > AGENTPP at agentpp.org
> > http://agentpp.org/mailman/listinfo/agentpp
> >
> >
> ------------------------------------------------------------------------
> > *Join Excite! - http://www.excite.com*
> > The most personalized portal on the Web!
>
>
>
>
> ------------------------------------------------------------------------
> *Join Excite! - http://www.excite.com*
> The most personalized portal on the Web!
More information about the AGENTPP
mailing list