Skip to main content
NetApp Knowledge Base

Overview of ONTAP Logs

Last Updated:

Applies to

  • ONTAP 9
  • Log path and Log files


Logging in ONTAP

  • Logs are event-triggered messages ranging in severity that are generated by the ONTAP operating system and recorded in flat text files on the cluster.
  • Logs are the primary resource for administrators, NetApp Support, and AutoSupport™ systems to determine and isolate root causes for a wide range of issues.
  • Logs can be collected, viewed, and forwarded using several different methods. 
  • All logs are stored in /mroot/etc/log and /mroot/etc/log/mlog, including EMS, audit logs, and user space application logs.  The paths cannot be changed.
  • Logs in /mroot/etc/log rotate once per week, with a maximum of five rotations before the oldest log is deleted. 
  • Logs in /mroot/etc/log/mlog rotate once per day, with a maximum of 35 rotations before the oldest log is deleted.
  • Access a node’s log, core dump, and MIB files by using a web browser
Event Management System (EMS)
  • The event management system (EMS) is the ONTAP messaging facility built on the syslog standard.
  • EMS simplifies the management of cluster wide events and how the administrator chooses to be notified.
  • EMS provides a cataloged logging mechanism, and every event has a formal definition.
  • This allows EMS to provide services such as automatic spam management (such as message suppression), configurable notifications, assistance with translating low-level data into understandable text, NVRAM backing of messages, and automatic tagging of messages.
  • EMS contains thousands of predefined messages that are triggered on the corresponding event.
  • The dot-separated, tree-style naming scheme of the messages provides significant accuracy pertaining to the messages’ origin and meaning.
  • The formal event definition describes the meaning of the event in the context of the cluster.
  • Each event contains a corrective action description, which can assist and accelerate the decisions the administrator needs to make in response to the event.
  • This standardization and accuracy also carry over to NetApp’s manageability tools, which utilize EMS data.
    • Note: EMS does not contain command history or administrative auditing.
  • EMS events are viewed at the command line with:

    cluster::> event log show
    Time                Node             Severity       Event
    ------------------- ---------------- ------------- ---------------------------
    3/18/2014 13:00:04  cluster-01       INFORMATIONAL kern.uptime.filer: 1:00pm up 20:17

Audit Logs
  • Audit logging is essential for the administrative security of the ONTAP system.
  • The audit log records the commands sent to the cluster, the user who is sending them, and the success or failure of the command.
  • This applies to command-line interface (CLI), Data ONTAP API (ONTAPI®) calls (such as commands from NetApp manageability tools), and HTTP requests.
  • In Data ONTAP 8.3 and earlier, the audit log is stored in /mroot/etc/log/mlog/command-history.log.
  • Command history can also be viewed in the MGWD log, located in /mroot/etc/log/mlog/mgwd.log
  • Beginning in ONTAP 9, the  command-history.log file is replaced by  audit.log, and the  mgwd.log file no longer contains audit information.
How ONTAP implements audit logging
  • Management activities recorded in the audit log are included in standard AutoSupport reports, and certain logging activities are included in EMS messages.
  • You can also forward the audit log to destinations that you specify, and you can display audit log files by using the CLI or a web browser.
  • ONTAP logs management activities that are performed on the cluster, for example, what request was issued, the user who triggered the request, the user's access method, and the time of the request.
  • The management activities can be one of the following types:
    • Set requests, which typically apply to non-display commands or operations
      • These requests are issued when you run a create, modify, or delete command, for instance.
      • Set requests are logged by default.
    • Get requests, which retrieve information and display it in the management interface
      • These requests are issued when you run a show command, for instance.
      • Get requests are not logged by default, but you can use the security audit modify command to control whether get requests sent from the ONTAP CLI (-cliget) or from the ONTAP APIs (-ontapiget) are logged in the file.
  • ONTAP records management activities in the  /mroot/etc/log/mlog/audit.log file of a node.
  • Commands from the three shells for CLI commands—the clustershell, the nodeshell, and the non-interactive systemshell (interactive systemshell commands are not logged)—as well as API commands are logged here.
  • Audit logs include timestamps to show whether all nodes in a cluster are time synchronized.
  • The  audit.log file is sent by the AutoSupport tool to the specified recipients. You can also forward the content securely to external destinations that you specify; for example, a Splunk or a syslog server.
  • The audit.log file is rotated daily. The rotation also occurs when it reaches 100 MB in size, and the previous 48 copies are preserved (with a maximum total of 49 files).
  • When the audit file performs its daily rotation, no EMS message is generated.
  • If the audit file rotates because its file size limit is exceeded, an EMS message is generated.
  • You can use the  security audit log show command to display audit entries for individual nodes or merged from multiple nodes in the cluster.
  • You can also display the content of the  /mroot/etc/log/mlog directory on a single node by using a web browser.
Other Logs
  • EMS events follow the syslog standard because they have the ability to be forwarded to a syslog server for real-time monitoring and because EMS events are the most relevant events to an administrator.
  • The rest of the logs generated by the ONTAP operating system are generated from user-space applications that are constantly logging their activity.
  • These logs are lower level and not targeted for administrators, but are mostly utilized by NetApp Support, development, and QA.

Table 1) Logs in /mroot/etc/log/

Log or directory



  • Sent to ASUP
  • Shelf Alternate Control Path Management (ACP) logs


  • Logs node shell commands (i.e., node run commands)
  • Equivalent is command-history.log in 8.3 and earlier.
  • Sent in Autosupport starting in clustered Data ONTAP 8.2.2



  • Log for NDMP backup procedures such as SMTape


  • Debug-level logs for the SAN kernel module


  • Logs LUN cloning

ems, ems.log

  • EMS events
  • Sent in Autosupport


  • Binary formatted file, used by NetApp Support in certain circumstances

leak_data, leak_data_filtered

  • Memory information, pertinent mostly for debugging purposes

messages, messages.log

  • Node level logs
  • Logs are links to /mroot/etc/log/mlog/messages.log


  • Contents of this directory are sent to ASUP
  • Contains management component application logs


  • Name service logs


  • SnapVault® logs


  • Logs absent FileIDs from the WAFL® playlist


  • Contains PLX PCI-E switch logs
  • Sent to ASUP starting in clustered Data ONTAP 8.2.1


  • Debug SAN trace logs


  • Service processor logs


  • Shelf logs

sis, sis.log

  •  Deduplication logs


  • System scratchpad RAM log


  • Performance-related logs

snapmirror.log, snapmirror_audit.log, snapmirror_error.log

  • SnapMirror® logs


  • Logs for the treecompare process that compare data integrities in volumes and/or qtrees using Snapshot® copies


  • Logs for the volread engine used by SnapMirror


Table 2) Logs in /mroot/etc/log/mlog/

Log or directory



  • Records history of log rotations


  • Logs history of access to the apache server
  • Contains history of GET requests for log files over HTTP(S)


  • Logs apache errors


  • Audit log for ONTAP 9.0 and later
  • Records commands from CLI, ONTAPI, HTTP
  • Always records set requests, but can toggle recording of get requests
  • Logs for the BCOM daemon, which handles SAN interaction between the management component and SCSI blade
  • Audit log for clustered Data ONTAP 8.3 and earlier
  • Records commands from CLI, ONTAPI, HTTP
  • Always records set requests, but can toggle recording of get requests


  • Logs at the DEBUG severity level


  • Logs for FPolicy®


  • Logs for the BranchCache hash daemon


  • Contains list of jobs that the job manager has restarted

memsnap-*.log (asterisk is a wildcard, because there are several types of memsnap logs)

  • Contains memory information


  • The messages log in ONTAP
  • Contains important logs throughout cluster
  • Some overlap with EMS, but no EMS features such as suppression


  • Contains logs from the management component
  • Records set requests by default, but can be toggled


  • Contains logs for the NDMP daemon


  • Contains logs for the NOTIFY daemon, which handles Autosupport (ASUP)


  • Contains logs for the PHP process
  • Contains history of syncing logs across nodes in the cluster


  • Contains logs for the Security daemon, which handles various authentication tasks, such as NAS authentication
    • Retains Max 10 copies


  • Contains logs on the service processor daemon


  • Debug-level logs for the main kernel
  •  Debug-level log for the main kernel


  • Contains logs related to abnormal events from the service processor


  • Contains logs on the service process manager daemon, which monitors user space applications to make sure they are healthy and running


  • Contains logs related to interfaces and networking


  • Contains logs on the volume location database application

Additional Information

::> set d
::*> event config show
                             Mail From:  admin@localhost
                           Mail Server:  localhost
                             Proxy URL:  -
                            Proxy User:  -
                           Suppression:  on
                               Console:  on
                   Max Target Log Size:  36700160
                      Max Filter Count:  50
                 Max Filter Rule Count:  128
                 Max Destination Count:  20
                Max Notification Count:  20
        Filter Exempt from Suppression:  no-info-debug-events
 Duplicate Suppression Duration (secs):  120
             Log Rotation Size (bytes):  40MB  <---- Default value
      REST API Delivery Timeout (secs):  60
  • The default value can be modified, if necessary. The maximum size is 100MB:

::*> set diag; event config modify -log-rotation-size 80MB

  • The storage period for logs displayed by the event log show command cannot be extended.
  • The AutoSupport (ASUP™) system is the Data ONTAP automated health-monitoring facility that enables error reporting and, in some instances, can generate a NetApp Support case.
  • Reporting might be triggered by an error condition using an EMS event or by schedule.
  • ASUP alerts can be sent to the administrator’s internal IT organization using e-mail and/or to NetApp Support for automated analysis.
  • The ASUP message contains important log data from EMS and other user space applications.
  • Exactly which logs ASUP collects is discussed in the next section.


NetApp provides no representations or warranties regarding the accuracy or reliability or serviceability of any information or recommendations provided in this publication or with respect to any results that may be obtained by the use of the information or observance of any recommendations provided herein. The information in this document is distributed AS IS and the use of this information or the implementation of any recommendations or techniques herein is a customer's responsibility and depends on the customer's ability to evaluate and integrate them into the customer's operational environment. This document and the information contained herein may be used solely in connection with the NetApp products discussed in this document.