Overview of ONTAP Logs

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/

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

AutoSupport

• 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.