[AGENT++] Advice for the statistic traps?

[Frank Fock]

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
>     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!