Messages produced by the LocalDirector that usually go to the console can be collected by sending these messages to a device running a syslogd daemon (syslogd). Syslogd listens on UDP port 514, the syslog port. Syslogging enables you to gain information about LocalDirector traffic and performance, analyze logs for suspicious activity, and troubleshoot problems.
Syslogd can run on a number of operating system platforms. Syslogd is installed when you install UNIX, however, you must configure it. Syslogd is not usually native to Windows-based systems, however, syslogd software is available for Windows NT.
This document describes how syslog works, how to set up the LocalDirector to send syslog messages to a device running syslogd, and how to set up a UNIX-based syslogd server.
The actual meanings of LocalDirector syslog messages can be found in the LocalDirector documentation. For example, for LocalDirector syslog messages for version 4.2, refer to Syslog Messages.
For more information on document conventions, see the Cisco Technical Tips Conventions.
There are no specific prerequisites for this document.
The information in this document is based on the software and hardware versions below.
The information presented in this document was created from devices in a specific lab environment. All of the devices used in this document started with a cleared (default) configuration. If you are working in a live network, ensure that you understand the potential impact of any command before using it.
In this section, you are presented with the information to configure the features described in this document.
All syslog messages have a logging facility and a level. The logging facility can be thought of as where, and the level can be thought of as what.
The single syslog daemon (syslogd) can be thought of as having multiple pipes. It uses the pipes to decide where to send incoming information based on the pipe on which the information arrives. In this analogy, the logging facilities are the pipes by which the syslogd decides where to send information it receives.
The eight logging facilities commonly used for syslog are local0 through local7, as shown below.
There are also different degrees of importance attached to incoming messages. Think of the levels as what. The LocalDirector can be set to send messages at the following different levels (these are listed from highest to lowest importance):
|| Numeric Code
When a LocalDirector is set up to send syslog messages, levels of lower importance include levels of higher importance. For example, if the LocalDirector is set for warning, error, critical, alert, and emergency messages would also be sent in addition to the warning. A debug setting would obviously include messages at all 8 levels.
The syslog syntax is as follows:
syslog host #.#.#.#
!--- #.#.#.# is the syslog servers address.
syslog output X.Y
!--- X is the logging facility and Y is the level.
How does the X number translate to logging facility?
The X number translates to a logging facility when converted to binary. The last bits bits comprise the local facility, as shown below.
16 = 00010000 = local0
17 = 00010001 = local1
18 = 00010010 = local2
19 = 00010011 = local3
20 = 00010100 = local4
21 = 00010101 = local5
22 = 00010110 = local6
23 = 00010111 = local7
For example, since 22 = 00010110, and the last 4 bits=0110=decimal 6, this is local6. A short-cut is to take the X value and subtract 16. For example, 22-16=6, or local6. On LocalDirector, the default facility is local4.
The Y number is the level. For example, if Y=2, messages sent would include those at level 2 (critical), level 1 (alert), and level 0 (emergency). The LocalDirector levels are 0-7; these should not be confused with the logging facilities, which are local0-local7. On LocalDirector, the default level is 3 (error). Two examples are shown below.
!--- 20 equals local4 logging facility. !--- .7 is the level. 7 means debug to the LocalDirector, that is, !--- all messages will be logged.
!--- 23 equals local7 logging facility !--- .2 is the level. 2 means critical to the LocalDirector, that is, !--- critical, alert, and emergency messages will be logged.
You can view the current facility.level and syslog server settings on LocaLDirector by issuing the show syslog command.
Because syslogd was originally a UNIX concept, the features available in the syslogd products on non-UNIX systems depend on the vendor implementation. Features may include dividing incoming messages by facility or debug level, or both, resolving the names of the sending devices, reporting facilities, and so on. For information on configuring the non-UNIX syslog server, refer to the vendor's documentation.
To configure syslog on UNIX, perform the following steps:
As root, on SunOS, AIX, HPUX, or Solaris, backup the /etc/syslog.conf file prior to modification.
Modify /etc/syslog.conf to tell the UNIX system how to sort out the syslog messages coming in from the sending devices, that is, which logging_facility.level goes in which file. Make sure that there is a tab between the logging_facility.level and file_name.
Make sure the destination file exists and is writable.
The #Comment section at the beginning of syslog.conf usually explains syntax for the UNIX system. Alternatively, you can read the man page of syslogd with man syslogd .
Do not put file information in the ifdef section.
As root, restart syslogd to pick up the changes.
If /etc/syslog.conf is set for local7.warn /var/log/local7.warn:
The warning, error, critical, alert, and emergency messages coming in on the local7 logging facility will be logged in the local7.warn file. The notification, informational, and debug messages coming in on the local7 facility will not be logged anywhere.
If /etc/syslog.conf is set for local7.debug /var/log/local7.debug:
The debug, informational, notification, warning, error, critical, alert, and emergency messages coming in on the local7 logging facility will be logged to the local7.debug file.
If /etc/syslog.conf is set for local7.warn /var/log/local7.warn or local7.debug /var/log/local7.debug:
The warning, error, critical, alert, and emergency messages coming in on the local7 logging facility will be logged to the local7.warn file. The debug, informational, notification, warning, error, critical, alert, and emergency messages coming in on the local7 logging facility will be logged to the local7.debug file (some messages will go to both files).
If /etc/syslog.conf is set for *.debug /var/log/all.debug:
All message levels from all logging facilities will go to this file.
Before issuing any debug commands, please see Important Information on Debug Commands.
To start syslog in debug (SunOS, AIX, HPUX, or Solaris), you must be root:
ps -ef | grep syslogd
kill -9 <pid>
You should see the following messages at the beginning, as syslogd is reading syslog.conf:
X X X X X X X X X X X X X X X X X X X X X X X 6 X FILE:
X X X X X X X X X X X X X X X X X X X X X X X 7 X FILE:
If these scroll by too quickly, issue the following command:
syslogd -d | more
If you see the following messages:
syslogd: /var/log/local7.junk: No such file or directory
logmsg: pri 53, flags 8, from pinecone, msg syslogd: /var/log/local7.junk:
No such file or directory
There is a problem in the setup. In the above example, the file did not exist. Running a debug will also show incoming syslog messages and to which file they are going.
logmsg: pri 275, flags 0, from 10.8.1.76, MSG 14: %SYS-5-CONFIG_I:
from console by vty0 (18.104.22.168)
Logging to UNUSED
Logging to FILE /var/log/local7.debug
In this case, a message that should have gone to local7.junk and local7.debug was received. Because local7.junk did not exist, the following message is also received:
Logging to UNUSED.
If syslogd -d shows that no messages are coming in, check to make sure that the show syslog command has been issued on LocalDirector. If syslogd information is arriving on the UNIX system, but not going into the proper file, work with the UNIX system administrator or operating system vendor support to correct the problem. If the cause of the problem still cannot be determined, syslog may be run in debug and the output redirected to a file as follows:
sh or ksh:
syslogd -d > <target_file> 2>&1
syslogd -d >& <target_file>
Note: Red Hat Linux syslogd must be started with the -r option to capture network output.
| UNIX Extension
|| System unusable, emergencies.
|| Take immediate action, alerts.
|| Critical condition, critical.
|| Error message, errors.
|| Warning message, warnings.
|| Normal but significant condition, notifications.
|| Informational messages, informational.
|| Debug message, debugging.
There is currently no verification procedure available for this configuration.
There is currently no specific troubleshooting information available for this configuration.