NetApp ONTAP Event Log: EMS Show and Filter Commands

When something goes wrong on a NetApp ONTAP cluster, the Event Management System (EMS) log is the first place to look - it records every significant event with a severity level, the node it happened on, and a message name. The challenge is volume: a busy cluster generates thousands of events, and most of them are informational. This guide shows how to use event log show with its filter parameters - event name, severity, message name, time range and node - so you can isolate the events that matter instead of paging through the whole log.

Everything below runs from the ONTAP CLI on any admin-level or cluster-level account, works identically on ONTAP 9.x and on Cloud Volumes ONTAP / FSx for ONTAP, and needs no diagnostic privilege except where noted.

What EMS Records and Why Volume Is the Problem

EMS is the cluster-wide event bus. Subsystems - the aggregate and volume layer, the network stack, the SAN stack, the HA and takeover layer, SnapMirror, AutoSupport - publish events with a message name in the form component.event, a severity, and a set of parameters. Each event also carries a timestamp, the node it was raised on, and a sequence number, and the log is replicated across all nodes in the cluster, so any node shows the whole cluster's history.

Two consequences follow from that design. First, event log show on one node is not a partial view - you do not need to log into every node to see every event, though you can filter by node when you want to. Second, the sheer density of events means an unfiltered listing is useless during an incident: a single volume near-full condition can generate dozens of related messages within minutes. The value of the command is entirely in its filters, and the sections below build them up in the order you would use them while troubleshooting.

The event log show Command

Run without parameters, the command displays EMERGENCY, ALERT and ERROR events, most recent first:

cluster1::> event log show
Time                Node             Severity      Event
------------------- ---------------- ------------- ------------------------
11/9/2015 13:54:19  node1            NOTICE        vifmgr.portup: A link up event...

Use the -severity parameter to include less severe events, and -detail for the full message with remediation action fields.

The default window is usually enough to answer "what just broke", and the -detail flag is what turns the one-line summary into something actionable - it prints the event description, the corrective action, and the parameter values (volume name, aggregate, LIF, and so on) that the message carries.

Filtering by Event or Message Name

Event names follow the pattern component.event. Search with wildcards - the search is case-sensitive:

cluster1::> event log show -event *disk*
cluster1::> event log show -event *"Completed block"*
cluster1::> event log show -message-name *reboot*

The -message-name filter is especially useful for finding node reboots, failovers and scheduled maintenance events (for example vsa.scheduledEvent.scheduled on CVO systems).

Wildcards work at both ends of the string, and the quotes are what let a phrase containing spaces match as one literal. If you know the exact event, pass it without wildcards - event log show -message-name monitor.volume.nearlyFull - so the output does not pick up loosely related names. Both filters accept multiple values in one call, separated by a comma, which lets you hunt two or three known-bad events in a single pass instead of three separate invocations.

Filtering by Severity

Severity levels run from EMERGENCY down through ALERT, CRITICAL, ERROR, WARNING, NOTICE, INFORMATIONAL and DEBUG. To see everything at warning level or worse:

cluster1::> event log show -severity <=WARNING

To see only NOTICE-level messages that mention reboot:

cluster1::> event log show -severity NOTICE -message-name *reboot*

The comparison operators are the part people miss. -severity WARNING returns exactly the warning-level events; -severity <=WARNING returns warning and everything more severe, which is what you want when scanning for anything that could have affected service. An exact-level query is the tool for a targeted question - "were there any warnings on this node last night" - while the range form is the tool for a first look at a cluster you do not yet know.

Filtering by Time

Time filters accept absolute values (MM/DD/YYYY HH:MM:SS), ranges and relative values based on "now":

cluster1::> event log show -time >=5m          <!-- last 5 minutes -->
cluster1::> event log show -time >=5h          <!-- last 5 hours -->
cluster1::> event log show -time <1h           <!-- more than one hour ago -->
cluster1::> event log show -time >=3/4/2026 16:25:00
cluster1::> event log show -time "3/4/2026 16:25:00".."3/4/2026 16:35:00"

Time is the filter that makes everything else usable during an incident, because it frames the question: what happened between the change window and the first alert? The relative forms (5m, 5h, 2d) are the fastest way to check whether an event you just saw repeated earlier, and the absolute range form is what you use to reconstruct a failure from a change ticket. ONTAP interprets the timestamps as cluster time, so when comparing against a syslog or monitoring alert, convert your timestamps rather than trusting the difference blindly.

Filtering by Node and SVM

On a multi-node cluster the node filter is often the difference between a 20-line answer and a 2,000-line one:

cluster1::> event log show -node node1
cluster1::> event log show -node node1,node2 -severity <=ERROR
cluster1::> event log show -vserver svm_data -time >=1d

-node accepts one node, a comma-separated list, or a wildcard such as node*. The -vserver filter narrows the view to events attributed to one SVM, which is how you investigate a single tenant or a single NAS namespace without reading unrelated events from the rest of the cluster. Storage-administrator accounts see only the SVMs they are allowed to read, so the vserver filter also mirrors what each team can actually query.

Controlling Output Size, Fields and Order

During a busy change window the raw output can scroll off the screen before you read it. Two parameters fix that:

cluster1::> event log show -severity <=ERROR -fields time,node,severity,event
cluster1::> event log show -fields time,node,severity -max-records 50
cluster1::> event log show -time >=30m -max-records 200 -severity <=NOTICE

-fields trims each record to the columns you asked for - handy when you want to paste a compact list into a ticket - and -max-records caps the number of lines returned so a query cannot flood an SSH session. Without a cap the default behaviour is to return everything matching, oldest first after the most-recent-first default ordering; when the answer is "give me the last 50 events per node" a combination of -time and -max-records gets you there without counting lines by hand.

Understanding What an Event Means

Each event has a catalog entry explaining why it was raised and what to do. Look up events with:

cluster1::> event catalog show -event-name <name>

The event's "action" field describes the remedy. Events are also shipped in AutoSupport reports, so Active IQ / NetApp Console history is a second source when local logs have rotated.

Read the catalog entry before acting. Many NOTICE and INFORMATIONAL events - scheduled SnapMirror updates, a link that came back within seconds, a volume that crossed the snapshot reserve threshold and then dropped below it - are descriptions of normal behaviour, and the catalog entry is where ONTAP tells you whether a response is required. The event catalog show output also names the component that raised the event, which tells you which subsystem's documentation is worth opening.

Suppressing Known-Benign Events

On a large cluster a handful of legitimate but noisy events can bury the important ones in a syslog pipeline. EMS supports filters and destination routes to handle that:

cluster1::> event filter show
cluster1::> event filter create -filter-name quiet-vif
cluster1::> event filter rule add -filter-name quiet-vif -type exclude -message-name vifmgr.portup -severity NOTICE
cluster1::> event route show

Filter rules are include/exclude rules applied in order, and the resulting filter can be attached to a notification destination so that the exclusion affects only what leaves the cluster - the local EMS log still records everything, which is exactly what you want when the noise is a monitoring problem rather than a logging problem. Suppress deliberately and document it: suppressing an event class that later turns out to be a symptom is how a real incident gets missed.

Forwarding EMS Events to Syslog

For real-time monitoring, forward EMS events to an external syslog server. ONTAP events follow the syslog standard:

cluster1::> event notification destination create -name SYSLOG1 -destination syslog://10.10.10.10:514
cluster1::> event notification create -name TO-SYSLOG -destination SYSLOG1 -severity warning

Inspect the current EMS configuration (log rotation, filters) with event config show and event filter show. With the diagnostic privilege set you can adjust EMS log rotation size when you need to retain more history locally.

cluster1::> event notification destination show
cluster1::> event notification show
cluster1::> event config show
cluster1::> set diag

Test the path after you build it: generate a harmless event or check the syslog server's receiver for the cluster's source IP. A destination that was created but never verified is a common reason a monitoring rule looks configured yet has never fired.

Local Retention and Log Rotation

ONTAP keeps EMS logs per node in the etc/log area of the node's root volume and rotates them, so the amount of history available locally depends on how much the node writes and how large the rotation files are allowed to grow. When an investigation reaches further back than what event log show can answer:

cluster1::> event log show -time >=7d -severity <=ERROR

If the logs on disk no longer cover the window you need, the historical copy exists in AutoSupport envelopes. Increasing the rotation size with the diagnostic commands buys local history at the cost of space in the root volume, which is rarely a good trade on a busy cluster - ship the events to a log server instead and keep the local window at its default.

Checking Notification and AutoSupport Delivery

EMS events are also what drives AutoSupport and call-home messages, so "did the cluster tell anyone?" is an EMS question as much as an email question:

cluster1::> autosupport check show
cluster1::> autosupport history show -node node1 -count 10
cluster1::> system node autosupport invoke -node * -type all
cluster1::> system node autosupport show -fields state

If the autosupport history show output shows transmissions failing with a name-resolution or proxy error, the corresponding EMS events will be sitting in the log as well - and fixing the delivery problem is what restores the weekly reporting that NetApp support relies on during a case.

Practical Troubleshooting Patterns

• Unexpected node reboot or takeover. event log show -message-name *reboot* -time >=1d -detail then event log show -message-name *takeover* -severity <=ERROR. The pair normally tells you whether the node panicked, was reset by its partner, or rebooted for maintenance.
• Volume filling up. event log show -message-name *nearlyFull* -max-records 20 shows the thresholds crossed and by which volumes; correlate with snapshot counts and the snapshot policy rather than deleting data blindly.
• Intermittent NAS or SAN connectivity. event log show -severity <=ERROR -time >=2h -fields time,node,event plus -event *lif* and -event *vifmgr* isolates link and failover churn from an application-side issue.
• After an ONTAP upgrade. event log show -time >=1d -severity <=WARNING -detail confirms whether post-upgrade remediation tasks (LIF migration, aggregate relocation) completed or left errors behind.
• Reconstructing a change window. Use the absolute range form with the fields list and export the result: a timestamped, filtered event list is the most convincing artefact to attach to a change record or a TAC case.

Related reading: NetApp ONTAP CLI cheat sheet and NetApp ONTAP network troubleshooting CLI commands. For the wider storage context, see creating SVMs and data LIFs from the CLI and the snapshot policy and schedule setup.

Original article: NetApp: event log show (ONTAP CLI reference) | NetApp KB: How to search the event (EMS) log in ONTAP