- ONTAP 9
- Clustered Data ONTAP 8
- Data ONTAP 7-Mode
- This article contains a list of common Syslog operational and troubleshooting workflows.
- However, it is not a comprehensive list.
- This can be used to narrow your search to the more commonly utilized troubleshooting KBs, broken down to a specific category.
- EMS events follow the syslog standard because they have the ability to be forwarded to a syslog server for real-time monitoring.
- Logs are event-triggered messages ranging in severity that are generated by the clustered Data 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.
- This article will discuss Syslog.
- Syslog is a defined standard for computer message logging.
- The standard is defined by the IETF in RFC 5424. Syslog defines how software formats and sends its messages so that administrators can properly monitor the software’s behavior and utilize tools that can receive and analyze the sent messages.
- Because this standard is universally recognized, administrators can monitor all assets that support syslog forwarding in real-time.
- Syslog messages are labeled with a facility code indicating the process or application that generated the message and assigned a severity.
How to configure Syslog forwarding
- Syslog Express Guides (9, 8.3)
- Syslog Management Guide ( 9, 8.3, 8.2 7-Mode)
- For additional in-depth configuration details, refer to Technical Guide - Logging in Clustered Data ONTAP
- Currently, only EMS events can be forwarded to a syslog server.
- In Data ONTAP 7-Mode, The syslogd daemon logs system messages to the console, log files and other remote systems as specified by its configuration file, /etc/syslog.conf.
- The syslogd daemon reads its configuration file when it starts up during the boot procedure, or within 30 seconds after the /etc/syslog.conf file is modified.
- For information about the format of the configuration file, see na_syslog.conf(5).
- Example of a configuration file in 7-Mode
# Log all kernel messages, and anything of level err or
# higher to the console.
# Log anything of level info or higher to /etc/messages.
# Also log the messages that go to the console to a remote
# loghost system called adminhost.
# Also log the messages that go to the console to the local7
# facility of another remote loghost system called adminhost2
# at level info.
# The /etc/secure.message file has restricted access.
Clustered Data ONTAP
- In clustered Data ONTAP, the /etc/syslog.conf file has been deprecated.
- Thus, what goes to the remote syslog host is controlled by the settings.
- Syslog can setup using the event route and event destination commands.
Changes in ONTAP 9.x to EMS configuration and the Event notification system
- EMS operations have been redesigned for ONTAP 9.0.
- The ‘event route’ and ‘event destination’ command family has been DEPRECATED in 9.0.
- Notifications are now setup using the event notification commands
After upgrading to ONTAP 9.0, use the EMS Configuration Express Guide to re-configure EMS notifications.
- To remove your current configuration, do the following:
::>event route remove-destinations -message-name !callhome.* -destinations *
::>event route modify -message-name callhome.* -destinations asup
The Syslog translator helps you understand or diagnose NetApp system error messages that appear on the console and the /etc/messages file.
The specific failure symptom can vary depending on your configuration and version of Data ONTAP
/etc/messagesor to the console.
- When troubleshooting Syslog related problems, the most common issues point to:
- Configuration issues
- Connectivity to the syslog server
- For configuration issues:
- Review the setup guides and related Articles for additional assistance
- For connectivity testing:
- If you are having issues not receiving messages on your Syslog server, then you can use a free packet capture program such as Wireshark.
- This program provides the ability to capture packets as they are sent to your Network Interface Card (NIC). By filtering for and analyzing this traffic, you will be able to determine if your network devices are actually sending the expected information to your system
- Download and install the program from Wireshark .
- Use the Capture menu to open the Capture Options form.
- Select your NIC and define a capture filter that will look for all packets sent to UDP port 514 (the default syslog port).
- Press the Start button and you should see packets being sent.
- Stop the capture and view the data. It should show packets with the protocol being Syslog.
- If you are not receiving any messages use the ping and traceroute commands to check connectivity to your syslog server.
- In 9.x you may run the following commands to verify if the EMS message was created and also verify connectivity to the syslog server.
::>event notification destination check
::>event notification history show
- event notification destination check command checks connectivity to a destination by sending a test message to it.
- The destination must be already configured by using the event notification destination command.
- The command displays a result indicating whether or not the message has successfully been sent to the destination.
- In case of a failure, more detailed information is found in the notifyd.log file.
- Note: Currently this command can only check connectivity to a destination of the rest-api type.
- event notification history show command displays a list of event messages that have been sent to a notification destination.
- The information displayed by the command for each event is identical to that of the event log show command.
- This command displays events sent to a notification destination while the event log show command displays all events that have been logged.
Syslog messages will choose the source interface based upon routing rules