Sounds like it might be a good idea. Not sure I understand exact usage of
"counter errors". Is this problems with the counters, counts of errors...?
----------------------------------------------
Harry Lewis
IBM STSM
Chairman - IEEE-ISTO Printer Working Group
http://www.pwg.org
IBM Printing Systems
http://www.ibm.com/printers
303-924-5337
----------------------------------------------
"McDonald, Ira" <imcdonald@sharplabs.com>
Sent by: owner-wims@pwg.org
01/25/2005 07:56 PM
To
"'wims@pwg.org'" <wims@pwg.org>
cc
Subject
WIMS> Counter MIB - Alert table/trap proposal
Hi folks, Tuesday (25 January 2005)
I propose that we add an Alert group (objects) and an Alert Trap group
(notification) to the Counter MIB and a Counter events class to the WIMS
Events schema.
A monitor application that registers for 'icAlertV2Trap' notifications
can effectively use the Counter MIB stand-alone, typically without data
from any other MIB.
Comments?
Cheers,
- Ira
Ira McDonald (Musician / Software Architect)
Blue Roof Music / High North Inc
PO Box 221 Grand Marais, MI 49839
phone: +1-906-494-2434
email: imcdonald@sharplabs.com
----------------------------------------
IcCounterEventTypeTC ::= TEXTUAL-CONVENTION
STATUS current
DESCRIPTION
"The type of counter event in this 'icAlertTable' entry."
REFERENCE
"prtAlertCode in Printer MIB (RFC 1759/3805).
PrtAlertCodeTC in IANA Printer MIB (RFC 3805
and http://www.iana.org/assignments/ianaprinter-mib)."
SYNTAX INTEGER {
other(1), -- non-standard type
unknown(2), -- unknown type
counterCreated(3) -- counter created
-- any counter element
counterErrors(4), -- counter errors
-- icTimeDownSeconds
-- icMonitorCriticalAlerts
-- icMonitorAbortedJobs
-- icMonitorMemoryAllocErrors
-- see prtAlertCriticalEvents in Printer MIB v2 (RFC 3805)
-- icMonitorStorageAllocErrors
counterReset(5), -- counter reset
-- any counter element
counterWarnings(6), -- counter warning
-- icTimeMaintenanceSeconds
-- icMonitorTotalAlerts (for warning alerts)
-- see prtAlertAllEvents in Printer MIB v2 (RFC 3805)
-- icMonitorCanceledJobs
-- icMonitorMemoryAllocWarnings
-- icMonitorStorageAllocWarnings
counterWrap(7) -- counter wrap (to zero)
-- any counter element
}
-- -- Alert Group (Optional) --IcAlertEntry ::= SEQUENCE { -- alert index elements icAlertKeyIndex Integer32, icAlertCycleType IcCycleTypeTC, icAlertWorkType IcWorkTypeTC, icAlertIndex Integer32,
-- alert description elements icAlertCounterEventType IcCounterEventTypeTC, icAlertCounterName DisplayString, icAlertCounterValue Integer32, icAlertDateAndTime DateAndTime, icAlertTime TimeTicks }
-- -- Alert Trap Group (Optional) --
icAlertV1Prefix OBJECT-IDENTITY STATUS current DESCRIPTION "The value of the enterprise-specific OID in an SNMPv1 trap sent signaling a counter event in the prtAlertTable." ::= { icAlertTrap 1 }
icAlertV2Prefix OBJECT IDENTIFIER ::= { icAlertV1Prefix 0 }
icAlertV2Trap NOTIFICATION-TYPE OBJECTS { icAlertCounterEventType, icAlertCounterName, icAlertCounterValue, icAlertDateAndTime } STATUS current DESCRIPTION "This trap is sent whenever a counter event is added to the icAlertTable.
Note: The values of the icAlertKeyIndex, icAlertCyclceType, icAlertWorkType, and icAlertIndex objects are included in the instance qualifiers of the explicit variable bindings in this trap. The value of icAlertTime (i.e., sysUpTime in IETF MIB-II, RFC 1213) is always included in SNMP traps, per RFC 3416." ::= { icAlertV2Prefix 1 }
-- Note that the SNMPv2 to SNMPv1 translation rules dictate that -- the preceding statement will result in SNMPv1 traps of the -- following form: -- -- icAlertV1Trap TRAP-TYPE -- ENTERPRISE icAlertV1Prefix -- VARIABLES { icAlertCounterEventType, icAlertCounterName, -- icAlertCounterValue, icAlertDateAndTime } -- DESCRIPTION -- "This trap is sent whenever a counter event is added -- to the icAlertTable." -- ::= 1
This archive was generated by hypermail 2b29 : Wed Jan 26 2005 - 01:02:15 EST