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 at sharplabs.com>
Sent by: owner-wims at pwg.org
01/25/2005 07:56 PM
To
"'wims at pwg.org'" <wims at 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 at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.pwg.org/archives/wims/attachments/20050125/fb0d1916/attachment-0001.html