ZENOSS-MIB

Description: Defines Zenoss enterprise monitoring platform trap definitions and event notification objects.

Start monitoring vendor-neutral, standards-based MIB, any SNMPv3-capable network device (SNMP engine identity/boot/clock status) with a free 30-day trial of IPNetwork Monitor. Import MIBs, browse SNMP OIDs, create custom SNMP monitors, configure alerts, and monitor any SNMP-enabled network device from a single console.

This MIB belongs to Zenoss, an open-source/commercial IT infrastructure monitoring platform, and it defines the structure of SNMP traps that Zenoss itself emits when it detects and processes events, rather than modeling a monitored device's own hardware. Its objects represent Zenoss's internal event model — event ID, deduplication ID, source device and component, event class, severity, state, and state-change time — carried inside notification PDUs sent to downstream NOC/alerting systems. Because Zenoss aggregates status from many other devices and MIBs, this MIB's practical monitoring use is at the meta-level: it lets a receiving management station correlate incoming Zenoss traps (severity, source device/component, class) back to whatever underlying hardware or software issue, such as an uptime loss, threshold breach, or service failure, triggered the original Zenoss event. It has an inherent dependency on whatever device-specific MIBs Zenoss itself polled to generate the event, since evtDevice/evtComponent/evtClass reference those upstream monitored elements. It is deployed wherever Zenoss Core/Enterprise serves as a central monitoring platform forwarding alerts via SNMP traps to a separate trap receiver or NMS. Engineers can download the ZENOSS-MIB file directly to load it into their MIB browser.

A downstream trap receiver parses an incoming zenTrapDef notification and extracts evtSeverity, evtDevice, evtComponent, and evtSummary to determine which monitored device and component triggered the alert and how critical it is. Tracking evtStateChange alongside evtState lets an operator tell whether an event is new, acknowledged, or cleared, while evtDedupid is used to suppress duplicate notifications for the same recurring condition. The evtClassKey and evtGroup fields help route the trap to the correct escalation policy in the receiving alert-management tool.

Defines trap structure for event notification system in Zenoss monitoring platforms with device and severity fields.