Platform Event Trap: The Alarm a Server Sends About Itself

A platform event trap, almost always shortened to PET, is an alert message that a server sends about its own body. A fan slows down, a power supply gives up, a processor runs hot: the moment a hardware sensor crosses a line, the server’s management controller packages the event and fires this trap across the network to the monitoring station you named in advance. Nothing in that path needs the operating system, which may be off, crashed, or not yet installed.

The format has two parents. The Intelligent Platform Management Interface, IPMI for short, created the platform event trap as the open alert format for server hardware, and the Distributed Management Task Force, the DMTF, wrote it into the Alert Standard Format, ASF for short, in its specification DSP0136. Oracle’s ILOM documentation sums up the senders neatly: PET events come from systems with ASF or an IPMI baseboard management controller, and they provide advance warning of possible system failures. Advance warning is the right phrase. A trap rarely announces a death. It announces the cough before it.

First, the platform event

Before the trap, there is the event. A platform event is any change in the physical state of the machine that its sensors can see, and the list stays short and concrete: heat, moving air, electricity, physical access. Temperature sensors watch processors and the air entering the case. Fan sensors report speed. Voltage sensors watch the power rails on the board. Other sensors report a power supply that failed or came back, a part that was inserted or removed, and a chassis cover that someone opened.

Each sensor guards a threshold, a number set by the maker or by you. Cross the number and the sensor asserts its event. Fall back inside the line and the event de-asserts. That is why a monitoring screen shows pairs: trouble started, trouble cleared. A processor that asserts a heat warning during one heavy job and clears a minute later is noise. A fan that asserts and stays asserted is a part asking to be replaced before it stops for good.

Oracle’s ILOM tables show what these events look like in a real log: a temperature sensor assert marked critical, with a hot CPU as the likely cause, an entity presence event when a blade or a power supply is inserted or removed, and power state events as the machine moves between off, sleep and working states. Plain, physical, and hard to argue with.

How a platform event trap travels

The controller does not wait to be polled. The moment an event asserts, it builds the trap and sends it to every destination address on its list. The packet is an SNMP trap, the oldest alert format in network management, addressed to UDP port 162 on the receiving machine. Because plain UDP never promises delivery, the ASF specification adds a belt to the braces: the sender transmits each platform event trap three times inside a one-minute window, and every copy carries the same sequence number, so the receiver can spot the repeats and ignore them.

The receiving side has one job to finish before any hardware fails: exist. A trap sent to an address where nothing listens is gone, apart from its copy in the controller’s own event log. That is why the destination list and the test button matter more than any clever filtering you bolt on later.

One honest limit matters here. Dell’s iDRAC7 manual notes that on older Dell controllers these IPMI alerts were confined to events from IPMI sensors, and did not include events from subsystems such as storage or memory. The trap covers the platform layer: power, cooling, and the board itself. Richer news about disks and memory arrives through the controller’s newer SNMP alerts or its event log, a point the tools section returns to.

Setting up trap destinations

Setup lives in the controller, not in the operating system you are watching. Dell’s iDRAC9 guide walks through the pattern every vendor follows, so it makes a fair checklist:

• Open the controller’s web interface and switch alerts on.
• Set the event filters: which categories, and which severities, should send a trap at all.
• Add the destination addresses. iDRAC accepts up to eight, as IPv4, IPv6, or host names.
• Match the community string on both ends. The Dell default is Public, and the alert port is normally 162.
• Send the built-in test trap. iDRAC offers a Test IPMI Trap button for exactly this, and the setup is not done until the receiver logs the test.

Two details from the same Dell material save confusion later. The SNMP trap format setting, which picks SNMP v1, v2, or v3, does not apply to IPMI traps: Dell states they always go out in SNMP v1 format. The filter screen names the usual categories, system health, storage, configuration, audit and updates, each split by warning and critical. And record what you configured, with the date and the reason, in the same place your team tracks every other infrastructure change. Our guide to version control systems explains why that written record pays off the first time a setting is questioned.

What the trap carries

A platform event trap is small, fixed, and specific, which is exactly why machines can read it without help. The ASF specification lists the variable bindings, the named fields inside the packet. Four identify the report itself. The GUID names the exact machine that sent it, taken from the system’s SMBIOS data, the built-in description of the hardware. The sequence number counts the traps, so gaps and repeats show. A local timestamp records when the event happened by the machine’s own clock, and a UTC offset states how far that clock sits from world time, so a receiver in another zone can line the event up correctly.

The remaining fields describe the event. A severity field sorts the report into monitor, non-critical, or critical condition. The sensor device and sensor number say which sensor raised it. An entity field names the part involved, usually a field replaceable unit such as the processor or a power supply, and event data bytes pin down what changed. The trap header adds one more fact for free: it follows the SNMPv1 format from RFC 1157, whose agent address field carries the address of the station that caused the event. Nothing in the packet is prose. That is a strength at 3 a.m. and a weakness at 9, because a raw trap on a screen is a string of numbers until software translates it.

What monitors platform event traps best

The honest answer is that the best receiver depends on how many servers you run. For one machine or a handful, the controller itself is the monitor. Dell iDRAC, Oracle ILOM, HPE iLO and their peers keep a system event log you can read in the web console, and they can turn the same events into email alerts. For a room full of one brand, the vendor’s fleet console earns its place: Dell states that SNMP is the only alert type OpenManage Enterprise accepts, which makes it the natural collection point for racks of Dell servers.

Mixed estates usually hand the job to a general monitoring platform, and Zabbix shows the standard moving parts. A small daemon called snmptrapd listens on port 162. A receiver script, or the translator SNMPTT, writes each trap to a file. Zabbix then reads the file, matches the trap to a host by the address it came from, and files it under SNMP trap items you define, with a fallback item to catch the rest. Zabbix also advises loading MIB files, the dictionaries that turn trap codes into readable names. Nagios teams follow the same shape, with SNMPTT translating raw traps into text Nagios can check. Before any of it goes live, prove the path in a throwaway setup: our explainer on what a sandbox environment is shows how to test alerting without touching production.

Two connections are worth making once the traps land. First, feed them into the same event pipeline as the rest of your tooling, so a hardware alert can sit next to the application alerts it may explain; our enterprise application integration guide covers how estates join systems like these together. Second, remember the layers. A trap receiver watches the metal. The layers above it, from the network to the application delivery features in F5’s application acceleration manager, belong to other tools, and a complete monitoring setup names an owner for each layer.

One more honest point on the best question: the tool matters less than the match. A trap that lands on the wrong host record, or in a fallback bucket nobody reads, may as well not have been sent. The best setup is the one whose host list and alert rules your team actually maintains.

PET, plain SNMP traps, and the Redfish successor

A platform event trap is an SNMP trap, but a very specific one. A normal vendor trap is a blank form: each maker defines its own traps in its own MIB files, so content and meaning change from product to product. The PET format fixes the form in the specification instead, which is why a receiver written years ago still reads a new server’s traps today. The trade is scope. Vendor traps can report almost anything, including storage and software agents. PET reports sensors, in the same words, forever.

The successor is already in the room. Redfish, the DMTF’s modern management standard, delivers simple and secure management over ordinary web technology, and it includes an event service: instead of a coded trap, the controller pushes a structured event record to destinations you subscribe, over encrypted HTTPS. Dell’s own alert menu shows the changing of the guard, listing Redfish events as one alert option beside SNMP traps, email, and remote syslog. Redfish records carry more context and travel more safely. Traps still win on reach: they work on old hardware, on controllers without the Redfish service running, and in the minutes when everything else about the server has failed.

Conclusion

A platform event trap is the server’s oldest and plainest distress call: a small, fixed SNMP message that the hardware controller sends when a sensor reports trouble, defined by the IPMI work and the DMTF’s Alert Standard Format, and repeated three times so the network cannot easily lose it. Set the destinations with care, prove the path with the test trap, and give the traps a receiver that translates them into words your team can act on. Newer Redfish events will keep taking over the top of the stack. At the bottom, where the fans and power supplies live, the trap still earns its keep.